Unit 2 Database Design

Database Design
• Functional Dependencies
• Inference Rules
• Functional Dependency Closure
• Minimal Cover
• Decomposition Properties
• Need of Normalization
• Normal Forms: 1NF, 2NF, 3NF and BCNF, Multi-valued Dependency,
4NF
Functional Dependencies
• Functional Dependency (FD) is a constraint that determines the relation of one
attribute to another attribute in a Database Management System (DBMS).
• The attributes of a table is said to be dependent on each other when an attribute of a
table uniquely identifies another attribute of the same table.
• For example: Suppose we have a student table with attributes: Stu_Id, Stu_Name,
Stu_Age. Here Stu_Id attribute uniquely identifies the Stu_Name attribute of student
table because if we know the student id we can tell the student name associated with
it. This is known as functional dependency and can be written as Stu_Id->Stu_Name
or in words we can say Stu_Name is functionally dependent on Stu_Id.
• Formally:
If column A of a table uniquely identifies the column B of same table then it can
represented as A->B (Attribute B is functionally dependent on attribute A)
• A->B The left side of FD is known as a determinant, the right side of the production is
known as a dependent.
Functional Dependencies
• Types of Functional Dependencies in DBMS
• There are mainly four types of Functional Dependency in DBMS. Following
are the types of Functional Dependencies in DBMS:
• Multivalued Dependency
• Trivial Functional Dependency
• Non-Trivial Functional Dependency
• Transitive Dependency
Functional Dependencies
• Multivalued Dependency:
• Multivalued dependency occurs in the situation where there are multiple
independent multivalued attributes in a single table.
• A multivalued dependency is a complete constraint between two sets of
attributes in a relation. It requires that certain tuples be present in a
relation. Car_mode
Maf_year Color
• In this example, maf_year and color are l
independent of each other but dependent on H001 2017 Metallic
car_model. In this example, these two columns are H001 2017 Green
said to be multivalue dependent on car_model. H005 2018 Metallic
H005 2018 Blue
• This dependence can be represented like this:
H010 2015 Metallic
• car_model -> maf_year H033 2012 Gray
• car_model-> colour
 Emp_nam
Emp_id
Functional Dependencies AS555
e
Harry
• Trivial Functional Dependency in DBMS AS811 George
• The Trivial dependency is a set of attributes which are called a trivial if the set of attributes are
included in that attribute.
• So, X -> Y is a trivial functional dependency if Y is a subset of X.
• Consider this table of with two columns Emp_id and Emp_name.
• {Emp_id, Emp_name} -> Emp_id is a trivial functional dependency as Emp_id is a subset of
{Emp_id,Emp_name}.
• Non Trivial Functional Dependency in DBMS
• Functional dependency which also known as a nontrivial dependency
occurs when A->B holds true where B is not a subset of A. Compan
CEO Age
• In a relationship, if attribute B is not a subset of attribute A, then it is y
considered as a non-trivial dependency. Satya
Microsoft 51
• (Company} -> {CEO} (if we know the Company, we knows the CEO name) Nadella
• But CEO is not a subset of Company, and hence it’s non-trivial functional Sundar
Google 46
Pichai
dependency.
Apple Tim Cook 57
ge

