Lecture 3

Database System
Concepts and Architecture

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

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

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

Data Models
 One fundamental characteristic of the database
approach is that it provides some level of data
abstraction.
 Data abstraction generally refers to the
suppression of details of data organization and
storage, and the highlighting of the essential
features for an improved understanding of data.
 One of the main characteristics of the database
approach is to support data abstraction so that
different users can perceive data at their preferred
level of detail.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 3
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:
 Structure of a database 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 3- 4

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 3- 5

 Categories of Data Models

 Data models categorize according to the types of concepts they use to

describe the database structure:

 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.)

 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.

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

Categories of 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. Concepts provided by
physical data models are generally meant for computer specialists, not for
end users.
 Physical data models describe how data is stored as files in the computer by
representing information such as record formats, record orderings, and access
paths. An access path is a search structure that makes the search for particular
database records efficient, such as indexing or hashing.

 Implementation (representational) data models:

 Provide concepts that fall between the above two, which provide
concepts that may be easily understood by end users but that are not too
far removed from the way data is organized in computer storage.
Representational data models hide many details of data storage on disk
but can be implemented on a computer system directly. (traditional
commercial DBMSs)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 7
Schemas versus Instances
 Database Schema:
 The description of a database.

 Includes descriptions of the database structure, data

types, and the constraints on the database.
 Specified during database design and is not expected
to change frequently.
 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 3- 8
Schemas versus Instances
 A schema diagram displays only some aspects of a schema, such as the
names of record types and data items, and some types of constraints.
Other aspects are not specified in the schema diagram; for example,
Figure 2.1 shows neither the data type of each data item nor the
relationships among the various files. Many types of constraints are not
represented in schema diagrams. A constraint such as students majoring
in computer science must take CS1310 before the end of their
sophomore year is quite difficult to represent diagrammatically.
 Database State:
 The actual data in a database may change quite frequently. For example, the
database shown in Figure 1.2 changes every time we add a new student or enter a
new grade.
 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).

 In a given database state, each schema construct has its own current set of
instances; for example, the STUDENT construct will contain the set of individual
student entities (records) as its instances.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 9
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 10
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 3- 11

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 3- 12

Example of a Database Schema

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

Example of a database state

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

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

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

Three-Schema Architecture
 The goal of the three-schema architecture, illustrated in Figure 2.2, is to
separate the user applications from the physical database. 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.
 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.

 Usually uses the same data model as the conceptual

schema.

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

The three-schema architecture

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

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 3- 18

Data Independence
 Logical Data Independence:
 The capacity to change the conceptual schema without having to change the
external schemas and their associated application programs.
 We may change the conceptual schema to expand the database (by adding a record type or
data item), to change constraints, or to reduce the database (by removing a record type or data
item).
 In the last case, external schemas that refer only to the remaining data should not be
affected. For example, the external schema of Figure 1.5(a) should not be affected by
changing the GRADE_REPORT file (or record type) shown in Figure 1.2 into the one
shown in Figure 1.6(a).
 Only the view definition and the mappings need to be changed in a DBMS that
supports logical data independence. After the conceptual schema undergoes a logical
reorganization, application programs that reference the external schema constructs
must work as before.
 Changes to constraints can be applied to the conceptual schema without affecting the
external schemas or application programs.

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

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 20
Data Independence
 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
 Physical data independence exists in most databases and file environments
where physical details, such as the exact location of data on disk, and
hardware details of storage encoding, placement, compression, splitting,
merging of records, and so on are hidden from the user. Applications remain
unaware of these details.
 On the other hand, logical data independence is harder to achieve because it
allows structural and constraint changes without affecting application
programs—a much stricter requirement.

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

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

DBMS Languages
 Data Definition Language (DDL)
 Data Manipulation Language (DML)
 High-Level or Non-procedural Languages: These
include the relational language SQL
 May be used in a standalone way or may be
embedded in a programming language
 Low Level or Procedural Languages:
 These must be embedded in a programming
language

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

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 3- 24

DBMS Languages
 Data Manipulation Language (DML):
 Used to specify database retrievals and updates
 DML commands (data sublanguage) can be
embedded in a general-purpose programming
language (host language), such as COBOL, C,
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 3- 25

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 3- 26

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.

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

DBMS Programming Language Interfaces

 Programmer interfaces for embedding DML in a

programming languages:
 Embedded Approach: e.g embedded SQL (for C,
C++, etc.), SQLJ (for Java)
 Procedure Call Approach: e.g. JDBC for Java,
ODBC for other programming languages
 Database Programming Language Approach:
e.g. ORACLE has PL/SQL, a programming
language based on SQL; language incorporates
SQL and its data types as integral components

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

User-Friendly DBMS Interfaces

 Menu-based, popular for browsing on the web

 Forms-based, designed for naïve users
 Graphics-based
 (Point and Click, Drag and Drop, etc.)
 Natural language: requests in written English
 Combinations of the above:
 For example, both menus and forms used
extensively in Web database interfaces

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

Database System Utilities
 To perform certain functions such as:
 Loading data stored in files into a database.
Includes data conversion tools.
 Backing up the database periodically on tape.
 Reorganizing database file structures.
 Report generation utilities.
 Performance monitoring utilities.
 Other functions, such as sorting, user monitoring,
data compression, etc.

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