Database Design

KALINGA INSTITUTE OF INDUSTRIAL

TECHNOLOGY

School Of Computer
Engineering

Dr. Amiya Ranjan Panda

Assistant Professor [II]
School of Computer Engineering,
Kalinga Institute of Industrial Technology (KIIT),
Deemed to be University,Odisha

4 Credit Lecture Note 15

Chapter Contents
2
q Bad Database Design/Concept of Anomalies
q Insertion Anomaly
q Updation Anomaly
q Deletion Anomaly

q Normalization
q Functional Dependency(FD)
q Trivial FDs and Non-Trivial FDs
q Armstrong’s Inference Axioms
q Logical Implication
q Closure of a Set of Attribute
q Finding all candidate Keys
q Checking whether an attribute set is a super kry or candidate key
q Computing F +
q Membership Test

q Closure of a Functional Dependency

q Redundancy of FDs
q Canonical Cover/Minimal Cover
Database Design
3
Ø First characterize fully the data requirements of the prospective database users,
which usually involves in textual descriptions (Requirement Analysis).
Ø Next, choose ER model to translate these requirements into a conceptual
schema of the database.
Ø In the logical design phase, map the high level conceptual schema onto the
implementation data model of the database system that will be used. The
implementation data model is typically the Relational data model.
Ø Finally, use the resulting system specific database schema in the subsequent
physical design phase, in which the physical features of the database are
specified.
Ø In designing a database schema, the major pitfalls which should be avoided are:
ü Redundancy: It means repetition of the information.
ü Incompleteness: It means certain aspects of the enterprise may not be
modeled due to difficulty or complexity
Bad Database Design/Concept of Anomalies
4
Ø Database anomalies are the problems in relations that occur due to redundancy
in the relations. These anomalies affect the process of inserting, deleting and
updating data in the relations.
Ø The intension of relational database theory is to eliminate anomalies from
occurring in a database.
Student database
S_Roll S_Name S_Section Fac_Id Fac_Name Fac_Sal
1705601 Mahesh CS-10 101 Alok 90000
1705602 Nitish CS-10 101 Alok 90000
1705603 Khitish CS-10 101 Alok 90000
1705604 Harish CS-10 101 Alok 90000
1705605 Pranshu CS-10 102 Sachin 70000
1705606 Prateek CS-10 103 Saurav 60000
1705607 Suman CS-10 104 Sunil 65000
1705608 Rohan CS-10 105 Paresh 80000
1705609 Sumit CS-10 106 Rakesh 84000
Bad Database Design/Concept of Anomalies
5
Ø Insertion Anomaly: It is the anomaly in which the user cannot insert a fact
about an entity until he/she has an additional fact about another entity. In other
words, there are circumstances in which certain facts can not be recorded at all.
Ex: We cannot record a new faculty details without assigning a student to him.
Ø Deletion Anomaly: It is the anomaly in which the deletion of facts about an
entity automatically deleted the fact of another entity.
Ex: If we want to delete the information about student with roll no 1705605,
automatically the information of faculty Sachin will be deleted which is not our
interest.
Ø Updation Anomaly: It is the anomaly in which the modification in the value of
specific attribute requires modification in all records in which that value occurs.
In other words, the same data can be expressed in multiple rows. Therefore,
updates to the table may result in logical inconsistencies.
Ex: If the updation to the salary of faculty Alok is done in a single row only,
then the updation process will put the database in an inconsistent state so that
the salary of faculty Alok will give conflicting answers.
Normalization
6
Ø Normalization: It is the process of decomposition of a relation / table to reduce
the redundancy and to remove the anomalies.
Student Faculty
S_Roll S_Name S_Section Fac_id Fac_Id Fac_Name Fac_Sal
1705601 Mahesh CS-10 101 101 Alok 90000
1705602 Nitish CS-10 101 102 Sachin 70000
1705603 Khitish CS-10 101 103 Saurav 60000
1705604 Harish CS-10 101 104 Sunil 65000
1705605 Pranshu CS-10 102 105 Paresh 80000
1705606 Prateek CS-10 103 106 Rakesh 84000
1705607 Suman CS-10 104
1705608 Rohan CS-10 105
1705609 Sumit CS-10 106
Functional Dependency (FD)
7
Ø Functional Dependency is the building block of normalization principles.
Ø Attribute (s) A in a relation schema R functionally determines another attribute
(s) B in R if for a given value a1 of A; there is a single, specific value b1 of B
in relation r of R.
Ø The symbolic expression of this FD is: A→B.
Ø where A (LHS of FD) is known as the determinant and B (RHS of FD) is
known as the dependent.
Ø In other words, if A functionally determines B in R, then it is invalid to have
two or more tuples that have the same A value, but different B values in R.
Ø From Student schema, we can infer that S_Roll→ S_Name because all tuples of
Student with a given Roll No value also have the same Name value
Ø FD is a constraint between two sets of attributes in a relation from a database.
Functional Dependency (FD)
8

