GUIDELINES FOR GOOD RELATIONAL DESIGN ... ( EmpNo, FName, MName, LName ) Mapping Multi_valued Attributes 7 A multivalued attribute M of an entity E is represented by a separate table

LECTURE 6:

GUIDELINES FOR GOOD RELATIONAL DESIGN

MAPPING ERD TO RELATIONS

1

Ref. Chapter 16

” Logical Database Design Methodology for the Relational Model”

Objectives 2

How to derive a set of relations from a conceptual data model (Mapping

ERD to Relations)

Derive relations for logical data model

3

In this step:

We specify the name of the relation followed by a list of the relation’s simple

attributes enclosed in brackets.

We then identify the primary key and foreign key(s) of the relation. Following the

identification of a foreign key, the relation containing the referenced primary key is

given

Any derived attributes are also listed together with how each one is calculated

For example:

Staff (staffNo, fName, lName, position, sex, DOB)

Client (clientNo, fName, lName, telNo, prefType, maxRent, staffNo)

Foreign Key staffNo references Staff(staffNo)


4

The relationship that an entity has with another entity is represented by the primary

key/foreign key mechanism.

In deciding where to place the foreign key attribute(s), we must first identify the

‘parent’ and ‘child’ entities involved in the relationship.

The parent entity refers to the entity that posts a copy of its primary key into the relation

that represents the child entity, to act as the foreign key.


5

We describe how relations are derived for the following structures that may

occur in a conceptual data model:

(1) strong entity types;

(2) weak entity types;

(3) composed / multi-valued / derived attributes;

(4) binary relationship types;

(5) recursive relationship types;

(6) complex relationship types;

(7) superclass/subclass relationship types;

Mapping Strong Entity types

6

For each strong entity in the data model, create a relation that includes all

the simple attributes of that entity.

If composite attributes exist, only their component simple attributes are

needed.

Derived attributes are usually omitted.

Name

FName MName LName

Employee

EmpNo

Employee ( EmpNo, FName, MName, LName )

Mapping Multi_valued Attributes

7

A multivalued attribute M of an entity E is represented by a separate table EM

1. Includes the multivalued attribute M in EM

2. Includes the PK of E as FK in EM

3. The PK of EM is the combination of the PK of E and the multivalued attribute

M.

E

EPK

M

EM ( M , EPK )

FK : EPK references E (EPK)

__ ___

Create a new relation to represent multi-valued attribute and include

primary key of the entity in the new relation, to act as a foreign key.

The primary key of the new relation is the combination of the multi-valued

attribute and the primary key of the entity.

Example of Multi-valued Attributes 8

Branch( branchNo, street, city, postCode)

BranchTel (telNo, branchNo)

FK: branchNo references Branch(branchNo)

Branch

BranchNo street

city

postCode

telNo

Example of Multi-valued Attributes

9

BranchNo Street City PostCode telNo

B1 Brookline London 33100 65509876

B2 River drive Dubai 1320 8976540

-8907654

B3 West river London 1100 6789008

Branch

Not allowed

BranchNo Street City PostCode

B1 Brookline London 3310

B2 West End Glasgow 1320

B3 West River London 1100

BranchNo telNo

B1 65509876

B2 8976540

B2 8907654

B3 6789008

After Mapping:

Branch Branch_Tel

Mapping Weak Entities 10

Create a relation for each weak entity that includes all the simple attributes of that entity.

A weak entity’s key includes its key and the primary key of the owner entity as FK .

The PK of the weak entity: is the combination of the two keys

E1 ( A, B )

E2 (X, A, Y)

FK : A references E1 (A)

E2 E1 R M N

Y X

A B

Mapping Weak Entities - Example 11

Employee has Dependents

Employee ( EmpNo, Lname)

Dependents(EmpNo, DepName, DepAge)

FK : EmpNo references Employee (EmpNo)

1 M

EmpNo DepName Lname DepAge

• One to many

• One to one

• Many to many

Mapping Binary Relationships 12

Mapping Binary Relationships 13

Identify one entity as “parent” and other entity as “child”

As a general rule:

PK of parent is added to child as FK

Any attributes of the relationship

are added to child relation

1. One-to-many (1:N) binary relationship

14

For each 1:* binary relationship, the entity on the ‘one side’ of the

relationship is designated as the parent entity and the entity on the ‘many

side’ is designated as the child entity

To represent this relationship:

Add a copy of the primary key attribute(s) of parent entity ‘one side’ into the relation representing the child entity ‘many side’, to act as a foreign key.

Add the attributes of the relationship into the relation.

E2 E1 R

1 N

R1 B E2-PK E1-PK A

• E1 ( E1-PK , A)

• E2 ( E2-PK , B , E1_PK , R1 )

FK1 : E1-PK references E1 (E1-PK)

