Chapter 3

Database Design:
Logical Design-Part2
Introduction
 Steps For Designing
Database
Conceptual Design STEP 1

STEP 2
Logical Design
STEP 3

STEP 4 STEP 6
STEP 5 STEP 7
Physical Design
STEP 8
STEP 9
 Methodology Overview -
Conceptual Database Design
 Step
1 Build local conceptual data
model for each user view
 Step 1.1 Identify entity types
 Step 1.2 Identify relationship types
 Step 1.3 Identify and associate attributes with entity or
relationship types
 Step 1.4 Determine attribute domains
 Step 1.5 Determine candidate and primary key attributes
 Step 1.6 Consider use of enhanced modeling concepts (optional
step)
 Step 1.7 Check model for redundancy
 Step 1.8 Validate local conceptual model against user transactions
 Step 1.9 Review local conceptual data model with user
 Methodology Overview - Logical
Database Design for Relational
Model
 Step2 Build and validate local logical
data model for each view
 Step 2.1 Remove features not compatible with the
relational model (optional step)
 Step 2.2 Derive relations for local logical data model

 Step 2.3 Validate relations using

normalization
 Step 2.4 Validate relations against user transactions

 Step 2.5 Define integrity constraints

 Step 2.6 Review local logical data model with user

 Methodology Overview - Logical
Database Design for Relational
Model(cont)
 Step3 Build and validate global logical
data model
 Step 3.1 Merge local logical data models into
global model
 Step 3.2 Validate global logical data model

 Step 3.3 Check for future growth

 Step 3.4 Review global logical data model with

users
 Methodology Overview - Physical
Database Design for Relational
Databases
 Step 4 Translate global logical data model for
target DBMS
 Step 4.1 Design base relations
 Step 4.2 Design representation of derived data
 Step 4.3 Design enterprise constraints

 Step 5 Design physical representation

 Step 5.1 Analyze transactions
 Step 5.2 Choose file organization
 Step 5.3 Choose indexes
 Step 5.4 Estimate disk space requirements
Methodology Overview - Physical
Database Design for Relational
Databases(cont)
 Step 6 Design user views
 Step 7 Design security mechanisms

 Step 8 Consider the introduction of

controlled redundancy
 Step 9 Monitor and tune the
operational system
Normalization
 Normalization

 Main objective in developing a logical data

model for relational database systems is to
create an accurate representation of
the data, its relationships, and
constraints.
 To achieve this objective, must identify a
suitable set of relations.
 Normalization(cont)
 Four most commonly used normal forms
are first (1NF), second (2NF) and
third (3NF) normal forms, and
Boyce–Codd normal form (BCNF).
 Based on functional dependencies
among the attributes of a relation.
 A relation can be normalized to a specific
form to prevent possible occurrence
of anomalies and data redundancy.
Data Redundancy
 Data Redundancy(cont)
 StaffBranch relation has redundant data:
details of a branch are repeated for
every member of staff.
 In contrast, branch information appears
only once for each branch in Branch relation
and only branchNo is repeated in Staff
relation, to represent where each member of
staff works.
 Normalization(cont)
 A bad database design may suffer from anomalies that make the
