Chapter 02

Copyright © 2007 Ramez Elmasri and Shamkant B.
Navathe Slide 5- 1
Chapter 2
Entity-Relational Data Model
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
 Entity-Relationship(ER) Model:
 Entity Types
 Entity Sets
 Types of Attributes
 Keys
 Relationship Constraints:
 Cardinality and Participation
 Extended Entity-Relationship (EER)Model
 Generalization
 Specialization
 Aggregation
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 5- 3
Introduction of ER Model
 The Entity Relational Model is a model for

identifying entities to be represented in the
database and representation of how those
entities are related. The ER data model specifies
enterprise schema that represents the overall
logical structure of a database graphically.

Symbols Used in ER Model
 ER Model is used to model the logical view of the system
from a data perspective which consists of these symbols:
 Rectangles: Rectangles represent Entities in the ER Model.
 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among
Entities.
 Lines: Lines represent attributes to entities and entity sets
with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued
Attributes.
 Double Rectangle: Double Rectangle represents a Weak
Entity.

Components of ER Diagram
 ER Model consists of Entities, Attributes, and Relationships

among Entities in a Database System.

 Entity
• An Entity may be an object with a physical existence
– a particular person, car, house, or employee – or it
may be an object with a conceptual existence – a
company, a job, or a university course.
 Entity Set: An Entity is an object of Entity Type and

a set of all entities is called an entity set.
 For Example, E1 is an entity having Entity Type
Student and the set of all students is called Entity
Set.

Types of Entity
 Weak and Strong Entity Set
• An Entity type has a key attribute that uniquely identifies
each entity in the entity set. But some entity type exists for
which key attributes can’t be defined. These are called
Weak Entity.
 Where an entity having its own key attributes specified.
• It has a primary key, that helps in identifying it uniquely, and
it is represented by a rectangle. These are called Strong
Entity .
• E.g. In Parent/Child relationship Parent is a Strong entity
and Child is a weak entity.

Attributes
 Attributes are the properties that define the entity
type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that
define entity type Student. In ER diagram, the
attribute is represented by an oval.
1. Key Attribute
 The attribute which uniquely identifies each
entity in the entity set is called the key attribute. For

example, Roll_No will be unique for each student.

2. Composite Attribute
 An attribute composed of many other attributes is
called a composite attribute. For example, the

Address attribute of the student Entity type consists
of Street, City, State, and Country.

3. Multivalued Attribute
 An attribute consisting of more than one value for a
given entity. For example, Phone_No (can be more
than one for a given student). In ER diagram, a
multivalued attribute is represented by a double
oval.
4. Derived Attribute
 An attribute that can be derived from other attributes

of the entity type is known as a derived attribute.
e.g.; Age (can be derived from DOB). In ER
diagram, the derived attribute is represented by a
dashed oval.

Relationship Type
 The association between two different entities is
called as Relationship.
 In ER diagram, the relationship type is
represented by a diamond and connecting the
entities with lines.
 E.g. A Student Enrolls for Course. So enroll is the
relationship
 Types:
 Unary Relationship
 Binary Relationship
 Ternary relationship
 Quaternary Relationship
1. Unary Relationship
 When there is only One entity set participating in
a relation, the relationship is called a unary

relationship. For example, one person is married
to only one person.
2.Binary Relationship
 When there are Two entities set participating in a
relationship, the relationship is called a binary
relationship. For example, a Student is enrolled in
a Course.

3. Ternary Relationship
 When there are Three entities set participating in
a relationship, the relationship is called a Ternary

Relationship. For example, A Teacher teaches
Subject to Student

4. Quaternary Relationship
 When there are FOUR entities set participating in
a relationship, the relationship is called a

Quaternary Relationship. For example, the four
entities Professor , Student , Course and Slides
are connected with each other through Teaching

Keys
 A key is an attribute or a set of attributes that is
used to identify data in entity sets.
 It is widely used to identify the tuples(rows)
uniquely in the table.
 We also use keys to set up relations amongst
various columns and tables of a relational
database.
 Different Types of Database Keys
1. Super Key
2. Candidate Key
3. Primary Key
4. Foreign Key
1. Super Key
 A Super key is a set of one or more attributes that allows us to identify
uniquely an entity in entity set.
 The set of attributes that can uniquely identify a tuple is known as Super
Key.
 For Example, STUD_NO, (STUD_NO, SNAME , Address and Phone). A
super key is a group of single or multiple keys that identifies rows in a
table. It supports NULL values.
 E.g STUD_NO + Phone
STUD_NO + Address
STUD_NO + SName
 Super Key values may also be NULL.
