Unit 3 dbms

UNIT - 3
Data Base Design & Normalization:
By: Ms. SWETA SINGH
Assistant Professor(CSE)

Functional dependencies
• The functional dependency is a relationship that exists
between two attributes. It typically exists between the
primary key and non-key attribute within a table.
• X → Y
• The left side of FD is known as a determinant, the right
side of the production is known as a dependent.
• The functional dependency is a relationship that exists
between two attributes. It typically exists between the
primary key and non-key attribute within a table.
• X → Y
• The left side of FD is known as a determinant, the right
side of the production is known as a dependent.

Types of Functional dependency
1. Trivial functional dependency
• A → B has trivial functional dependency if B is a subset of A. The following
dependencies are also trivial like: A → A, B → B
• Example:
• Consider a table with two columns Employee_Id and Employee_Name.
• {Employee_id, Employee_Name} → Employee_Id is a trivial functional depende
ncy as
• Employee_Id is a subset of {Employee_Id, Employee_Name}.
• Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name ar
e trivial dependencies too.
2. Non-trivial functional dependency
• A → B has a non-trivial functional dependency if B is not a subset of A.
• When A intersection B is NULL, then A → B is called as complete non-trivial.
• Example:
• ID → Name,
• Name → DOB

Inference Rule (IR):
• The Armstrong's axioms are the basic inference rule.
• Armstrong's axioms are used to conclude functional dependencies
on a relational database.
• The inference rule is a type of assertion. It can apply to a set of
FD(functional dependency) to derive other FD.
• Using the inference rule, we can derive additional functional
dependency from the initial set.
• The Functional dependency has 6 types of inference rule:
• 1. Reflexive Rule (IR1)
• In the reflexive rule, if Y is a subset of X, then X determines Y.
• If X ⊇ Y then X → Y
• Example:
• X = {a, b, c, d, e}
• Y = {a, b, c}

2. Augmentation Rule (IR2)
• The augmentation is also called as a partial dependency. In augmentation, if X determines Y, then
XZ determines YZ for any Z.
• If X → Y then XZ → YZ
• Example:
• For R(ABCD), if A → B then AC → BC
3. Transitive Rule (IR3)
• In the transitive rule, if X determines Y and Y determine Z, then X must also determine Z.
• If X → Y and Y → Z then X → Z
4. Union Rule (IR4)
• Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.
• If X → Y and X → Z then X → YZ
• Proof:
• 1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)

5. Decomposition Rule (IR5)
• Decomposition rule is also known as project rule. It is the reverse of union rule.
• This Rule says, if X determines Y and Z, then X determines Y and X determines Z separately.
• If X → YZ then X → Y and X → Z
• Proof:
• 1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)
6. Pseudo transitive Rule (IR6)
• In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ determines W.
• If X → Y and YZ → W then XZ → W
• Proof:
• 1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
•

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 the undesirable
characteristics like Insertion, Update and Deletion
Anomalies.
• Normalization divides the larger table into the
smaller table and links them using relationship.
• The normal form is used to reduce redundancy
from the database table.

Types of Normal Forms
There are the four types of normal forms:

Normal Form Description
• 1NFA relation is in 1NF if it contains an atomic value.
• 2NFA relation will be in 2NF if it is in 1NF and all non-
key attributes are fully functional dependent on the
primary key.
• 3NFA relation will be in 3NF if it is in 2NF and no
transition dependency exists.
• 4NFA relation will be in 4NF if it is in Boyce Codd
normal form and has no multi-valued dependency.
• 5NFA relation is in 5NF if it is in 4NF and not contains
any join dependency and joining should be lossless.

• Levels of normalization based on the amount of
redundancy in the database.
• Various levels of normalization are:
– First Normal Form (1NF)
– Second Normal Form (2NF)
– Third Normal Form (3NF)
– Boyce-Codd Normal Form (BCNF)
– Fourth Normal Form (4NF)
– Fifth Normal Form (5NF)
– Domain Key Normal Form (DKNF)
Levels of Normalization
Redundancy
Number
of
Tables
Most databases should be 3NF or BCNF in order to avoid the database anomalies.
Complexity

Levels of Normalization
Each higher level is a subset of the lower level
DKNF
1NF
2NF
3NF
4NF
5NF

