Database Design – Lecture 7

Converting a Logical ERD to a Relational Model

2

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

3

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

4

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

5

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

6

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

7

Converting Entities and Attributes

Consider an employee who has multiple skills Approach 2:

Create a new entity to hold the attribute’s components

Employee

PK EMP_ID

FNAME LNAME DATE_OF_BIRTH

Employee Skill

PK SKILL_IDPK,FK1 EMP_ID

DESCRIPTION

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

8

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 createdEmployee

PK EMP_ID

FNAME LNAME DATE_OF_BIRTH

Employee Skill

PK,FK2 SKILL_IDPK,FK1 EMP_ID

DATE_EARNED

Skill

PK SKILL_ID

NAME

9

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

10

Example Conversion

Given the following ERD, convert to a relational structure using the techniques provided

**Note: this ERD is slightly different than last class. Changed to provide more attributes to demonstrate converting to relational tables.

CUSTOMER

PK CUST_ID

NAME ADDRESS PHONE DOB

LIBRARIAN

PK EMPL_ID

NAME

BOOK

PK BOOK_ID

FK1 CAT_ID TITLE AUTHOR DESCRIPTION ISBN

CATEGORY

PK CAT_ID

CAT_NAME

BORROW_TRANSACTION

PK TRANS_ID

FK1 CUST_IDFK2 EMPL_ID DATE

can generate has

BORROW_DETAIL

PK,FK1 TRANS_IDPK LINE_NUMBER

FK2 BOOK_ID

has

can be on

contains

11

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)