2. Relational Database Design : ER- Mapping

3. Outline ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types
Step 2: Mapping of Weak Entity Types
Step 3: Mapping of Binary 1:1 Relation Types
Step 4: Mapping of Binary 1:N Relationship Types.
Step 5: Mapping of Binary M:N Relationship Types.
Step 6: Mapping of Multivalued attributes.
Step 7: Mapping of N-ary Relationship Types.
Specialization/Generalization

4. The ER conceptual schema diagram for the COMPANY database.

5. Result of mapping the COMPANY ER schema into a relational schema.

6. ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types.
For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E.
Choose one of the key attributes of E as the primary key for R.
If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R.

7. ER-to-Relational Mapping Algorithm (contd.)
Step 2: Mapping of Weak Entity Types
For each weak entity type W in the ER schema with owner entity type E, create a relation R & include all simple attributes (or simple components of composite attributes) of W as attributes of R.
Also, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s).
The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any.

8. ER-to-Relational Mapping Algorithm (contd.)
Step 3: Mapping of Binary 1:1 Relationship Types
For each 1:1 relationship type R, identify the relations S and T that participating in R.
Foreign key approach
Choose one relation S. Include the primary key of T as a foreign key in S.
It is better to choose an entity type with total participation in R in the role of S.

9. ER-to-Relational Mapping Algorithm (contd.)
Step 4: Mapping of Binary 1:N Relationship Types
For each binary 1:N relationship type R, identify the relation S that represents the participating entity type at the N-side of the relationship. Let T denotes the other participating entity.
Include the primary key of T as a foreign key in S.
Include any simple attributes of the relationship as attributes of S.

10. ER-to-Relational Mapping Algorithm (contd.)
Step 5: Mapping of Binary M:N Relationship Types
For each binary M:N relationship type R, create a new relation S.
Include the primary keys of both participating entities as foreign keys.
Their combination will form the primary key of S.
Also include any simple attributes of R.

11. ER-to-Relational Mapping Algorithm (contd.)
Step 6: Mapping of Multivalued attributes.
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.
The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components.

12. ER-to-Relational Mapping Algorithm (contd.)
Step 7: Mapping of N-ary Relationship Types.
For each n-ary relationship type R, where n>2, create a new relation S to represent R.
Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types.
Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S.

13. Ternary relationship types. (a) The SUPPLY relationship.

14. Mapping the n-ary relationship type SUPPLY from Figure 3.17(a).

15. EXAMPLES

16. 1. Create a relation for each strong entity type
include all simple attributes
choose a primary key
Suppose we have:
name
term
course no
Section no
offered in 1 N
course
section
description
credit hours
meeting

17. We create a relation for Course - four attributes, course_no is the PK.
name
term
course no
Section no
offered in 1 N
course
section
description
credit hours
meeting
Course
Course_no
name
credit_hours
description

18. 2. Create a relation for each weak entity type
include primary key of owner (an FK)
Owner’s PK + partial key become the PK
Suppose we have:
name
term
course no
Section no
offered in 1 N
course
section
description
credit hours
meeting

19. We create a relation for Section
name
term
course no
Section no
offered in 1 N
course
section
description
credit hours
meeting
Section
PK is {course_no, section_no}.
course_no is an FK.
meeting is not a simple attribute, so it’s not included.
Course_no
Section_no
Term

20. There are two choices here choose department, or choose instructor
3. For each binary 1:1 relationship choose an entity and include the other’s PK in it as an FK.
department
instructor
chair 1
dept_no
dname
instr_no
iname
There are two choices here
choose department, or
choose instructor
Which is the better choice?

21. Department is the better choice since it must participate in the relationship.
instr_no
iname
dname
dept_no
chair 1 1
department
instructor
If we choose department then instr_no is included as, of course, an FK. Note that instr_no must have a value.
Department
dept_no
dname
chair

22. We must choose instructor We end up with:
4. For each binary 1:n relationship, choose the n-side entity and include an FK w.r.t the other entity.
instr_no
iname
dname
dept_no
employs 1 N
department
instructor
We must choose instructor
We end up with:
Note that Step 1 would lead to the instructor relation - we have now augmented instructor with the dept_no attribute.
instructor
PK is instr_no
dept_no is an FK
instr_no
iname
dept_no