database difficult to use:
COMPANIES(company_name, owner_id,
company_address, date_founded,owner_name,
owner_title, #shares )
Suppose Primary Key (company_name, owner_id)
 Anomalies:
 update anomaly occurs if changing the value of an attribute
leads to an inconsistent database state.
 insertion anomaly occurs if we cannot insert a tuple due to
some design flaw.
 deletion anomaly occurs if deleting a tuple results in
unexpected loss of information.
 Normalization is the systematic process for removing all such
anomalies in database design.
 Update Anomaly
 If a company has three owners, there are three tuples in the
COMPANIES relation for this company.
 If this company moves to a new location, the company’s
address must be updated consistently in all three tuples
 updating the company address in just one or two of the tuples
creates an inconsistent database state
 It would be better if the company name and address were in a
separate relation so that the address of each company appears in
only one tuple

COMPANIES(company_name, company_address,
date_founded, owner_id, owner_name,
owner_title, #shares )
 Example of Update
Anomalies
To insert a new staff with branchNo B007 into the
StaffBranch relation;
To delete a tuple that represents the last member of staff
located at a branch B007;
To change the address of branch B003.
StaffBranch
staffNo sName position salary branchNo bAddress
SL21 John White Manager 30000 B005 22 Deer Rd, London
SG37 Ann Beech Assistant 12000 B003 163 Main St,Glasgow
SG14 David Ford Supervisor 18000 B003 163 Main St,Glasgow
SA9 Mary Howe Assistant 9000 B007 16 Argyll St, Aberdeen
SG5 Susan Brand Manager 24000 B003 163 Main St,Glasgow
SL41 Julie Lee Assistant 9000 B005 22 Deer Rd, London

Figure 1 StraffBranch relation

 Example of Update
Anomalies (cont)
Staff

staffNo sName position salary branceNo

SL21 John White Manager 30000 B005
SG37 Ann Beech Assistant 12000 B003
SG14 David Ford Supervisor 18000 B003
SA9 Mary Howe Assistant 9000 B007
SG5 Susan Brand Manager 24000 B003
SL41 Julie Lee Assistant 9000 B005

Branch
branceNo bAddress
B005 22 Deer Rd, London
B007 16 Argyll St, Aberdeen
B003 163 Main St,Glasgow

Figure 2 Straff and Branch relations

 Insert Anomaly
 Suppose that three people have just created a new company:
 the three founders have no titles yet
 stock distributions have yet to be defined
 The new company cannot be added to the COMPANIES
relation because there is not enough information to fill in all
the attributes of a tuple
 at best, null values can be used to complete a tuple
 It would be better if owner and stock information was stored
in a different relation

COMPANIES(company_name, company_address,
date_founded, owner_id, owner_name,
owner_title, #shares )
 Delete Anomaly
 Suppose that an owner of a company retires so is no longer
an owner but retains stock in the company
 If this person’s tuple is deleted from the COMPANIES
relation, then we lose the information about how much
stock the person still owns
 If the stock information was stored in a different relation,
then we can retain this information after the person is
deleted as an owner of the company

COMPANIES(company_name, company_address,
date_founded, owner_id, owner_name,
owner_title, #shares )
Relationship Between
Normal Forms
 Steps For Normalization
Unnormalized Form

Remove Repeating Groups

First Normalized Form

(1NF)

Remove Partial Dependencies

Second
Normalized Form
(2NF)

Remove Transitive Dependencies

Third
Normalized Form
(3NF)
Unnormalized A table that contains one or more repeating groups
Form (UNF)

First Normal A relation in which the intersection of each row and

Form (1NF) column contains one and only one value

Indicates that if A and B are attributes of a relation,

Full Functional
B is fully functionally dependent on A if B is
Dependency
functionally dependent on A, but not on any proper
subset of A.

Second Normal A relation that is in 1NF form and every non-

Form (2NF) primary-key attribute is fully functionality
dependent on the primary key.

A condition where A, B, C are attributes of a relation

Transitive
such that if A->B and B->C then C is transitively
Dependency
dependent on A via B (provided that A is not
functionally dependent on B or C)

Third Normal A relation that is in 1NF and 2NF, and in which no

Form (3NF) non-primary key attribute is transitively dependent
on the primary key
 Unnormalized
Table/Relation
SALESPERSON SALESPERSON SALES CUSTOMER CUSTOMER WAREHOUSE WAREHOUSE SALES
NUMBER NAME AREA NUMBER NAME NUMBER LOCATION AMOUNT

3462 Waters West 18765 Delta Sys. 4 Fargo 13540

18830 Levy & Sons 3 Bismarck 10600
19242 Ranier Com 3 Bismarck 9700

3593 Dryne East 18841 R.W.Flood 2 Superior 11560

18899 Seward 2 Superior 2590
19565 Stodola 1 Plymouth 8800

… … … … … … … …
 SALESPERSON
First Normal {PK}
SALESPERSON
NUMBER
SALESPERSON
NAME
SALES
AREA

Form (1NF) 3462

3593
Waters
Dryne
West
East

… … …
SALESPERSON-CUSTOMER
SALESPERSON CUSTOMER CUSTOMER NAME WAREHOUSE WAREHOUSE SALES
{PK} NUMBER NUMBER NUMBER LOCATION AMOUNT

3462 18765 Delta Sys. 4 Fargo 13540

3462 18830 Levy & Sons 3 Bismarck 10600

3462 19242 Ranier Com 3 Bismarck 9700

3593 18841 R.W.Flood 2 Superior 11560

3593 18899 Seward 2 Superior 2590

3593 19565 Stodola 1 Plymouth 8800

… … … … … …
 A Data Model Diagarm
(SALESPERSON-CUSTOMER)
SALES
AMOUNT

CUSTOMER
NAME
SALESPERSON CUSTOMER
NUMBER NUMBER

WAREHOUSE
NUMBER

WAREHOUSE
LOCATION
 SALESPERSON CUSTOMER SALES

Second
NUMBER AMOUNT
SALES NUMBER
3462 18765 13540
3462 18830 10600

Normal Form 3462 19242 9700

(2NF)
3593 18841 11560

3593 18899 2590

3593 19565 8800

CUSTOMER-WAREHOUSE … … …

{PK} CUSTOMER CUSTOMER NAME WAREHOUSE WAREHOUSE

NUMBER NUMBER LOCATION

18765 Delta Sys. 4 Fargo

18830 Levy & Sons 3 Bismarck

19242 Ranier Com 3 Bismarck

18841 R.W.Flood 2 Superior

18899 Seward 2 Superior

19565 Stodola 1 Plymouth

… … … …
 SALESPERSON CUSTOMER SALES
SALESPERSON SALES NUMBER NUMBER AMOUNT

3462 18765 13540

SALESPERSON SALESPERSON SALES
{PK} NUMBER NAME AREA 3462 18830 10600

3462 19242 9700

3462 Waters West
3593 Dryne East 3593 18841 11560

3593 18899 2590

… … …
3593 19565 8800

CUSTOMER-WAREHOUSE … … …

{PK} CUSTOMER CUSTOMER NAME WAREHOUSE WAREHOUSE

NUMBER NUMBER LOCATION

18765 Delta Sys. 4 Fargo

18830 Levy & Sons 3 Bismarck

19242 Ranier Com 3 Bismarck

18841 R.W.Flood 2 Superior

18899 Seward 2 Superior

19565 Stodola 1 Plymouth

… … … …
 A Data Model Diagram
(CUSTOMER-WAREHOUSE)

CUSTOMER
CUSTOMER
NAME
NUMBER

WAREHOUSE
NUMBER

WAREHOUSE
LOCATION
 WAREHOUSE

Third Normal {PK}

WAREHOUSE
NUMBER
WAREHOUSE
LOCATION

Form (3NF) 4
3
Fargo
Bismarck

CUSTOMER {FK} 2 Superior

CUSTOMER CUSTOMER WAREHOUSE

{PK} NUMBER NAME NUMBER 1 Plymouth

18765 Delta Sys. 4 … …

18830 Levy & Sons 3

19242 Ranier Com 3

18841 R.W.Flood 2

18899 Seward 2

19565 Stodola 1

… … …
 SALESPERSON SALES
SALESPERSON CUSTOMER SALES
SALESPERSON SALESPERSON SALES
NUMBER NUMBER AMOUNT
{PK} NUMBER NAME AREA
3462 18765 13540
3462 18830 10600
3462 Waters West
3593 Dryne East 3462 19242 9700

… … …
3593 18841 11560

CUSTOMER {FK} 3593 18899 2590

CUSTOMER CUSTOMER WAREHOUSE 3593 19565 8800

{PK} NUMBER NAME NUMBER

… … …
18765 Delta Sys. 4
18830 Levy & Sons 3 WAREHOUSE
WAREHOUSE WAREHOUSE
19242 Ranier Com 3 {PK} NUMBER LOCATION

4 Fargo
18841 R.W.Flood 2
3 Bismarck

18899 Seward 2
2 Superior

19565 Stodola 1
1 Plymouth

… … … … …
 Boyce-Codd Form (BCNF)
 A more restricted version of 3NF (known as Boyce-
Codd Normal Form) A relation is in BCNF, if
and only if, every determinant is a candidate
key.
 Consider the following relation:
StaffProject(StnNo,PjcNo, StaffNo);
StnNo,PjcNo -> StaffNo (primary key)
StaffNo,StnNo -> PjcNo (candidate key)
StaffNo -> PjcNo (not a candidate key)
 Boyce-Codd Normal Form for above:
Project(PjcNo, StnNo);
Staff(StaffNo, PjcNo)
 Conceptual Level,
Conceptual Schema,
Logical Design,
Logical Data Model
 CASE 1

DreamHome Case Study – An Overview

Pls refer to Connolly, T., Begg,

C.(2002).“Database System: A Practical
Approach to Design, Implementation, and
Management”, Addision Wesley, USA
Chapter 10, Section 10.4.1, pp 309
 Functional
Dependencies
Functional dependency describes the relationship between
attributes in a relation.
For example, if A and B are attributes of relation R, and B is
functionally dependent on A ( denoted A B), if each value of
A is associated with exactly one value of B. ( A and B may each
consist of one or more attributes.)

B is functionally
A B
dependent on A

Determinant
Refers to the attribute or group of
attributes on the left-hand side of
the arrow of a functional
dependency
 First Normal Form (1NF)

Unnormalized form (UNF)

A table that contains one or more repeating groups.
ClientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName

6 lawrence Tina
1-Jul-00 31-Aug-01 350 CO40 Murphy
PG4 St,Glasgow
John
CR76
kay Tony
PG16 5 Novar Dr, Shaw
1-Sep-02 1-Sep-02 450 CO93
Glasgow
6 lawrence Tina
PG4 1-Sep-99 10-Jun-00 350 CO40 Murphy
St,Glasgow

Tony
Aline 2 Manor Rd,
CR56 PG36 10-Oct-00 1-Dec-01 370 CO93 Shaw
Stewart Glasgow

Tony
5 Novar Dr, Shaw
PG16 1-Nov-02 1-Aug-03 450 CO93
Glasgow

Figure 3 ClientRental unnormalized table

 1NF ClientRental relation with
the first approach
The ClientRental relation is defined as follows:
ClientRental
( clientNo, propertyNo, cName, pAddress, rentStart, rentFinish, rent,
ownerNo, oName)

ClientNo propertyNo cName pAddress rentStart rentFinish rent ownerNo oName

John 6 lawrence Tina

CR76 PG4 1-Jul-00 31-Aug-01 350 CO40
Kay St,Glasgow Murphy

John 5 Novar Dr, Tony

CR76 PG16 1-Sep-02 1-Sep-02 450 CO93
Kay Glasgow Shaw

Aline 6 lawrence Tina

CR56 PG4 1-Sep-99 10-Jun-00 350 CO40
Stewart St,Glasgow Murphy
Tony
Aline 2 Manor Rd,
CR56 PG36 10-Oct-00 1-Dec-01 370 CO93 Shaw
Stewart Glasgow
Tony
Aline 5 Novar Dr,
CR56 PG16 1-Nov-02 1-Aug-03 450 CO93 Shaw
Stewart Glasgow

Figure 4 1NF ClientRental relation with the first approach

1NF ClientRental relation with the
second approach
Client (clientNo, cName)
PropertyRentalOwner (clientNo, propertyNo, pAddress,
rentStart, rentFinish, rent, ownerNo,
oName)
ClientNo cName With the second approach, we remove the repeating group
CR76 John Kay (property rented details) by placing the repeating data along
CR56 Aline Stewart
with a copy of the original key attribute (clientNo) in a
separate relation.

ClientNo propertyNo pAddress rentStart rentFinish rent ownerNo oName

6 lawrence Tina
CR76 PG4 1-Jul-00 31-Aug-01 350 CO40
St,Glasgow Murphy
5 Novar Dr, Tony
CR76 PG16 1-Sep-02 1-Sep-02 450 CO93
Glasgow Shaw
6 lawrence Tina
CR56 PG4 1-Sep-99 10-Jun-00 350 CO40
St,Glasgow Murphy
2 Manor Rd, Tony
CR56 PG36 10-Oct-00 1-Dec-01 370 CO93
Glasgow Shaw
5 Novar Dr, Tony
CR56 PG16 1-Nov-02 1-Aug-03 450 CO93
Glasgow Shaw

Figure 5 1NF ClientRental relation with the second approach

 2NF ClientRental
relation
The ClientRental relation has the following functional
dependencies:

fd1 clientNo, propertyNo  rentStart, rentFinish

(Primary Key)
fd2 clientNo  cName
(Partial dependency)
fd3 propertyNo  pAddress, rent, ownerNo, oName

(Partial dependency)
fd4 ownerNo  oName
(Transitive Dependency)
fd5 clientNo, rentStart  propertyNo, pAddress,
rentFinish, rent, ownerNo, oName
(Candidate key)
fd6 propertyNo, rentStart  clientNo, cName, rentFinish
(Candidate key)
 2NF ClientRental
relation
Client (clientNo, cName)
Rental (clientNo, propertyNo, rentStart, rentFinish)
PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)

Client Rental
ClientNo cName ClientNo propertyNo rentStart rentFinish
CR76 John Kay CR76 PG4 1-Jul-00 31-Aug-01
CR56 Aline Stewart CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03
PropertyOwner

propertyNo pAddress rent ownerNo oName

PG4 6 lawrence St,Glasgow 350 CO40 Tina Murphy

PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw

PG36 2 Manor Rd, Glasgow 370 CO93 Tony Shaw

Figure 6 2NF ClientRental relation

 3NF ClientRental
relation
The functional dependencies for the Client, Rental and
PropertyOwner relations are as follows:

Client
fd2 clientNo  cName (Primary Key)

Rental
fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)
fd5 clientNo, rentStart  propertyNo, rentFinish (Candidate key)
fd6 propertyNo, rentStart  clientNo, rentFinish (Candidate key)

PropertyOwner
fd3 propertyNo  pAddress, rent, ownerNo, oName (Primary Key)
fd4 ownerNo  oName (Transitive Dependency)
 3NF ClientRental
relation
The resulting 3NF relations have the forms:

Client
(clientNo, cName)

Rental
(clientNo, propertyNo, rentStart, rentFinish)

PropertyOwner
(propertyNo, pAddress, rent, ownerNo)

Owner
(ownerNo, oName)
 3NF ClientRental
relation
Client Rental
ClientNo propertyNo rentStart rentFinish
ClientNo cName
CR76 PG4 1-Jul-00 31-Aug-01
CR76 John Kay
CR56 Aline Stewart CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03

PropertyOwner Owner

propertyNo pAddress rent ownerNo ownerNo oName

PG4 6 lawrence St,Glasgow 350 CO40 CO40 Tina Murphy

PG16 5 Novar Dr, Glasgow 450 CO93 CO93 Tony Shaw

PG36 2 Manor Rd, Glasgow 370 CO93

Figure 7 2NF ClientRental relation

 Boyce-Codd Normal
Form (BCNF)
Boyce-Codd normal form (BCNF)
A relation is in BCNF, if and only if, every determinant
is a candidate key.

The difference between 3NF and BCNF is that for a

functional dependency A  B, 3NF allows this
dependency in a relation if B is a primary-key
attribute and A is not a candidate key, whereas BCNF
insists that for this dependency to remain in a
relation, A must be a candidate key.
 Boyce-Codd Normal Form
(BCNF)(cont)
 To test whether a relation is in BCNF, we identify all
the determinant is an attribute, or a group of
attributes, on which some other attribute is fully
functionally dependent.
 Violation of BCNF is quite rare, since it may only
happen under specific condition. The potential to
violate BCNF may occur in a relation that:
 Contains two (or more) composite candidate keys;
 The candidate keys overlap, that is have at least
one attribute in common.
 Example of BCNF
fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)
fd2 clientNo, rentStart propertyNo, rentFinish (Candidate key)
fd3 propertyNo, rentStart  clientNo, rentFinish (Candidate key)

3NF already
BCNF 3NF
Client Rental
already
ClientNo propertyNo rentStart rentFinish BCNF
ClientNo cName
CR76 PG4 1-Jul-00 31-Aug-01
CR76 John Kay
CR56 Aline Stewart CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
3NF CR56 PG16 1-Nov-02 1-Aug-03
already
PropertyOwner BCNF
Owner
3NF
propertyNo pAddress rent ownerNo
ownerNo oName already
PG4 6 lawrence St,Glasgow 350 CO40 BCNF
CO40 Tina Murphy
PG16 5 Novar Dr, Glasgow 450 CO93
CO93 Tony Shaw
PG36 2 Manor Rd, Glasgow 370 CO93
 Example of BCNF
fd1 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary Key)
fd2 staffNo, interviewDate, interviewTime clientNo, roomNo (Candidate key)
fd3 roomNo, interviewDate, interviewTime  clientNo, staffNo (Candidate key)
fd4 staffNo, interviewDate  roomNo (not a candidate key)