STUD_NO SNAME ADDRESS PHONE
1 Shyam Delhi 123456789
2 Rakesh Kolkata 223365796
3 Suraj Delhi 175468965

2. Candidate Key
 The minimal set of attributes that can uniquely identify a
tuple is known as a candidate key. For Example, STUD_NO
in STUDENT relation.
 It is selected from set of super keys
 It is a super key with no repeated data is called a candidate
key.
 It must contain unique values.
 It can contain NULL values.
 E.g STUD_NO + Phone
STUD_NO + Address

3. Primary Key
 There can be more than one candidate key in
relation out of which one can be chosen as the

primary key.
 For Example, STUD_NO, as well as STUD_PHONE,
are candidate keys for relation STUDENT but

STUD_NO can be chosen as the primary key.
 It cannot be NULL.

4. Foreign Key
 A foreign key is a column whose values are the
same as the primary key of another table.
 It combines two or more relations or table at a time.
 It is a key it acts as a primary key in one table and it
acts as secondary key in another table.

 They act as a cross-reference between the tables.

Relationship Constraints:
 Cardinality:
 Cardinality represents the number of times an entity of an
entity set participates in a relationship set.
 Types of cardinality in between tables are:
One-to-One
One-to-Many
Many-to-One
Many-to-Many
 Participation:
 Types of Participation in between table :
Total Participation
Partial Participation

Mapping Cardinalities
 One-to-one: In this type of cardinality mapping,
an entity in A is connected to at most one entity in
B. Or we can say that a unit or item in B is
connected to at most one unit or item in A.

 Example:
 In a particular hospital, the surgeon department
has one head of department. They both serve
one-to-one relationships.

 One-to-many: In this type of cardinality mapping,
an entity in A is associated with any number of
entities in B. Or we can say that one unit or item
in B can be connected to at most one unit or item
in A.

 Example:
 In a particular hospital, the surgeon department
has multiple doctors. They serve one-to-many
relationships.


 Many-to-one: In this type of cardinality mapping,
an entity in A is connected to at most one entity in
B. Or we can say a unit or item in B can be
associated with any number (zero or more) of
entities or items in A.

 Example:
 In a particular hospital, multiple surgeries are
done by a single surgeon. Such a type of
relationship is known as a many-to-one
relationship.


 Many-to-many: In this type of cardinality
mapping, an entity in A is associated with any
number of entities in B, and an entity in B is
associated with any number of entities in A.


 Example:
 In a particular company, multiple people work on
multiple projects. They serve many-to-many
relationships.

Participation
 Participation constraints define the least number
of relationship instances in which an entity must
compulsorily participate.

 Total Participation
 It specifies that each entity in the entity set must compulsorily
participate in at least one relationship instance in that
relationship set.
 That is why, it is also called as mandatory participation.
 Total participation is represented using a double line between
the entity set and relationship set.
 Double line between the entity set “Student” and relationship
set “Enrolled in” signifies total participation.
 It specifies that each student must be enrolled in at least one
course.

 Partial Participation
 It specifies that each entity in the entity set may or may not
participate in the relationship instance in that relationship set.
 That is why, it is also called as optional participation.
 Partial participation is represented using a single line between
the entity set and relationship set.
 Single line between the entity set “Course” and relationship set
“Enrolled in” signifies partial participation.
 It specifies that there might exist some courses for which no
enrollments are made.

Example
 Draw E-R model of University Database
application considering the constraints −
1. A university has many departments.
2. Each department has multiple instructors (one
person is HOD or Dean).
3. An instructor belongs to only one department.
4. Each department offers multiple courses, each
subject is taught by a single instructor.
5. A student may enroll for many courses offered by
different departments.

 Solution
 Follow the steps given below to draw an Entity
Relationship (ER) diagram for a University
database application −
Step 1 − Identifying the entity sets.
 The entity set has multiple instances in a given
business scenario.
 As per the given constraints the entity sets are as
follows-
College ,Department , Course , Student, Section ,
Instructor

Step 2
 Identifying the attributes for the given entities
 College - The relevant attributes are College Name ,

Office, Location , Contact no.
 Department − The relevant attributes are department
Name and Office.

 Course − The relevant attributes are course code,
course Name, Duration, and level .

 Instructor − The relevant attributes are Instructor
Name, Room No, and telephone number.
 Section- The relevant attributes are Section Name ,
ID no , Semester, Year , Class room.

 Student − The relevant attributes are Student No,
Student Name, and date of birth. Slide 5- 37
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Step 3 −
 Identifying the Key attributes
 College_Name is the key attribute for College.
 Department_Name is the key attribute for

