CET2002B Database Management

Systems

SCHOOL OF COMPUTER ENGINEERING AND TECHNOLOGY

National Assessment and Accreditation Council
(NAAC)
Education plays a vital role in the development of any nation. Therefore, there is a premium on
both quantity (increased access) and quality (relevance and excellence of academic programmes
offered) of higher education. The NAAC has been set up to facilitate the volunteering institutions
to assess their performance vis-a-vis set parameters through introspection and a process that
provides space for participation of the institution.
National Institutional Ranking Framework (NIRF)
The National Institutional Ranking Framework (NIRF) was approved by the MHRD in 2015
for the purpose of accessing educational institutes according to following parameters.

NIRF Ranking Parameters:

1. Teaching Learning & Resources

2. Research and Professional Practice
3. Graduation Outcome
4. Outreach & Inclusivity
5. Perception
Vision and Mission of SCET
CET2002B Database Management Systems Syllabus

UNIT I - INTRODUCTION TO DBMS AND DATA MODELING

DBMS Vs File Systems, Database System Architecture, Database Architectures: Centralized, Client-Server, Parallel,
Distributed, Data Abstraction, Data Independence, Data Definition and Data Manipulation Languages, Data Models ,
E-R diagram: Components of E-R Model,
Conventions, Keys, EER diagram Components, Reduce E-R diagram into Tables

UNIT- II - RELATIONAL DATABASE DESIGN AND NORMALISATION

Relational Model: Attributes, Tuple, Domain, CODD’s rule Relational Integrity, Referential Integrities, Enterprise
Constraints, Normalisation: 1NF, 2NF, 3NF, BCNF, Functional dependency, Decomposition Query Processing:
Overview, Measures of Query cost, Selection and Join operations, Evaluation of Expressions, Introduction to Query
optimization: Estimation, Transformation of Relational Expression

UNIT III - RELATIONAL ALGEBRA AND DATABASE PROGRAMMING

Relational Algebra, Basic Operations, Relational calculus: Tuple Calculus, Domain Calculus, Introduction to SQL,
Characteristics and advantages of SQL, SQL Data Types, DDL Commands, DCL Commands. SQL Queries: DML
Queries with Select Query Clauses, Creating, Modifying, Deleting.
Views: Creating, Dropping, Updating, Indexes, SQL DML Queries, Set Operations, Predicates and Joins, Set
membership, Grouping and Aggregation, Aggregate Functions, Nested Queries
CET2002B Database Management Systems Syllabus

UNIT IV - ADVANCED DATABASE PROGRAMMING

PL/SQL Concepts: PL/SQL Functions and Procedures, Cursors, Database Triggers.Complex Data Types: Semi
structure data: XML, Document Type Definitions (DTDs), XML Schemas, XPATH, XSL, XSLT
Unstructured data: JSON, Data types, Application of DBMS

UNIT- V - TRANSACTION MANAGEMENT AND CONCURRENCY CONTROL

ACID properties, transactions, schedules and concurrent execution of transactions, serializability: View, Conflict.
Concurrency control lock based protocol (simple, 2 phase: Rigorous 2 phase, Strict 2 phase), Cascade-less Schedule,
Recoverable Schedule,
Deadlocks: Prevention Techniques (Wait Die, Wound Wait), Detection Techniques, Database Recovery: Failure
classification Recovery and atomicity: Log-based recovery, Shadow paging.
 CET2002B Database Management Systems
Course Objectives:

1. Knowledge
i. Understand the fundamental concepts of database management System
ii. To provide a strong formal foundation in database concepts, DBMS architectures recent
technologies and best industry practices.

2. Skills
i. To learn the SQL database system.
ii. To program PL/SQL including stored procedures, stored functions, cursors and packages.

3. Attitude
i. To design the database system for real world applications.
ii. To access, modify, program and authenticate the database system..

DATABASE MANAGEMENT SYSTEMS 8

 CET2002B Database Management Systems

Course Outcomes:
Upon completion of the course, the students will be able to:
1. Understand the different data models
2. Implement relational database design from any data model.
3. Create database system for real world applications
4. Handle the transaction management system.

