CH1 - 380CSS-3 - Fundamentals of Database Systems-Merged

380CSS-3 Fundamentals of
DATABASE SYSTEMS
Copyright © 2015 Ramez Elmasri and Shamkant B.

1
Navathe
COURSE OUTLINE
CHAPTER TOPICS PAGE
1 Databases and Database Users 3 – 24
2 Database System Concepts and Architecture 25 – 42
3 Data Modeling Using the Entity-Relationship 43 – 78

(ER) Model
4 The Relational Data Model and Relational 79 – 101

Database Constraints
5 Relational Algebra 102 – 123
6 Functional Dependencies and Normalization for 124 - 153

Relational Databases

2
Navathe
Chapter 1
Databases and Database Users

3
Navathe
Overview
Chapter-1: Databases and Databases Users
1. Introduction : Types of databases and functionalities
1.2 An Example (University Database)
1.3 Characteristics of the Database Approach
1.3.1 Self-Describing Nature of a Database System
1.3.2 Insulation between Programs and Data, and Data Abstraction
1.3.3 Support of Multiple Views of the Data
1.3.4 Sharing of Data and Multiuser Transaction Processing
1.4 Actors on the Scene
1.4.1 Database Administrators
1.4.2 Database Designers
1.4.3 End Users
1.4.4 System Analysts and Application Programmers (Software Engineers)
1.5 Workers behind the Scene
1.6 Advantages of Using the DBMS Approach
4
Navathe
Types of Databases and Database
Applications
Traditional Applications:
Numeric and Textual Databases
More Recent Applications:
Multimedia Databases
Geographic Information Systems (GIS)
Data Warehouses
Real-time and Active Databases
Many other applications
We will focus on traditional applications of
database to solve mini-world problems.

5
Navathe
Basic Definitions
 Database:
 A collection of related data.
 Data:
 Known facts that can be recorded and have an implicit
meaning.
 Mini-world or the Universe of discourse (UoD) :
 Represents some aspects /parts of the real world about which
data is stored in a database. For example, student registration
system at a university, Patients record system in a hospital.
 Database Management System (DBMS):
 A collection of programs/software package to facilitate the
creation and maintenance of a database.
 Its facilitates the processes of defining, constructing,
manipulating, and sharing databases among various users
applications.
and
6
Navathe
Typical DBMS Functionality
 Define a particular database in terms of its data types,
structures, and constraints
 Construct or Load the initial database contents on a
secondary storage medium
 Manipulating the database:
Retrieval: Querying, generating reports
Modification: Insertions, deletions and updates to its content
Generating reports from the data
 Processing and Sharing a database allows multiple users
and programs to access the database simultaneously

7
Navathe
Typical DBMS Functionality (continued)x
 Application program: accesses the database by sending queries
or requests for data to the DBMS.
 A query typically causes some data to be retrieved; a transaction
may cause some data to be read and some data to be written into
the database.
 Protection includes system protection against hardware or software
malfunction (or crashes), unauthorized or malicious access.
 DBMS must be able to maintain the database system by allowing
the system to evolve as requirements change over time.
 Database system: To complete our initial definitions, we will call the
database and DBMS software together a database system.
 Figure I.I illustrates some of the concepts we have discussed so far.

8
Navathe
Simplified database system environmentx

9
Navathe
Example of a Database
(with a Conceptual Data Model)
Mini-world for the example:
Part of a UNIVERSITY environment.
Some mini-world entities:
STUDENTs
COURSEs
SECTIONs (of COURSEs)
(academic) DEPARTMENTs
INSTRUCTORs

10
Navathe
Example of a Database
(with a Conceptual Data Model)
 Some mini-world relationships:
SECTIONs are of specific COURSEs
STUDENTs take SECTIONs
COURSEs have prerequisite COURSEs
INSTRUCTORs teach SECTIONs
COURSEs are offered by DEPARTMENTs
STUDENTs major in DEPARTMENTs
 Note: The above entities and relationships are typically

expressed in a conceptual data model, such as the
ENTITY-RELATIONSHIP data model (see Chapters 3, 4)
11
Navathe
Example of a simple databasex

12
Navathe
Main Characteristics of the Database
Approachx
 Self-describing nature of a database system:
A DBMS catalog stores the description of a particular
database (e.g. data structures, types and constraints on the
data)
The information stored in the catalog is called meta-
data, and it describes the structure of the primary
database.
This allows the DBMS software to work with different
database applications.
 Insulation between programs and data:
Called program-data independence.
Allows changing data structures and storage organization
without having to change the DBMS access programs. 13
Copyright © 2015 Ramez Elmasri and Shamkant B. Navathe
Example of a simplified database catalogx

14
Navathe
Approach (continued)
Data Abstraction:
The characteristic that allows program-data
independence and program-operation independence is
called data abstraction. Informally, A data model is
used to hide storage details and present the users with
a conceptual view of the database.
Support of multiple views of the data:x
Each user may see a different view (subset or
virtual data) of the database, which describes only
the data of interest to that user.

15
Navathe
Approach (continued)
Sharing of data and multi-user transaction
processing:
Allowing a multiple users to retrieve/access from
and update to the database
Concurrency control within the DBMS guarantees
that each transaction is correctly executed or
aborted
These types of applications are generally called
online transaction processing (OLTP)
applications.