Department.
 Course_No is the key attribute for Course entity.
 Instructor_Id is the key attribute for the Instructor

entity.
 Section_No is the key attribute for Section.
 Student_Id is the key attribute for Student entities.

Step 4
 Identifying the relationship between entity sets
 The College has Multiple Departments with Multiple

Instructors manages by Dean.
 The department offers multiple courses and each
course belongs to only one department, hence

cardinality between department and course if one to
many.
 One course is enrolled by multiple students and one
student for multiple courses. Hence, relationships

are many to many.
 One department has multiple instructors and one
instructor belongs to one and only one department,

hence the relationship is one to many.
 Each department has one “HOD” and one instructor
is “HOD” for only one department, hence the
relationship is one to one.
 One course is taught by only one instructor but one
instructor teaches many courses hence the
relationship between course and instructor is many
to one.
 The relationship between instructor and student is
not defined because of the following reasons −
 There is no significance in the relationship.
 We can always derive this relationship indirectly
through course and instructors, and course and
student.

Step 5 − Complete ER model

Extended Entity-Relationship
(EER)Model
 EER model in DBMS generates designs that are
more accurate.
 It includes all modeling concepts of ER model.
 It reflects the data properties and constraints
more precisely.

In addition to ER model concepts EE-R includes −
 Subclasses and Super classes.

 Generalization and Specialization.
 Category or union type.
 Aggregation.
These concepts are used to create EE-R diagrams.

Generalization in EER
 It is a process of defining more general entity type

from a set of more specialized entity type.
 Generalization is a Bottom-up Approach.
 Consider we have 3 sub entities Car, Truck and
Motorcycle. Now these three entities can be
generalized into one super class named as Vehicle.

Specialization In EER
 Specialization is a process of identifying subsets

of an entity that share some different
characteristic.
 It is a top down approach in which one entity is
broken down into low level entity.
 Vehicle entity can be subdivided into Car, Truck
or Motorcycle.

Generalization and Specialization

Aggregation in EER
 Represents relationship between a whole object
and its component.
 Consider a ternary relationship Works_On between
Employee, Branch and Manager.
 Now the best way to model this situation is to use
aggregation, So, the relationship-set, Works_On is
a higher level entity-set. Such an entity-set is
treated in the same manner as any other entity-set.
 We can create a binary relationship, Manager,
between Works_On and Manager to represent who
manages what tasks.

In-Class Exercise
Draw an E-R & EE-R diagram for Banking Enterprise
1.Bank(Bank_Code , Bank_name , Address , Phone.No )
2. Branch ( Branch_Code , Address )
3. Customer ( PAN_No , Branch_code , Name(Composite attribute) ,
Address , Phone.No, DOB )
4.Account (Acc_No , Balance)
5. Saving _Account (Acc_No . Interest_amt)
6. Current_Account ( Acc_No , Overdraft_amt)
7. Loan (Loan_No , Duration , Interest_Rate)
Car_Loan (Loan_No. , Car_Name)
Home_Loan (Loan_No , Property_Name , Property_Address)
note: Show Cardinality Constraints

Chapter 02

Uploaded by

Document Information

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

Chapter 02

Uploaded by

Copyright:

Available Formats

Copyright © 2007 Ramez Elmasri and Shamkant B.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 The Entity Relational Model is a model for

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

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

 ER Model consists of Entities, Attributes, and Relationships

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

 Entity Set: An Entity is an object of Entity Type and

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

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

entity in the entity set is called the key attribute. For

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

called a composite attribute. For example, the

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

 An attribute that can be derived from other attributes

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

a relation, the relationship is called a unary

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

a relationship, the relationship is called a Ternary

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

a relationship, the relationship is called a

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

1 Shyam Delhi 123456789

2 Rakesh Kolkata 223365796

3 Suraj Delhi 175468965

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

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

relation out of which one can be chosen as the

are candidate keys for relation STUDENT but

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

 It is a key it acts as a primary key in one table and it

acts as secondary key in another table.

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

 Types of Participation in between table :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 College - The relevant attributes are College Name ,

Name and Office.

course Name, Duration, and level .

ID no , Semester, Year , Class room.

 College_Name is the key attribute for College.

 Department_Name is the key attribute for

 Instructor_Id is the key attribute for the Instructor

 Student_Id is the key attribute for Student entities.

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

 The College has Multiple Departments with Multiple

course belongs to only one department, hence

student for multiple courses. Hence, relationships

instructor belongs to one and only one department,

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

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

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