Example 1

15

Staff Department Has

1 N

year sName

sCode DeptNo DeptName

• Department (DeptNo, DeptName)

• Staff (sCode, sName , DeptNo , year)

FK: DeptNO references Department(DeptNo)

• The Department has Staff relationship is a 1:* relationship,

• A single department can has many staff members.

• Department is on the ‘one side’ and represents the parent entity, and Staff is on the ‘many

side’ and represents the child entity.

• The relationship between these entities is established by placing a copy

• of the primary key of the Department (parent) entity, DeptNo, into the Staff (child)

relation

16

Example 1

DeptNo DeptName

140 Information System

160 Computer Science

171 Networks

SID SName

1211 Nora

6550 Fatima

2250 Dena S.

8765 Samar N.

7895 Sara L.

9897 Reem N.

Department

Staff

SID SName DeptNo Year

1211 Nora 140 2010

6550 Fatima 171 2008

2250 Dena S. 140 2013

8765 Samar N. 160 2005

7895 Sara L. 171 2009

9897 Reem N. 190 2006

Staff

DeptNo DeptName

140 Information System

160 Computer Science

171 Networks

Department

After Mapping:

1

M

Example 2

17

Foreign key

• CUSTOMER (Customer_ID, Customer_Name, Customer_Address)

• Order (Order_ID, Order_Date, Customer_ID)

FK: Customer_ID references CUSTOMER (Customer_ID)

2- One-to-one (1:1) binary relationship

18

Creating relations to represent a 1:1 relationship is slightly more complex

as the cardinality cannot be used to help identify the parent and child

entities in a relationship.

The participation are used to help decide how to map the relationship.

We consider how to create relations to represent the following

participation constraints:

(a) mandatory participation on both sides of 1:1 relationship

(b) optional participation on both sides of 1:1 relationship

(c) mandatory participation on one side of 1:1 relationship


19

A. Mandatory participation on both sides

B. Optional on both sides

Choose one entity and add its PK, and attributes of the relationship, to the

other entity.

E2 E1 R

1 1

R1 B E2-PK E1-PK A

• E1 ( E1-PK , A)

• E2 ( E2-PK , B


, E1-PK , R1 )

• E1 ( E1-PK , A

• E2 ( E2-PK , B)


, E2-PK , R1 )


20

C. Mandatory participation on one side

In this case we are able to identify the parent and child entities for the 1:1

relationship using the participation constraints.

The entity that has optional participation in the relationship is designated

as the parent entity, and the entity that has mandatory participation in the

relationship is designated as the child entity

To map this relation, Add the PK attributes of the optional side “Parent”,

and attributes of the relationship, to the mandatory side “Child”.

E2 E1 R

1 1

R1 B E2-PK E1-PK A

• E1 ( E1-PK , A)

• E2 ( E2-PK , B


, E1-PK , R1 )

1:1 relationship -Mandatory on both sides 24

Employee( Emp_name, Emp_id )

Office (officeNo, office_Loc, Emp_id, year)

FKs: Emp_id references Employee (Emp_id)

Employee Office

1 1

has

Emp_name officeNo

Emp_id Office_Loc year

1:1 relationship - Mandatory on one sides

25


Spouse(Spouse_id, Spouse_name, Emp_id, year) FKs: emp_id references employee (Emp_id)

Employee Spouse

1 1

has

Emp_name Spouse_id

Emp_id Spoude_name

year

1:1 relationship - Optional on both sides

26


Car (Car_No, Car_name, Emp_id, year)

FKs: Emp_id references Employee (Emp_id)

Employee Car

1 1

use

Emp_name Car_No

Emp_id Car_name year

3. Many-to-many (M:N) binary relationship

27

Create a relation to represent the relationship and include any attributes

that are part of the relationship.

Add the primary key attribute(s) of the entities that participate in the

relationship into the new relation, to act as foreign keys.

These foreign keys will also form the primary key of the new relation,

possibly in combination with some of the attributes of the relationship.

E2 E1 R

M N

R1 B E2-PK E1-PK A

R (E1-PK, E2-PK , R1 )

__________ E1 ( E1-PK , A)

E2 ( E2-PK , B) FK1 : E1-PK references E1 (E1-PK)


Example 1 28

• Student (stNo, stName)

• Subject (sCode, sName)

• Enroll (stNo, sCode, date)

FKs: stNO references Student(stNo)

sCode references Subject(sCode)

SUBJECT STUDENT Enroll

M N

date sName

sCode stNo stName

SNO S_ID Date

433099876 IS 220 3-1-2014

433099876 IS 333 5-4-2014

433221660 IS 220 6-3-2014

433099876 CS 110 3-1-2014

29

StNo StName

433099865 Asma

433099876 Nouf

433221660 Noura

sCode sName

CS 110 Programming Language (1)