A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values).
Example (Not 1NF)
First Normal Form (1NF)
Author and AuPhone columns are not scalar
0-321-32132-1 Balloon Sleepy,
Snoopy,
Grumpy
321-321-1111,
232-234-1234,
665-235-6532
Small House 714-000-0000 $34.00
0-55-123456-9 Main Street Jones,
Smith
123-333-3333,
654-223-3455
Small House 714-000-0000 $22.95
0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00
1-22-233700-0 Visual
Basic
Roman 444-444-4444 Big House 123-456-7890 $25.00
ISBN Title AuName AuPhone PubName PubPhone Price

1. Place all items that appear in the repeating group in a new
table
2. Designate a primary key for each new table produced.
3. Duplicate in the new table the primary key of the table from
which the repeating group was extracted or vice versa.
Example (1NF)
1NF - Decomposition
0-321-32132-1 Balloon Small House 714-000-0000 $34.00
0-55-123456-9 Main Street Small House 714-000-0000 $22.95
0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00
1-22-233700-0 Visual
Basic
Big House 123-456-7890 $25.00
ISBN Title PubName PubPhone Price
ISBN AuName AuPhone
0-123-45678-0 Joyce 666-666-6666
1-22-233700-0 Roman 444-444-4444
0-55-123456-9 Smith 654-223-3455
0-55-123456-9 Jones 123-333-3333
0-321-32132-1 Grumpy 665-235-6532
0-321-32132-1 Snoopy 232-234-1234
0-321-32132-1 Sleepy 321-321-1111

1. If one set of attributes in a table determines another
set of attributes in the table, then the second set of
attributes is said to be functionally dependent on the
first set of attributes.
Example 1
Functional Dependencies
0-321-32132-1 Balloon $34.00
0-55-123456-9 Main Street $22.95
0-123-45678-0 Ulysses $34.00
1-22-233700-0 Visual
Basic
$25.00
ISBN Title Price Table Scheme: {ISBN, Title, Price}
Functional Dependencies: {ISBN}  {Title}
{ISBN}  {Price}

Example 2
1 Big House 999-999-9999
2 Small House 123-456-7890
3 Alpha Press 111-111-1111
PubID PubName PubPhone Table Scheme: {PubID, PubName, PubPhone}
Functional Dependencies: {PubId}  {PubPhone}
{PubId}  {PubName}
{PubName, PubPhone}  {PubID}
AuID AuName AuPhone
6 Joyce 666-666-6666
7 Roman 444-444-4444
5 Smith 654-223-3455
4 Jones 123-333-3333
3 Grumpy 665-235-6532
2 Snoopy 232-234-1234
1 Sleepy 321-321-1111
Example 3
Table Scheme: {AuID, AuName, AuPhone}
Functional Dependencies: {AuId}  {AuPhone}
{AuId}  {AuName}
{AuName, AuPhone}  {AuID}

FD – Example
Database to track reviews of papers submitted to an
academic conference. Prospective authors submit
papers for review and possible acceptance in the
published conference proceedings. Details of the
entities
– Author information includes a unique author number, a
name, a mailing address, and a unique (optional) email
address.
– Paper information includes the primary author, the
paper number, the title, the abstract, and review
status (pending, accepted,rejected)
– Reviewer information includes the reviewer number,
the name, the mailing address, and a unique (optional)
email address
– A completed review includes the reviewer number, the
date, the paper number, comments to the authors,
comments to the program chairperson, and ratings
(overall, originality, correctness, style, clarity)

FD – Example
– AuthNo  AuthName, AuthEmail, AuthAddress
– AuthEmail  AuthNo
– PaperNo  Primary-AuthNo, Title, Abstract, Status
– RevNo  RevName, RevEmail, RevAddress
– RevEmail  RevNo
– RevNo, PaperNo  AuthComm, Prog-Comm, Date,
Rating1, Rating2, Rating3, Rating4, Rating5

For a table to be in 2NF, there are two requirements
– The database is in first normal form
– All nonkey attributes in the table must be functionally dependent on the
entire primary key
Note: Remember that we are dealing with non-key attributes
Example 1 (Not 2NF)
Scheme  {Title, PubId, AuId, Price, AuAddress}
1. Key  {Title, PubId, AuId}
2. {Title, PubId, AuID}  {Price}
3. {AuID}  {AuAddress}
4. AuAddress does not belong to a key
5. AuAddress functionally depends on AuId which is a subset of a key
Second Normal Form (2NF)

