Download presentation
Presentation is loading. Please wait.
1
Mapping ER Diagrams to Tables
From ER to Tables Mapping ER Diagrams to Tables
2
Designing the Tables First approach… Draw a dependency diagram
Each statement is a single path through the diagram Tables are formed by traversing the dependency diagram
3
Simpler method – Use ER Diagram
Paths are hard to follow… Create an ER Diagram using the Dependencies Transform Entities into Tables Transform Relationships into keys You’re done! No paths to follow!
4
Example ER Diagram Fname Lname Number N Name Gender 1 Locations Salary
WORKS_FOR Name Address StartDate DEPARTMENT Snn EMPLOYEE 1 1 MANAGES Birthdate CONTROLS Hours N N 1 WORKS_ON 1 N PROJECT SUPERVISION DEPENDENTS_OF Name Location N Number DEPENDENT Name Gender Birthdate
5
Review Key Constraints
lot name ssn since dname did budget Manages Employees Departments Works_In since An employee can work in many departments; a dept can have many employees. In contrast, each dept has at most one manager, according to the key constraint on Manages. 6
6
Review Participation Constraints
Does every employee work in a department? If so, this is a participation constraint Basically means “at least one” since since name name dname dname ssn lot did did budget budget Employees Manages Departments Works_In since 8
7
Identify Weak Entities
A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. lot name age pname Dependents Employees ssn Policy cost Weak entities have only a “partial key” (dashed underline) 10
8
Review Relationships Bad design Better design
Policies policyid cost age pname Dependents Covers name Employees ssn lot If each policy is owned by just 1 employee: Bad design Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Better design Key constraint on Policies would mean policy can only cover 1 dependent! 7
9
Review Relationships Previous example illustrated a case when two binary relationships were better than one ternary relationship. An example in the other direction: a ternary relation Contracts relates entity sets Parts, Departments and Suppliers, and has descriptive attribute qty. No combination of binary relationships is an adequate substitute. 9
10
Review Relationships qty Parts Contract Departments VS. Suppliers Parts needs Departments can-supply Suppliers deals-with S “can-supply” P, D “needs” P, and D “deals-with” S does not imply that D has agreed to buy P from S. 9
11
How do you make the Tables?
Fname Lname Number N Name Gender 1 Locations Salary WORKS_FOR Name Address StartDate DEPARTMENT Snn EMPLOYEE 1 1 MANAGES Birthdate CONTROLS Hours N N 1 WORKS_ON 1 N PROJECT SUPERVISION DEPENDENTS_OF Name Location N Number DEPENDENT Name Gender Birthdate
12
Each Entity becomes a Table
ENTITY TABLE PRIMARY KEY Employee Employee Employee_SSN Department Department Department_Number Project Project Project Number
13
1:N Relationships - Create the Primary Key
For each 1:N relationship – create the Primary Key from the entity on the 1 side to the entity on the N side where it will become a foreign key. EMPLOYEE WORKS_FOR DEPARTMENT N Department Number is moved into the Employee entity
14
Examine Weak Entities The DEPENDENT entity cannot exist on its own and must have a parent entity (EMPLOYEE). They are identified in a M:N relation as the ‘intersect entity’ with the primary key the composite of the primary keys of the two (or more) other ‘strong entities’
15
Weak Entities Become Tables as Well
For each weak entity create a table - include the Primary Key of the owner tables The Primary Key becomes the: owner key plus the weak entity key Entity Table Primary Key Dependent Dependent Employee_SSN + Dependent_No
16
What about M:N Relationships?
For each M:N relationship create a new table with the Primary Key being the the Primary Key of both entities involved in the relationship EMPLOYEE WORKS_ON PROJECT Empno Hours Projno E P E P E P E P
17
Representing the M:N Relationships
18
What about Multi-valued Attributes?
For each multi-valued attribute create a new relation. The Primary Key is the Primary Key of the entity plus the Multi-valued attribute. DEPARTMENT LOCATION TABLE PRIMARY KEY DEPARTMENT_LOCATIONS DEPARTMENT LOCATION D MELB D SYD D MELB
19
What about N-ary Relationships?
For N-ary Relationships create a new entity and create the Primary Key of each entity involved in the relationship to the new entity Supplier supplies Parts from Cities TABLES PRIMARY KEY SUPPLIER_PARTS_CITIES SNo PNo City S NUT MELB S NUT SYD
20
The Finished Table Design
EMPLOYEE Fname Lname Essn Bdate Address M/F Salary Superssn Dno p.k DEPARTMENT f.k Dname Dnumber Mgrssn Mgrstartdate p.k DEPT_LOCATIONS Dnumber Dlocation PROJECT WORKS_ON Pname Pnumber Plocation Dnumber f.k f.k Essn Pnumber Hours DEPENDENT f.k NOT NULL NOT NULL Essn Dependent_name M/F Bdate
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.