16
Navathe
Database Users
Users may be divided into
Those who actually use and control the database
content, and those who design, develop and
maintain database applications (called “Actors on
the Scene”), and
Those who design and develop the DBMS
software and related tools, and the computer
systems operators (called “Workers Behind the
Scene”).

17
Navathe
Database Users
Actors on the scene
Database administrators:
Responsible for authorizing access to the database,
for coordinating and monitoring its use, acquiring
software and hardware resources, controlling its use
and monitoring security and efficiency of operations.
Database Designers:
Responsible to define the content, the structure, the
constraints, and functions or transactions against
the database. They must communicate with the end
-users and understand their needs.

18
Navathe
Categories of End-users
Actors on the scene
End-users: They use the data for queries, reports
and some of them update the database content.
End-users can be categorized into:
Casual: access database occasionally when
needed
Naïve or Parametric: Constantly querying and
updating the database, using standard types of
queries and updates-called canned transactions.
Examples are bank-tellers or university secretaries who do
this activity for an entire shift of operations.

19
Navathe
Categories of End-users (continued)x
Sophisticated:
These include business analysts, scientists, engineers,
others thoroughly familiar with the system capabilities.
Stand-alone:
Mostly maintain personal databases using ready-to-use
packaged applications.
E.g.:
(i) User of a tax package that stores a variety of personal
financial data for tax purposes,
(ii) A scientists that creates a
databaseforitsown
experiments,
(iii) A user that maintains an address book
You may become sophisticated or stand-alone
users 20
Navathe
Categories of End-users (continued)
 System analysts: determine the requirements of end
users, and develop specifications for standard canned
transactions that meet these requirements.
 Application programmers:
implement these
specifications as programs; they test, debug,
then
document, and maintain these canned transactions. Such
analysts and programmers commonly referred to as
software developers or software engineers.

21
Navathe
Workers behind the Scenex
 DBMS system designers and implementers design
and implement the DBMS modules and interfaces as a
software package.
 Tool developers design and implement tools- that
facilitate database modeling and design, database system
design, and improved performance.
 Operators and maintenance personnel (system
administration personnel) are responsible for the actual
running and maintenance of the hardware and software.

22
Navathe
Advantages of Using the Database
Approach
 Interacting easily with data using high-level dedicated tools
 Controlling redundancy in data storage and in development
and maintenance efforts.
Sharing of data among multiple users.
Ensuring consistency of data.
 Restricting unauthorized access to data.
 Providing storage structures (e.g. indexes) for efficient
query processing
 Providing backup and recovery services.
 Providing multiple interfaces to different classes of users.
 Representing complex relationships among data.
 Enforcing integrity constraints on the 23
database.
Review questions
1. Define the following terms: data, database, DBMS, database system, database
catalog, UoD, data model, program-data independence, DBA, User view,
canned transaction, meta-data, transaction-processing application etc.
2. What are the responsibilities of the DBA and the Database designers?
3. List down the advantages of using DBMS approach.
4. Discuss the differences between system Analysts and Application programmers.
5. What do you understand by database management systems (DBMS)?
6. Briefly explain the advantages of using DBMS approach.
7. What four main types of actions involve databases? Briefly discuss each.
8. What are the different types of database end users? Discuss the main activities
of each.
9. Discuss the main characteristics of the database approach and how it differs
from traditional file systems.
10. Draw a simplified diagram of a database system environment.
11. Draw a schema of a mini world database.
12. Explain the workers behind the scene.
24
Navathe
Chapter 3
Data Modeling Using the Entity-
Relationship (ER) Model

43
Navathe
Overview
Chapter 3 : Data Modeling Using the Entity-Relationship (ER) Model
3. Introduction
3.1 Using High–Level Conceptual Data Model for Database Designs
3.2 An Example database application
3.3 Entity types, Entity Sets, Attributes, and keys
3.3.1 Entities and Attributes
3.3.2 Entity types, Entity Sets, keys and Value Sets
3.3.3 Initial conceptual design of the COMPANY database
3.4 Relationships types, Relationship Sets, Roles, and Structural Constraints
3.4.1 Relationships types, Sets, Roles
3.4.2 Relationships Degree, Roles Names, and Recursive Relationships
3.4.3 Constraints on Binary Relationship Types
3.4.4 Attributes of Relationship Types
3.5 Weak Entity Types
3.6 Refining the ER Design for the COMPANY Database
In-Class Exercise & Assignment 4 4
Navathe
ER Model
Entity-Relationship (ER) model:
In this chapter, we follow the traditional approach of
focusing on the database structures and
constraints during conceptual database design.
We present the modeling concepts of the Entity-
Relationship (ER) model, which is a popular high-
level conceptual data model.
This model is frequently used ER diagrams for the
conceptual design of database applications, and
many database design tools employ its concepts.

3
Navathe
Figure 3.1: A simplified diagram to illustrate the main phases
of database design