DATABASE MANAGEMENT SYSTEMS 9

Assessment Scheme
Class Continuous Assessment (CCA) – 30 marks

Theory Assignment (CCA) – Week 10

Active Learning (CCA) – Week 15

Laboratory Continuous Assessment (LCA) – 30 marks

Term End Examination: 40 Marks

Bloom’s Taxonomy
 Database Management System Basics

▪ It contains information about a particular enterprise. Database Applications

• Banking: Transactions
▪ It provides : • Airlines: Reservations, Schedules
⮚Collection of interrelated data. • Universities : Student Registration.
• Sales: Customers, Orders, Products
⮚Set of programs to access the collected data. • Online retailers : Order tracking,
⮚An environment that is both recommendations
• Manufacturing :Production,
convenient and efficient to use. Inventory, Supply Chain
⮚Databases touch all aspects of our lives. • Human Resources :Employee
payroll.

DATABASE MANAGEMENT SYSTEMS 12

 Motivation for Database Management Systems
Traditional file Systems have following drawbacks to store data :
▪ Data Redundancy and Inconsistency
⮚Multiple file formats, duplication of information in different files
▪ Difficulty in accessing data
⮚Need to write a new program to carry out each new task.
▪ Data Isolation
⮚Multiple files and formats.
Question : What can be other drawbacks related to usage of file systems ?

DATABASE MANAGEMENT SYSTEMS 13

 Motivation for Database Management Systems
Answer : Traditional file Systems have following drawbacks to store data:
▪ Integrity Problems
⮚Integrity constraints (e.g., account balance > 0) become “buried” in
program code rather than being stated explicitly
⮚Difficult to add new constraints or change existing ones
▪ Atomicity of Updates
⮚Failures may leave database in an inconsistent state with partial updates
carried out.

DATABASE MANAGEMENT SYSTEMS 14

 Motivation for Database Management Systems
Traditional file Systems have following drawbacks to store data :
▪ Concurrent Access by Multiple users
⮚Concurrent access needed for performance.
⮚Uncontrolled concurrent accesses can lead to inconsistencies.
▪ Security Problems
⮚Hard to provide user access to some, but not all, data
Database Management Systems offers solutions to all the above
problems/limitations of traditional file systems.

DATABASE MANAGEMENT SYSTEMS 15

 Database System Architectures

• Centralized
• Client-Server Systems
• Parallel Systems
• Distributed Systems

16
Centralized Systems
• Run on a single computer system and do
not interact with other computer
systems.
• General-purpose computer system: one
to a few CPUs and a number of device
controllers that are connected through a
common bus that provides access to
shared memory.
• Single-user system (e.g., personal
computer or workstation): desk-top unit,
single user, usually has only one CPU
and one or two hard disks; the OS may
support only one user.
• Multi-user system: more disks, more
memory, multiple CPUs, and a multi-
user OS. Serve a large number of users
who are connected to the system vie
terminals. Often called server systems.

17
Client-Server
Systems
• Server systems satisfy requests
generated at m client systems,
whose general structure is
shown in the dig.
• Database functionality can be
divided into:
• Back-end: manages access
structures, query evaluation
and optimization,
concurrency control and
recovery.
• Front-end: consists of tools
such as forms, report-writers,
and graphical user interface
facilities.
• The interface between the front-
end and the back-end is through
SQL or through an application
program interface.
Parallel Systems
• Parallel database systems
consist of multiple processors
and multiple disks connected by
a fast interconnection network.
• A coarse-grain parallel machine
consists of a small number of
powerful processors
• A massively parallel or fine
grain parallel machine utilizes
thousands of smaller processors.
• Two main performance
measures:
• throughput --- the number of
tasks that can be completed in a
given time interval
• response time --- the amount of
time it takes to complete a single
task from the time it is submitted

