translating er model into relational model
DESCRIPTION
Translating ER Model into Relational Model. ER Model Relational Model. Considerations: Minimize the number of relations to reduce query-processing time. Do not allow null values if possible Provide a semantically clear design - PowerPoint PPT PresentationTRANSCRIPT
Translating ER Model into Relational Model
ER Model Relational Model
Considerations:Minimize the number of relations to reduce query-processing time.
Do not allow null values if possible
Provide a semantically clear design
Provide a design that accommodates potential changes of the schema
Reality: decreasing the number of relationsPros: higher efficiency of query processing
Cons: more nulls; less semantic clarity; less flexibility
2
3
ER Model Relational Model (cont.)
Step 0: Identify: 0.1. Entity types (strong & weak, superclass/subclass)0.2. Relationship types0.3. Special attributes (composite, multi-valued, derived)
Step 1: Strong entity types and single-valued attributesStep 2: Many-to-many relationshipsStep 3: One-to-many relationshipsStep 4: One-to-one relationshipsStep 5: n-ary relationships (n 3)Step 6: Weak entity typesStep 7: Multi-valued attributesStep 8: Superclasses and subclasses
Note: Steps 1-8 may not be followed in the above sequence. For example, you may do step 6 before step 2, and so on
Applicable to both binary and unary (recursive) relationships
An ER Model
INFO 605 4
5
Step 0
0.1.1. Strong entity types:
Department, Course, Instructor, TeachingAssistant
0.1.2. Weak entity types:
TeachingPreference
0.1.3. Superclasses/Subclasses:
Instructor/(DeptHead, ParttimeInstructor)
0.2.1. Relationship types related to strong entity types:
Many-to-many: None
One-to-many: Department:Course, Department:Instructor, Instructor(Superviser):Instructor(Supervisee)
One-to-one: Department:DeptHead
n-ary: Course:Instructor:TeachingAssistant
0.2.2. Relationship types related to weak entity types:
One-to-many: Instructor:TeachingPreference
6
Step 0 (cont.)
0.3.1. Composite attributes:
address(street, city, state, zipcode)
0.3.2. Multi-valued attributes:
phoneNo
0.3.3. Derived attributes:
unitsTaught
7
Step 1: Strong Entity Types
Each strong entity type maps into a relation(table)Each simple attribute of the strong entity type maps to an attribute of the relationEach composite attribute will be broken into multiple simple attributes (address = street, city, state, zip)We’ll deal with Multi-valued attributes later (PhoneNo)Derived attributes, by definition, can be derived, and therefore are not necessary to be representedThe primary key of the entity type maps to the primary key of the relationPrimary keys are underlined
8
Step 1: Example
At this step, we got:
Department (deptCode, deptName, street, city, state, zipcode)
Course (courseNo, sectionNo, title, courseType, units)
Instructor (instructorID, fName, lName, gender, ssn, position)
TeachingAssistant (teachingAssistantID, ssn, studentID, salary)
How about phoneNo of Department and unitsTaught of Instructor?
We will deal with multi-valued attributes (e.g., phoneNo) later
We don’t need to add derived attributes (e.g., unitsTaught) in relations.
9
Step 2: Many-to-Many Relationships
Each Many-to-Many relationship type maps into a relation (i.e., a relationship relation)
The primary key of this relation is the combination of the primary keys of the participating entity types
These are also foreign keys
Attributes of the relationship type maps to attributes of the relation, similar to those of strong entity types
10
Step 2: Example
empID name salary
0001 Harry 80k
0002 Leon 100k
0003 John 90k
projectID startDate endDate
1001 9/10/2003 3/14/2004
1002 4/3/2003 7/2/2004
Employee
empID {PK}namesalary…
Project
projectID{PK}startDateendDate…
AssignedTo0..*1..3
empID projectID position
0001 1001 manager
0002 1001 designer
0001 1002 developer
0003 1002 manager
Employee (empID, name, salary)
position
Project (projectID, startDate, endDate)
Assignment (empID, projectID, position)
11
Step 3: One-to-Many Relationships
For each One-to-Many relationship type related to strong entity types:
Can be treated as a Many-to-Many relationshipAdd a relationship relation
Do not need to introduce a separate relationAdd a foreign key (FK) (and relationship attributes)
to the relation on the “many” side
that references the PK on the “one” side
Can we add the FK on the “one” side? Why or why not?
12
Step 3: Example
If we add an FK to the “many” side, we get:
If we add an FK to the “one” side, we get:
deptCode deptName
math mathematics
acct accounting
instructorID position
11 assistant
22 associate
33 full
Departm ent Instructor1..1 1..*Has
instructorID position deptCode
11 assistant math
22 associate math
33 full acct
deptCode deptName instructorID
math mathematics 11
math mathematics 22
acct accounting 33
Step 3: Example
At this step, we got:
Department:CourseCourse (courseNo, sectionNo, title, courseType, units, deptCode)
Foreign key deptCode references Department (deptCode);
Department:InstructorInstructor (instructorID, fName, lName, gender, ssn, position,
deptCode)
Foreign key deptCode references Department (deptCode);
13
Department CourseOffers
1..1 1..*
Department InstructorHas
1..1 1..*
Step 3: Example (cont.)
Instructor(Supervisor):Instructor(Supervisee)
Add a foreign key to the “Many” side: Instructor (Supervisee)
Instructor (instructorID, fName, lName, SSN, position, deptCode, supervisorID)Foreign key supervisorID references Instructor (instructorID)
In case of recursive relationship, we need to rename the foreign key.
Due to the partial participation of Instructor(Supervisee), supervisorID can be null.
If you want to avoid null values, we need to create a new relation: Supervision (instructorID, supervisorID)
Foreign key instructorID references Instructor (instructorID)
Foreign key supervisorID references Instructor (instructorID)
Avoid nulls for foreign keys, but lower efficiency of query processing
14
The “Many” side has partial participation.(i.e., an instructor may not have a supervisor.)
Instructor
Supervises 0..3
0..1Supervisor
Supervisee
15
Step 4: One-to-One Relationships
Three approachesEmployee (empID, empName)
Account (username, password)
Foreign key approachAdd an FK to the entity type that “fully” participates in the relationship
Account (username, password, empID)Foreign key empID references Employee (empID)
Merged relation approachMerge the two entity types and the relationship into a single relation
Employee (empID, empName, username, password)
Relationship relation approachAdd another relation to represent the relationship
Employee_Account (empID, username)
Partial participation Full participation
16
Step 4: Example
In our case, we have an one-to-one relationship:
Department fully participants in Manages relationship;
Only a subclass of Instructor, DeptHead, participates in this relationship
Because DeptHead is a subclass of Instructor, we will do Step 8 first and accomplish this step later
17
Step 5: n-ary Relationships
Each n-ary (n3) relationship type maps into a relation
The primary key of this relation is the combination of the primary keys of the participating entity types
These are also foreign keys.
Exception: if the cardinality of any entity type is 1, the primary key for this entity type is not as part of the primary key of the new relation.
Attributes of the relationship type maps to attributes of the relation, similar to those of strong entity types
Step 5: Example
18
Supplier (supplierID, supplierName)
Project (projectID, projectName) Part (partID, partName)
Supply (supplierID, projectID, partID, quantity)
Primary key
Foreign keys
Step 5: Example
In our case,
TeachingCourse (courseNo, sectionNo, instructorID, teachingAssistantID, instructorEval, taEval)
PK: {courseNo, sectionNO}
FKs: {courseNo, sectionNo}, instructorID, teachingAssistantID19
Course (courseNo, sectionNo, …)
TeachingAssistant (TeachingAssistantID, …)
Instructor (instructorID, …)
20
Step 5: Example
At this step, we got:
TeachingCourse (courseNo, sectionNo, instructorID, teachingAssistantID, instructorEval, taEval)
Foreign key {courseNo, sectionNo} references Course (courseNo, sectionNo)
Foreign key instructorID references Instructor (instructorID)
Foreign key teachingAssistantID references TeachingAssistant (teachingAssistantID);
21
Step 6: Weak Entities
For each weak entity, create a relation that includes all the simple attributes of that entity.
The primary key of a weak entity is partially or fully derived from each owner entity.
The identification of a weak entity’s primary key depends on the relationship with its owner entity.
22
Step 6: Example
First, we create a relation for the weak entity.
TeachingPreference (courseType, numCourses)
The primary key is undetermined at present.
Second, according to its relationship with the owner entity, we add the primary key.
TeachingPreference (instructorID, courseType, numCourses)
Foreign key instructorID references Instructor (instructorID);
primary keyforeign key
23
Step 7: Multi-valued Attributes
Each multi-valued attribute maps into a separate relationThe relation has an attribute for each simple attribute of the multi-valued attributeInclude also an attribute for the primary key of the entity or relationship type that the attribute belongs to
This is also a foreign key
The primary key of this relation is the combination of all the attributes if the multi-valued attribute is simpleIf the multi-valued attribute is composite, the primary key of this relation may be a combination of some of the attributes
24
Step 7: Example
At this step, we got:
DeptPhoneNo (deptCode, phoneNo)
Foreign key deptCode references Department (deptCode);
An example on multi-valued attribute that is composite
Customer (custNo, lName, fName)
CreditCard (custNo, cardNo, expiration)
Foreign key custNo references Customer (custNo);
25
Step 8: Superclasses/Subclasses
Each superclass maps into a relation
Each subclass also maps into a relationThe primary key is the same as the primary key of its superclass
This is also a foreign key
Treat attributes that belongs to the subclasses only as usual
For multi-leveled hierarchy, the primary key of the root entity propagates down a hierarchy of entity types
26
Step 8: Example
At this step, we got:
Superclass:Instructor (instructorID, fName, lName, gender, ssn, position, deptCode)
Foreign key deptCode references Department (deptCode);
Subclasses:DeptHead (instructorID, startDate, bonus)
Foreign key instructorID references Instructor (instructorID);
ParttimeInstructor (instructorID, hourlyRate)Foreign key instructorID references Instructor (instructorID);
27
Go back to Step 4: Example
At this step, we got:
Department (deptCode, deptName, street, city, state, zipcode, deptHeadID)
Foreign key deptHeadID references DeptHead (instructorID)
Department DeptHeadManages
1..1 1..1
Instructor
28
Final Results of Relational Schema
How to get the final results of relational schema:
Revisit Step 1 through Step 8, write down all relation schemas. If a relation schema occurs more than once, write down the latest modified one.
Finally, we got totally 10 relations.
Final Results of Relational Schema (Cont.)
Department (deptCode, deptName, street, city, state, zipcode, deptHeadID)
Foreign key deptHeadID references DeptHead (instructorID);
DeptPhoneNo (deptCode, phoneNo)
Foreign key deptCode references Department (deptCode);
Instructor (instructorID, fName, lName, gender, ssn, position, deptCode)
Foreign key deptCode references Department (deptCode);
Supervision (instructorID, supervisorID)
Foreign key instructorID references Instructor (instructorID)
Foreign key supervisorID references Instructor (instructorID);
TeachingPreference (instructorID, courseType, numCourses)
Foreign key instructorID references Instructor (instructorID);
29
Final Results of Relational Schema (Cont.)
DeptHead (instructorID, startDate, bonus)
Foreign key instructorID references Instructor (instructorID);
ParttimeInstructor (instructorID, hourlyRate)
Foreign key instructorID references Instructor (instructorID);
Course (courseNo, sectionNo, title, courseType, units, deptCode)
Foreign key deptCode references Department (deptCode);
TeachingAssistant (teachingAssistantID, ssn, studentID, salary);
TeachingCourse (courseNo, sectionNo, instructorID, teachingAssistantID, instructorEval, taEval)
Foreign key {courseNo, sectionNo} references Course (courseNo, sectionNo)
Foreign key instructorID references Instructor (instructorID)
Foreign key teachingAssistantID references TeachingAssistant (teachingAssistantID);
30
Use “” to Represent Foreign Keys
31
32
Summary of the Schema Mapping Process
Step 0: IdentificationStep 1: Strong entity
Entity -> a new relation
Step 2: Many-to-Many relationshipsAdd a new relation
Step 3: One-to-Many relationshipsFK on the M-side
Step 4: One-to-one relationshipsFK on the fully participating side
Step 5: n-ary relationshipsAdd a new relation
Step 6: Weak entityA new relation with FK from the strong entity as part of its PK
Step 7: Multi-valued attributesA new relation with FK
Step 8: Superclasses and subclassesFK in each subclass