Presented by
Dr. B.Thirumala Rao,
Professor, CSE
Agenda
Relational Model Concepts
Relational Model Constraints
Relational Database Schemas
Update Operations
Dealing with Constraint Violations
The key attribute of the entiry type becomes the primary key of the
Relation
Entity example
Here address is a composite attribute
Employee
SkillSet
EmpCode PK
EmpCode FK
EmpName
Skills
DateofJoining
SkillSet
Converting weak entity types
Weak entity types are converted
into a relation of their own, with
the primary key of the strong
entity acting as a foreign key in the
relation
This foreign key along with the key
of the weak entity form the
composite primary key of this
relation
Employee
Dependent
EmpCode PK
EmpCode PK /FK
EmpName
Dependent_ID PK
DateofJoining
Name
SkillSet
Address
Converting relationships
The way relationships are represented depends on the cardinality
and the degree of the relationship
Employee Department
EmpCode PK DeptCode PK
EmpName DeptName
DateofJoining Location
SkillSet Head FK
Binary 1:1
Employee Sits_on CHAIR
The primary key of either of the participants can become a foreign key in
the other
◦ Employee (E#,name…)
◦ Chair (item#,….)
Binary 1 : 1
Employee
Chair
EmpCode PK
ItemNo PK
EmpName
DateofJoining Model
SkillSet Location
Used_By FK
Employee
EmpCode PK Chair
EmpName
ItemNo PK
DateofJoining
SkillSet Model
Sits_On FK Location
Binary 1:N
1 N
Teacher teaches Subject
The primary key of the relation on the “1” side of the relationship
becomes a foreign key in the relation on the “N” side
Teacher Subject
TeacherID PK SubCode PK
Name SubName
Telephone Duration
Cabin TeacherID FK
Binary M:N
M N
Enrolls Course
Student
Contains two foreign keys - one from each of the participants in the relationship
The primary key of the new relation is the combination of the two foreign keys
Course
CourseID PK
Coursename Enrolls
StudentCode PK / FK
CourseID PK / FK
Student
DOIssue
StudentID PK Status
StudentName
DOB
Address
Unary 1:1
Employee
EmpCode PK
EmpName
DateofJoining
SkillSet
Spouse FK
Unary 1:N
• The primary key field
itself will become foreign
key in the same relation
Employee
EmpCode PK
EmpName
DateofJoining
SkillSet
Manager FK
Unary M:N
Guarantor_of
M
Employee N
There will be two resulting relations. One to represent the entity and anoth
to represent the M:N relationship as follows
Employee
Guaranty
EmpCode PK
Guarantor PK/FK
EmpName
Beneficiary PK /FK
DateofJoining
SkillSet
Ternary relationship
Represented by a new relation.
Prescription
Doctor
DocID PK / FK
DocID PK
PatCode PK / FK
Title
MedName PK/ FK
NextVisit
Patient
PatCode PK
PatName Medicine
DOB MedName PK
Address ExpDate
ER-to-Relational Mapping Algorithm
(cont’d.)
Step 6: Mapping of Multivalued attributes
I. For each multivalued attribute A, create a new relation R. This relation R
will include an attribute corresponding to A, plus the primary key attribute K-as a
foreign key in R-of the relation that represents the entity type of relationship type
that has A as an attribute.
II. The primary key of R is the combination of A and K. If the multivalued attribute is
composite, we include its simple components.
Dnum
References
Dnumber
DEPARTM
ENTS
Primary
60 Key
ER-to-Relational Mapping Algorithm
(cont’d.)
Step 7: Mapping of N-ary Relationship Types
61
Relational Schema Diagram
62
Mapping EER Model Constructs to
Relations
• Step8: Options for Mapping Specialization or
Generalization.
Convert each specialization with m subclasses {S1, S2,….,Sm} and
generalized superclass C, where the attributes of C are {k,a1,…an} and k
is the (primary) key, into relational schemas using one of the four following
options:
Option 8A: Multiple relations-Superclass and subclasses.
Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and
PK(L) = k.
Create a relation Li for each subclass Si, 1 < i < m, with the
attributesAttrs(Li) = {k} U {attributes of Si} and PK(Li)=k.
This option works for any specialization (total or partial, disjoint of
over-lapping).
63
Option 8 a)
Converting
Specialization
64
Mapping of Specialization or
Generalization
Step8: Options for Mapping Specialization or
Generalization
Option 8B: Multiple relations-Subclass relations only
Create a relation Li for each subclass Si, 1 < i < m, with the
attributes Attr(Li) = {attributes of Si} U {k,a1…,an} and PK(Li) = k.
This option only works for a specialization whose subclasses are
total (every entity in the superclass must belong to (at least) one
of the subclasses).
65
Option 8 b)
Converting
Generalization
66
Mapping of Specialization or
Generalization
Option 8C: Single relation with one type attribute.
Create a single relation L with attributes Attrs(L) = {k,a1,…an}
U {attributes of S1} U…U {attributes of Sm} U {t} and PK(L) = k.
The attribute t is called a type (or discriminating) attribute that
indicates the subclass to which each tuple belongs
68
Mapping of Specialization or
Generalization
Option 8D: Single relation with multiple type
attributes.
Create a single relation schema L with attributes
Attrs(L) = {k,a1,…an} U {attributes of S1} U…U
{attributes of Sm} U {t1, t2,…,tm} and PK(L) = k. Each ti, 1
< I < m, is a Boolean type attribute indicating whether a
tuple belongs to the subclass Si.
71
Mapping of Shared Subclasses
(Multiple Inheritance)
option 8A for PERSON/{EMPLOYEE, ALUMNUS, STUDENT}
option 8C for EMPLOYEE/{STAFF, FACULTY,
STUDENT_ASSISTANT} by including the type attribute
Employee_type, and
option 8D for STUDENT_ASSISTANT/{RESEARCH_ASSISTANT,
TEACHING_ ASSISTANT} by including the type attributes Ta_flag
and Ra_flag in EMPLOYEE, STUDENT/ STUDENT_ASSISTANT by
including the type attributes Student_assist_flag in STUDENT, and
STUDENT/{GRADUATE_STUDENT,
UNDERGRADUATE_STUDENT} by including the type attributes
Grad_flag and Undergrad_flag in STUDENT
all attributes whose names end with type or flag are type fields.
73