Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe Slide 2- 1
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

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 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 Constructs 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- 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. insert, delete, update)
and user-defined operations (e.g.
compute_student_gpa, update_inventory)

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

Basic Definitions
◼ 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- 6
 Example of a Database Schema

Some aspects are not specified in the schema diagram; Figure 2.1 shows neither the
data
Copyright typeElmasri
© 2007 Ramez of data items,
and Shamkant nor relationships among various files.
B. Navathe Slide 2- 7
Database State (Instance)
◼ Database State:
◼ The actual content (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 (occurrence
/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- 8

Database States
◼ 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.

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

Database Schema vs. Database State
◼ Distinction
◼ The database schema changes very
infrequently.(Schema evolution)
◼ The database state changes every time the
database is updated.

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

Example of a database state

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

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

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

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- 13
The three-schema architecture

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

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 re-organized or new indexes are created to
improve database performance (ex. improve retrieval speed)

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

Mappings
◼ A DBMS that cleanly separates the three levels must have
mappings between the schemas to transform requests
and query results from one level to the next.

◼ These mappings may be time-consuming, cause

overhead during compilation or execution of a query or
program, leading to inefficiencies in the DBMS. Thus,
Most DBMSs do not separate the three levels completely.

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

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

DBMS Languages
◼ Data Definition Language (DDL):
◼ Used by the DBA and database designers to
specify the conceptual schema of a database.
◼ Commands for Creation of database and
manipulating structure of database
◼ Ex: create table, constraint. Adding new column,
delete table, delete constraint…..

◼ In many DBMSs, the DDL is also used to define

internal and external schemas (views).
◼ Examples: Create/Alter/Drop
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 2- 18
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 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- 19

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

Chapter 3
Data Modeling Using
the Entity-Relationship (ER) Model
Chapter Outline
◼ Overview of Database Design Process
◼ Example Database Application (COMPANY)
◼ ER Model Concepts
◼ Entities and Attributes
◼ Entity Types, Value Sets, and Key Attributes
◼ Relationships and Relationship Types
◼ Weak Entity Types
◼ Roles and Attributes in Relationship Types
◼ ER Diagrams - Notation
◼ ER Diagram for COMPANY Schema
◼ Relationships of Higher Degrees

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Overview of Database Design Process

◼ Database application includes two main activities:

◼ Database design
◼ Applications design
◼ Focus in this chapter on database design
◼ To design the conceptual schema for a database
◼ Applications design focuses on the programs and
interfaces that access the database
◼ Generally considered part of software engineering

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Overview of Database Design Process

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ER DIAGRAM for the COMPANY database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example COMPANY Database
◼ We need to create a database schema design
based on the following (simplified) requirements
of the COMPANY Database:
◼ The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We
keep track of the start date of the department
manager. A department may have several
locations.
◼ Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single
location.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Example COMPANY Database
(Contd.)
◼ We store each EMPLOYEE’s social security
number, address, salary, sex, and birth date.
◼ Each employee works for one department but may
work on several projects.
◼ We keep track of the number of hours per week
that an employee currently works on each project.
◼ We also keep track of the direct supervisor of
each employee.
◼ Each employee may have a number of
DEPENDENTs.
◼ For each dependent, we keep track of their name,
sex, birthdate, and relationship to the employee
for insurance purposes.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
ER DIAGRAM for the COMPANY database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ER Model Concepts
◼ Entities and Attributes
◼ Entities are specific objects or things in the mini-world
that are represented in the database. An entity may be an object
with a physical existence (for example, a particular person, car,
or with a conceptual existence (for instance, a company, a job, or a
university course)
◼ For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the ProductX PROJECT
◼ Attributes are properties used to describe an entity.
◼ For example an EMPLOYEE entity may have the attributes
Name, SSN, Address, Sex, BirthDate
◼ A specific entity will have a value for each of its attributes.
◼ For example a specific employee entity may have Name='John
Smith', SSN='123456789', Address ='731, Fondren, Houston,
TX', Sex='M', BirthDate='09-JAN-55‘
◼ Each attribute has a value set (or data type) associated
with it – e.g. integer, string, enumerated type, …
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Types of Attributes

◼ Simple versus composite

◼ Single-valued versus multi-valued
◼ Stored versus derived

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Types of Attributes
Simple versus composite
◼ Simple
◼ Each entity has a single atomic value for the
attribute. For example, SSN or Sex.

◼ Composite ()
◼ The attribute may be composed of several
components. For example:
◼ Address (Apt#, House#, Street, City, State, ZipCode,
Country)
◼ Name (FirstName, MiddleName, LastName).
◼ Composition may form a hierarchy where some
components are themselves composite.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Example of a composite attribute

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Types of Attributes
Single-valued versus multi-valued
◼ Age is a single-valued attribute of a person.
◼ Multi-valued {}
◼ An entity may have multiple values for that attribute. For
example, Color of a CAR or College_degree of a PERSON.
◼ Denoted as {Color} or {College_degree}.

◼ It may have upper bounds to constrain the number of values allowed for
each individual entity (Ex: a car can have three colors at most)
◼ Complex Attributes: In general, composite and multi-valued
attributes may be nested arbitrarily to any number of levels,
although this is rare.
◼ For example, College_degree of a STUDENT is a composite

multi-valued attribute denoted by

{College_degree (College, Year, Degree, Field)}
◼ Multiple College_degree values can exist

◼ Each has four subcomponent attributes:

CopyrightCollege, Year, Degree, Field

◼ © 2007 Ramez Elmasri and Shamkant B. Navathe
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Types of Attributes
Stored versus derived
◼ Derived Attributes:
◼ For example, the Age and the Birth_date attributes
of a person.
◼ The Age attribute is called a derived attribute and
is said to be derivable from the Birth_date
attribute, which is called a stored attribute.
◼ Some attribute values can be derived from
related entities; for example, an attribute
Number_of_employees of a DEPARTMENT entity
can be derived by counting the number of
employees related to (working for) that
department.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
ER DIAGRAM for the COMPANY database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Null – 3 cases
◼ Case 1 (Not applicable): a particular entity may not
have an applicable value for an attribute.
◼ For example, Military Status for girls, the
Apartment_number and a College_degrees attribute
◼ Case 2 (Unknown): NULL can also be used if we do not
know the value of an attribute for a particular entity—for
example, if we do not know the home phone number of
‘John Smith’.
◼ Exists but is missing—for instance, if the Height

attribute of a person is listed as NULL.

◼ Not known whether the attribute value exists—for

example, if the Home_phone attribute of a person is

NULL.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Entity Types and Key Attributes
◼ Entities with the same basic attributes are
grouped or typed into an entity type.
◼ For example, the entity type EMPLOYEE
and PROJECT.
◼ An attribute of an entity type for which each
entity must have a unique value is called
a key attribute of the entity type.
◼ For example, SSN of EMPLOYEE.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Key Attributes
◼ A key attribute may be composite.
◼ VehicleTagNumber is a key of the CAR entity

type with components (Number, State).

◼ An entity type may have more than one key
(candidate key).
◼ The CAR entity type may have two keys:

◼ VehicleIdentificationNumber (popularly called VIN)

◼ VehicleTagNumber (Number, State), plate number.
◼ Each key is underlined
◼ An entity type may also have no key, in which
case it is called a weak entity type
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Displaying an Entity type
◼ In ER diagrams, an entity type is displayed in a
rectangular box
◼ Attributes are displayed in ovals
◼ Each attribute is connected to its entity type
◼ Components of a composite attribute are
connected to the oval representing the composite
attribute
◼ Each key attribute is underlined
◼ Multivalued attributes displayed in double ovals
◼ See CAR example on next slide

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Entity Type CAR with two keys and a
corresponding Entity Set

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe