Database System Concepts and

Architecture

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

Data Abstraction
 Data abstraction refers to the
suppression of details of data
organization and storage, and the
highlighting of the essential features
for an improved understanding of
data

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

 A data model—a collection of concepts that can
be used to describe the structure of a database—
provides the necessary means to achieve this
abstraction.
 Structure of a database :data types, relationships,
and constraints that apply to the data.
 Data models : include a set of basic operations
for specifying retrievals and updates on the
database.
 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- 3

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, update_inventory)

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

 Categories of Data Models

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

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. These are usually specified in an ad-hoc
manner through DBMS design and administration manuals
 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- 6

High-level or conceptual
data models
 Conceptual data models use concepts such as entities, attributes,
and relationships.
 An entity represents a real-world object or concept, such as an
employee or a project from the miniworld that is described in the
database.
 An attribute represents some property of interest that further
describes an entity, such as the employee’s name or salary.
 A relationship among two or more entities represents an association
among the entities, for example, a works-on relationship between an
employee and a project.
 Entity–relationship model—a popular high-level conceptual data
model. Mini-world

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

Low-level or Physical data models
 Describe the details of how data is stored on the
computer storage media, typically magnetic disks.
 Describe how data is stored as files in the
computer by representing information such as
record formats, record orderings, and access paths
 Access path is a search structure that makes the
search for particular database records efficient,
such as indexing or hashing
 An index is an example of an access path that
allows direct access to data using an index term or
a keyword.

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

Representational (or
implementation) data models
 Provide concepts that may be easily understood by
end users .
 Representational data models hide many details of
data storage on disk but can be implemented on a
computer system directly.
 Most frequently used relational data model, as
well as the so-called legacy data models—the
network and hierarchical models—that have
been widely used in the past
 Representational data models represent data by
using record structures and hence are sometimes
called record-based data models.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 9
 Types of Data Models

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

Types of Data Models
 Network Model
 Hierarchical Model
 Relational Model
 Object-oriented Data Models
 Object-Relational Models

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

Example of Network Model Schema

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

Network Model
 Advantages:
 Network Model is able to model complex
relationships and represents semantics of
add/delete on the relationships.
 Can handle most situations for modeling using
record types and relationship types.
 Language is navigational; uses constructs like
FIND, FIND member, FIND owner, FIND NEXT
within set, GET, etc.

Programmers can do optimal navigation through the
database.

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

Network Model
 Disadvantages:
 Navigational and procedural nature of processing
 Database contains a complex array of pointers
that thread through a set of records.

Little scope for automated “query optimization”

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

History of Data Models
 Hierarchical Data Model:
 Initially implemented in a joint effort by IBM and
North American Rockwell around 1965. Resulted
in the IMS family of systems.
 IBM’s IMS product had (and still has) a very large
customer base worldwide
 Hierarchical model was formalized based on the
IMS system
 Other systems based on this model: System 2k
(SAS inc.)

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

Hierarchical Model
 Advantages:
 Simple to construct and operate
 Corresponds to a number of natural hierarchically organized
domains, e.g., organization (“org”) chart
 Language is simple:

Uses constructs like GET, GET UNIQUE, GET NEXT, GET
NEXT WITHIN PARENT, etc.
 Disadvantages:
 Navigational and procedural nature of processing
 Database is visualized as a linear arrangement of records
 Little scope for "query optimization"

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

Relational Model
 Relational Model:
 Proposed in 1970 by E.F. Codd (IBM), first commercial
system in 1981-82.
 Now in several commercial products (e.g. DB2, ORACLE,
MS SQL Server, SYBASE, INFORMIX).
 Several free open source implementations, e.g. MySQL,
PostgreSQL
 Currently most dominant for developing database
applications.
 SQL relational standards: SQL-89 (SQL1), SQL-92 (SQL2),
SQL-99, SQL3, …

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

 Object-oriented Data Models:
 Several models have been proposed for implementing in a
database system.
 One set comprises models of persistent O-O Programming
Languages such as C++ (e.g., in OBJECTSTORE or
VERSANT), and Smalltalk (e.g., in GEMSTONE).
 Additionally, systems like O2, ORION (at MCC - then
ITASCA), IRIS (at H.P.- used in Open OODB).
 Object Database Standard: ODMG-93, ODMG-version 2.0,