19
Distributed
Systems
• Data spread over multiple machines (also
referred to as sites or nodes).
• Network interconnects the machines
• Data shared by users on multiple machines
• Homogeneous distributed databases
• Same software/schema on all sites, data
may be partitioned among sites
• Goal: provide a view of a single
database, hiding details of distribution
• Heterogeneous distributed databases
• Different software/schema on different
sites
• Goal: integrate existing databases to
provide useful functionality
• Differentiate between local and global
transactions
• A local transaction accesses data in the
single site at which the transaction was
initiated.
• A global transaction either accesses data
in a site different from the one at which the
transaction was initiated or accesses data in
several different sites.

20
 Levels of Data Abstraction in Database System

▪ Physical level: describes how a record (e.g.,

customer) is stored.

▪ Logical level: describes data stored in database, and

the relationships among the data.
type instructor = record
ID : string;
name : string;
dept_name : string;
salary : integer;
end;

▪ View level: application programs hide details of

data types. Views can also hide information (such as
Levels of Abstraction in a Database System an employee’s salary) for security purposes.

DATABASE MANAGEMENT SYSTEMS 21

 Instances and Schema

▪ Schema – the logical structure of the

database
◦ Example: The database consists of information about a set
of customers and accounts and the relationship between
them
⮚ Physical schema: database design at the physical level
⮚ Logical schema: database design at the logical level

– the actual content of the

▪ Instance
database at a particular point in time
⮚ Analogous to the value of a variable.
DATABASE MANAGEMENT SYSTEMS 22
 Data Independence
Types of Data Independence :
▪ Physical Data Independence : the ability to modify the physical schema without
changing the logical schema
⮚ Applications depend on the logical schema
⮚In general, the interfaces between the various levels and components should be
well defined so that changes in some parts do not seriously influence others.

▪ Logical Data Independence : the ability to change the conceptual scheme without
changing
⮚External views
⮚External API or programs
⮚Any change made will be absorbed by the mapping between external and
conceptual levels.
⮚When compared to Physical Data independence, it is challenging to achieve
logical data independence.
DATABASE MANAGEMENT SYSTEMS 23
Examples of Physical and Logical Data independence

Physical Data Independence : Logical Data Independence:

• Using a new storage device like Hard • Add/Modify/Delete a new attribute,

Drive or Magnetic Tapes entity or relationship is possible
• Modifying the file organization without a rewrite of existing
technique in the Database application programs
• Switching to different data structures. • Merging two records into one
• Changing the access method. • Breaking an existing record into two
• Modifying indexes. or more records
• Changes to compression techniques
or hashing algorithms.
• Change of Location of Database
from say C drive to D Drive
 Data Models
A collection of tools for describing :
▪ Data
▪ Data relationships
▪ Data semantics
▪ Data constraints

DATABASE MANAGEMENT SYSTEMS 25

Database System Languages

Data Definition Language(DDL) Data Manipulation Language(DML)

Specification notation for defining the database Language for accessing and manipulating the data
schema Example: create table instructor ( organized by the appropriate data model
ID char(5),
name varchar(20), ◦ DML also known as query language
dept_name varchar(20),
salary Two classes of languages
numeric(8,2)) ◦ Procedural – user specifies what data is required
DDL compiler generates a set of table templates stored in a and how to get those data
data dictionary ◦ Declarative (nonprocedural) – user specifies
what data is required without specifying how to
Data dictionary contains metadata (i.e., data about get those data
data)
◦ Database schema
SQL is the most widely used query language
◦ Integrity constraints
◦ Primary key (ID uniquely identifies instructors)
◦ Referential integrity (references constraint in SQL)
◦ e.g. dept_name value in any instructor tupleMANAGEMENT
DATABASE must SYSTEMS 26
appear in department relation
Database System Structure/Architecture

Important Components of
Database System :
⮚Database Users
⮚Query Processing
⮚Storage Management
⮚Transaction Management

DATABASE MANAGEMENT SYSTEMS 27

Database System Components : Database Users

Types of Database Users :

⮚Naive Users
⮚Application Programmers
⮚Sophisticated Users
⮚Database Administrators

DATABASE MANAGEMENT SYSTEMS 28

Database System Components : Query Processing