4
Navathe
Using High-Level Conceptual Data
Models for Database Design
Database design process steps:
1. Requirements collection and analysis: Interview database
users to understand and document their data requirements &
functional requirements (operations, transactions, retrievals
and updates)
2. Create a conceptual schema using a high-level
conceptual data model (ER Model). This step is called
conceptual design.
3. Logical design or data model mapping: Mapping of database
schema in the implementation data model of the DBMS.
4. Physical design phase: In which
the internal storage structures, indexes, file access
organizations,
paths, and for the database files are specif4ie
physical design parameters
d.
ER-Diagram Notation for ER Schemas
Symbol Meaning
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
COMPOSITE ATTRIBUTE DERIVED
ATTRIBUTE
E1 R E2 TOTAL PARTICIPATION OF E2 IN R
N
E1 R E2 CARDINALITY RATIO 1:N FOR E1:E 2 IN R
(min,max) STRUCTURAL CONSTRAINT (min, max) ON

R E

PARTICIPATION OF E IN R
6
Navathe
Entity Types, Entity Sets, Attributes, and
Keys
 Entities- The basic object that the ER model represents is an
entity, which is a thing in the real world with an independent
physical OR conceptual existence.
 E.g. a particular person, car, house, employee or a company, a
job, a university course.
 Attributes - The particular properties that describe an Entity.
E.g.- an EMPLOYEE entity may be described by the
employee's ssn, name, age, address, salary, sex, department
etc..

7
Navathe
Entity Types, Entity Sets, Attributes,
and Keys
 Composite Attributes - Composite attributes can be divided
into smaller subparts. E.g.- The Address attribute of the
EMPLOYEE can be subdivided into Street_address, City, State,
and Zip. Attributes that are not divisible are called Simple
(Atomic) Attributes E.g.- Zip, University ID, Section, Grade etc.
State Zip
Street_address City
Address

8
Navathe
and Keys
 Single-Valued Attributes- Most attributes have a single value
for a particular entity; such attributes are called single-valued.
E.g.- Age is a single-valued attribute of a person.
 Multivalued Attributes- have a set of values for the same
entity. E.g. (1) a Colors attribute for a car, Cars with one color
have a single value, whereas two-tone cars have two color
values.
 E.g.-(2) One person may not have a college degree, another
person may have one, and a third person may have two or
more degrees; therefore, different people can have different
numbers of values for the College_degrees attribute. Such
attributes are called Multivalued.

9
Navathe
and Keys
 Stored Attribute- In some cases, two (or more) attribute
values are related.
 E.g.(1) - the Age and Birth_date attributes of a person. For a