1 Functional Dependencies
6
• Transitive Dependency in DBMS
7
• A Transitive Dependency is a type of functional dependency which happens
when “t” is indirectly formed by two functional dependencies.
• {Company} -> {CEO} (if we know the compay, we know its CEO’s name)
• {CEO } -> {Age} If we know the CEO, we know the Age
• Therefore according to the rule of rule of transitive dependency:
• { Company} -> {Age} should hold, that makes sense because if we know the
company name, we can know his age.
• Note: You need to remember that transitive dependency can only occur in a
relation of three or more attributes.
Functional Dependencies
• Some key terms for Functional Dependency in Database:
Key Terms Description
Axiom Axioms is a set of inference rules used to infer all the
functional dependencies on a relational database.
Decompositio It is a rule that suggests if you have a table that appears to
n contain two entities which are determined by the same
primary key then you should consider breaking them up
into two different tables.
Dependent It is displayed on the right side of the functional dependency
diagram.
Determinant It is displayed on the left side of the functional dependency
Diagram.
Union It suggests that if two tables are separate, and the PK is the
same, you should consider putting them together.
Functional Dependencies
• Inference Rules of Functional Dependencies
• Below are the Three most important rules for Functional Dependency in Database:
• Reflexive rule –. If X is a set of attributes and Y is_subset_of X, then X holds a
value of Y. For example {STU_ID, NAME} →NAME is valid reflexive relation.
• Augmentation rule: When x -> y holds, and c is attribute set, then ac -> bc also
holds. That is adding attributes which do not change the basic dependencies. For
example {STU_ID, NAME} →{ DEPT_BUILDING} is valid then {STU_ID,
NAME,DEPT_NAME} →{ DEPT_BUILDING,DEPT_NAME} is also valid.
• Transitivity rule: This rule is very much similar to the transitive rule in algebra if x
-> y holds and y -> z holds, then x -> z also holds. X -> y is called as functionally
that determines y. For example, if STU_ID→CLASS, CLASS→LECTURE_HALL holds
true then according to the axiom of transitivity, STU_ID→LECTURE_HALL will also
hold true.
Functional Dependencies
• Inference Rules of Functional Dependencies
• Union Rule (IR4)
• This rule is also known as the additive rule. if X determines Y and X determines Z, then X
also determines both Y and Z.
• If X → Y and X → Z then X → YZ
• For example, STU_ID → STU_NAME, STU_ID→COURSE then STU_ID→ {STU_NAME,
COURSE} holds true.
• Proof:
• 1. X → Y (given)
• 2. X → Z (given)
• 3. X → XY (using IR2 on 1 by augmentation with X)
• 4. XY → YZ (using IR2 on 2 by augmentation with Y)
• 5. X → YZ (using IR3 on 3 and 4)
 Functional Dependencies • Pseudo transitive Rule (IR6)
• Inference Rules of Functional • In the pseudo transitive rule, if X
Dependencies determines Y, and YZ determines W,
• Decomposition Rule (IR5) then XZ also determines W.
• This rule is the reverse of the Union rule • If X → Y and YZ → W then XZ → W
and is also known as the project rule. • Proof:
• if X determines Y and Z together, then X • 1. X → Y (given)
determines Y and Z separately
• For example STU_ID→ {STU_NAME, COURSE}
• 2. WY → Z (given)
then STU_ID → STU_NAME, STU_ID→COURSE • 3. WX → WY (using IR2 on 1 by augmenting
holds true. with W)
• If X → YZ then X → Y and X → Z • 4. WX → Z (using IR3 on 3 and 2)
• Proof:
• 1. X → YZ (given)
• 2. YZ → Y (using IR1 Rule)
• 3. X → Y (using IR3 on 1 and 2)
 Functional Dependency Closure
• Finding Closure of an attribute set
• Attribute Closure of an attribute set
• You can follow the steps to find the Closure of an
is defined as a set of all attributes
attribute set:
that can be functionally
determined from it. 1. Determine A+, the Closure of A under functional
dependency set F.
• Closure of an attribute x is the set 2. A+: = will contain A itself; For example, if we need to
of all attributes that are functional find the closure of an attribute X, the closure will
dependencies on X with respect to incorporate the X itself and the other attributes that
F. It is denoted by X+ which means the X attribute can determine.
what X can determine. 3. Repeat the process as
• The closure of an attribute is 4. old A+: = A Closure;
represented as + 5. for each FB X → Y in the FD set, do
6. if X Closure is a subset of X, then A Closure:= A
Closure U Y;
7. Repeat until ( A+= old A+);
 Functional Dependency Closure
