Database Design – Lecture 7

Converting a Logical ERD to a

Relational Model
 Lecture Objectives
 How to convert entities and their
relationships from the logical model to the
relational model
 Refining the key structure of an entity
 Refining relationships between entities based
on Business Rules

2
Converting Entities and Attributes
1. Create a separate table for each entity and
consider all the attributes defined as the
table columns
2. Verify PK defined in logical model – is it
appropriate for table or does another
unique (generic) PK need to be defined
3. Remove derived attributes

3
Converting Entities and Attributes
4. Convert composite attributes to atomic
attributes
 i.e. NAME: convert to FIRST_NAME,
LAST_NAME, INITIAL
 i.e. ADDRESS: convert to STREET, CITY,
PROVINCE, POSTAL_CODE

4
Converting Entities and Attributes
5. Convert multi-valued attributes
 Approach 1:
 Within original entity, create several new attributes,
one for each of the original multi-valued attribute’s
components
 Can lead to major structural problems in table
 Approach 2:
 Create a new entity composed of original multi-valued
attribute’s components
 A 1:M dependent relationship to original table will exist
 Approach 3:
 Create a new entity composed of multi-valued
attribute’s components
 A M:N relationship to original table will exist
5
Converting Entities and Attributes
 Consider an employee who has multiple skills
 Approach 1:
 Create attributes to hold the skill information
 What if an employee has more than 3 skills?
Employee
PK EMP_ID

FNAME
LNAME
DATE_OF_BIRTH
SKILL1
SKILL2
SKILL3

6
Converting Entities and Attributes
 Consider an employee who has multiple skills
 Approach 2:
 Create a new entity to hold the attribute’s components

Employee Employee Skill

PK EMP_ID PK SKILL_ID
PK,FK1 EMP_ID
FNAME
LNAME DESCRIPTION
DATE_OF_BIRTH

Existent dependent because these skills are for this employee and
are of no value without the employee

7
Converting Entities and Attributes
 What if other employees can have the same
skills?
 Approach 3:
 Create a new entity to hold the attribute’s components
 Results in a M:N relationship between EMPLOYEE and
SKILL entities which will require a bridge table to be
created
Employee
Employee Skill Skill
PK EMP_ID
PK,FK2 SKILL_ID PK SKILL_ID
FNAME PK,FK1 EMP_ID
LNAME NAME
DATE_OF_BIRTH DATE_EARNED

8
Converting Relationships
1. For 1:M connectivity, take the PK of the ‘1’
table and make it an FK in the ‘M’ table
2. For M:N connectivity, create a bridge table
 Include the PK from each of the original tables
as composite PK in the bridge table. These will
also be FKs in the bridge table
 Add additional attributes to the bridge table as
required
3. For Strong – Weak Entity relationships, take
the PK of the Strong Entity and include it as
part of the PK of the Weak Entity. It will
also be an FK in the Weak Entity
9
 Example Conversion
LIBRARIAN

CUSTOMER PK EMPL_ID

 Given the PK CUST_ID NAME

NAME
following ERD, ADDRESS
PHONE
can generate has

convert to a DOB
BORROW_TRANSACTION

relational PK TRANS_ID

PK
CATEGORY
CAT_ID
FK1 CUST_ID
structure using FK2 EMPL_ID
DATE CAT_NAME

the techniques has contains

provided BORROW_DETAIL BOOK

PK,FK1 TRANS_ID PK BOOK_ID
PK LINE_NUMBER can be on
FK1 CAT_ID
FK2 BOOK_ID TITLE
AUTHOR
DESCRIPTION
ISBN

**Note: this ERD is slightly different than last class. Changed to provide more
attributes to demonstrate converting to relational tables.
10
 Example Conversion
 Resulting Tables Might Look Like:
CUSTOMER (CUST_NUMBER (PK), CUST_FNAME, CUST_LNAME,
CUST_INITIAL, STREET_ADDRESS, CITY, PROVINCE, POSTAL_CODE,
HOME_PHONE, DOB)

LIBRARIAN (EMPL_ID (PK), LIBR_FNAME, LIBR_LNAME, LIBR_INITIAL)

BORROWING_TRANSACTION (TRANS_ID (PK), CUST_ID (FK), EMPL_ID (FK),

DATE)

BORROWING_DETAIL (TRANS_ID (PK, FK), LINE_NUMBER (PK), BOOK_ID

(FK))

CATEGORY (CAT_ID (PK), NAME)

BOOK (BOOK_ID (PK), CAT_ID (FK), TITLE, AUTHOR, DESCRIPTION, ISBN)

11