A B C
a1 b1 c1
a2 b2 c2
a1 b1 c3
a2 b3 c2
a3 b4 c4
Trivial FDs and Non-Trivial FDs
9
Ø Trivial FDs:
ü A functional dependency X→Y is a trivial functional dependency if Y is a
subset of X.
ü For example, {Name, Course}→ Course. If two records have the same
values on both the Name and Course attributes, then they obviously have
the same Course.
ü Trivial dependencies hold for all relation instances.
Ø Non-Trivial FDs:
ü A functional dependency X→Y is called as non-trivial type if Y∩X =Φ.
ü For example, S_Roll → S_Name.
ü Non-trivial FDs are given implicitly in the form of constraints when
designing a database.
Armstrong’s Inference Axioms
10
Ø The inference axioms or rules allow users to infer the FDs that are satisfied by a
relation.
Ø Let R (X, Y, Z, W) where X, Y, Z, and W are arbitrary subsets of the set of
attributes of a universal relation schema R.
Ø The three fundamental inference rules are:

ü Reflexivity Rule: If Y is a subset of X, then X→Y (Trivial FDs).

Ex:{Name, Course} → Course
ü Augmentation Rule: If X→Y, then {X, Z}→{Y, Z}.
Ex: as Prof→Grade, therefore {Prof, Major}→{Grade, Major}
ü Transitivity Rule: If X→Y and Y→Z, then X→Z.
Ex: as Course→Name and Name → Phone_no functional dependencies
are present, therefore Course → Phone_no
Armstrong’s Inference Axioms
11
Ø The four secondary inference rules are:

ü Union or Additive Rule: If X→Y and X→Z, then X→{Y, Z}.

Ex: as Prof→Grade and Prof→Course FDs are present; therefore,
Prof→{Grade, Course}
ü Decomposition Rule: If X→{Y, Z}, then X→Y and X→Z.
Ex: if Prof→{Grade, Course}, then this FD can be decomposed as
Prof→Grade and Prof→Course
ü Composition Rule: If X→Y and Z→W, then {X, Z}→{Y, W}.
Ex: if Prof→Grade and Name→Phone_no, then the FDs can be composed
as {Prof, Name}→{Grade, Phone_no}
ü Pseudo-transitivity Rule: If X→Y and {Y, W}→Z, then {X, W}→Z.
Ex: if Prof→Grade and {Grade, Major}→Course, then the FD {Prof,
Major}→Course is valid
Logical Implication
12
Ø Given a relation schema R and a set of functional dependencies F. Let FD
X→Y is not in F. F can be said to logically imply X→Y if for every relation r
on the relation schema R that satisfies the FD in F, the relation r also satisfies
X→Y
Ø F logically implies X→Y is written as: F|=X→Y
Ø Let R = (A, B, C, D) and F = {A→B, A→C, BC→D}
F|=A→D
Given F = {A→B, C→D} with C⊆B, show that F|=A→D
Closure of a Set of Attributes
13
Ø Given a set of attributes X and a set of functional dependencies F, then the
closure of the set of attributes X under F, denoted as X +, is the set of attributes
A that can be derived from X by applying the Armstrong’s Inference Axioms to
the functional dependencies of F.
Ø The closure of X is always a non empty set.
Ø R = (A, B, C, D) and F = {A→C, B→D}
{A}+ = { }, {B}+ = { }, {C}+={ }, {D}+={ },

{A, B}+ = { }, {A, C}+ = { }, {A, D}+ = { },

{B, C}+ = { }, {B, D}+ = { }, {C, D}+ = { },
{A, B, C}+ = { }, {A, B, D}+ = { },
{B, C, D}+ = { }, {A, B, C, D}+ = { }
R = (X, Y, Z) and F = {X→Y, Y→Z}
Closure of a Set of Attributes
14
Ø Uses of Attribute Closure:
ü Testing for key : To test whether X is a key or not, X+ is computed. X is a
key iff X+ contains all the attributes of R. X is a candidate key if none of
its subsets is a key
ü Testing functional dependencies: To check whether a functional
dependency X→Y holds or not, just check if Y⊆ X + .
Application of Closure of a Set of Attributes
15

1. Finding all Candidate Keys

2. Checking whether an attribute set is a Super / Candidate Key

3. Computing F+

