er-to-relational mapping jan. 2008acs-3902 yangjun chen1 er-to-relational mapping principles...

Jan. 2008 ACS-3902 Yangjun Chen 1

ER-to-Relational Mapping

• ER-to-Relational Mapping Principles

• Specialization/Generalization

- Superclass/Subclass Relationship

Outline: ER-to-Relational Mapping



Sec. 9.1, Sec. 4.1 and 4.2.

General process

1. Create a relation for each strong entity type

2. Create a relation for each weak entity type•include primary key of owner (an FK - foreign key)•owner’s PK + partial key becomes PK

3. For each binary 1:1 relationship choose an entity and include the other’s PK in it as an FK. Include any

attributes of the relationship

4. For each binary 1:n relationship, choose the n-side entity and include an FK w.r.t the other entity. Include any attributes of the relationship



5. For each binary M:N relationship, create a relation for therelationship

•include PKs of both participating entities and any attributesof the relationship•PK is the concatenation of the participating entity PKs

6. For each multivalued attribute create a new relation•include the PK attributes of the entity type•PK is the PK of the entity type and the multivalued attribute

7. For each n-ary relationship, create a relation for the relationship•include PKs of all participating entities and any attributes ofthe relationship•PK may be the concatenation of the participating entity PKs



1. Create a relation for each strong entity type

•include all simple attributes

•choose a primary key

Suppose we have:

course 1 Noffered in

Section noterm

meeting

course noname

credit hoursdescription

section



We create a relation for Course - four attributes, course_no is the PK.


Section noterm

meeting

course noname


section

CourseCourse_no name credit_hours description



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:


Section noterm

meeting

course noname


section



We create a relation for Section


Section noterm

meeting

course noname


section

Section

Course_no Section_no Term

•PK is {course_no, section_no}.

•course_no is an FK.

•meeting is not a simple attribute, so it’s not included.



3. For each binary 1:1 relationship choose an entity and include the other’s PK in it as an FK.

department instructorchair1 1

dept_no dname instr_no iname

There are two choices here

•choose department, or

•choose instructor

Which is the better choice?



Department is the better choice since it must participate in the relationship.

department instructorchair1 1


Department

chairdept_no dname

If we choose department then instr_no is included as, of course, an FK. Note that instr_no must have a value.



4. For each binary 1:n relationship, choose the n-side entity and include an FK w.r.t the other entity.

department instructoremploys1 N


We must choose instructor

We end up with:

instructorinstr_no iname dept_no

•PK is instr_no

•dept_no is an FK

Note that Step 1 would lead to the instructor relation - we have now augmented instructor with the dept_no attribute.



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 courseenrollm ngrade

Enroll

student_no Course_no grade

•PK is {student_no, course_no}

•student_no is a FK

•course_no is a FK

•grade is an attribute of Enroll

course_nostudent_no



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


Section noterm

meeting

course noname


section

Meeting is a multi-valued attribute



Create a relation for meeting

Section was created because of Step 2 - its PK is {course_no, section_no}

meeting

Meeting

course_no section_no meeting•PK is {course_no, section_no, meeting}.

•Meeting is an all-key relation.



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 courseoffersm nroom course_nosemester_no

instructor

instr_no

p



We need one relation, offers, with PK of {semester_no, course_no, instr_no}

semester courseoffersm nroom no course_nosemester_no

instructor

instr_no

p

Offers

course_no instr_no semester_no Room_no



student

graduate undergraduate

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

d



student

graduate undergraduate

d

The arc implies graduate and undergraduate are subtypes of student

The bubble and the d imply disjoint subtypes(o - overlap subtypes)

A student must be a graduate or 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’

Student_class

Subtype is determined by the student_class attribute



Mapping to a relational database - Section 9.2.1 (Step 8)

•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



SECRETARY ENGINEER

d

Example for super- & sub-types: choice 1

TECHNICIAN

name

lnameminitfname

Ssn bDates Address JobType

TypingSpeed

TGradeEngType

fname, minit, lname, ssn, bdate, address, JobType

EMPLOYEE

Essn, TypingSpeed

SECRETARY

Essn, TGrade

TECHNICIAN

Essn, EngType

ENGINEER

EMPLOYEE



CAR TRUCK

d


VehicleId Price LicensePlate

TNoOfPassengersNoOfAxles

VehicleId, LicensePlate, Price, MaxSpeed, NoOfPassenger

CAR

VehicleId, LicensePlate, Price, NoOfAxles, Tonnage

TRUCK

MaxSpeed Tonnage

Vehicle



SECRETARY ENGINEER

d


TECHNICIAN

name

lnameminitfname

Ssn bDates Address JobType

TypingSpeed

TGradeEngType

fname, minit, lname, ssn, bdate, address, JobType, TypingSpeed, Tgrade, EngType

EMPLOYEE

EMPLOYEE



Part

Manufacture_Part Purchased_Part

o


PartNo Description

manufactureDate

Supplier

PartNo, Desription, MFlag, Drawing, ManufactureDate, BatchNo, Pflag, Supplier, ListPrice

Part

BatchNo

DrawingNoListPrice

er-to-relational mapping jan. 2008acs-3902 yangjun chen1 er-to-relational mapping principles...

Documents