• Step-1 : Add the attributes which are present on Left Hand Side in the original functional
dependency.
• Step-2 : Now, add the attributes present on the Right Hand Side of the functional
dependency.
• Step-3 : With the help of attributes present on Right Hand Side, check the other
attributes that can be derived from the other given functional dependencies. Repeat this
process until all the possible attributes which can be derived are added in the closure.
• Example-1 : Consider the table student_details having (Roll_No, Name,Marks, Location)
as the attributes and having two functional dependencies.
• FD1 : Roll_No -> Name, Marks
• FD2 : Name -> Marks, Location
• Now, We will calculate the closure of all the attributes present in the relation using the
three steps.
 Functional Dependency Closure
• Example: Calculate closure of Roll_No
• Step-1 : Add attributes present on the LHS of the first functional dependency to the
closure.
• {Roll_no}+ = {Roll_No}
• Step-2 : Add attributes present on the RHS of the original functional dependency to the
closure.
• {Roll_no}+ = {Roll_No, Marks}
• Step-3 : Add the other possible attributes which can be derived using attributes present
on the RHS of the closure. So Roll_No attribute cannot functionally determine any
attribute but Name attribute can determine other attributes such as Marks and Location
using 2nd Functional Dependency(Name -> Marks, Location).
• Therefore, complete closure of Roll_No will be :
• {Roll_no}+ = {Roll_No, Marks, Name, Location}
Functional Dependency Closure
• Similarly, we can calculate closure for other attributes too i.e “Name”.
• Step-1 : Add attributes present on the LHS of the functional dependency to the closure.
• {Name}+ = {Name}
• Step-2 : Add the attributes present on the RHS of the functional dependency to the
closure.
• {Name}+ = {Name, Marks, Location}
• Step-3 : Since, we don’t have any functional dependency where “Marks or Location”
attribute is functionally determining any other attribute , we cannot add more attributes
to the closure. Hence complete closure of Name would be :
• {Name}+ = {Name, Marks, Location}
• Calculate Closure for Marks and Location attribute:
• We don’t have any Functional dependency where marks and location can functionally
determine any attribute. Hence, for those attributes we can only add the attributes
themselves in their closures. Therefore,
• {Marks}+ = {Marks} and {Location}+ = { Location}
Minimal Cover /Canonical Cover of Functional Dependency
• In any relational model, there exists a set of functional dependencies. These functional dependencies
when closely observed might contain redundant attributes. The ability of removing these redundant
attributes without affecting the capabilities of the functional dependency is known as “Canonical Cover
of Functional Dependency”.
• Canonical cover of functional dependency is sometimes also referred to as “Minimal Cover”. Canonical
cover of functional dependency is denoted using "Mc".
• A canonical cover or irreducible a set of functional dependencies FD is a simplified set of FD that has a
similar closure as the original set FD.
• Important terms:
1.Extraneous attributes: If we can delete an attribute of a functional dependency without modifying the
closure of the set of functional dependencies, it is said to be unnecessary.
2.Canonical cover: Canonical cover Fc is a set of functional dependencies F such that the following
properties are not violated:
• 1) All dependencies in Fc are logically implied by F.
• 2) All dependencies in F are logically implied by Fc.
• 3) There are no extraneous attributes in Fc's functional dependencies.
• 4) Each functional dependency's left side in Fc is distinct. There are no two dependencies ɑ1→β1 and
ɑ2→β2 in such that ɑ1→ɑ2.
Minimal Cover /Canonical Cover of Functional Dependency
• Algorithm for Canonical Cover as follows:
• Step 1: First use union rules to replace any functional dependence such as A1
-> B1 and A1 -> B2 with A1 -> B1B2.
• Step 2: Find functional dependency Fd A -> B with an irrelevant attribute in A
or B.
• Step 3: If any irrelevant attribute is found delete it from A -> B until
functional dependency does not change.
• Example
• Consider a given relation(X, Y, Z, W) having some attributes, and below are
mentioned functional dependencies as follows.
• FD: Y -> X
• FD: XW -> Z
• FD: Z ->XYW
Minimal Cover /Canonical Cover of Functional Dependency
• FD: Y -> X
• FD: XW -> Z
• FD: Z ->XYW
• Step 1:
• First, decompose all functional dependencies using the decomposition rule.
That means a single attribute on the right-hand side. Decomposition of
functional dependence as follows.
• FD 1: Y -> X
• FD 2: XW -> Z
• FD 3: Z -> X
• FD 4: Z -> Y
• FD 5: Z -> W
Minimal Cover /Canonical Cover of Functional Dependency
• FD 1: Y -> X
• FD 2: XW -> Z
• FD 3: Z -> X
• FD 4: Z -> Y
• FD 5: Z -> W
• Step 2:
• In the second step, we remove all irrelevant attributes from the left-hand side of
functional dependencies by finding the closure as follows.
• Only one functional dependency has two or more attributes that means XW -> Z.
• {X}+ = {X}
• {W}+ = {W}
• In above both cases X can only determine X and W can only determine W, so no
irrelevant attributes are present in the above functional dependencies and functional
dependencies will remain constant and will not be removed.
Minimal Cover /Canonical Cover of Functional Dependency
• Step 3:
• Remove all functional dependencies that having transitive relation.
• FD 1: Y -> X
• FD 2: XW -> Z
• FD 3: Z -> X
• FD 4: Z -> Y
• FD 5: Z -> W
• After removing transitive relation the functional dependencies look as follows.
• FD 1: Y -> X
• FD 2: Z -> Y
• FD 3: XW -> Z
• FD 4: Z -> W
• We combine 2 and 4 functional dependencies together now the canonical cover of the above
relation R(X, Y, Z, W) is {Y -> X, Z ->YW, XW -> Z}
• With the help of normal form, we can implement canonical cover.
 Decomposition Properties