ODMG-version 3.0.

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

 Object-Relational Models:
 Most Recent Trend. Started with Informix
Universal Server.
 Relational systems incorporate concepts from
object databases leading to object-relational.
 Exemplified in the latest versions of Oracle-10i,
DB2, and SQL Server and other DBMSs.
 Standards included in SQL-99 and expected to be
enhanced in future SQL standards.

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

Schemas versus Instances
 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.
 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- 20

Example of a Database Schema

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

Schemas versus Instances
 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, entity instance

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

Database Schema
vs. Database State
 Database State:
 Refers to the content of a database at a moment
in time.
 Initial Database State:
 Refers to the database state when it is initially
loaded into the system.
 Valid State:
 A state that satisfies the structure and constraints
of the database.

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

Database Schema
vs. Database State (continued)
 Distinction
 The database schema changes very 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- 24

 Schema Evolution :
Another data item needs to be stored for
each record in a file, such as adding the
Date_of_birth to the STUDENT schema.
 Meta Data :The DBMS stores the

descriptions of the schema constructs and

constraints—in the DBMS catalog so that
DBMS software can refer to the schema
whenever it needs to

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

Example of a database state

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

 Three-Schema Architecture

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

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

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

The three-schema architecture

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

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.

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

Three-Schema Architecture
 Mappings among schema levels are needed to
transform requests and data.
 Programs refer to an external schema, and are
mapped by the DBMS to the internal schema for
execution.
 Data extracted from the internal DBMS level is
reformatted to match the user’s external view (e.g.
formatting the results of an SQL query for display
in a Web page)

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

Data Independence
 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

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

Data Independence (continued)
 When a schema at a lower level is changed, only
the mappings between this schema and higher-
level schemas need to be changed in a DBMS
that fully supports data independence.
 The higher-level schemas themselves are
unchanged.
 Hence, the application programs need not be
changed since they refer to the external schemas.

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

Centralized and Client/Server
Architectures for DBMSs

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

Centralized DBMS Architectures
 Centralized DBMS:
 Combines everything into single system including-
DBMS software, hardware, 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- 35

A Physical Centralized Architecture

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

Basic Client/Server
Architectures
 The client/server architecture was
developed to deal with computing
environments in which a large number of
PCs, workstations, file servers,printers,
database servers, Web servers, e-mail
servers, and other software and equipment
are connected via a network.
 The idea is to define specialized servers
with specific functionalities.

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

Basic 2-tier Client-Server Architectures
 Specialized Servers with Specialized functions
 Print server: by being connected to various
printers; all print requests by the clients are
forwarded to this
machine

File server : maintains the files of the client

DBMS server

Web server

Email server
 Clients can access the specialized servers as needed

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

Logical two-tier client server architecture

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

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- 40

DBMS Server
 Provides database query and transaction services to the
clients
 Relational DBMS servers are often called SQL servers,
query servers, or transaction 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

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

Classification of DBMSs
 Based on the data model used
 Traditional: Relational, Network, Hierarchical.
 Emerging: Object-oriented, Object-relational.
 Other classifications
 Single-user (typically used with personal
computers)
vs. multi-user (most DBMSs).
 Centralized (uses a single computer with one
database)
vs. distributed (uses multiple computers, multiple
databases)

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

Variations of Distributed DBMSs
(DDBMSs)
 Homogeneous DDBMS -use the same DBMS
software at all the sites
 Heterogeneous DDBMS- can use different DBMS
software at each site
 Federated or Multidatabase Systems :
middleware software to access several
autonomous preexisting databases stored under
heterogeneous DBMSs

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

Cost considerations for DBMSs
 Cost Range: from free open-source systems to
configurations costing millions of dollars
 Examples of free relational DBMSs: MySQL, PostgreSQL,
others
 Commercial DBMS offer additional specialized modules,
e.g. time-series module, spatial data module, document
module, XML module
 These offer additional specialized functionality when
purchased separately
 Sometimes called cartridges (e.g., in Oracle) or blades
 Different licensing options: site license, maximum number
of concurrent users (seat license), single user, etc.

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

 Thank You

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