BACS3183

Advanced Database Management

Chapter 5
Relational Database Design
 Learning Outcomes
At the end of this class, you should be able to
•Explain normalization and its role in the database design
process.
•Determine the functional dependency between two or
more attributes that are a subset of a relation.
•Describe the properties of 1NF, 2NF, 3NF, BCNF.
•Transform lower normal forms to higher normal forms

2
 1. Relational Database Design
• Relational database design requires that we find a “good”
collection of relation schemas
• A bad design may lead to
- Repetition of Information.
• Leads to anomalies
– Loss of information (lossy decomposition).
• Design Goals:
– Avoid redundant data
– Ensure that relationships among attributes are
represented.
– Facilitate the checking of updates for violation of
integrity constraints
 Problems of Data Redundancy

• Update anomalies include

– Insertion
– Deletion
– Modification

4
 Problems of Data Redundancy
Modification Anomaly
The same information can be expressed on multiple rows;
therefore modification to the table may result in logical
inconsistencies

5
 Problems of Data Redundancy
Insertion Anomaly
There are circumstances in which certain facts cannot be
recorded at all

6
 Problems of Data Redundancy
Deletion Anomaly
Under certain circumstances, deletion of data representing certain
facts necessitates deletion of data representing completely different
facts.

All information about Dr. Giddens is lost if he is

temporarily stopped to be assigned to any courses.
7
 2. Functional Dependency

• Vital for the redesign of database

schemas to eliminate redundancy

• Enable systematic improvement of

database designs

8
 Functional Dependency
• Functional dependency describes relationship
between attributes.
• For example,
If A and B are attributes of relation R,
B is functionally dependent on A
(denoted A  B),
if each value of A in R is associated with exactly
one value of B in R.

9
 Functional Dependency

• The determinant of a functional

dependency refers to the attribute or
group of attributes on the left-hand side
of the arrow.

10
 Functional Dependency
A  B (B is functionally dependent on A)
if each value of A in R is associated with
exactly one value of B in R.
Example Functional Dependency

12
Example Functional Dependency that
holds for all Time
• Consider the values shown in staffNo and
sName attributes of the Staff relation
• The functional dependency is
staffNo → sName sName → staffNo ??

13
 Full Functional Dependency
Full functional dependency indicates that if A and B are
attributes of a relation, B is fully functionally dependent on
A, if B is functionally dependent on A, but not on any proper
subset of A.
• Exists in the Staff relation : staffNo, sName → branchNo
• True - each value of (staffNo, sName) is associated with a
single value of branchNo.
• However, branchNo is also functionally dependent on a
subset of (staffNo, sName), namely staffNo. Example above
is a partial dependency.

14
 Transitive Dependency
• A transitive dependency in a relation can
potentially cause update anomalies.

• Transitive dependency describes a condition

where A, B, and C are attributes of a relation
such that
if A → B and B → C, then
C is transitively dependent on A via B
(provided that A is not functionally
dependent on B or C).
15
 Example Transitive Dependency

staffNo → sName, position, salary, branchNo, bAddress

branchNo → bAddress
Transitive dependency,
staffNo → branchNo,
branchNo → bAddress
Thus bAddress is transitively dependent on staffNo
via branchNo
16
 3. Normalization

• FDs are the basis of normalization -- a formal

methodology for refining and creating good
relational designs
One common schema refinement techniques -
decomposition

Starts with a relational schema, and uses the FDs to

guide the schema decomposition,
e.g., R (ABCD)

R1(AB) R2 (BCD) 17
 Properties Of Decomposition

• Two important properties:

– Lossless-join property : the final relations
must contain exactly the information
contained in the original relation, without
losing any nor adding any other ones.

– Dependency preservation property : the final

relations must be characterized by the same
FDs as the original relation
18
 The Process of Normalization

Normalization is a formal methodology for

refining and creating good relational designs 19
Data Source Example

20
 Unnormalized Form (UNF)
• A table that contains one or more repeating
groups.
• To create an unnormalized table
– Transform the data from the information source
(e.g. form) into table format with columns and
rows.

21
Any Insertion, Deletion and Modification Anomalies?
22
Which normal form is the table in?
 First Normal Form (1NF)
• A relation in which the intersection of each row
and column contains one and only one value.

Not in 1NF

23
 UNF to 1NF
• Nominate an attribute or group of attributes to act as
the key for the unnormalized table.
• Identify the repeating group(s) in the unnormalized
table which repeats for the key attribute(s).

24
 UNF to 1NF
• Remove the repeating group by
– Entering appropriate data into the empty
columns of rows containing the repeating
data (‘flattening’ the table).

25
‘Flattening the Table’

26
Dependency Diagram
1NF
ORDERLINE

OrderID, ProductID → OrderQuantity (Full Dependency)

ProductID → ProductDescription, ProductFinish, ProductStandardPrice
(Partial Dependencies)
CustomerID → CustomerName, CustomerAddress (Transitive
Depedencies)
Dependency Diagram
1NF (Remove Repeating Group)
ORDERLINE

ORDERLINE (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress,

ProductID, ProductDescription, ProductFinish, ProductStandardPrice,
OrderQuantity)

ORDER (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress)

ORDERLINE (OrderID*, ProductID, ProductDescription, ProductFinish,
ProductStandardPrice, OrderQuantity)
 Second Normal Form (2NF)
• Based on the concept of full functional
dependency.

• Full functional dependency indicates that

