Database Systems

Normalization - l

Dr. Maqbool Khan

1 www.pktutorials.com
 Purpose of Normalization:

▪ Normalization is a technique for producing a set of

suitable relations that support the data requirements of
an enterprise

▪ The process of decomposing relations with anomalies to

produce smaller, well-structured relations

2 www.pktutorials.com
 Characteristic of Suitable Set of Relations:

▪ The minimal number of attributes necessary to support the data

requirements of the enterprise
▪ Attributes with a close logical relationship (described as functional
dependency) are found in the same relation
▪ Minimal redundancy with each attribute represented only once with
the important exception of attributes that form all or part of foreign
keys, which are essential for the joining of related relations

3 www.pktutorials.com
 Benefits of DB with Suitable Relations:

▪ The benefits of using a database that has a suitable set of

relations are:

▪ Easier for the user to access and maintain the data

▪ Take up minimal storage space on computer

4 www.pktutorials.com
5 www.pktutorials.com
 Data Redundancy & Update Anomalies:

▪ Major aim of relational database design is to group attributes into

relations to minimize data redundancy
▪ If this aim is achieved, the potential benefits for the implemented
database include the following:
▪ Updates to the data stored in the database are achieved with a minimal
number of operations thus reducing the opportunities for data
inconsistencies occurring in the database
▪ Reduction in the file storage space required by the base relations thus
minimizing costs

6 www.pktutorials.com
 Data Redundancy & Update Anomalies:

▪ Problems associated with data redundancy are illustrated by comparing

the Staff and Branch relations with the StaffBranch relation
▪ The StaffBranch relation is an alternative format of the Staff and
Branch relations

7 www.pktutorials.com
 Data Redundancy & Update Anomalies:

In the StaffBranch relation

there is redundant data

8 www.pktutorials.com
 Data Redundancy & Update Anomalies:
▪ Relations that contain redundant information may potentially
suffer from update anomalies
▪ Types of update anomalies include:
▪ Insertion
▪ Insert new staff/branch in StaffBranch relation
▪ Deletion
▪ Delete SA9 from StaffBranch relation
▪ Modification
▪ Update the address for branch number B003

9 www.pktutorials.com
 Decomposition:

▪ We can avoid these anomalies by decomposing the original relation into the
Staff and Branch relations
▪ There are two important properties associated with decomposition of a larger
relation into smaller relations:
▪ The lossless-join property ensures that any instance of the original relation
can be identified from corresponding instances in the smaller relations
▪ The dependency preservation property ensures that a constraint on the
original relation can be maintained by simply enforcing some constraint on
each of the smaller relations. In other words, we do not need to perform
joins on the smaller relations to check whether a constraint on the original
relation is violated

10 www.pktutorials.com
 Functional Dependencies:

▪ Important concept associated with normalization

▪ Functional dependency (FD) describes relationship between
attributes and could be defined as:
▪ 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
▪ Functional dependency is a property of the meaning or semantics of the
attributes in a relation
▪ An alternative way to describe the relationship between attributes A and B is
to say that ‘A functionally determines B’

11 www.pktutorials.com
 Determinant:

The determinant of a functional dependency refers to the attribute or

group of attributes on the left-hand side of the arrow

12 www.pktutorials.com
 An Example Functional Dependency:

13 www.pktutorials.com
 Observations: Example FD

▪ The relationship between staffNo and position is one-to-one (1:1): for each staff
number there is only one position

▪ On the other hand, the relationship between position and staffNo is one-to-many
(1:*): there are several staff numbers associated with a given position

▪ For the purposes of normalization, we are interested in identifying functional

dependencies between attributes of a relation that have a one-to-one relationship

▪ A functional dependency is a property of a relational schema (intension) and not a

property of a particular instance of the schema (extension)

14 www.pktutorials.com
 Example: FD for all Time

▪ Consider the values shown in staffNo and sName attributes of

the Staff relation
▪ Based on sample data, the following functional dependencies
appear to hold

▪ staffNo → sName (holds for all time)

▪ sName → staffNo (holds for the current instance)

15 www.pktutorials.com
 Full Functional Dependency:

▪ Determinants should have the minimal number of attributes necessary to

maintain the functional dependency with the attribute(s) on the right
hand-side
▪ FFD 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
▪ A functional dependency A→ B is a full functional dependency if removal
of any attribute from A results in the dependency no longer existing
staffNo → branchNo

16 www.pktutorials.com
 Partial Functional Dependency:

▪ Partial functional dependency indicates that if A and B are