particular person entity, the value of Age can be determined
from the current (today's) date and the value of that person's
Birth_date, hence Age is called Derived attribute and is
derived from the Birth_date attribute, which is called a stored
attribute.
 E.g.(2) An attribute Number_of_employees (Derived) of a
DEPARTMENT entity can be derived by counting the number
of employees related to (working for) that department.

10
Navathe
and Keys
 NULL Values- In some cases, a particular entity may not have
an applicable value/not known/unavailable for an attribute.
 E.g. (1) The Apartment_number attribute of an address applies
only to addresses that are in apartment buildings and not to
other types of residences, such as single-family homes.
 E.g. (2) A College_degrees attribute applies only to people with
college degrees. For such situations, a special value called
NULL is created.
 NULL can also be used if we do not know the value of an attrib-
ute for a particular entity- E.g.- if we do not know the home
phone number of ‘Ali‘.
11
Navathe
and Keys
 Complex Attributes- Composite and Multivalued attributes
can be nested arbitrarily. Such attributes are called Complex
attributes.
Composite
 Example: attribute
Multivalued
attribute
 {Address_phone(
{Phone(Area_code,Phone_number)},Address(Street_address
(Number,Street,Apartment_number),City,State,Zip)
Multivalued )}
attribute
 Composite attribute should be in

mentioned parentheses () between
 Multivalued attributes between braces { }
12
Navathe
Entity Types, Entity Sets, Keys, and
Value Sets
 Entity Types- An entity type defines a collection (or set) of
entities that have the same attributes.
 Entity Sets- The collection of all entities of a particular entity
type in the data base at any point in time is called an entity
set .

55
Navathe
Value Sets
 Key Attributes- An important constraint on the entities of an
entity type is the key or uniqueness constraint on attributes.
 Has one or more attributes in an entity
 Values are distinct/different for each record
 Used to identify each entity uniquely
 Use underlined inside the oval to define
Such an attribute is called a key attribute.
Figure 3.7
The CAR entity
type with two key
attributes

14
Navathe
Value Sets
 Value Sets (Domains) of Attributes- A set of value that
may be assigned to that attribute for each individual entity, in
an entity set is called Value set or Domain.
 E.g.(1)- E.g.- In Employee entity, range of ages allowed for
employees is between 20 and 58 then the value set of the
Age attribute consist of integer numbers between 20 and 58.
Age: Domain[20-58]
 E.g.(2) The value set for the Name attribute to be the set of
strings of alphabetic characters and some special characters
and so on.
 Name: Domain[a-z],[A-Z],blank space, dot,#,_,@ e.c.t.

15
Navathe
Initial Conceptual Design of the COMPANY
Database
 An entity type DEPARTMENT with attributes Name, Number, Locations,
Manager, and Manager_start_date. Locations is the only multivalued
attribute. Name and Number are (separate) key attributes because each
was specified to be unique.
 An entity type PROJECT with attributes Name, Number, Location, and

Controlling_department. Both Name and Number are (separate) key
attributes.

16
Navathe
Initial Conceptual Design of the
COMPANY Database
 An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address,
Salary, Birth_date, Department, and Supervisor. Both Name and
Address may be composite attributes and ssn is key attribute.
 An entity type DEPENDENT with attributes Employee, Dependent_name,

Sex, Birth_date, and Relationship (to the employee).

17
Navathe
Relationship Types, Relationship Sets,
Roles, and Structural Constraints
A Relationship relates two or more distinct entities
withaspecific
meaning.
 E.g.- EMPLOYEE Ali works on a PROJECT or
EMPLOYEEHussian manages the Research DEPARTMENT.
(a) (b)
18
Navathe
Relationship Types, Relationship Sets,
Roles, and Structural Constraints
 Relationships of the same type are grouped or typed into a
relationship type.
 E.g.- The WORKS_ON relationship type in which

EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and
DEPARTMENTs participate in previous figures (a-b).
 A relationship type R among n entity types El' E2' ... , En

defines a set of associations- or a relationship set - among
entities from these entity types.

19
Navathe
Relationship Degree, Role Names, and
Recursive Relationships
 Degree of a Relationship Type- The degree of a relationship type is
the number of participating entity types. Hence, the WORKS_FOR
relationship is of degree two .
 A relationship type of degree two is called Binary, and one of degree
three is called Ternary.
Binary relationships Ternary relationships

6
Navathe
Relationship as Attributes
 A relationship type can have attributes;
 E.g.- HoursPerWeek of WORKS_ON; its value for each

relationship instance describes the number of hours per
week that an EMPLOYEE works on a PROJECT.

21
Navathe
Role Names and Recursive
Relationships.
 Each entity type that participates in a relationship type plays a particular
role in the relationship. The role name signifies the role that a
participating entity from the entity type plays in each relationship instance,
and helps to explain what the relationship means.
 For example, in the WORKS_FOR relationship type, EMPLOYEE plays
the role of employee or worker and DEPARTMENT plays the role of
department or employer.

22
Navathe
Role Names and Recursive
Relationships
We can also have a Recursive relationship type.
 Both participations are same entity type in different roles.
 E.g. - SUPERVISION relationships between EMPLOYEE (in role of supervisor or
boss) and (another) EMPLOYEE (in role of subordinate or worker).
 In following figure, first role participation labeled with 1 and second role
participation labeled with 2.
 In ER diagram, need to display role names to distinguish participations.

23
Navathe
Constraints on Relationship Types
 Also known as Ratio constraints
 Maximum Cardinality
 One-to-One (1:1)
 One-to-Many (1:N) or Many-to-One (N:1)
 Many-to-Many (N:M)
Minimum Cardinality (also called participation

constraint or existence dependency constraints)
 zero (optional participation, not existence-dependent)
 one or more (mandatory, existence-dependent)

24
Navathe
One-to-One (1:1) RELATIONSHIP
(MANAGES)

25
Navathe
Many-to-one (N:1) RELATIONSHIP
(WORKS_FOR)

26
Navathe
Many-to-Many (M:N) RELATIONSHIP
(WORKS_FOR)

27
Navathe
Weak Entity Types
Weak entity that does not have a key attribute itself,
hence it is identified by a partial key, which is the
attribute that can uniquely identify weak entities that
are related to the same owner entity
A weak entity must participate in an identifying
relationship type with an owner or identifying entity
type
Example:
Suppose that a DEPENDENT entity is identified by the dependent’s first
name and birhtdate, and the specific EMPLOYEE that the dependent is
related to. DEPENDENT is a weak entity type with EMPLOYEE as its
identifying entity type via the identifying relationship type
DEPENDENT_OF.
70
Navathe
ER DIAGRAM OF COMPANY SCHEMA
Entity Types are: EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

7
Navathe
Review questions
1. Discuss the role of a high-level data model in the database design process.
2. What do you understand by Entity-Relationship model?
3. List the various cases where use of a NULL value would be appropriate.
4. Define the following terms: entity, attribute, attribute value, relationship,
instance, composite attribute, multivalued attribute, derived attribute, complex
attribute, key attribute, and value set (domain).
5. Explain the difference between an attribute and a value set.
6. What is meant by a recursive relationship type? Give some examples of
recursive relationship types.
7. Define the terms owner entity type, weak entity type, identifying relationship
type, and partial key.
8. Construct a preliminary design of Department, Employee, Product, Car,
Student, Teacher, Mobile, Class, book etc with all its possible attributes.

30
Navathe
Review questions
9. What is an entity type? What is an entity set? Explain the differences among
an entity, an entity type, and an entity set.
10.What is a relationship type? Explain the differences among a relationship
instance, a relationship type, and a relationship set.
11. Discuss the conventions for displaying an ER schema as an ER diagram.
12. Draw a simplified diagram to illustrate the main phases of database design.
13. For the following binary relationships, suggest cardinality ratios based on the
common- sense meaning of the entity types.
Entity 1 Ca rdinality Ratio Entity 2
STUDENT TEACHER EXAM
STUDENT OFFICE
CLASSROOM TEACHER
COURSE WALL
PRODUCT BOOK TEXTBOOK
PRICE
COURSE

31
Navathe
Review questions
14. Draw an ER diagram of UNIVERSITY database, that captures all the given
below requirements. Specify key attribute(s) of each entity set. For each
relationship set, specify structural constraints and participation constraints.
 For each STUDENT, the university maintains student Name, student ID, SSN (S ocial
S ecurity Number), Address, Phone, Birthdate, Gender, Level, Major (CS, IS, CNET).
Both Social Security Number and Student Number have unique values for each
student.
 Each DEPARTMENT is described by a Name, Department code, Department Phone,

and Office address. Both Name and Code have unique values for each department.
 Each COURSE has a Course Name, Description, Course Code, Credit Hours, Level,
and Offering Department. The value of Course Code is unique for each course.
 Each SECTION is associated with an Instructor, Semester, Year, Course, and

Section Number. The Section Number distinguishes sections of the same course
that are taught during the same semester.

74
Navathe
Review questions
15. Draw an ER diagram of COMPANY database, that captures all the given below
requirements. Specify key attribute(s) of each entity set. For each relationship
set, specify structural constraints and participation constraints.
 For each DEPARTMENT, the company maintains Name, department

Number, Manager, Location. Both Name and department Number have
unique values for each student.
 Each PROJECT is described by a Name, Number, Location, and

Controlling Department. Both Name and Number have unique values for
each department.
 Each EMPLOYEE has a SSN, Name, Sex, Department, Address, and Salary. The
value of SSN is unique for each employee, whereas Name, a composite attribute has
Fname, Minit and Lname as a subpart of it.

33
Navathe
Review questions
16. Draw an ER diagram of ONLINE COURSE REGISRATION database, that
captures all the given below requirements. Specify key attribute(s) of each
entity set. For each relationship set, specify structural constraints and
participation constraints.
 For each USER, the portal maintains user ID, Name, E-mail. Each user has
a unique ID. Name is a composite attributes with Fname, Midname, Lname.
 Each COURSE is described by a course Code, Description, Category, and

Term. Both Code and Term have unique values for each course.
 Each LECTUR has a lecturer Title ID, Duration, and Date. The value of ID
is unique for each lecturer.

34
Navathe
Review questions
17. Read the following case study, which describes the data requirements
for a video rental company.
 The video rental company has several branches throughout the USA. The data
held on each branch is the branch address made up of street, city, state, and zip
code, and the telephone number. Each branch is given a branch number, which
is unique throughout the company.
 Each branch is allocated staff, which includes a Manager. The Manager is
responsible for the day-to-day running of a given branch. The data held on a
member of staff is his or her name, position, and salary. Each member of staff is
given a staff number, which is unique throughout the company.
 Each branch has a stock of videos. The data held on a video is the catalog
number, video number, title, category, daily rental, cost, status, and the names
of the main actors and the director. The catalog number uniquely identifies each
video.
 However, in most cases, there are several copies of each video at a branch,
and the individual copies are identified using the video number. A video is given
a category such as Action, Adult, Children, Drama, Horror, or Sci-Fi. The st7a7
tus indC icopayrtigehts© w201h5eRa thmeezrElmaassripaned cSh ifiamckacntoBp. Nyavoathfea video is
Review questions
 Before hiring a video from the company, a customer must first register as a
member of a local branch. The data held on a member is the first and last
name, address, and the date that the member registered at a branch. Each
member is given a member number, which is unique throughout all branches of
the company. Once registered, a member is free to rent videos, up to a
maximum of ten at any one time.
 The data held on each video rented is the rental number, the full name and
number of the member, the video number, title, and daily rental, and the dates
the video is rented out and returned. The rental number is unique throughout
the company.
 Identify the main entity types of the video rental company.
 Identify attributes and associate them with entity or relationship types.
Represent each attribute in the ER diagrams created in (a).
 Determine candidate and primary key attributes for each (strong) entity
type.
 Identify the main relationship types between the entity types described in
(a) and represent each relationship as an ER diagram. 78
Navathe
Chapter 4
The Relational Data Model and
Relational Database Constraints

1
Navathe
Overview
Chapter 4 :The Relational Data Model and Relational Database Constraints
5. Introduction
5.1 Relational model concepts
5.1.1 Domains, Attributes, Tuples, and Relations
5.2 Relational model Constraints and Relational Database Schema
5.2.1 Domain Constraints
5.2.2 Key Constraints and Constraints on NULL Values
5.2.3 Relational Databases and Relational Database Schemas
5.2.4 Integrity, Referential Integrity, and Foreign Keys
In-Class Exercise & Assignment

2
Navathe
Relational Model Concept
 The Relational Model represents the database as a

collection of relations. Informally, each relation resembles a
table of values or, to some extent, a flat file of records.
 It is called a flat file because each record has a simple linear
or flat structure (See Figure 1.2).

3
Navathe
A database that stores STUDENT and
COURSE information

4
Navathe
Domains, Attributes, Tuples, and
Relations
 A domain D is a set of atomic values. By atomic we mean
that each value in the domain is indivisible.
 Example: A domain has a logical definition :
 “KSA_phone_numbers”- are the set of 10 digit phone numbers valid
in the U.S.
 “Social_security_numbers”- The set of valid nine-digit Social Security
numbers.
 A domain may have a data-type or a format defined for it .
The USA_phone_numbers may have a format: (ddd)-ddd-dddd where
each d is a decimal digit.
 Dates have various formats such as month name, date, year or yyyy-
mm-dd, or dd mm,yyyy etc.
 An attribute designates the role played by the domain.
E.g., the domain Date may be used to define attributes “Invoice-date”
and “Payment-date”.
5
Navathe
Relations
 A column header is called an attribute.
 The degree (or arity) of a relation is
thenumberof attributes of its relation schema.
 E.g.: A STUDENT relation of degree of seven
STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)
 Using the data type of each attribute,