if A and B are attributes of a relation,
B is fully dependent on A if B is functionally
dependent on A but not on any proper subset of A.
studID, studName → programmeCode

29
 Second Normal Form (2NF)
• A relation that is
• in 1NF and
• every non primary-key attribute is
fully functionally dependent on the primary
key.

studID, studName → programmeCode

partial dependency exists

30
 1NF to 2NF
• Identify the primary key for the 1NF relation.

• Identify the functional dependencies in the

relation.

• If partial dependencies exist on the primary

key remove them by placing them in
a new relation along with a copy of their
determinant.
31
1NF (Remove Repeating Group)

ORDERLINE

2NF (Remove Partial Dependencies)

2NF (Remove Partial Dependencies)

ProductID -> ProductDescription, ProductFinish, ProductStandardPrice

(Partial Dependencies)

ORDERLINE (OrderID*, ProductID*, OrderedQuantity)

PRODUCT (ProductID, ProductDescription, ProductFinish,
ProductStandardPrice)
ORDER (OrderID, OrderDate, CustomerID, CustomerName,
CustomerAddress)
 Third Normal Form (3NF)
• Based on the concept of transitive dependency.
• Transitive Dependency is a condition where
– A, B and C are attributes of a relation such that
if A  B and B  C,
then C is transitively dependent on A through B.
(Provided that A is not functionally dependent
on B or C).

34
 Third Normal Form (3NF)
• A relation that is
• in 1NF and 2NF and
• in which no non primary-key attribute is
transitively dependent on the primary key.

35
 2NF to 3NF
• Identify the primary key in the 2NF relation.

• Identify functional dependencies in the

relation.

• If transitive dependencies exist on the

primary key remove them by placing them in
a new relation along with a copy of their
determinant.

36
2NF (Remove Partial Dependencies)

3NF (Remove Transitive Dependencies)

37
3NF (Remove Transitive Dependencies)

CustomerID -> CustomerName, CustomerAddress

(Transitive Dependencies)

ORDERLINE (OrderID*, ProductID*, OrderedQuantity)

PRODUCT (ProductID, ProductDescription, ProductFinish,
ProductStandardPrice)
ORDER (OrderID, OrderDate, CustomerID*)
CUSTOMER (CustomerID, CustomerName, CustomerAddress) 38
 General Definitions of 2NF and 3NF
• Second normal form (2NF)
– A relation that is in 1NF and every non primary-
key attribute is fully functionally dependent on
any candidate key.

• Third normal form (3NF)

– A relation that is in 1NF and 2NF and in which no
non primary-key attribute is transitively
dependent on any candidate key.

Superkey – an attribute or set of attributes that uniquely

identifies a tuple within a relation.
Candidate key – a minimal superkey
39
 The Process of Normalization

Normalization is a formal methodology for

refining and creating good relational designs 40
UNF to 1NF

41
 1NF to 2NF
1NF (Remove Repeating Group)

2NF (Remove Partial Dependencies)

42
 2NF to 3NF
2NF (Remove Partial Dependencies)

3NF (Remove Transitive Dependencies)

 1NF to 2NF
1NF (Remove Repeating Group)
ORDERLINE (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress,
ProductID, ProductDescription, ProductFinish, ProductStandardPrice,
OrderQuantity)

ORDER (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress)

ORDERLINE (OrderID*, ProductID, ProductDescription, ProductFinish,
ProductStandardPrice, OrderQuantity)

2NF (Remove Partial Dependencies)

ProductID -> ProductDescription, ProductFinish, ProductStandardPrice (Partial
Dependencies)

ORDERLINE (OrderID*, ProductID*, OrderedQuantity)

PRODUCT (ProductID, ProductDescription, ProductFinish, ProductStandardPrice)
ORDER (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress)

44
 2NF to 3NF
2NF (Remove Partial Dependencies)
ProductID -> ProductDescription, ProductFinish, ProductStandardPrice (Partial
Dependencies)

ORDERLINE (OrderID*, ProductID*, OrderedQuantity)

PRODUCT (ProductID, ProductDescription, ProductFinish, ProductStandardPrice)
ORDER (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddress)

3NF (Remove Transitive Dependencies)

CustomerID -> CustomerName, CustomerAddress (Transitive Dependencies)

ORDERLINE (OrderID*, ProductID*, OrderedQuantity)

PRODUCT (ProductID, ProductDescription, ProductFinish, ProductStandardPrice)
ORDER (OrderID, OrderDate, CustomerID*)
CUSTOMER (CustomerID, CustomerName, CustomerAddress)
 Boyce–Codd Normal Form (BCNF)
– A relation is in BCNF if and only if every determinant
is a candidate key.

 A student can take more

than 1 majors
 A major can have several
faculty members as
advisors
 A faculty member advises
in only one major area.

StudentID, Subject AdvisorName

AdvisorName Subject AdvisorName is not a candidate key
 Boyce–Codd Normal Form (BCNF)

 A student can take more

than 1 majors
 A major can have several
faculty members as
advisors
 A faculty member advises
in only one major area.

Is this table in 3NF?

Any Insertion, Deletion and Modification Anomalies?
48
 References
• Database Systems: A Practical Approach to
Design, Implementation and Management.
Connolly, T. M. and Begg, C. E. .
• Modern Database Management.Hoffer, J.A.,
Prescott, M., and McFadden,F.
• Database System Concepts Silberschatz, A.,
Korth, H,. and Sudarshan, S.
• Database Processing Fundamentals, Design &
Implementation. Kroenke D.
49