4. Membership Test
Keys
16
Ø Super key: An attribute or a set of attribute that has uniqueness property is
called super key. If an attribute set closure contains all attributes of relation
then it called as a super key.
Ø Key: An attribute or a set of attribute that has uniqueness and Minimality
property is called key.
Ø Candidate Key: The set of all the keys.
Ø Primary Key: One of the candidate key that is selected by the database
designer for a particular application.
Ø Alternate Key: All the candidate keys except primary key are called
alternate key.
Ø Foreign Key: An attribute or a set of attribute of one relation that refers to the
primary key of same or other relation is called foreign key.
1. Finding all Candidate Keys
17
1. R (ABC)
F= { A B,
B C}
2. R (ABC)
F = {A B,
B C,
C A}
3. R (ABCD)
F={A C,
B D}
4. R (ABCD) 5. R (ABCD)
F = { AB C, F = { AB C,
C D, B D,
A B} D B}
2. Checking whether an attribute set is Candidate Key
18
1. R (ABCDE) Check for AB ?
F= { AB C,
C D,
D E,
A B}
2. R (ABCDE) Check for AD ?
F = {A B,
B CD ,
D E,
AB D}
3. Closure of a Set of Functional Dependencies
19
Ø Given a set F of functional dependencies for a relation schema R, we define F +,
the closure of F, to be the set of all functional dependencies that are logically
implied by F. Mathematically,
F ={X→Y/F|=X→Y}
Ø To generate all FDs that can be derived from F, the steps are:
ü First, apply the inference axioms to all single attributes and use the FDs of
F whenever it is applicable
ü Second, apply the inference axioms to all combinations of two attributes
and use the functional dependencies of F whenever it is applicable
ü Next apply the inference axioms to all combinations of three attributes and
use the FDs of F when necessary
ü Proceed in this manner for as many different attributes as there are in F
Computing F+
20
1. R (ABC) Find out F+ ?
F= { A B,
B C}

2. R (AB)
F={A B,
B A}

3. R (ABC)
F = { AB C,
C B,
B A}
Closure of a Set of Functional Dependencies
21
Ø Let R=(A, B, C) and F={A→B, A→C}

F + = {A→A, B→B, C→C, A→B, A→C, A→BC, A→AB, A→AC, AB→A,

AB→B, AB→AB, AC→A, AC→C, AC→AC, BC→B, BC→C, BC→BC,
ABC→AB, ABC→AC, ABC→BC, ABC→ABC}

Ø Let R=(W, X, Y) and F={W→X, X→Y, W→XY}

Ø Uses of set of Functional Dependency Closure:
Ø Computing if two sets of functional dependencies F and G are equivalent :
When F +=G+, then the functional dependencies sets F and G are equivalent
F={W→X, X→Y, W→XY} and G= {W→X, W→Y, X→Y}
Redundancy of FDs
22
Ø Redundancy of FDs:
ü Given a set of functional dependencies F, a functional dependency A→B
of F is said to be redundant with respect to the FDs of F if and only if
A→B can be derived from the set of FDs F - {A→B}
ü Eliminating redundant functional dependencies allows us to minimize the
set of FDs
ü Ex: A→C is redundant in {A→B, B→C, A→C}
Ø Redundant attribute on RHS:
ü In a functional dependency, some attributes in the RHS may be redundant
ü Ex: F= {A→B, B→C, A→{C, D}} can be simplified to {A→B, B→C,
A→D}
Ø Redundant attribute on LHS:
ü In a functional dependency, some attributes in the LHS may be redundant
ü Ex: F = {A→B, B→C, {A, C}→D} can be simplified to {A→B, B→C,
A→D}
Canonical Cover / Minimal Cover
23
Ø Canonical Cover / Minimal Cover: For a given set F of FDs, a canonical
cover, denoted by Fc , is a set of FDs where the following conditions are
satisfied:
ü F and Fc are equivalent
ü Every FD of Fc is simple. That is, the RHS of every functional
dependency of Fc has only one attribute
ü No FD in Fc is redundant
ü The determinant or LHS of every FD in Fc is irreducible
Ø R = (A, B, C) and F = {A→{B, C}, B→C, A→B, {A, B}→C}
Ø Fc = {A→B, B→C}
Ø As canonical cover contains the functional dependencies without any
redundancy, therefore finding the key of the relation becomes efficient.
4. Membership Test
24
1. R (ABCDE) Does AC B, D AC belongs to F+?
F= { A B,
B C,
AC D,
D C,
C E,
C A}
2. R (ABCDEF) Does AF BD and BE AC belongs to F+?
F = {AB CE,
C DF,
F AB,
E AC,
A C}
25