Database Management

Systems

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Contents:

Functional Dependency

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Functional Dependencies
Functional Dependencies
We say an attribute, B, has a functional dependency on
another attribute, A, if for any two records, which have
the same value for A, then the values for B in these two
records must be the same. We illustrate this as:
AB
Example: Suppose we keep track of employee email addresses,
and we only track one email address for each employee.
Suppose each employee is identified by their unique employee
number. We say there is a functional dependency of email
address on employee number:
employee number  email address

91.2814 3
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Functional Dependencies
EmpNum EmpEmail EmpFname EmpLname
123 [email protected] John Doe
456 [email protected] Peter Smith
555 [email protected] Alan Lee
633 [email protected] Peter Doe
787 [email protected] Alan Lee

If EmpNum is the PK then the FDs:

EmpNum  EmpEmail
EmpNum  EmpFname
EmpNum  EmpLname
must exist.

91.2814 4
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
 Database Tables and Normalization
 Dependency Diagram
 The primary key components are bold,
underlined, and shaded in a different color.
 The arrows above entities indicate all desirable
dependencies, i.e., dependencies that are based
on PK.

FigureMd.
5.3Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Functional Dependencies
EmpNum  EmpEmail
EmpNum  EmpFname 3 different ways
EmpNum  EmpLname you might see FDs
depicted
EmpEmail
EmpNum EmpFname
EmpLname

EmpNum EmpEmail EmpFname EmpLname

91.2814 6
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Determinant
Functional Dependency

EmpNum  EmpEmail

Attribute on the LHS is known as the determinant

• EmpNum is a determinant of EmpEmail

91.2814 7
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Transitive dependency
Transitive dependency

Consider attributes A, B, and C, and where

A  B and B  C.
Functional dependencies are transitive, which
means that we also have the functional dependency
AC
We say that C is transitively dependent on A
through B.

91.2814 8
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Transitive dependency

91.2814 9
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Transitive dependency
EmpNum  DeptNum

EmpNum EmpEmail DeptNum DeptNname

DeptNum  DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum  DeptName

91.2814 10
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Transitive dependency

91.2814 11
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
Partial dependency
A partial dependency exists when an attribute B is
functionally dependent on an attribute A, and A is a
component of a multipart candidate key.

12
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
 Normal Forms
Normalization is a process of organizing data to minimize data redundancy.

Each normal form is a set of conditions on a schema that guarantees certain properties that are
related to redundancy and update anomalies.

The normal forms based on FDs alone form a hierarchy with increasingly strict limitations on
the allowed functional dependencies as follows:

- First Normal Form (1NF)

- Second Normal Form (2NF)

- Third Normal Form (3NF)

- Boyce-Codd Normal Form (BCNF)

- Fouth Normal Form (4NF)

- Fifth Normal Form (not examinable)

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

First Normal From

 A table is in the first normal form iff

 The domain of each attribute contains only
atomic values, and
 The value of each attribute contains only a
single value from that domain.

In layman's terms. it means every column of

your table should only contain single values

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

 For a library

Patron ID Borrowed books

C45 B33, B44, B55
C12 B56

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

1-NF Solution

Patron ID Borrowed book

C45 B33
C45 B44
C45 B33
C12 B56

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

 For an airline

Flight Weekdays
UA59 Mo We Fr
UA73 Mo Tu We Th Fr

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

1NF Solution
Flight Weekday
UA59 Mo
UA59 We
UA59 Fr
UA73 Mo
UA73 We
… …

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 First Normal Form (1NF)
 A relation is in 1NF if the following conditions are satisfied:
 Each row of data must have a unique identifier i.e Primary key
 There are no duplicated rows in the table.
 All underlying domains contain atomic values only.
 Entries in a column (attribute, field) are of the same kind.
 The 1NF deals only with the basic structure of the relation and does not resolve
the problems of redundant information or the anomalies.
 Example:

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