Example 2 (Not 2NF)
Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}
1. key  {City, Street, HouseNumber}
2. {City, Street, HouseNumber}  {HouseColor}
3. {City}  {CityPopulation}
4. CityPopulation does not belong to any key.
5. CityPopulation is functionally dependent on the City which is a proper subset of the
key
Example 3 (Not 2NF)
Scheme  {studio, movie, budget, studio_city}
1. Key  {studio, movie}
2. {studio, movie}  {budget}
3. {studio}  {studio_city}
4. studio_city is not a part of a key
5. studio_city functionally depends on studio which is a proper subset of the key
Second Normal Form (2NF)

1. If a data item is fully functionally dependent on only a part of the
primary key, move that data item and that part of the primary key
to a new table.
2. If other data items are functionally dependent on the same part of
the key, place them in the new table also
3. Make the partial primary key copied from the original table the
primary key for the new table. Place all items that appear in the
repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme  {Title, PubId, AuId, Price, AuAddress}
New Scheme  {Title, PubId, AuId, Price}
New Scheme  {AuId, AuAddress}
2NF - Decomposition

Old Scheme  {Studio, Movie, Budget, StudioCity}
New Scheme  {Movie, Studio, Budget}
New Scheme  {Studio, City}
Old Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}
New Scheme  {City, Street, HouseNumber, HouseColor}
New Scheme  {City, CityPopulation}
2NF - Decomposition