As a consequece the ClientInterview relation may suffer from update anomalies. For
example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on
the 13-May-02.

ClientInterview
ClientNo interviewDate interviewTime staffNo roomNo
CR76 13-May-02 10.30 SG5 G101
CR56 13-May-02 12.00 SG5 G101
CR74 13-May-02 12.00 SG37 G102
CR56 1-Jul-02 10.30 SG5 G102

Figure 8 ClientInterview relation

 Example of BCNF
fd1 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary Key)
fd2 staffNo, interviewDate, interviewTime clientNo, roomNo (Candidate key)
fd3 roomNo, interviewDate, interviewTime  clientNo, staffNo (Candidate key)
fd4 staffNo, interviewDate  roomNo (not a candidate key)

As a consequece the ClientInterview relation may suffer from update anomalies. For
example, two tuples have to be updated if the roomNo need be changed for staffNo SG5 on
the 13-May-02.

ClientInterview
ClientNo interviewDate interviewTime staffNo roomNo
CR76 13-May-02 10.30 SG5 G101
CR56 13-May-02 12.00 SG5 G101
CR74 13-May-02 12.00 SG37 G102
CR56 1-Jul-02 10.30 SG5 G102

Figure 8 ClientInterview relation

 Example of BCNF(cont)
To transform the ClientInterview relation to BCNF, we must remove
the violating functional dependency by creating two new relations
called Interview and StaffRoom as shown below,

Interview (clientNo, interviewDate, interviewTime, staffNo)

StaffRoom(staffNo, interviewDate, roomNo)
Interview
ClientNo interviewDate interviewTime staffNo
CR76 13-May-02 10.30 SG5
CR76 13-May-02 12.00 SG5
CR74 13-May-02 12.00 SG37
CR56 1-Jul-02 10.30 SG5

StaffRoom
staffNo interviewDate roomNo
SG5 13-May-02 G101
SG37 13-May-02 G102
SG5 1-Jul-02 G102

Figure 9 BCNF Interview and StaffRoom relations

Questions