• When a relation in the relational model is not appropriate normal form then
the decomposition of a relation is required.
• In a database, breaking down the table into multiple tables termed as
decomposition.
• If the relation has no proper decomposition, then it may lead to problems
like loss of information.
• Decomposition is used to eliminate some of the problems of bad design like
anomalies, inconsistencies, and redundancy.
• Types of Decomposition
 EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME

Decomposition Properties 22 Denim 28 Mumbai 827 Sales

33 Alina 25 Delhi 438 Marketing

• Lossless Decomposition 46 Stephan 30 Bangalore 869 Finance

52 Katherine 36 Mumbai 575 Production

• If the information is not lost 60 Jack 40 Noida 678 Testing

from the relation that is

EMP_ID EMP_NAME EMP_AGE EMP_CITY
decomposed, then the
22 Denim 28 Mumbai
decomposition will be lossless. 33 Alina 25 Delhi
• The lossless decomposition 46 Stephan 30 Bangalore

guarantees that the join of 52 Katherine 36 Mumbai

relations will result in the same 60 Jack 40 Noida

relation as it was decomposed. DEPT_ID EMP_ID DEPT_NAME

• The relation is said to be lossless 827 22 Sales

decomposition if natural joins of 438 33 Marketing

all the decomposition give the 869 46 Finance

original relation. 575 52 Production

678 60 Testing
Decomposition Properties
• Dependency Preserving
• In the dependency preservation, at least one decomposed table must satisfy every
dependency.
• If each functional dependency X->Y specified in F appears directly in one of the relation
schemas Ri in the decomposition D or could be inferred from the dependencies that appear
in some Ri. This is the Dependency Preservation.
• If a decomposition is not dependency preserving some dependency is lost in
decomposition. To check this condition, take the JOIN of 2 or more relations in the
decomposition.
• For example:
• R = (A, B, C)
• F = {A ->B, B->C}
• Key = {A}
• R is not in BCNF.
• Decomposition R1 = (A, B), R2 = (B, C)
Decomposition Properties
• Attribute Preservation:
• Using functional dependencies the algorithms decompose the universal
relation schema R in a set of relation schemas D = { R1, R2, ….. Rn } relational
database schema, where ‘D’ is called the Decomposition of R.
• The attributes in R will appear in at least one relation schema Ri in the
decomposition, i.e., no attribute is lost.
• This is called the Attribute Preservation condition of decomposition.
• Non Additive Join Property:
• Another property of decomposition is that D should possess is the Non
Additive Join Property, which ensures that no spurious/Extra tuples are
generated when a NATURAL JOIN operation is applied to the relations
resulting from the decomposition.
 What is Normalization?