attributes of a relation, B is partially functionally dependent on
A, if B is functionally dependent any proper subset of A
▪ A functional dependency A→ B is a partially dependency if there
is some attribute that can be removed from A and yet the
dependency still holds

▪ staffNo, sName → branchNo

17 www.pktutorials.com
 Functional Dependency:

In summary, the functional dependencies that we use in normalization have the following
characteristics:

▪ There is a one-to-one relationship between the attribute(s) on the left-hand side

(determinant) and those on the right-hand side of a functional dependency
(opposite direction, can have a one-to-one relationship or one-to-many relationship)
▪ They hold for all time
▪ The determinant has the minimal number of attributes necessary to maintain the
dependency with the attribute(s) on the right-hand side (full functional
dependency)

18 www.pktutorials.com
 Transitive Dependency:

▪ There is an additional type of functional dependency called a transitive

dependency that we need to recognize because its existence in a relation can
potentially cause the types of update anomaly

▪ 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)

19 www.pktutorials.com
 Example: Transitive Dependency

▪ Consider functional dependencies in the StaffBranch relation

staffNo → sName, position, salary, branchNo, bAddress

branchNo → bAddress

▪ Transitive dependency,
branchNo → bAddress exists on staffNo via branchNo

20 www.pktutorials.com
 Identifying Functional Dependencies:

▪ Identifying all functional dependencies between a set of attributes is relatively

simple if the meaning of each attribute and the relationships between the
attributes are well understood
▪ This information should be provided by the enterprise in the form of discussions
with users and/or documentation such as the users’ requirements specification
▪ What if the users are unavailable for consultation and/or the documentation is
incomplete?
▪ Database designer should use their common sense and/or experience to
provide the missing information

21 www.pktutorials.com
 Identifying FDs: Staff Branch Relation

▪ Examine semantics of attributes in StaffBranch relation, assume that

position held, and branch determine a member of staff’s salary

▪ staffNo → sName, position, salary, branchNo, bAddress

▪ branchNo → bAddress
▪ bAddress → branchNo
▪ branchNo, position → salary
▪ bAddress, position → salary

22 www.pktutorials.com
 Identifying FDs: Using Sample Data

▪ Consider the data for attributes denoted A, B, C, D, and E in the

Sample relation
▪ Important to establish that sample data values shown in relation
are representative of all possible values that can be held by
attributes A, B, C, D, and E
▪ Assume that this is true despite the relatively small amount of
data shown in this relation

23 www.pktutorials.com
 Identifying FDs: Using Sample Data

24 www.pktutorials.com
 Identifying FDs: Using Sample Data

25 www.pktutorials.com
 Identifying FDs: Using Sample Data
➢ Functional dependencies between attributes A to E in the Sample
relation

1. A→C (fd1)
2. C →A (fd2)
3. B →D (fd3)
4. A, B → E (fd4)

26 www.pktutorials.com
 Identifying PKs Using FDs:

▪ Main purpose of identifying a set of functional dependencies for a

relation is to specify the set of integrity constraints that must hold on
a relation

▪ An important integrity constraint to consider first is the identification

of candidate keys, one of which is selected to be the primary key for
the relation

27 www.pktutorials.com
 Identifying PKs Using FDs:
StaffBranch relation has five functional dependencies
1) The determinants are staffNo, branchNo, bAddress, (branchNo, position), and
(bAddress, position)
2) To identify all candidate key(s), identify the attribute (or group of attributes) that
uniquely identifies each tuple in this relation
3) All attributes that are not part of a candidate key should be functionally
dependent on the key
4) The only candidate key and therefore primary key for StaffBranch relation, is
staffNo, as all other attributes of the relation are functionally dependent on
staffNo
5) Although branchNo, bAddress, (branchNo, position), and (bAddress, position) are
determinants in this relation, they are not candidate keys for the relation

28 www.pktutorials.com
 Identifying PKs Using FDs:
Sample relation has four FDs and the determinants in the Sample relation are A,
B, C, and (A, B):
1) However, the only determinant that functionally determines all the other
attributes of the relation is (A, B), hence identified as the primary key for
this relation
2) In particular, A functionally determines C, B functionally determines D, and
(A, B) functionally determines E
3) In other words, the attributes that make up the determinant (A, B) can
determine all the other attributes in the relation either separately as A or B
or together as (A, B)
4) An essential characteristic for a candidate key of a relation is that the
attributes of a determinant either individually or working together must be
able to functionally determine all the other attributes in the relation

29 www.pktutorials.com
 THANKS

30 4/30/2024 www.pktutorials.com