thedefinitionis sometimes written as:
 STUDENT(Name:string, Ssn:integer, Home_phone:integer,

Address: string, Office_phone: string, Age: integer, Gpa: real)
6
Navathe
Relations
 A tuple is an ordered set of values
 Each value is derived from an appropriate domain.

 Each row in the STUDENT table may be referred to as a
tuple in the table and would consist of four values.
 STUDENT(ID: integer, Name: string, Section_No: integer,

Major: string)
<201898722, “Ali”,, 33, “CS”>

7
Navathe
Relations
RELATION: A table of values
A relation may be thought of as a set of rows.
A relation may alternately be though of as a set of
columns.
Each row represents a fact that corresponds to a real-
world entity or relationship.
Each row has a value of an item or set of items that
uniquely identifies that row in the table.
Sometimes row-ids or sequential numbers are assigned
to identify the rows in the table.
Each column typically is called by its column name or
column header or attribute name.

8
Navathe
Formal Relational Model Terminology
 A Relation may be defined in multiple ways.
 The Schema of a Relation: R (A1, A2, .....An)
Relation schema R is defined over attributes A1, A2, .....An
For Example -
CUSTOMER (Cust-id, Cust-name, Address, Phone#)
Here, CUSTOMER is a relation defined over the four attributes

Cust-id, Cust-name, Address, Phone#, each of which has a
domain or a set of valid values. For example, the domain of
Cust-id is 6 digit numbers.

9
Navathe
Example Figure 5.1 and Definition
Summary
Informal Terms Formal Terms

Table Relation
Column Attribute/Domain
Row Tuple
Values in a column Domain
Table Definition Schema of a Relation
Populated Table
Extension 10
Navathe
Relational Model Constraints
and Relational Database
Schemas
 Constraints (or restrictions) on the actual
valuesina database state are derived from the rules in the
mini-world.
 Constraints can be divided into three main categories:
1. Constraints that are inherent in the data model. We call these inherent
model-based constraints or implicit constraints.
2. Constraints that can be directly expressed in schemas of the data model,
typically by specifying them in the DDL (data definition language. We call
these schema-based constraints or explicit constraints.
3. Constraints that cannot be directly expressed in the schemas of the data
model, and hence must be enforced by the application programs. We call
.
these application-based or semantic constraints or business rules11
Navathe
Domain Constraints
 Domain constraints specify that within each tuple, the value
of each attribute A must be an atomic value from the domain
dom(A).
 Each table has certain set of columns and each column
allows a same type of data, based on its data type. The
column does not accept values of any other data type.
 E.g.
KSA_phone_numbers(10 digit) – 0543776699
Date_of_Birth(dd/mm/yyyy) – 21/09/1998 Name(A-Z, a-z)
– Ali Hamza
GPA(0 to 5, real numbers) – 3.65
12
Navathe
Key Constraints and Constraints on
NULL Values
 There are three main types of constraints:
1. Key constraints
2. Entity integrity constraints
3. Referential integrity constraints

13
Navathe
Initial Conceptual Design of the COMPANY
Database
 Superkey of R: A set of attributes SK of R such that no two tuples
in any valid relation instance r(R) will have the same value for SK.
That is, for any distinct tuples t1 and t2 in r(R), t1[SK] t2[SK].
 Key of R: A "minimal" superkey; that is, a superkey K such that
removal of any attribute from K results in a set of attributes that is
not a superkey.
Example: The CAR relation schema:
CAR(State, Reg#, SerialNo, Make, Model, Year)
has two keys Key1 = {State, Reg#}, Key2 = {SerialNo}, which are
also superkeys. {SerialNo, Make} is a superkey but not a key.
 If a relation has several candidate keys, one is chosen arbitrarily
to be the primary key. The primary key attributes are underlined.

14
Navathe
Initial Conceptual Design of the
COMPANY Database

15
Navathe
Entity Integrity, Referential Integrity, and
Foreign Keys
 Relational Database Schema: A set S of relation schemas
that belong to the same database. S is the name of the
database.
S = {R1, R2, ..., Rn}
 Entity Integrity: The primary key attributes PK of each
relation schema R in S cannot have null values in any tuple
of r(R). This is because primary key values are used to
identify the individual tuples.
t[PK] null for any tuple t in r(R)
Note: Other attributes of R may be similarly constrained to
disallow null values, even though they are not members of the
primary key.

16
Navathe
Entity Integrity, Referential Integrity, and
Foreign Keys
 Referential Integrity: A constraint involving two relations
(the previous constraints involve a single relation).
 Used to specify a relationship among tuples in two relations:
the referencing relation and the referenced relation.
 Tuples in the referencing relation R1 have attributes FK
(called foreign key attributes) that reference the primary key
attributes PK of the referenced relation R2.
 A tuple t1 in R1 is said to reference a tuple t2 in R2 if
t1[FK] = t2[PK].
 A referential integrity constraint can be displayed in a
relational database schema as a directed arc from R1. FK to
R2 (FK PK). 17
Navathe
Referential Integrity, and Foreign
Keys
PK FK
T_ID Name Department Course_Code# Foreign key (can be)
T001 Ali IS 221 • Duplicate
T002 Hussain CS 452
T003 Rashid CNET 443
• Null
T004 Khalid CS 443 • Reference to Primary
T005 John IS NULL key or Unique key
PK C_Code# Name Level

221 Database-1 5
Primary key 222 Database-2 6
• Unique 443 Multimedia 9
334 Software Eng 8
• Not Null

18
Navathe
Schema diagram of COMPANY database

19
Navathe
Referential Integrity Displayed (PKFK)

20
Navathe
COMPANY database state

21
Navathe
Review questions
1. Define the following terms as they apply to the relational model of data: domain,
attribute, tuple, relation schema, relation state, degree of a relation, relational
database schema, and relational database state etc.
2. Why are duplicate tuples not allowed in a relation?
3. What is the difference between a key and a superkey?
4. Define key, Super key, Candidate key, Primary key, and foreign key.
5. Compare the differences between primary key and foreign key.
6. Discuss the entity integrity and referential integrity constraints.
7. Identify the Super key, Candidate key, Primary key, Foreign Key in the below
relation.
T_ID Name Department Course_Code#
T001 Ali IS 221
T002 Hussain CS 452
T003 Rashid CET 443
T004 Khalid CS 443

100
Navathe
Review questions
8. Consider the following relations for a database that keeps track of automobile
sales in a car dealership, Specify the foreign keys for this schema, stating any
assumptions you make.
CAR(SerialNo, Model, Manufacturer, Price) OPTION(SerialNo,
OptionName, Price) SALE(SalespersoId, SerialNo, Date,
Sale_price) SALESPERSON(SalespersonId, Name, Phone)
9. Consider the following relations for a database that keeps track of student
enrollment in courses and the books adopted for each course. Draw a
relational schema diagram specifying the foreign keys for this schema.
STUDENT (SSN , Name, Major, Bdate) COURSE (Course#, Cname, Dept)

ENROLL (SSN , Course#, Quarter, Grade)
BOOK_ADOPTION(Course#, Quarter, Book_ISBN)
TEXT(Book_ISBN, Book_Title, Publisher, Author)

23
Chapter 2
Database System Concepts and
Architecture
25
Navathe
Overview
Chapter-2 : Database System Concepts and Architecture
2. Introduction
2.1 Data models, Schemas and Instances
2.1.1 Categories of Data Models
2.1.2 Schemas, Instances, and Database State
2.2 Three schema architecture and data independence
2.2.1 The Three-Schema Architecture
2.2.2 Data Independence
2.3 Database languages and interfaces
2.3.1 DBMS Languages
2.3.2 DBMS Interfaces
2.4 DBMS system environment
2.4.1 DBMS Component Modules
2.4.2 Database System Utilities
2.4.3 Tools, Application Environments
In-Class Exercise & Assignment
26
Navathe
Data Model & Data Abstraction
Data Model:
A data model is a collection of concepts that can
be used to describe the structure of a database-
provides the necessary means to achieve this
abstraction. By structure of a database we mean
the data types, relationships, and constraints
that apply to the data.
Data abstraction:
It generally refers to the hiding of details of data
organization and storage, and the highlighting of
the essential features for an improved
understanding of data.
27
Navathe
Categories of Data Modelsx
 High-level or conceptual data models: provide concepts
that are close to the way many users perceive data.
 Low-level or physical data models: provide concepts that
describe the details of how data is stored on the computer’s disk.
 An access path is a structure that makes the search for particular
database records efficient.
 An index is an example of an access path that allows direct access
to data using an index term or a keyword.
Between these two extremes we have,
 Representational or implementation data models 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 (hard disks). 4
Navathe
Categories of Data Models (Continued)
 Conceptual data models use concepts such as
entities, attributes, andrelationships.
 Entity represents a real-world object or
concept,suchasan
employee or a project from the mini-world.
 Attribute represents some property of interest
entity, further
describes anthat such as the employee's name or salary.
 Relationship among two or more entities
representsanamong the entities,
association
 Example, a works-on relationship between an employee and a
project. (See chapter-3 : Entity-Relationship model).
Employee works-on Project

5
Navathe
Schemas, Instances, and Database State
 Schemas: The description of a database is called the database
schema.
 Schema diagram: A displayed schema
iscalledaschema
diagram. (See Figure 2.1)

6
Navathe
Schemas, Instances, and Database State
 Schema construct: Each object in the schema - such as
STUDENT or COURSE- is a schema construct.
 Database state or Snapshot: The data in the database at a
particular moment in time is called a database state or
snapshot . It is also called the current set of occurrences or
instances.
 The distinction between database schema and database
state is very important.
 When we define a new database, we specify its database
schema only to the DBMS. At this point, the corresponding
database state is the empty state with no data. We get
the initial state of the database when the database is first
populated or loaded with the initial data. 7
Three-Schema Architecture and
Data Independencex
 Three of the four important characteristics of the database
approach:
(1) Use of a catalog to store the database description (schema) so as
to make it self-describing,
(2) Insulation of programs and data (program-data and program-
operation independence), and
(3) Support of multiple user views.

8
Navathe
The Three-Schema Architecture

9
Navathe
The Three-Schema Architecture
1. Internal schema (Internal level) at the internal level to
describe physical storage structures and access paths.
Typically uses a physical data model.
2. Conceptual schema (Conceptual level) describes the

structure of the whole database. It hides the details of physical
storage structures and concentrates on describing entities, data
types, relationships, user operations, and constraints.
3. External schema (view level), 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.

10
Navathe
Data Independencex
Logical data independence is the capacity to change the
conceptual schema without having to change external schemas
or 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).
Physical data independence is the capacity to change
the internal schema without having to change the conceptual
schema. Hence, the external schemas need not be changed as
well.
11
Navathe
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.
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 or an Assembly Language.

12
Navathe
DBMS Languages (Continued)x
High Level or Non-procedural e.g.,
SQL,
Languages
are: set-oriented and specify what data
to retrieve than how to retrieve. Also called declarative
languages.
Low Level or Procedural Languages: record-at-a-

time; they specify how to retrieve data and include constructs
such as looping.

13
Navathe
DBMS Interfaces
User-friendly interfaces:
Menu-based, popular for browsing on the web
Forms-based, designed for naïve users
Graphical User Interface (Point and Click, Drag and Drop
etc.)
Natural language: requests in written English
Speech as Input (?) and Output
Parametric interfaces (e.g., bank tellers) using function
keys.
Interfaces for the DBA: Creating accounts, granting
authorizations, Setting system parameters, Changing
schemas or access path

14
Navathe
The Database System Environment
DBMS Component Modules

15
Navathe
Database System Utilitiesx
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.
Database storage reorganization reorganizes a set
of database files into different file organizations, and
create new access paths to improve performance.
Performance monitoring utility monitors database
usage and provides statistics to the DBA. such as
whether or not to reorganize files or whether to add or
drop indexes to improve performance.
16
Navathe
Tools and Application Environments
Data dictionary / repository : Used to store schema
descriptions and other information such as design
decisions, application program descriptions, user
information, usage standards, etc.
Active data dictionary is accessed by DBMS software
and users/DBA.
Passive data dictionary is accessed by users/DBA
only.
Application Development Environments and CASE
(computer-aided software engineering) tools:
Examples – Power builder (Sybase), Builder (Borland)
17
Review questions
1. Define the following terms: data model, database schema, database state,
internal schema, conceptual schema, external schema, data independence,
access path, DDL, DML, SDL, VDL, query language, host language, data
sublanguage, database utility etc.
2. List down the main categories of data models.
3. What is the difference between a database schema and a database state?
4. What is the difference between logical data independence and physical data
independence?
5. Draw the diagram of three-schema architecture.
6. What is the difference between procedural and nonprocedural DMLs?
7. List down the different types of user-friendly interfaces.
8. With what other computer system software does a DBMS interact?
9. Discuss the main categories of data models.
10. Explain the three-schema architecture with the help of its diagram.
11. Discuss the different types of user-friendly interfaces and the types of users who
typically use each.
12. Discuss some types of database utilities and tools and their
42
Navathe

CH1 - 380CSS-3 - Fundamentals of Database Systems-Merged

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH1 - 380CSS-3 - Fundamentals of Database Systems-Merged

Uploaded by

Copyright:

Available Formats

380CSS-3 Fundamentals of

Copyright © 2015 Ramez Elmasri and Shamkant B.

CHAPTER TOPICS PAGE

1 Databases and Database Users 3 – 24

2 Database System Concepts and Architecture 25 – 42

3 Data Modeling Using the Entity-Relationship 43 – 78

4 The Relational Data Model and Relational 79 – 101

5 Relational Algebra 102 – 123

6 Functional Dependencies and Normalization for 124 - 153

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

 Note: The above entities and relationships are typically

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

IDENTIFYING RELATIONSHIP TYPE

(min,max) STRUCTURAL CONSTRAINT (min, max) ON

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

 Composite attribute should be in

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

 An entity type PROJECT with attributes Name, Number, Location, and

Copyright © 2015 Ramez Elmasri and Shamkant B.

 An entity type DEPENDENT with attributes Employee, Dependent_name,

Copyright © 2015 Ramez Elmasri and Shamkant B.

 E.g.- The WORKS_ON relationship type in which

 A relationship type R among n entity types El' E2' ... , En

Copyright © 2015 Ramez Elmasri and Shamkant B.

Binary relationships Ternary relationships

 E.g.- HoursPerWeek of WORKS_ON; its value for each

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Minimum Cardinality (also called participation

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

Copyright © 2015 Ramez Elmasri and Shamkant B.

 Each DEPARTMENT is described by a Name, Department code, Department Phone,

 Each SECTION is associated with an Instructor, Semester, Year, Course, and

Copyright © 2015 Ramez Elmasri and Shamkant B.