This form dictates that all non-key attributes of a table must be functionally
dependent on a candidate key i.e. there can be no interdependencies
among non-key attributes.
For a table to be in 3NF, there are two requirements
– The table should be second normal form
– No attribute is transitively dependent on the primary key
Example (Not in 3NF)
Scheme  {Title, PubID, PageCount, Price }
1. Key  {Title, PubId}
2. {Title, PubId}  {PageCount}
3. {PageCount}  {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {Title, PubID}  {Price} hence not in 3NF
Third Normal Form (3NF)

Example 2 (Not in 3NF)
Scheme  {Studio, StudioCity, CityTemp}
1. Primary Key  {Studio}
2. {Studio}  {StudioCity}
3. {StudioCity}  {CityTemp}
4. {Studio}  {CityTemp}
5. Both StudioCity and CityTemp depend on the entire key hence 2NF
6. CityTemp transitively depends on Studio hence violates 3NF
Scheme  {BuildingID, Contractor, Fee}
1. Primary Key  {BuildingID}
2. {BuildingID}  {Contractor}
3. {Contractor}  {Fee}
4. {BuildingID}  {Fee}
5. Fee transitively depends on the BuildingID
6. Both Contractor and Fee depend on the entire key hence 2NF
Third Normal Form (3NF)
BuildingID Contractor Fee
100 Randolph 1200
150 Ingersoll 1100
200 Randolph 1200
250 Pitkin 1100
300 Randolph 1200

1. Move all items involved in transitive dependencies to a new entity.
2. Identify a primary key for the new entity.
3. Place the primary key for the new entity as a foreign key on the
original entity.
Old Scheme  {Title, PubID, PageCount, Price }
New Scheme  {PubID, PageCount, Price}
New Scheme  {Title, PubID, PageCount}
3NF - Decomposition

Old Scheme  {Studio, StudioCity, CityTemp}
New Scheme  {Studio, StudioCity}
New Scheme  {StudioCity, CityTemp}
Old Scheme  {BuildingID, Contractor, Fee}
New Scheme  {BuildingID, Contractor}
New Scheme  {Contractor, Fee}
3NF - Decomposition
BuildingID Contractor
100 Randolph
150 Ingersoll
200 Randolph
250 Pitkin
300 Randolph
Contractor Fee
Randolph 1200
Ingersoll 1100
Pitkin 1100

• BCNF does not allow dependencies between attributes that belong to candidate keys.
• BCNF is a refinement of the third normal form in which it drops the restriction of a non-key
attribute from the 3rd normal form.
• Third normal form and BCNF are not same if the following conditions are true:
– The table has two or more candidate keys
– At least two of the candidate keys are composed of more than one attribute
– The keys are not disjoint i.e. The composite candidate keys share some attributes
Example 1 - Address (Not in BCNF)
Scheme  {City, Street, ZipCode }
1. Key1  {City, Street }
2. Key2  {ZipCode, Street}
3. No non-key attribute hence 3NF
4. {City, Street}  {ZipCode}
5. {ZipCode}  {City}
6. Dependency between attributes belonging to a key
Boyce-Codd Normal Form (BCNF)

Example 2 - Movie (Not in BCNF)
Scheme  {MovieTitle, MovieID, PersonName, Role, Payment }
1. Key1  {MovieTitle, PersonName}
2. Key2  {MovieID, PersonName}
3. Both role and payment functionally depend on both candidate keys thus 3NF
4. {MovieID}  {MovieTitle}
5. Dependency between MovieID & MovieTitle Violates BCNF
Example 3 - Consulting (Not in BCNF)
Scheme  {Client, Problem, Consultant}
1. Key1  {Client, Problem}
2. Key2  {Client, Consultant}
3. No non-key attribute hence 3NF
4. {Client, Problem}  {Consultant}
5. {Client, Consultant}  {Problem}
6. Dependency between attributess belonging to keys violates BCNF
Boyce Codd Normal Form
(BCNF)

1. Place the two candidate primary keys in separate entities
2. Place each of the remaining data items in one of the resulting
entities according to its dependency on the primary key.
Example 1 (Convert to BCNF)
Old Scheme  {City, Street, ZipCode }
New Scheme1  {ZipCode, Street}
New Scheme2  {City, Street}
• Loss of relation {ZipCode}  {City}
Alternate New Scheme1  {ZipCode, Street }
Alternate New Scheme2  {ZipCode, City}
BCNF - Decomposition

1. If decomposition does not cause any loss of information it is called
a lossless decomposition.
2. If a decomposition does not cause any dependencies to be lost it is
called a dependency-preserving decomposition.
3. Any table scheme can be decomposed in a lossless way into a
collection of smaller schemas that are in BCNF form. However the
dependency preservation is not guaranteed.
4. Any table can be decomposed in a lossless way into 3rd normal form
that also preserves the dependencies.
• 3NF may be better than BCNF in some cases
Decomposition–Loss of Information
Use your own judgment when decomposing schemas

Old Scheme  {MovieTitle, MovieID, PersonName, Role, Payment }
New Scheme  {MovieID, PersonName, Role, Payment}
New Scheme  {MovieTitle, PersonName}
• Loss of relation {MovieID}  {MovieTitle}
New Scheme  {MovieID, PersonName, Role, Payment}
New Scheme  {MovieID, MovieTitle}
• We got the {MovieID}  {MovieTitle} relationship back
Old Scheme  {Client, Problem, Consultant}
New Scheme  {Client, Consultant}
New Scheme  {Client, Problem}
BCNF - Decomposition

• Fourth normal form eliminates independent many-to-one relationships
between columns.
• To be in Fourth Normal Form,
– a relation must first be in Boyce-Codd Normal Form.
– a given relation may not contain more than one multi-valued attribute.
Example (Not in 4NF)
Scheme  {MovieName, ScreeningCity, Genre)
Primary Key: {MovieName, ScreeningCity, Genre)
1. All columns are a part of the only candidate key, hence BCNF
2. Many Movies can have the same Genre
3. Many Cities can have the same movie
4. Violates 4NF
Fourth Normal Form (4NF)
Movie ScreeningCity Genre
Hard Code Los Angles Comedy
Hard Code New York Comedy
Bill Durham Santa Cruz Drama
Bill Durham Durham Drama
The Code Warrier New York Horror

Scheme  {Manager, Child, Employee}
1. Primary Key  {Manager, Child, Employee}
2. Each manager can have more than one child
3. Each manager can supervise more than one employee
4. 4NF Violated
Scheme  {Employee, Skill, ForeignLanguage}
1. Primary Key  {Employee, Skill, Language }
2. Each employee can speak multiple languages
3. Each employee can have multiple skills
4. Thus violates 4NF
Fourth Normal Form(4NF)
Manager Child Employee
Jim Beth Alice
Mary Bob Jane
Mary NULL Adam
Employee Skill Language
1234 Cooking French
1234 Cooking German
1453 Carpentry Spanish
1453 Cooking Spanish
2345 Cooking Spanish

1. Move the two multi-valued relations to separate tables
2. Identify a primary key for each of the new entity.
Old Scheme  {MovieName, ScreeningCity, Genre}
New Scheme  {MovieName, ScreeningCity}
New Scheme  {MovieName, Genre}
4NF - Decomposition
Movie Genre
Hard Code Comedy
Bill Durham Drama
The Code Warrier Horror
Movie ScreeningCity
Hard Code Los Angles
Hard Code New York
Bill Durham Santa Cruz
Bill Durham Durham
The Code Warrier New York

Old Scheme  {Manager, Child, Employee}
New Scheme  {Manager, Child}
New Scheme  {Manager, Employee}
Old Scheme  {Employee, Skill, ForeignLanguage}
New Scheme  {Employee, Skill}
New Scheme  {Employee, ForeignLanguage}
4NF - Decomposition
Manager Child
Jim Beth
Mary Bob
Manager Employee
Jim Alice
Mary Jane
Mary Adam
Employee Language
1234 French
1234 German
1453 Spanish
2345 Spanish
Employee Skill
1234 Cooking
1453 Carpentry
1453 Cooking
2345 Cooking

• Fifth normal form is satisfied when all tables are broken into
as many tables as possible in order to avoid redundancy.
Once it is in fifth normal form it cannot be broken into
smaller relations without changing the facts or the meaning.
Fifth Normal Form (5NF)

• The relation is in DKNF when there can be no insertion or
deletion anomalies in the database.
Domain Key Normal Form (DKNF)

Inclusion Dependency
• Inclusion dependencies are quite common. They typically
show little influence on designing of the database.
• The inclusion dependency is a statement in which some
columns of a relation are contained in other columns.
• The example of inclusion dependency is a foreign key. In
one relation, the referring relation is contained in the
primary key column(s) of the referenced relation.
• In inclusion dependency, we should not split groups of
attributes that participate in an inclusion dependency.
• In practice, most inclusion dependencies are key-based
that is involved only keys.

Relational Decomposition
• When a relation in the relational model is not in
appropriate normal form then the decomposition of a
relation is required.
• In a database, it breaks the table into multiple tables.
• 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.

Lossless Decomposition
• If the information is not lost from the relation that is
decomposed, then the decomposition will be lossless.
• The lossless decomposition guarantees that the join of
relations will result in the same relation as it was
decomposed.
• The relation is said to be lossless decomposition if natural
joins of all the decomposition give the original relation.

Example:
EMPLOYEE_DEPARTMENT table:
EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME
22 Denim 28 Mumbai 827 Sales
33 Alina 25 Delhi 438 Marketing
46 Stephan 30 Bangalore 869 Finance
52 Katherine 36 Mumbai 575 Production
60 Jack 40 Noida 678 Testing

The above relation is decomposed into two relations
EMPLOYEE and DEPARTMENT
EMPLOYEE table:
EMP_ID EMP_NAME EMP_AGE EMP_CITY
22 Denim 28 Mumbai
33 Alina 25 Delhi
46 Stephan 30 Bangalore
52 Katherine 36 Mumbai
60 Jack 40 Noida

DEPARTMENT TABLE
DEPT_ID EMP_ID DEPT_NAME
827 22 Sales
438 33 Marketing
869 46 Finance
575 52 Production
678 60 Testing

Now, when these two relations are joined on the common column
"EMP_ID", then the resultant relation will look like:
• Employee ⋈ Department
EMP_I
D
EMP_N
AME
EMP_A
GE
EMP_CI
TY
DEPT_I
D
DEPT_
NAME
22 Denim 28 Mumba
i
827 Sales
33 Alina 25 Delhi 438 Marketi
ng
46 Stepha
n
30 Bangal
ore
869 Finance
52 Katheri
ne
36 Mumba
i
575 Product
ion
60 Jack 40 Noida 678 Testing
Hence, the decomposition is Lossless join decomposition.

MVD
• Multivalued dependency occurs when there are more
than one independent multivalued attributes in a table.

Unit 3 dbms

More Related Content

What's hot (20)

Similar to Unit 3 dbms (20)

More from Sweta Singh (8)

Recently uploaded (20)

Unit 3 dbms