Query Processing
Steps :

1.Parsing and
Translation
2.Optimization
3.Evaluation

DATABASE MANAGEMENT SYSTEMS 29

 Database System Components :Storage
Management
Storage manager : is a program module Issues:
that provides the interface between the
low-level data stored in the database and
the application programs and queries ▪ Storage access
submitted to the system. ▪ File organization
It is responsible for the following tasks: ▪ Indexing and hashing
▪ Interaction with the file manager
▪ Efficient storing, retrieving and
updating of data

DATABASE MANAGEMENT SYSTEMS 30

 Database System Components :Transaction
Management
What if the system fails? ▪ Transaction-management component
What if more than one user is concurrently updating ensures that the database remains in a
consistent (correct) state despite system
the same data?
failures (e.g., power failures and operating
A transaction is a collection of operations that system crashes) and transaction failures.
performs a single logical function in a database
application. ▪ Concurrency-control manager controls
the interaction among the concurrent
Two Important Components related to
transactions, to ensure the consistency of
Transactions:
the database.
▪ Transaction Manager
▪ Concurrency Control Manager

DATABASE MANAGEMENT SYSTEMS 31

 Entity Relationship Model
▪ A database can be modeled as:
◦ a collection of entities,
◦ relationship among entities.
▪ An entity is an object that exists and is distinguishable
from other objects.
◦ Example: specific person, company, event, plant
▪ Entities have attributes
◦ Example: people have names and addresses
▪ An entity set is a set of entities of the same type that
share the same properties.
◦ Example: set of all persons, companies, trees,
holidays
DATABASE MANAGEMENT SYSTEMS 32
 Relationship Sets

A relationship is an association among several entities

Example:
44553 (Peltier) advisor 22222
(Einstein)
student entity relationship set instructor
entity
A relationship set is a mathematical relation among n ≥
2 entities, each taken from entity sets
{(e1, e2, … en) | e1 ∈ E1, e2 ∈ E2, …, en
∈ En}

where (e1, e2, …, en) is a relationship

◦ Example:
(44553,22222) ∈ advisor DATABASE MANAGEMENT SYSTEMS 33
 Relationship Sets

▪ An attribute can also be property of a

relationship set.
⮚For instance, the advisor relationship
set between entity sets instructor and
student may have the attribute date
which tracks when the student started
being associated with the advisor

DATABASE MANAGEMENT SYSTEMS 34

 Degree of a Relationship Set

▪ Binary relationship ▪ Ternary relationship

⮚involve two entity sets (or degree two). ⮚ Example: students work on research
projects under the guidance of an
⮚most relationship sets in a database
instructor.
system are binary.
⮚ relationship proj_guide is a ternary
Relationships between more than two entity relationship between instructor, student,
sets are rare. Most relationships are binary. and project

DATABASE MANAGEMENT SYSTEMS 35

 Attributes

▪ Attribute types
⮚ Simple and composite attributes. ▪ An entity is represented by a set of
⮚ Single-valued and multivalued attributes. attributes, that is descriptive properties
Example: multivalued attribute: possessed by all members of an entity set.
phone_numbers ◦ Example:
⮚ Derived attributes instructor = (ID, name, street, city,
Can be computed from other attributes
salary )
Example: age, given date_of_birth
course= (course_id, title, credits)

▪ Domain – the set of permitted values for

each attribute

DATABASE MANAGEMENT SYSTEMS 36

 Mapping Cardinality Constraints

Express the number of entities to which

another entity can be associated via a
relationship set.
Most useful in describing binary relationship
sets.
One to one One to many
For a binary relationship set the mapping
cardinality must be one of the following types:
⮚One to one
⮚One to many
⮚Many to one
⮚Many to many Many to one Many to many
DATABASE MANAGEMENT SYSTEMS 37
 Keys for Relationship Sets

The combination of primary keys of the participating entity sets forms a