• Normalization is the process of organizing the data in the database.
• Normalization is used to minimize the redundancy from a relation or set of relations.
• It is also used to eliminate undesirable characteristics like Insertion, Update, and
Deletion Anomalies.
• Normalization divides the larger table into smaller and links them using
relationships.
• Most commonly used normal forms:
• First normal form(1NF)
• Second normal form(2NF)
• Third normal form(3NF)
• Boyce & Codd normal form (BCNF)
• Fourth Normal Form(4NF)
Why do we need Normalization?
• The main reason for normalizing the relations is removing these anomalies. Failure
to eliminate anomalies leads to data redundancy and can cause data integrity and
other problems as the database grows.
• Update anomalies − When we try to update one data item having its copies scattered
over several places, a few instances get updated properly while a few others are left
with old values. Such instances leave the database in an inconsistent state.
• Deletion anomalies − We tried to delete a record, but parts of it was left undeleted
because of unawareness, the data is also saved somewhere else.
• Insert anomalies − We tried to insert data in a record that does not exist at all.
• Normalization is a method to remove all these anomalies and bring the database to
a consistent state.
• Normalization consists of a series of guidelines that helps to guide you in creating a
good database structure.
 • Example: Relation EMPLOYEE is not in 1NF because
First normal form(1NF) of multi-valued attribute EMP_PHONE.
EMP_ID EMP_NAME EMP_PHONE EMP_STATE

• A relation will be 1NF if it contains an 14 John 7272826385, UP

9064738238
atomic value.
20 Harry 8574783832 Bihar
• It means, A relation is said to be in 12 Sam 7390372389, Punjab
"1NF" if, every attribute in a relation is 8589830302
has “Single Valued” tuple.
• Also, the domain of the attributes • The decomposition of the EMPLOYEE table
must remain same throughout the into 1NF has been shown below:
table. For example : E_ID attribute
EMP_ID EMP_NAME EMP_PHONE EMP_STATE
should contain only Employee ID and
not any other value. 14 John 7272826385 UP
14 John 9064738238 UP
• Each column in a table should have a
20 Harry 8574783832 Bihar
unique name.
12 Sam 7390372389 Punjab
• First normal form disallows the multi- 12 Sam 8589830302 Punjab
valued attribute, composite attribute,
and their combinations.
 • A relation / table to be in the Second Normal
Second normal form(2NF) Form,
1.It should be in the First Normal form.
2.And, it should not have Partial Dependency.
• Partial Dependency: It is a type of functional
dependency that occurs when non-prime
attributes are partially dependent on part of
Candidate keys.
• In the employee table, if manager details are to be
fetched for an employee, multiple results are
returned when searched with EMP_ID, in order to
fetch one result, EMP_ID and PROJECT_ID together
are considered as the Candidate Keys.
• Here the manager depends on PROJECT_ID and not
on EMP_ID, this creates a partial dependency.
• There are multiple ways to eliminate this partial
dependency and reduce the table to its 2nd normal
form, one such method is adding the Manager
information to the project table .
 Third normal form(3NF)
