IT 203 Database Management System 1
Transforming ER diagram into relations example
Transform the ER diagram for the real-estate firm shown below.
Middlename
Province
Lastname
Firstname
Town/City
Barangay
Employee_Name
Location
Gender
Civil Status
Phone_No
SALES OFFICE
is assigned
EMPLOYEE
Office_No
Employee_ID
Address
Town/City
Barangay
lists
Province
Middlename
Property_ID
Lastname
Percent_Owned
Firstname
PROPERTY
Owner_Name
Value
is owned
Owner_ID
Description
OWNER
Location
Address
Barangay
Barangay
Town/City
Town/City
Province
Province
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 entity type becomes
an attribute of the relation. The identifier of the entity type becomes the primary key of the
corresponding relation.
Composite Attributes
When a regular entity type has a composite attribute, only the simple component attributes of the
composite attribute are included in the new relation.
Multivalued Attribute
When the regular entity type contains a multivalued attribute, two new relations are created. The
first relation contains all of the attributes of the entity type except the multivalued attribute. The
second relation contains two attributes: the first is the primary key from the first relation which
becomes the foreign key in the second relation, and the second is the multivalued attribute. The
name of the second relation should capture the meaning of the multivalued attribute.
Since there are four entities (EMPLOYEE, SALES OFFICE, PROPERTY, and OWNER) each of these will be
mapped into a relation. Regular attributes become columns or fields in the relation.
EMPLOYEE
Employee_ Last_
First_
Middle_
Gender Civil_
Barangay Town/City Province
ID
name
name
name
Status
Since the attributes Employee_Name and Address are composite, only their simple components are
included.
SALES OFFICE
Office_No. Barangay Town/City Province
Location is a composite attribute – include only the simple components
PROPERTY
Property_ID Description Value Barangay Town/City Province
Location is a composite attribute – include only the simple components
OWNER
Owner_ID Last_ name First_ name Middle_ name Barangay Town/City Province
Since the attributes Owner_Name and Address are composite, only their simple components are
included.
The attribute Phone_No. in the entity Employee is multivalued – it will be placed in a separate relation
then include the primary key Employee_ID
EMPLOYEE PHONE
Employee ID Phone_No.
Step 2: Map Binary Relationships
Binary One-to-Many Relationships
For each binary 1:M relationship, first create a relation for each of the two entity types
participating in the relationships (Step 1). Next, include the primary key attribute(s) of the entity
on the one-side of the relationship as a foreign key in the relation that is on the many-side of the
relationship.
a. The EMPLOYEE AND SALES OFFICE relationship is one-to-many. The entity EMPLOYEE is on the
one-side and SALES OFFICE is on the many-side.
EMPLOYEE
is assigned
SALES OFFICE
EMPLOYEE
Employee_
ID
Last_
name
First_
name
Middle_
name
Gender Civil_
Status
Barangay Town/City Province
SALES OFFICE
Office_No. Barangay Town/City Province Employee_ID
To show the relationship between the entities EMPLOYEE and SALES OFFICE insert a foreign key
(Employee_ID) in the relation on the many side (SALES OFFICE).
b. The SALES OFFICE and PROPERTY relationship is one-to-many. The entity SALES OFFICE is on the
one side and PROPERTY is on the many-side.
SALES OFFICE
lists
PROPERTY
SALES OFFICE
Office_No. Barangay Town/City Province
PROPERTY
Property_ID Description Value Barangay Town/City Province Office_No.
To show the relationship between the entities SALES OFFICE and PROPERTY insert a foreign key
(Office_No) in the relation on the many side (PROPERTY).
Binary Many-to-Many Relationships
For each binary M:N relationship, first create a relation for each of the two entity types
participating in the relationships (Step 1). Then create a new relation and include as foreign key
attributes the primary key for each of the two participating entity types. Any nonkey attributes
that are associated with the M:N relationship are included with the new relation.
The OWNER and PROPERTY relationship is many-to-many. The relationship is owned has an attribute
Percent_Owned.
Percent_Owned
OWNER
is owned
PROPERTY
PROPERTY
Property_ID Description Value Barangay Town/City Province Office_No.
OWNER
Owner_ID Last_ name First_ name Middle_ name Barangay Town/City Province
Create a new relation named OWNER PROPERTY (or PROPERTY OWNED) with the relationship attribute
as one column or field. Then include the primary keys of the relation PROPERTY (Property_ID) and the
relation OWNER (Owner_ID) in the new relation. This is called a junction table or look-up table
PROPERTY OWNED
Property_ID Owner_ID Percent_Owned
RESULT: The ER diagram for the real-estate firm is transformed into six (6) relations. One relation for
each of the entities, one relation for the multivalued attribute (Employee Phone), and one relation for
the many-to-many relationship (Property Owned)
EMPLOYEE
Employee_
ID
Last_
name
First_
name
Middle_
name
Gender Civil_
Status
Barangay Town/City Province
EMPLOYEE PHONE
Employee ID Phone_No.
SALES OFFICE
Office_No. Barangay Town/City Province Employee_ID
PROPERTY
Property_ID Description Value Barangay Town/City Province Office_No.
OWNER
Owner_ID Last_ name First_ name Middle_ name Barangay Town/City Province
PROPERTY OWNED
Property_ID Owner_ID Percent_Owned
Solutions for the exercises on transforming ER to Relations
1. ER diagram for the employee-project problem
Employee_ID
Address
Project_Name
Employee_Name
EMPLOYEE
Contact_No
is assigned
Position
Project_ID
PROJECT
Billing_Rate
Location
Project_Status
Start_Date
EMPLOYEE
Employee_ ID Employee_Name Address Contact_No Position
PROJECT
Project_ ID Project_name Location Project_Status Start_Date
EMPLOYEE_PROJECT
Project_ ID Employee_ ID Billing_Rate
Junction table for the many-to-many relationship in “employee is assigned project”
2. ER diagram for the Stillwater Antiques problem
Sales Tax
Commission
Date sold
Selling price
Comments
sells
Client No.
Asking Price
Client Name
CLIENT
ITEM
Description
Condition
Client Address
buys
Item No.
Purchase cost
Date purchased
CLIENT
Client_No Client_Name Client_Address
ITEM
Item_No Description Condition Asking_Price Comments
Purchase
condition
PURCHASED_ITEMS
Client_No Item_No Purchase_Cost Date_Purchased Purchase_Condition
Junction table for the many-to-many relationship in “client sells item”
SOLD_ITEMS
Client_No Item_No Selling_Price Date_Sold Commission Sales_Tax
Junction table for the many-to-many relationship in “client buys item”
3. ER diagram for hospital exercise
Patient ID
Treats
Physician ID
Patient Name
Physician Name
PHYSICIAN
PATIENT
Address
Specialty
Admits
Barangay
Town/City
Treatment Detail
Date
Time
Province
Result
PHYSICIAN
Physician_ID Physician_Name Specialty
PATIENT
Patient_ID Patient_Name Barangay Town Province Physician_ID
Include Physician_ID as foreign key because there is one-to-many relationship in “physician treats
patient”
ADMITTED-PATIENT
Physician_ID Patient_ID Date Time Result
Junction table for the many-to-many relationship when “physician admits patient”
Prepared by:
A. JONATHAN S. PAGATPATAN