First Normal Form
The following in not in 1NF

EmpNum EmpPhone EmpDegrees

123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

EmpDegrees is a multi-valued field:

employee 679 has two degrees: BSc and MSc
employee 333 has three degrees: BA, BSc, PhD

91.2814 20
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
 First Normal Form
To obtain 1NF relations we must, without loss of information,
replace the above with two relations
EmployeeDegree
Employee
EmpNum EmpDegree
EmpNum EmpPhone
333 BA
123 233-9876
333 BSc
333 233-1231
333 PhD
679 233-1231
679 BSc
679 MSc

An outer join between Employee and EmployeeDegree will

produce the information we saw before

91.2814 21
Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100
 First Normal Form (1NF)
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)

ISBN Title AuName AuPhone PubName PubPhone Price

0-321-32132-1 Balloon Sleepy, 321-321-1111, Small House 714-000-0000 $34.00

Snoopy, 232-234-1234,
Grumpy 665-235-6532

0-55-123456-9 Main Street Jones, 123-333-3333, Small House 714-000-0000 $22.95

Smith 654-223-3455
0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00

1-22-233700-0 Visual Roman 444-444-4444 Big House 123-456-7890 $25.00

Basic

Author and AuPhone columns are not scalar

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 1NF - Decomposition
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)
ISBN AuName AuPhone

0-321-32132-1 Sleepy 321-321-1111

0-321-32132-1 Snoopy 232-234-1234

ISBN Title PubName PubPhone Price 0-321-32132-1 Grumpy 665-235-6532

0-321-32132-1 Balloon Small House 714-000-0000 $34.00

0-55-123456-9 Jones 123-333-3333

0-55-123456-9 Main Street Small House 714-000-0000 $22.95

0-55-123456-9 Smith 654-223-3455

0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00

0-123-45678-0 Joyce 666-666-6666

1-22-233700-0 Visual Big House 123-456-7890 $25.00

1-22-233700-0 Roman 444-444-4444
Basic

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

keyword

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 Second Normal Form (2NF)
 A relation is in 2NF if the following conditions are satisfied:
 It is in 1NF.

 All non-key attributes are dependent on the entire key

(candidate key).

2NF does not have any partial dependencies. It means that
for a table that has concatenated primary key, each column
in the table that is not part of the primary key must depend
upon the entire concatenated key for its existence.
 2NF attempts to reduce the amount of redundant data in a
relation by extracting it, placing it in new table(s) and
creating relationships between those tables.

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Second Normal Form

 A table is in 2NF iff

 It is in 1NF and
 no non-prime attribute is dependent on any proper
subset of any candidate key of the table
 A non-prime attribute of a table is an
attribute that is not a part of any candidate
key of the table
 A candidate key is a minimal superkey

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

 Library allows patrons to request books that

are currently out

BookNo Patron PhoneNo

B3 J. Fisher 555-1234
B2 J. Fisher 555-1234
B2 M. Amer 555-4321

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

 Candidate key is {BookNo, Patron}

 We have
 Patron → PhoneNo
 Table is not 2NF
 Potential for
 Insertion anomalies
 Update anomalies
 Deletion anomalies

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

2NF Solution

 Put telephone number in separate Patron

table

BookNo Patron Patron PhoneNo

B3 J. Fisher J. Fisher 555-1234
B2 J. Fisher M. Amer 555-4321
B2 M. Amer

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

• prime key attributes are Stu_ID and Proj_ID

• According to the rule, non-key attributes (Stu_Name and Proj_Name ) must

be dependent upon both Stu_ID and Proj_ID

• Stu_Name can be identified by Stu_ID and

• Proj_Name can be identified by Proj_ID
• This is called partial dependency, which is not allowed in Second Normal Form.

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 Second Normal Form (2NF)
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

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 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

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 2NF - Decomposition
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}

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 2NF - Decomposition
Example 2 (Convert to 2NF)
Old Scheme  {Studio, Movie, Budget, StudioCity}
New Scheme  {Movie, Studio, Budget}
New Scheme  {Studio, City}

