Database Management Systems

Dr. Alshaimaa abo-alian

[email protected]

Lecture 2
Slide 1- 1
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 2
Chapter 2
Database System Concepts and
Architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Outline
◼ Data Models and Their Categories
◼ Schemas, Instances, and States
◼ Three-Schema Architecture
◼ Data Independence
◼ DBMS Languages and Interfaces
◼ Database System Utilities and Tools
◼ Centralized and Client-Server Architectures
◼ Classification of DBMSs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 4

Data Models
◼ Data Model:
◼ A set of concepts to describe the structure of a database,
the operations for manipulating these structures, and
certain constraints that the database should obey.
◼ Data Model Structure and Constraints:
◼ Constructs are used to define the database structure
◼ Constructs typically include elements (and their data
types) as well as groups of elements (e.g. entity, record,
table), and relationships among such groups
◼ Constraints specify some restrictions on valid data; these
constraints must be enforced at all times

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 5

Data Models (continued)
◼ Data Model Operations:
◼ These operations are used for specifying database
retrievals and updates by referring to the
constructs of the data model.
◼ Operations on the data model may include basic
model operations (e.g. generic insert, delete,
update) and user-defined operations (e.g.
compute_student_gpa, balance_transfer)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 6

Categories of Data Models
◼ Conceptual (high-level, semantic) data models:
◼ Provide concepts that are close to the way many users
perceive data.
◼ (Also called entity-based or object-based data models.)
◼ Physical (low-level, internal) data models:
◼ Provide concepts that describe details of how data is stored in the
computer. by representing information such as record formats,
record orderings, and access paths.
◼ Implementation (representational) data models:
◼ Provide concepts that fall between the above two, used by
many commercial DBMS implementations (e.g. relational
data models used in many commercial systems).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 7

Database Schema versus Database Instance
◼ Database Schema:
◼ The description of a database.
◼ Includes descriptions of the database structure,
data types, and the constraints on the database.
◼ Schema Diagram:
◼ An illustrative display of (most aspects of) a
database schema.
◼ Other aspects are not specified in the schema diagram??
◼ Schema Construct:
◼ A component of the schema or an object within
the schema, e.g., STUDENT, COURSE.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 8

Example of a Database Schema

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 9

Database Schema versus Database Instance

◼ Database State:
◼ The actual data stored in a database at a
particular moment in time. This includes the
collection of all the data in the database.
◼ Also called database instance (or occurrence or
snapshot).
◼ The term instance is also applied to individual
database components, e.g. record instance, table
instance, …
◼ Database State:
◼ Refers to the content of a database at a moment
in time. Slide 2- 10
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Example of a database state

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 11

Database Schema vs. Database State

◼ Empty Database State (with no data):

◼ When we define a new database, we specify its
database schema only to the DBMS.
◼ Initial Database State:
◼ Refers to the database state when it is initially
loaded with the initial data into the system.
◼ Valid State:
◼ A state that satisfies the structure and constraints
of the database.
◼ DBMS responsibility: stores the descriptions of the schema
constructs and constraints (meta-data)—in the DBMS catalog so
that it can refer to the schema whenever it needs to.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 12
Database Schema vs. Database State

◼ Distinction
◼ The database schema changes infrequently.
◼ The database state changes every time the
database is updated.

◼ Schema is also called intension.

◼ State is also called extension.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 13

Three-Schema Architecture
◼ Proposed to support DBMS characteristics of:
◼ Program-data independence.
◼ Support of multiple views of the data.

◼ Not explicitly used in commercial DBMS products, but has

been useful in explaining database system organization

◼ The goal of the three-schema architecture is to

separate the user applications from the physical
database
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 14
Three-Schema Architecture
◼ Defines DBMS schemas at three levels:
◼ Internal schema at the internal level to describe physical
storage structures and access paths (e.g indexes).
◼ Typically uses a physical data model.
◼ Conceptual schema at the conceptual level to describe the
structure and constraints for the whole database for a
community of users.
◼ Uses a conceptual or an implementation data model.
◼ External schemas at the external level to describe the
various user views.
◼ Usually uses the same data model as the conceptual schema.
◼ Each external schema describes the part of the database that
a particular user group is interested in and hides the rest of the
database from that user group.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 15
The three-schema architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 16

Data Independence
◼ The capacity to change the schema at one level of a database system
without having to change the schema at the next higher level.
◼ Logical Data Independence:
◼ The capacity to change the conceptual schema
without having to change the external schemas
and their associated application programs.
◼ Physical Data Independence:
◼ The capacity to change the internal schema
without having to change the conceptual schema.
◼ For example, the internal schema may be changed
when certain file structures are reorganized or new
indexes are created to improve database
performance (ex. improve retrieval speed)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 17
DBMS Languages
◼ The DBMS must provide appropriate languages
and interfaces for each category of users
◼ Data Definition Language (DDL)
◼ Data Manipulation Language (DML)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 19

