Chapter One
Overview of Database
Objectives:
-Introduction
-DBMS architecture
-Definitions
-Data models
-DB lifecycle
Definitions

Database Management System
(DBMS): is a record keeping
system (software) that allows one
or more people to use or modify
the data.
2
Why DBMS:
Centralized Control


Redundancy(Eliminated or Reduced)
(Propagating update)











Inconsistency (Avoided)
Shared Data
Standardization
Security
Integrity
Transaction Support
Complex Design
Required Specialist (DBA)
Training Cost
Program Failures (potential)
Cost
3
Good DBMS must have:






Support for at least one Data Model
Support for certain high level languages for
Retrieve, Insert, Deletes, etc. into Database
(Navigate)
Transaction Management:
Capable of access to DB by many users at
once
Access control:
Limit access to DB by unauthorized user
Recovery capability form system failure
Security System
4
Architecture of DBMS
View

Conceptual DB
Physical DB
View Level:
Def:
Example (SQL)

CREATE VIEW
SELECT
FROM

GradStudent
Name, ID, GPA
Students;
Data Manipulation Language (DML) (Query
Language)
5
Architecture of DBMS

Conceptual Level:

Describe what data are stored &
relationship among data (DB)
Example:
Students=Record
Name:char[15];
ID:Integer;
End;
6
Architecture of DBMS
Example:

Create table Students
(Name VARCHAR2(30),
ID
NUMBER(14),
GPA
NUMBER(3,2));

Data Definition Language (DDL)
7
External
Level
Application
Program
Conceptual
Level
Internal
Level
End
User
DB Administrator
System
Calls
Query
DB
Scheme
DML
Compiler
Query
Processor
DDL
Compiler
Application Program
Application
Program
Object Code
File Manager
DB Manager
Data File
Data Dictionary
Definitions



File
DB
DBMS
10
Definitions (Continued)

Instances & Schemes
Instance: The collection of Information
stored in a DB at a particular instant of
time
Scheme: The overall design of the DB

Example:
Students (ID, Name, Address, GPA)
111, John, 34 1st, 2.6,
123, Mary, 18 Main, 2.8

(Plan for view is called sub-scheme)
11
Definitions (Continued)

Data Independence:
a.
b.
Physical data Independence
The ability to modify physical
scheme without changing the
application program
Logical data Independence:
The ability to modify conceptual
scheme without changing the
application program
12
Definitions (Continued)

Data Definition Language (DDL)
a.
b.
A set of instructions which define
the DB scheme
Result of compilation of DDL in a set
of tables which are stored in a
special file called “data dictionary”.
13
Definitions (Continued)
Data Manipulation Language
(DML) A set of instructions to
manipulate data. (Insert,
Retrieve, Delete, …)

Types of DML
a.
i.
ii.
Procedural:
Non Procedural (Declarative)
14
Definitions (Continued)
 Database Manager:
A program which provides the
interface between data stored in
DB and application programs
15
Definitions (Continued)

Database manager is responsible
for:
a.
b.
c.
d.
e.
Interaction with the file manager
(retrieving & updating data in DB)
Integrity enforcement:
Data value must satisfy certain
types of consistency constraints
Security enforcement
Backup & recovery
16
Definitions (Continued)
 Database Administrator (DBA):
Person(s) who involves in central control
Function of DBA:
1.
2.
3.
4.
Scheme definitions
Storage structure & access method (Physical
organization)
Modification of scheme & physical
organization
Granting of authorization for data access
17
Definitions (Continued)

Database Users
a. Application Programmer
b. End User (Query Language)
Host Language:
High level programming language
supported by DBMS that can be
used to manipulate DB

18
Overall System Structure








Database Administration
File Manager
Data File
Data Dictionary
Database Manager
Query Processes
DML Compiler
DDL Compiler
19
Data Models

Introduction:




Physical Model
Mathematical Model
Abstract Model
Data Model
20
Data Model

Describes Data, Data Relationships,
Data Semantics and Data Constraints

<Object Name, Object Property, Property Values, Time>

Example:
Car
Employer
Person
Manager
21
Representing Models
•
•
-Networking
-Categories
•
•
Strictly Typed
Loosely Typed
22
Types of Models
1.
2.
3.
4.
Object Based logical Model
Record Based Model
Physical Data Model
Object Record Model
23
Object Based Logical Models



Describing data at the conceptual and
view levels
Flexible structure
Specify data constraints explicitly
Example:
1.
2.
3.
4.
Entity-Relationship
Semantic Data Modeling
Binary Data Model
Infological Model
24
Entity-Relationship Model (ER
Model):




Consists of a collection of basic objects
called (Entities) and (Relationships)
An entity is an object which exists and
is distinguished from other objects
Each entity has a set of attributes which
describes the object
A relationship is an association among
several entities
25
Binary Data Model




Base on graph data model; nodes and arcs
Node represents a classification of data
instances into a type called category
(Generalization)
Arc represents a binary relationship between
categories and is called binary relation
This graph is called Type Graph
26
Record-Based Logical Models


Describing data at the conceptual
and view levels
They do not provide facilities for
specifying data constraints
explicitly
27
Record-Based Logical Models
(Continued)
1.
2.
3.
Relational data and relationships are
represented by a collection of
Tables(Relations)
Network data are represented by
collections of records and
relationships among data are
represented by links
Hierarchical similar to network, but
records are organized as a collection
of trees rather than arbitrary graph
28
Physical Data Models

Describes data at the lowest level
29
Object Relational






Present information in object form
Object of object type (hierarchical)
Inheritance
Encapsulation
Interface
Polymorphism
30
Database Lifecycle
Stage One:
a.
Analysis:



b.
Study and Analyze business requirements
Interview manager, and users for the
information requirements
Incorporate the future system specifications
Develop a user system specifications
31
Database Lifecycle
Stage Two:
Design

Entity relational model
Unify modeling language

Check the design

Stage Three:
Build the Databases/Document/Test


Create tables, views and programs
Produce manuals (User documentation)
32
Database Lifecycle
Stage Four:
Product delivery

Load the software

Monitor the performance
33