IS 333 Project Management

IS 220 Database Fundamentals

Student Subject

Enroll

The Supplies relationship will need to become a separate relation

Example 2

30

M M

New relation

Foreign key

Foreign key

Composite primary key

• RAW_MATERIALS (Material_ID, Standard_cost, unit-of_measure)

• VENDOR (Vendor_ID, Vendor_Name, Vendor_Address)

• QUOTE (Material_ID, Vendor_ID, Unit_price)

FKs: Material_ID references RAW_MATERIALS (Material_ID)

Vendor_ID references VENDOR (Vendor_ID) 31

• One to many

• One to one

• Many to many

Mapping Unary Relationships 32

Unary one-to-many (1:N) relationships

33

For a 1:N recursive relationship represent it as a single relation with two copies of the primary key ( one needs to be renamed and treated as the FK), plus attributes of the relationship. .

A recursive foreign key is a foreign key in a relation that references the

primary key values of that same relation.

E1 ( E1-PK , A

FK1 : E1_PK_Copy references E1 (E1-PK)

, E1_PK_Copy , R1 )

E1 R

1

E1-PK A

M

R1

1

M

Employee ( Employee_ID,Name,Birthdate,Manager_ID)

FK : Manager_ID references Employee (Employee_ID)

34

Unary many-to-many (M:N) relationships

35

For a M:N recursive relationship , Two relations are created;

One to represent the entity type in the relationship

A new relation to represent the relationship.

The new relation would includes two copies of the primary key, and attributes of the relationship.

The copies of the primary keys act as foreign keys and have to be renamed to indicate the purpose of each in the relation.

N

E1 R

M

E1-PK A

R1

E1 ( E1-PK , A)

New_E ( E1-PK ,


FK2 : E1_PK_copy references E1 (E1-PK)

E1_PK_copy , R1 )

• ITEM (Item_No, Name, Unit_Cost)

• COMPONENT (Item_No, Component_No, Quantity)

FK1: Item_No references ITEM (Item_No)

FK2: Component_No references ITEM (Item_No)

36

M

M

Unary one-to-one (1:1) 37

Mandatory participation on both sides

Follow the rules of mapping 1:M unary relationship

represent the recursive relationship as a single relation with two copies of the

primary key.

Optional on both sides

Follow the rules of mapping M:N unary relationship

create a new relation to represent the relationship.

Mandatory on one side

Follow either of the two methods above.

Unary one-to-one (1:1) 38

• Person (SSN , Name)

• Marriage (Husband_SSN, Wife_SSN, Date)

FK1: Husband_SSN reference Person(SSN)

FK2: Wife_SSN reference Person(SSN)

Mapping Complex Relationships (n-ary) 39

Mapping Complex Relationships (n-ary)

40

For each complex n–ary relationship R where n>2, create a new relation

to represent the relationship and include any attributes that are part of

the relationship.

Add a copy of the primary key attribute(s) of the entities E1,E2.. En that

participate in the complex relationship into the new relation, to act as

foreign keys. However, this will change if the cardinality constraints on

any of the participating entities in R is 1 !

Any foreign keys that represent a ‘many’ relationship generally will form

the primary key of this new relation, possibly in combination with some of

the attributes of the relationship


41

E2 E1 R

R1 B E2-PK E1-PK A

E3

A E3-PK

R (E1-PK, E2-PK , E3-PK, R1 )

E1 ( E1-PK , A) E2 ( E2-PK , B)



FK3: E3-PK references E3 (E3-PK)

E3 ( E3-PK , A)


42

Supplier (SName) Project (ProjName) Part (PartNo)

Supply (SName, PartNo, ProjName, Quantity)

FKs : SName references Supplier(SName)

PartNo references Part(PartNo)

ProjName references Project(ProjName)

Mapping Superclass/subclass relationship types 43

Mapping Superclass/subclass relationship types

44

Identify superclass entity as parent entity and subclass entity as the child

entity.

There are various options on how to represent such a relationship as one

or more relations.

The selection of the most appropriate option is dependent on a number

of factors:

Disjointness and participation constraints on the superclass/subclass

relationship.


45


46

Owner

PrivateOwner BusinessOwner name bType

d

fName

lName

contactName

bName

onwerNo telNo address

How to map these entities?

47

48

Exercise 49

Convert the following ERD to relational tables, specify the primary key and foreign keys

sex

Person

Faculty Student

d class

Street

Office

Rank

Adress Bdate

SSN

Name

Fname

Lname

City

Apt_no

Salary

Belong

Department

Major

M

N

M

1

Documents

GUIDELINES FOR GOOD RELATIONAL DESIGN ... ( EmpNo, FName, MName, LName ) Mapping Multi_valued Attributes 7 A multivalued attribute M of an entity E is represented by a separate table