DBMS Languages
◼ Data Definition Language (DDL):
◼ Used by the DBA and database designers to
specify the conceptual schema of a database.
◼ In many DBMSs, the DDL is also used to define
internal and external schemas (views).
◼ In some DBMSs, separate storage definition
language (SDL) and view definition language
(VDL) are used to define internal and external
schemas.
◼ SDL is typically realized via DBMS commands
provided to the DBA and database designers

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 21

DBMS Languages
◼ Data Manipulation Language (DML):
◼ Used to specify database retrievals and updates
(insertion, deletion, and modification of the data)
◼ DML commands (data sublanguage) can be
embedded in a general-purpose programming
language (host language), such as C++, or Java.
◼ A library of functions can also be provided to access
the DBMS from a programming language
◼ Alternatively, stand-alone DML commands can be
applied directly (called a query language).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 22

Types of DML
◼ High Level or Non-procedural Language:
◼ For example, the SQL relational language
◼ Are “set”-oriented and specify what data to retrieve
rather than how to retrieve it.
◼ Also called declarative languages.
◼ Low Level or Procedural Language:
◼ Retrieve data one record-at-a-time;
◼ Constructs such as looping are needed to retrieve
multiple records, along with positioning pointers.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 23

DBMS Interfaces
◼ Stand-alone query language interfaces
◼ Example: Entering SQL queries at the DBMS

interactive SQL interface (e.g. SQL*Plus in ORACLE)

◼ Programmer interfaces for embedding DML in
programming languages
◼ User-friendly interfaces
◼ Menu-based, forms-based, graphics-based, etc.

◼ Interfaces for the DBA:

◼ Creating user accounts, granting authorizations
◼ Setting system parameters
◼ Changing schemas or access paths

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 24

Database System Utilities
◼ Database utilities that help the DBA manage the database
system to perform certain functions such as:
◼ Loading data stored in files into a database. Includes data

conversion tools.
◼ Backing up the database periodically on another storage

medium.
◼ Report generation utilities.

◼ Performance monitoring utilities.

◼ Other functions, such as sorting, user monitoring, data

compression, etc.
◼ Data dictionary / repository:

◼ Used to store schema descriptions, constraints and other information

such as application program descriptions, user information, etc
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 26
Centralized and
Client-Server DBMS Architectures
◼ Centralized DBMS:
◼ Combines everything into single system including-
DBMS software, application programs, and user
interface processing software.
◼ User can still connect through a remote terminal –
however, all processing is done at centralized site.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 27

A Physical Centralized Architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 28

Basic 2-tier Client-Server Architectures

◼ Specialized Servers with Specialized functions

◼ Print server
◼ File server
◼ DBMS server
◼ Web server
◼ Email server
◼ Clients can access the specialized servers as
needed

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 29

Logical two-tier client server architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 30

Clients
◼ Provide appropriate interfaces through a client
software module to access and utilize the various
server resources.
◼ Clients may be diskless machines or PCs or
Workstations with disks with only the client
software installed.
◼ Connected to the servers via some form of a
network.
◼ (LAN: local area network, wireless network, etc.)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 31

DBMS Server
◼ Provides database query and transaction services to the
clients
◼ Relational DBMS servers are often called SQL servers,
query servers, transaction servers, or data servers
◼ Applications running on clients utilize an Application
Program Interface (API) to access server databases via
standard interface such as:
◼ ODBC: Open Database Connectivity standard
◼ JDBC: for Java programming access
◼ Client and server must install appropriate client module
and server module software for ODBC or JDBC
◼ See Chapter 9

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 32

Physical two-tier client server
architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 33

Three Tier Client-Server Architecture
◼ Common for Web applications
◼ Intermediate Layer called Application Server or Web
Server:
◼ Stores the web connectivity software and the business logic
part of the application used to access the corresponding
data from the database server
◼ Acts like a channel for sending partially processed data
between the database server and the client.
◼ Three-tier Architecture Can Enhance Security:
◼ Database server only accessible via middle tier
◼ Clients cannot directly access database server

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 34

Three-tier client-server architecture

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 35

Classification of DBMSs
We can classify DBMSs according to several
criteria:
1. Number of users
▪ Single-user (typically used with personal
computers)
vs. multi-user (most DBMSs).
2. Number of sites
▪ Centralized (data is stored at a single computer
site)
vs. distributed (database & DBMS software are
distributed over many sites)
▪ Homogeneous DDBMS (same DBMS software at
all the sites) vs. Heterogeneous DDBMS Slide 2- 36
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Classification of DBMSs
We can classify DBMSs according to several
criteria:
3. Data model
▪ Relational, object, Network, Hierarchical
4. Cost.
▪ open source (free) DBMS products like MySQL
▪ License-based like Oracle

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 37

Summary
◼ Data Models and Their Categories
◼ Schemas, Instances, and States
◼ Three-Schema Architecture
◼ Data Independence
◼ DBMS Languages and Interfaces
◼ Database System Utilities and Tools
◼ Centralized and Client-Server Architectures
◼ Classification of DBMSs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 38