INTRODUCTION

C S - 2 2 4 - F U N D A M E N TA L S O F D ATA B A S E S Y S T E M

Instructor: Tinsae D. (MSc.)

 INTRODUCTION TO DATABASE SYSTEMS

What Is a Database System?

 can be viewed as a “repository for data” or “a collection
of data.”
 Implicit properties:
 It represents aspects of a real world.
 It is collection of coherent (related) data.
 It is designed, built and populated to address a specific situation in
real world.

2
… INTRODUCTION TO DATABASE SYSTEMS
DBMS?
 DBMS is then a general-purpose software that facilities
the processes of
 Defining
 Constructing
 Manipulating, and
 Sharing database.

DBMS
Advantages Disadvantages
 Potential for enforcing standards  Complexity
 Reduced application development time  Size
 Flexibility  Cost of DBMSs
 Availability of up-to-date information  Additional hardware costs
 Economies of scale  Cost of conversion
 Performance
 Higher impact of a failure

3
 DATABASE ADMINISTRATORS
 is a person responsible for the management of
the data resource (which includes un-
computerized data) including database planning,
development and maintenance of standards,
policies and procedures, and conceptual/logical
database design
 Ensures that the direction of database
development will ultimately support corporate
objectives.

4
DATABASE ADMINISTRATORS
is responsible for the physical realization of the database, including physical
database design and implementation, security and integrity control.

Database Administration
 Evaluates new DBMSs
 Executes plans to achieve goals
 Enforces standards, policies, and procedures
 Implements data requirements
 Develops logical and physical database design
 Implements physical database design
 Monitors and controls database
 Technical orientation
 DBMS dependent

5
DATABASE DESIGNERS
There are two types of designers:- logical and physical database designers.
The logical database designer
concerned with identifying the data (i.e. the entities and attributes), the relationships
between the data, and the constraints on the data that is to be stored in the database
The Physical database designer:
 Decides how the logical database design is to be physically realized
This involves
 i. Mapping the logical database design into a set of tables and integrity constraints
 ii..Selecting specific storage structures and access methods for the data to achieve
good performance
 Designing any security measures required on the data

6
 Application developers:

 Responsible for the implementation application

programs that provide the required functionality
for the end-users
 Each program contains statements that
request the DBMS to perform some
operation on the database this includes –
retrieving data, inserting, updating, and
deleting data

7
DATABASE USERS
 Naïve users
 Access the database through specially written application programs that
attempt to make the operations as simple as possible
 
 They don’t need to know anything about the database or the DBMS

 Sophisticated users
 Familiar with the structure of the database and the facilities offered by the
DBMS
 
 May use high level query languages such as SQL to perform the required
operations

8
EVOLUTION OF A DATABASE SYSTEM
1st generation was file system, such as ISAM and VSAM.((indexed sequential access
method & Virtual Storage Access Method))
2nd generation was hierarchical database systems, such as IMS and System 2000.
3rd generation was the network model CODASYL (Conference on Data Systems
Languages) database systems.
4th generation relational database technology.
 Commercially available systems in late 70s and early 80s, such as
Oracle, SQL/DB and DB2 and INGRES
Relational and past-generation database systems are called conventional database
systems.

9
… EVOLUTION OF A DATABASE SYSTEM
Shortcomings of the conventional database technology :
 too simple for modeling complex nested entities, such as design and engineering
objects, and complex documents.
 support only a limited set of atomic data types, such as integer, string, etc.
 The performance of conventional database systems, unacceptable for various types of
compute-intensive applications, such as simulation programs in computer-aided design
and programming language environments.
 Application programs are implemented in some algorithmic programming language
 ..
5th generation database technology will be characterized by a richer
data model and a richer set of database facilities.
 Both the extended relational and object-oriented approaches are viable, and that most
likely systems adopting either approach co-exist.

10
LANDMARKS IN DATABASE SYSTEM HISTORY
1950s and early 1960s:
 Magnetic disc into the usage of data storage.
Late 1962s and 1970s:
 Hard disks come into play in late 1960s.
 A paper by Codd [1970] on relation model, querying and relational
database.
1980s:
 commercially available systems in late 70s and early 80s, such as
Oracle, SQL/DB and DB2
Late 1990s:
 WWW and Multimedia
 Object-Oriented Programming

11
DATABASE SYSTEM REQUIREMENTS
Consistency: ensure that the data itself is consistently.
Concurrency: enable multiple users and systems.
Performance: support reasonable response times.
Standard Adherence: support standard language
 DDL
 DML