super key of a relationship set.
◦ (s_id, i_id) is the super key of advisor
◦ NOTE: this means a pair of entity sets can have at most one
relationship in a particular relationship set.
◦ Example: if we wish to track multiple meeting dates between a student and
her advisor, we cannot assume a relationship for each meeting. We can use a
multivalued attribute though
Must consider the mapping cardinality of the relationship set when deciding
what are the candidate keys

DATABASE MANAGEMENT SYSTEMS 38

Entity Relationship
Diagram

DATABASE MANAGEMENT SYSTEMS 39

 Entity-Relationship Diagram
It is a graphical Representation of ER Model
Basic Notations :

▪ Rectangles represent entity sets.

▪ Diamonds represent relationship sets.
▪ Attributes listed inside entity rectangle
▪ Underline indicates primary key attributes

DATABASE MANAGEMENT SYSTEMS 40

 Entity Relationship Diagram Continued
▪ Entity With Composite, ▪ Relationship Sets with Attributes
Multivalued, and Derived
Attributes

DATABASE MANAGEMENT SYSTEMS 41

 Entity Relationship Diagram Continued

Roles
⮚ Entity sets of a relationship need not be distinct.
⮚Each occurrence of an entity set plays a “role” in the relationship.
The labels “course_id” and “prereq_id” are called roles.

DATABASE MANAGEMENT SYSTEMS 42

 Entity Relationship Diagram Continued

Cardinality Constraints
⮚We express cardinality constraints by drawing either a directed line (→), signifying “one,” or
an undirected line (—), signifying “many,” between the relationship set and the entity set.
1. One-to-One Relationship
one-to-one relationship between an
instructor and a student
◦ an instructor is associated with at
most one student via advisor
◦ and a student is associated with at
most one instructor via advisor

DATABASE MANAGEMENT SYSTEMS 43

 Entity Relationship Diagram Continued

b. One-to-Many Relationship
A one-to-many relationship between an instructor and a student
⮚a an instructor is associated with several (including 0) students via advisor
⮚student is associated with at most one instructor via advisor
c. Many-to-One Relationship
In a many-to-one relationship between an instructor and a student,
⮚an instructor is associated with at most one student via advisor,
⮚and a student is associated with several (including 0) instructors via advisor
d. Many-to Many Relationship
⮚An instructor is associated with several (possibly 0) students via advisor

⮚A student is associated with several (possibly 0) instructors via advisor

DATABASE MANAGEMENT SYSTEMS 44
 Entity Relationship Diagram Continued

Participation of an Entity Set in a Relationship

Set
▪ Total participation (indicated by double line):
every entity in the entity set participates in at least
one relationship in the relationship set
• E.g., participation of section in sec_course is
total
4 every section must have an associated
course
▪ Partial participation: some entities may not
participate in any relationship in the relationship
set
▪ Example: participation of instructor in advisor
is partial DATABASE MANAGEMENT SYSTEMS 45
 Entity Relationship Diagram : Weak Entity Sets

⮚An entity set that does not have a primary key is referred to as a
weak entity set.
⮚The existence of a weak entity set depends on the existence of a
identifying entity set
◦ It must relate to the identifying entity set via a total, one-to-
set
many relationship set from the identifying to the weak entity
◦ Identifying relationship depicted using a double diamond ▪ We underline the discriminator of a
weak entity set with a dashed line.
⮚The discriminator (or partial key) of a weak entity set is the set ▪ We put the identifying relationship
of attributes that distinguishes among all the entities of a weak of a weak entity in a double
entity set.
diamond.
The primary key of a weak entity set is formed by the primary key ▪ Primary key for section –
of the strong entity set on which the weak entity set is existence (course_id, sec_id, semester, year)
dependent, plus the weak entity set’s discriminator.
DATABASE MANAGEMENT SYSTEMS 46
Example of Strong and Weak Entity

Strong Entity :
Professor(ID,Name,City,Salary)

Weak Entity :
Dependent(Name,DOB,Relation)
The Dependent Entity will share the ID
attribute of Professor.
Resultant Schema :
Dependent(ID,Name,DOB,Relation)
The primary key for Weak Entity Dependent
will be ID + Name as Name is the
discriminator attribute.