23. PK is the catenation of the participating entities’ PKs
5. For each binary M:N relationship, create a relation for the relationship
include PKs of both participating entities and any attributes of the relationship
PK is the catenation of the participating entities’ PKs
student_no
course_no
grade m n
student
course
enroll
Enroll
PK is {student_no, course_no}
student_no is a FK
course_no is a FK
grade is an attribute of Enroll
student_no
Course_no
grade
Jan. 2011
ACS-3902 Yangjun Chen

24. 6. For each multi-valued attribute create a new relation
include the PK attributes of the entity type
PK is the PK of the entity type and the multi-valued attribute
name
term
course no
Section no
offered in 1 N
course
section
description
credit hours
meeting
Meeting is a multi-valued attribute

25. Create a relation for meeting
Section was created because of Step 2 - its PK is {course_no, section_no}
meeting
Meeting
PK is {course_no, section_no, meeting}.
Meeting is an all-key relation.
course_no
section_no
meeting

26. 7. For each n-ary relationship, create a relation for the relationship
include PKs of all participating entities and any attributes of the relationship
PK may be the catenation of the participating entity PKs (depends on cardinalities)
semester_no
course_no
room m n
semester
course
offers p
instructor
instr_no

27. We need one relation, offers, with PK of {semester_no, course_no, instr_no}
room no m n
semester
course
offers p
instructor
instr_no
Offers
course_no
instr_no
semester_no
Room_no

28. Return to Entity-Relationship Modeling
Consider Section 4.2 on Specialization and Generalization
Specialization is the process of defining a set of sub-entities of some entity type. Generalization is the opposite approach/process of determining a supertype based on certain entities having common characteristics.
e.g. employees may be paid by the hour or a salary (part vs full-time)
e.g. students may be part-time or full-time; graduate or undergraduate
these are similar to 1:1 relationships, but they always involve entities of one (super)type
these are ‘is-a’ relationships
student d
graduate
undergraduate

29. student graduate undergraduate
Subtype is determined by the student_class attribute
student
A student must be a graduate or undergraduate
Student_class
The bubble and the d imply disjoint subtypes
(o - overlap subtypes) d
The arc implies graduate and undergraduate are subtypes of student
graduate
undergraduate
Participation of supertype may be mandatory or optional
Subtypes may be disjoint or overlapping
a predicate (on an attribute) determines the subtype: e.g. attribute Student_class
Student_class = ‘graduate’; Student_class = ‘undergraduate’

30. Mapping to a relational database -
4 choices:
1. Create separate relations for the supertype and each of the subtypes.
2. Create relations for the subtypes only - each contains attributes from the supertype.
3. (disjoint subtypes) Create only one relation - includes all of the attributes for the supertype and all for the subtypes, and one discriminator attribute.
4. (overlapping subtypes) Create only one relation - includes all of the attributes for the supertype and all for the subtypes, and one logical discriminator attribute per subtype.
PK is always the same - determined from the supertype

31. fname, minit, lname, ssn, bdate, address, JobType
Example for super- & sub-types: choice 1
fname
lname
minit
Address
bDates
JobType
name
Ssn
EMPLOYEE
TypingSpeed d
EngType
TGrade
SECRETARY
TECHNICIAN
ENGINEER
EMPLOYEE
fname, minit, lname, ssn, bdate, address, JobType
SECRETARY
TECHNICIAN
ENGINEER
Essn, TypingSpeed
Essn, TGrade
Essn, EngType

32. Example for super- & sub-types: choice 2
Price
LicensePlate
VehicleId
Vehicle
TNoOfPassengers d
NoOfAxles
CAR
TRUCK
Tonnage
MaxSpeed
CAR
VehicleId, LicensePlate, Price, MaxSpeed, NoOfPassenger
TRUCK
VehicleId, LicensePlate, Price, NoOfAxles, Tonnage

33. Example for super- & sub-types: choice 3
fname
lname
minit
Address
bDates
JobType
name
Ssn
EMPLOYEE d
TypingSpeed
EngType
TGrade
SECRETARY
TECHNICIAN
ENGINEER
EMPLOYEE
fname, minit, lname, ssn, bdate, address, JobType, TypingSpeed, Tgrade, EngType

34. Example for super- & sub-types: choice 4
Description
PartNo
Part
manufactureDate o
Supplier
DrawingNo
ListPrice
Manufacture_Part
Purchased_Part
BatchNo
Part
PartNo, Desription, MFlag, Drawing, ManufactureDate, BatchNo, Pflag, Supplier, ListPrice

35. Mapping Exercise
An ER schema for a SHIP_TRACKING database.