Security: provide away to set access permissions.
Reliability: keep the stored data intact.

12
DATABASE SYSTEM VERSUS FILE SYSTEM
Data redundancy and inconsistency
Difficulty in accessing data
Data isolation
Integrity problems
Atomicity problems
Concurrent access anomalies
Security problems

13
DATABASE SYSTEM ARCHITECTURE
Centralized Database System Architecture
 run on a single computer system

Client/Server Architecture for a Database System

 Two machines acting as:
 Server
 Client
 Two-Tier Client/Server Architecture
 Three-Tier Client/Server Architecture
 Presentation
 Business
 Data

14
TOW-TIER CLIENT/SERVER ARCHITECTURE

Client Client Client Client Client

Process

File Mail DBMS Server

Server Server Server Process

Fig 1. Structure of client/server architecture

Middle Tier
 Fat Client Application
 Thin Client Application
15
THREE-TIER CLIENT/SERVER ARCHITECTURE

Client
User Tier

Web Server

Business
Tier

Data Server
Data Tier

Fig 2. Logical three-tier client/server architecture for a web application

16
COMPONENTS AND FUNCTIONALITIES OF A DATABASE
SYSTEM
Storage Manager
 Authorization and integrity manager
 Transaction manager
 File manager
 Buffer manger
Query Processor
 DDL interpreter (compiler)
 DML compiler
 Query evaluation engine

17
COMPONENTS AND FUNCTIONALITIES OF A DATABASE
SYSTEM

Application Application Query Tools Administration

Interfaces Programs Tools

Compiler and DML Queries DDL Queries

Linker
Application
Program Object DML Compiler and DDL Interpreter
Code Organizer
Query Evaluation
Engine Query Processor

Authorization and Transaction

Buffer Manager File Manager Integrity Manager Manager

Storage Manager

Data Dictionary Disk Storage

Indices
Data Statistical Data

Fig 3. Database System Structure

18
TYPES OF DATA MODELS
Implementation (or representational) data
models
 Hierarchical Model
 Hierarchy of parent and child data segments
 parent-child relationship is one – to – many
 Network Model
 permitted the modeling of many-to-many relationships in data
 In 1971, the Conference on Data Systems Languages (CODASYL)
formally defined the network model
 Relational Model

19
RELATIONAL MODEL
The history of the relational database began with E.F. Codd's 1970 paper
Allows the definition of data structures, storage and retrieval operations and
integrity constraints.
The data and relations between them are organized in tables.

20
… RELATIONAL MODEL
Properties of Relational Tables:
 Values Are Atomic
 Each Row is Unique
 Column Values Are of the Same Kind
 The Sequence of Columns is Insignificant
 The Sequence of Rows is Insignificant
 Each Column Has a Unique Name

21
HIGH-LEVEL (CONCEPTUAL) MODEL

Entity–Relationship Model
 Entity
 Attribute
 Relationship
Object-Oriented Model
 advancement of the Object-Oriented Programming (OOP)
 object-oriented data model
 object-relational data model

22
STEPS OF DATABASE DESIGN
Requirements analysis
Design (conceptual, logical and physical)
Implementation

23
REQUIREMENTS ANALYSIS ISSUES
What user views are required (present and
future)?
What data elements are required in these user
views?
What are the primary keys that uniquely
identify entities in the organization?
What are the relationships between data
elements?
What are the operational requirements such as
security, integrity, and response time?

24
STEPS IN REQUIREMENTS ANALYSIS

Identify scope of the design effort.

Establish metadata collection standards.
Identify user views.
 User View
Build a data dictionary.
Identify data volumes and usage patterns.
Identify operational (functional) requirements.

25
DESIGN
Conceptual Design
 Synthesis of information from requirements analysis
according to semantic rules.
Implementation (Logical) Design
 Transforms the conceptual data model into an internal
model - schema that can be processed by a particular
DBMS.
Physical Design
 High level design of
 internal storage structures, record formats, access methods, record
blocking and so on .

26
DATABASE SYSTEM DESIGN STEPS Part of the Real
Part of the Real
World
World

Problem

Requirement
Analysis

Functional Requirement Data Requirement

Functional Conceptual
Analysis Design

High-level Conceptual Schema

DBMS Transaction (High-level
Independent Specification Data Model)

Implementation
(Logical) Design

Application Program
DBMS Implementation
Design
Dependent (Logical) Schema

Application Program Physical

Structure Design

Internal Schema
Implementation (Low-level
Data Model)

Application Program
27
Fig 4. Database System Design Steps
 -
N D
- E