DATABASE MANAGEMENT SYSTEMS 47

 E-R Diagram Example
Question : Design an ER Diagram for Airline Reservation scenario given below :
The flight database stores details about an airline’s fleet, flights, and seat bookings.
Consider the following scenario:
• The airline has one or more airplanes.
• An airplane has a model number, a registration number, and the capacity to take one or more passengers.
• An airplane flight has a unique flight number, a departure airport, a destination airport, a departure date
and time, and an arrival date and time.
• Each flight is carried out by a single airplane.
• A passenger has given names(first name, last name),contact and a unique email address.
• Passengers can book seats on flights.

DATABASE MANAGEMENT SYSTEMS 48

 Flight Reservation ERD
Last
Name
Contact
Airline Passenger
_name Airline
Name

Email
Has Books
First
NAme
Model
_no

Airplane particip Flight

Model_ ates To
name

Flight_ Arrival_Dat
Capacity
No e_Time
From Departure
_Date_Ti
me
DATABASE MANAGEMENT SYSTEMS 49
Extended ER Features :
⮚ Specialization
⮚ Generalization
⮚ Aggregation

DATABASE MANAGEMENT SYSTEMS 50

 Extended ER Features : Specialization

⮚Top-down design process; we designate subgroupings within an entity set that are distinctive from
other entities in the set.
⮚These subgroupings become lower-level entity sets that have attributes or participate in relationships
that do not apply to the higher-level entity set.
⮚Depicted by a triangle component labeled IS A (E.g., instructor “is a” person).
⮚Attribute inheritance – a lower-level entity set inherits all the attributes and relationship
participation of the higher-level entity set to which it is linked.

DATABASE MANAGEMENT SYSTEMS 51

Specialization : Example

DATABASE MANAGEMENT SYSTEMS 52

 Extended ER Features : Generalization
⮚A bottom-up design process – combine a number of entity sets that share the
same
features into a higher-level entity set.
⮚Specialization and generalization are simple inversions of each other; they
are represented in an E-R diagram in the same way.
⮚The terms specialization and generalization are used interchangeably.

DATABASE MANAGEMENT SYSTEMS 53

Generalization : Example

DATABASE MANAGEMENT SYSTEMS 54

 Extended ER Features : Aggregation

▪ Consider the ternary relationship proj_guide, which

we saw earlier
▪ Suppose we want to record evaluations of a student
by a guide on a project.

▪ Relationship sets eval_for and proj_guide represent

overlapping information
▪ Every eval_for relationship corresponds to a
proj_guide relationship
▪ However, some proj_guide relationships may not
correspond to any eval_for relationships
◦ So we can’t discard the proj_guide relationship
DATABASE MANAGEMENT SYSTEMS 55
 Extended ER Features : Aggregation
⮚Eliminate this redundancy via aggregation
▪ Treat relationship as an abstract entity
▪ Allows relationships between relationships
▪ Abstraction of relationship into new entity

⮚Without introducing redundancy, the

following diagram represents:
▪ A student is guided by a particular instructor on a
particular project
▪ A student, instructor, project combination may have
an associated evaluation

DATABASE MANAGEMENT SYSTEMS 56

Reduction of ER Diagram to
Relation Schemas

DATABASE MANAGEMENT SYSTEMS 57

 Reduction to Relation Schemas

▪ Entity sets and relationship sets can be expressed uniformly as relation

schemas that represent the contents of the database.
▪ A database which conforms to an E-R diagram can be represented by a
collection of schemas.
▪ For each entity set and relationship set there is a unique schema that is
assigned the name of the corresponding entity set or relationship set.
▪ Each schema has a number of columns (generally corresponding to
attributes), which have unique names

DATABASE MANAGEMENT SYSTEMS 58

 Reduction to Relation Schemas
Representing Entity Sets with Simple Attributes
Representing Relationship Sets :

A strong entity set reduces to a schema with the same