• A relation will be in 3NF if it is in 2NF and not contain any transitive partial dependency.
• 3NF is used to reduce the data duplication. It is also used to achieve the data integrity.
• If there is no transitive dependency for non-prime attributes, then relation must be in 3NF.
• Super key in the given table is:
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY
• {EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID,
222 Harry 201010 UP Noida EMP_NAME, EMP_ZIP}....so on
333 Stephan 02228 US Boston
• Candidate key: {EMP_ID}
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
• Non-prime attributes: In the given table, all
666 John 462007 MP Bhopal
attributes except EMP_ID are non-prime.
• Here, EMP_STATE & EMP_CITY dependent on
EMPLOYEE_DETAIL table: EMP_ZIP and EMP_ZIP dependent on
EMP_ID. The non-prime attributes
(EMP_STATE, EMP_CITY) transitively
dependent on super key(EMP_ID). It violates
the rule of third normal form.
Third normal form(3NF)
• To convert relation in 3NF,we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.

EMP_ID EMP_NAME EMP_ZIP EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 201010 UP Noida
333 Stephan 02228 02228 US Boston
444 Lan 60007 60007 US Chicago
555 Katharine 06389 06389 UK Norwich
666 John 462007 462007 MP Bhopal

EMPLOYEE table: EMPLOYEE_ZIP table:

 Boyce & Codd normal form (BCNF)
• BCNF is the advance version of 3NF. It is stricter than 3NF.
• A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
• For BCNF, the table should be in 3NF, and for every FD, LHS is super key.
• Example: Let's assume there is a company where employees work in more than one
department.
• The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.
EMP_ID EMP_COUNTRY EMP_DEP DEPT_TYPE EMP_DEPT_NO • In the given table Functional
T
dependencies are as follows:
264 India Designing D394 283
• EMP_ID → EMP_COUNTRY
264 India Testing D394 300
364 UK Stores D283 232 • EMP_DEPT → {DEPT_TYPE,
364 UK Developing D283 549
EMP_DEPT_NO}
• Candidate key: {EMP-ID,
EMP-DEPT}
EMPLOYEE table
 Boyce & Codd normal form (BCNF)
• To convert the given table into BCNF, we decompose it into three tables:
EMP_DEPT DEPT_TYPE EMP_DEPT_NO EMP_ID EMP_DEPT
EMP_ID EMP_COUNTRY
Designing D394 283 D394 283
264 India
Testing D394 300 D394 300
264 India
Stores D283 232 D283 232
Developing D283 549 D283 549
EMP_COUNTRY table

EMP_DEPT table EMP_DEPT_MAPPING table

• Functional dependencies:
• EMP_ID → EMP_COUNTRY
• EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}
• Candidate keys:
• Now, this is in BCNF because left
• For the first table: EMP_ID
side part of both the functional
• For the second table: EMP_DEPT
• For the third table: {EMP_ID, EMP_DEPT}
dependencies is a key.
Fourth Normal Form(4NF) • You must be thinking what problem
this can lead to, right?
• A table is said to be in the Fourth Normal • Well the two records for student with
s_id 1, will give rise to two more
Form when, records, as shown below, because for
1.It is in the Boyce-Codd Normal Form. one student, two hobbies exists,
hence along with both the courses,
2.And, it doesn't have Multi-Valued these hobbies should be specified.
Dependency. s_id course hobby
s_id course hobby 1 Science Cricket
1 Science Cricket 1 Maths Hockey
1 Maths Hockey 1 Science Hockey
2 C# Cricket 1 Maths Cricket
2 Php Hockey • And, in the table above, there is no
relationship between the columns course
• As you can see in the table above, and hobby. They are independent of each
other.
student with s_id 1 has opted for two
• So there is multi-value dependency, which
courses, Science and Maths, and has leads to un-necessary repetition of data and
two hobbies, Cricket and Hockey. other anomalies as well.
Fourth Normal Form(4NF)
• To make the above s_id hobby
s_id course
relation satify the 4th
1 Science 1 Cricket
normal form, we can
decompose the table 1 Maths 1 Hockey
into 2 tables. 2 C# 2 Cricket
2 Php 2 Hockey
Hobbies Table
CourseOpted Table
Table
• Now this relation satisfies the fourth normal form.
• A table can also have functional dependency along with multi-valued
dependency. In that case, the functionally dependent columns are moved in a
separate table and the multi-valued dependent columns are moved to
separate tables.