Logical DB Design: Mapping An ER Model To The Relational Model
This document outlines rules for mapping an entity-relationship (ER) model to a relational database model. It discusses how to map: regular entities as relations; composite attributes; and different types of binary relationships (1:1, 1:N, M:N). It provides examples of mapping each type of entity and relationship accordingly.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
55 views
Logical DB Design: Mapping An ER Model To The Relational Model
This document outlines rules for mapping an entity-relationship (ER) model to a relational database model. It discusses how to map: regular entities as relations; composite attributes; and different types of binary relationships (1:1, 1:N, M:N). It provides examples of mapping each type of entity and relationship accordingly.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 15
Logical DB Design:
Mapping an ER Model to the
Relational Model Mapping Rules Following mapping rules produce a well- designed (well normalized) relational database from an ER model. Step 1: map regular entities Each regular entity type in an ER diagram is transformed into a relation The name given to the relation is generally the same as the entity type Each simple attribute of the type becomes an attribute of the relation The identifier of the entity type becomes the primary key of the corresponding relation (a) CUSTOMER entity type with simple attributes (b) CUSTOMER relation Mapping a regular entity Composite attributes When a regular entity type has composite attributes, only the simple component attributes of the composite attribute are included in the new relation The following Fig. Shows a variation on the previous one, where Customer_Address is represented as a composite attribute with components Street, City, State and Zip (a) CUSTOMER entity type with composite attribute (b) CUSTOMER relation with address detail Mapping a composite attribute PROJECT Budget Project Name Project No EMPLOYEE Employee No Employee Name Salary Title WORKS ON Address City Apt. # Street # Examples of Step 1 Project (ProjectNo, ProjectName, Budget) PROJECT Budget Project Name Project No EMPLOYEE Employee No Employee Name Salary Title WORKS ON Address City Apt. # Street # Employee (EmployeeNo, EmployeeName, Title, Salary, Apt#, City, Street#) Examples of Step 1 Step 3: map binary relationships The procedure for representing relationships depends on both the degree of the relationships (unary, binary, ternary) and the cardinalities of the relationships Translation to relational model? Many-to-Many 1-to-1 1-to Many Many-to-1 Translating 1:1 Relationships Add to one of the participating relations an FK to the other relation: It is better to add to a relation that has total participation in the relationship. E.g. add a MGRSSN attribute to the Department relation in which to record the departments manager.
Include any relationship attributes. E.g. add managers start-date to Department. Translating 1:N Relationships Add to the relation on the N-side a FK to the other relation. E.g. add DNO to Employee to represent the department an employee works-for.
Include any relationship attributes
PROJECT Budget Project Name Project No EMPLOYEE Employee No Employee Name Salary Title Responsibility WORKS ON Works On Duration N 1 Table 1: Employee (EmployeeNo, EmployeeName, Title, Salary, ProjectNo, Duration, Responsibility)
Table 2: Project (ProjectNo, ProjectName, Budget) Foreign key that references Project table Example of Binary One-to-Many Relationship Translating M:N Relationships Create a new relation containing FKs to both participating relations relationship attributes
E.g. see Works-On
PK is the combination of both FKs Sometimes you also need to add one or more of the relationship attributes to form the PK. PROJECT Budget Project Name Project No EMPLOYEE Employee No Employee Name Salary Title Responsibility WORKS ON Works On Duration N M Table 1: Employee (EmployeeNo, EmployeeName, Title, Salary) Table 2: Project (ProjectNo, ProjectName, Budget) Table 3: WorksOn (EmployeeNo, ProjectNo, Duration, Responsibility) Foreign key that references Employee table Foreign key that references Project table Example of Binary Many-to-Many Relationship SUPPLIER PROJECT Budget Project Name Project No SupplierNo Supplier Name Location PART PartNo Part Name QTY Price PROVIDES N M L PART Table 1: Supplier (SupplierNo, SupplierName, Location) Table 2: Project (ProjectNo, ) Table 3: Part (PartNo, PartName, QTY, Price) Table 4: Provides (SupplierNo, PartNo, ProjectNo) Foreign key that references Supplier table Foreign key that references Part table Foreign key that references Project table Translating n-ary Relationship