attributes
course(course_id,title,credits) A many-to-many relationship set is represented as
course_id title credits a schema with attributes for the primary keys of
the two participating entity sets, and any
descriptive attributes of the relationship set.
A weak entity set becomes a table that includes a
column for the primary key of the identifying strong Example: schema for relationship set advisor
entity set advisor = (s_id, i_id) S_id i_id
section ( cours
Course_id _id,
e Sec_idid, sem,
sem ) year
sec_ year DATABASE MANAGEMENT SYSTEMS 59
 Reduction to Relation Schema
Redundancy of schemas:
▪ Many-to-one and one-to-many relationship sets that are total on the many-side can be
represented by adding an extra attribute to the “many” side, containing the primary
key of the “one” side.
Inst_d
Dept Instructor
ept

Example: Instead of creating a schema for relationship set inst_dept, add an attribute
dept_name to the schema arising from entity set instructor

DATABASE MANAGEMENT SYSTEMS 60

 Redundancy of Schemas
• For one-to-one relationship sets, either side can be chosen to act as the “many” side
– That is, extra attribute can be added to either of the tables corresponding to the two
entity sets
• If participation is partial on the “many” side, replacing a schema by an extra attribute
in the schema corresponding to the “many” side could result in null values
• The schema corresponding to a relationship set linking a weak entity set to its
identifying strong entity set is redundant.
– Example: The section schema already contains the attributes that would appear in the
sec_course schema
 Reduction to Relation Schema
Representing Composite and Multi-valued
Attributes
▪ Composite attributes are flattened out by creating a
separate attribute for each component attribute
◦ Example: given entity set instructor with composite
attribute name with component attributes first_name and
last_name the schema corresponding to the entity set has
two attributes name_first_name and name_last_name
◦ Prefix omitted if there is no ambiguity
▪ Ignoring multivalued attributes, extended instructor schema is :
ID First_nam Middle_initial Last_name Street_ Street_ Apt_num city state zip Date_of
e number name ber _birth

DATABASE MANAGEMENT SYSTEMS 62

 Reduction to Relation Schema
Representing Composite and Multi-valued Attributes
A multivalued attribute M of an entity E is represented by a
separate schema EM
◦ Schema EM has attributes corresponding to the primary key of
E and an attribute corresponding to multivalued attribute M
◦ Example: Multivalued attribute phone_number of instructor is
represented by a schema:
inst_phone= ( ID, phone_number)
◦ Each value of the multivalued attribute maps to a separate tuple
of the relation on schema EM ID Phone_number
◦ For example, an instructor entity with primary key 22222 22222 456-7890
and phone numbers 456-7890 and 123-4567 maps to two 22222 123-4567
tuples:
DATABASE MANAGEMENT SYSTEMS 63
(22222, 456-7890) and (22222, 123-4567)
Extended ER Features Reduction to Relation Schemas

DATABASE MANAGEMENT SYSTEMS 64

Example for Reduction of ER Diagram to Relation schemas
University
1
Reduced
Schema-Names
Contains University

N Faculty
Faculty School
1
Program
Divided
into Lecturer

Course
1 N 1
School offers Program Student
1
Full-time_
Lecturer
Employe
contains
e Part-
time_Lecturer
M N
M N Lect_Course
Lecturer teaches Course enrolls (Associative
N Entity due to
IS M:M)
A
enrolls Student_Course(
Contact Associative Entity
Full-Time Part-time N due to M:M)
Lecturer DATABAS MANAGEMENT SYSTEMS
Lecturer N 50
E Student
 References

Text Books:
• Abraham Silberschatz, Henry F. Korth and S. Sudarshan, Database System Concepts 6th
Ed, McGraw Hill, 2010.
• Elmasi, R. and Navathe, S.B., “Fundamentals of Database Systems”, 4th
• Ed., Pearson Education.

Reference Books :
• Ramakrishnan, R. and Gherke, J., “Database Management Systems”, 3rd Ed., McGraw-
Hill.
• Connally T, Begg C.,”Database Systems”,Pearson Education

DATABASE MANAGEMENT SYSTEMS 66

End of Module 1 Part 1

DATABASE MANAGEMENT SYSTEMS 67