0% 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.
Copyright
© © All Rights Reserved
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% 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.
Copyright
© © All Rights Reserved
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

You might also like