Example 3 (Convert to 2NF)

Old Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}
New Scheme  {City, Street, HouseNumber, HouseColor}
New Scheme  {City, CityPopulation}

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Third Normal Form

 A table is in 3NF iff

 it is in 2NF and
 all its attributes are determined only by its
candidate keys and not by any non-prime
attributes

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

 Table BorrowedBooks

BookNo Patron Address Due

B1 J. Fisher 101 Main Street 3/2/15
B2 L. Perez 202 Market Street 2/28/15

 Candidate key is BookNo

 Patron → Address

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

3NF Solution

 Put address in separate Patron table

BookNo Patron Due
B1 J. Fisher 3/2/15
B2 L. Perez 2/28/15

Patron Address
J. Fisher 101 Main Street
L. Perez 202 Market Street

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Third Normal Form (3NF)
 Third Normal form applies that every non-prime
attribute of table must be dependent on primary key
 There should not be the case that a non-prime

attribute is determined by another non-prime

 So this transitive functional dependency should be

removed from the table and also the table must be in

Second Normal form.

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

• City can be identified by Stu_ID as well as Zip itself.

• Neither Zip is a superkey nor is City a prime attribute.
• Additionally, Stu_ID → Zip → City, so there exists transitive dependency.

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 3NF Continue…..
# Consider the relation subject (cno, cname, instructor, office).
Assume that cname is not unique and cno is the only candidate key. The
following functional dependencies exists:
cno → cname ………………….(1)
cno → instructor ………………….(2)
instructor → office …………………..(3)
From (1) and (2) no, we can derive cno → office. So relation is in 2NF.
But relation is not in 3NF (Transitive dependency cno → office).
To overcome this, it is needed to decompose the above relation in the
following two relations:
sub (cno, cname, instructor) and inst (instructor, office)
Now, sub is now in 3NF and so is inst.

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Another example
 Tournament winners

Tournament Year Winner DOB

Indiana Invitational 1998 Al Fredrickson 21 July 1975

Cleveland Open 1999 Bob Albertson 28 Sept. 1968

Des Moines Masters 1999 Al Fredrickson 21 July 1975
 Candidate key is {Tournament, Year}
 Winner →DOB

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

Example

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 Third Normal Form (3NF)
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

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 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
BuildingI Contractor Fee
Example 3 (Not in 3NF) D
100 Randolph 1200
Scheme  {BuildingID, Contractor, Fee} 150 Ingersoll 1100
1. Primary Key  {BuildingID} 200 Randolph 1200
2. {BuildingID}  {Contractor} 250 Pitkin 1100
3. {Contractor}  {Fee} 300 Randolph 1200
4. {BuildingID}  {Fee}
5. Fee transitively depends on the BuildingID
6. Both Contractor and Fee depend on the entire key hence 2NF

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 3NF - Decomposition
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.

Example 1 (Convert to 3NF)

Old Scheme  {Title, PubID, PageCount, Price }
New Scheme  {PubID, PageCount, Price}
New Scheme  {Title, PubID, PageCount}

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 3NF - Decomposition
Example 2 (Convert to 3NF)
Old Scheme  {Studio, StudioCity, CityTemp}
New Scheme  {Studio, StudioCity}
New Scheme  {StudioCity, CityTemp}

Contractor Contractor
Example 3 (Convert to 3NF) BuildingI Fee
D
100 Randolph Randolph 1200
Old Scheme  {BuildingID, Contractor, Fee}
150 Ingersoll Ingersoll 1100
New Scheme  {BuildingID, Contractor} 200 Randolph Pitkin 1100
New Scheme  {Contractor, Fee} 250 Pitkin
300 Randolph

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100

 END

Md. Manowarul Islam, Dept. of CSE, Jagannath University, Dhaka-1100