Chapter 5.1 and 5.2Brian CobarrubiaDatabase Management Systems IIJanuary 31, 2008

Agenda

5.1 – Functional Dependencies Between Attributes Superkeys and Keys Inferring Functional Dependencies Determining Keys from Functional Dependencies

5.2 – Normal Forms 1st Normal Form 2nd Normal Form 3rd Normal Form Boyce Codd Normal Form

Functional Dependencies between Attributes

Functionally Dependent An attribute B is functionally dependent on an attribute A in a

relational table if the value of A uniquely determines the value of B

We can also say that A determines B

A B Formal Definition of Functional Dependencies

Let R be a relation schema where

R and RThe functional dependency

Holds on R if and only if for any legal relations r (R), whenever any two tuples t1 and t2 of r agree on the attributes they also agree

on the attributes . That is, t1[] = t2 [] t1[ ] = t2 [ ]

Functional Dependencies between Attributes

Superkeys and Keys A superkey of a relation schema is a set of attributes that

functionally determines all other attributes of the table

A set of attributes A is a key of a relation schema if A is a superkey and any proper subset of A is not a superkey

An attribute that is part of any key of the schema is called a prime attribute and an attribute that is not part of any key is a non-prime attribute

Functional Dependencies between Attributes

Inferring Functional Dependencies Inference process help us find functional dependencies in a

relation, there are six rules:

• Reflexivity: If X Y, then X Y• Augmentation: If X Y, then XZ YZ• Transitivity: If X Y and Y Z, then X Z• Decomposition: If X YZ, then X Y• Union: If X Y and X Z, then X YZ• Pseudo-transitivity: If X Y and WX Z, then WX Z

Let W,X,Y, and Z be sets of functional dependencies and XY is the union of X and Y

The first three are known as Armstrong's Axioms which was used to derive the later rules as well

Functional Dependencies between Attributes

Determining Keys from Functional Dependencies Left side of a functional dependency is the determinant and the

right side is known as the dependent Formal Definition of the keys of a schema

Suppose S is a schema that is specified as a set of attributes A and a set of functional dependencies F. Let F+ be the closure

of the functional dependencies defined for S. A set of attributes X is a key of S if and only if X A- X is in F+ and for each Y ⊂ X,

Y X is not in F+

If a functional dependency X Z includes all of the attributes of the schema, then X is a superkey

Functional Dependencies between Attributes

Functionally Dependencies Example #1

Functional Dependency defined on the attributes X and Y

Would read the relationship as

“X determines Y” or “X Y” All the tuples in X that agree on

X must also agree on Y

Functional Dependencies between Attributes

Functionally Dependencies Example #2

Functional Dependencies in Schemas

Employee: (EmpID, Name, Phone, Position)

EmpID Name, Phone, Position

Position Phone

Normal Forms Normalization

Normalization is the process of transforming some objects into a structural form that satisfies some collection of rules

Used to reduce update anomalies and redundancy A database schema is said to be in normal form if each of its

relation schemas is in the normal form A dependency X Y is a full dependency if Y is not dependent

on any subset of X A dependency X Y is a maximal dependency if there is no

attribute A not in X or Y such that X ∪ Y {A} A dependency X Y is a trivial dependency if at least one

attribute is part of both sides, that is, where X ∩ Y is not empty

Normal Forms First Normal Form: Atomic Attributes

The first normal form specifies that every attribute of a schema must takes its values from an atomic domain

Not in First Normal Form

First Normal Form

Normal Forms Second Normal Form: No Partial Key Dependencies

The second normal form is designed to eliminate functional dependencies that have part of a key on the left side

It is in second normal form if no non-prime attributes are partially dependent on any key of the schema and it is in (1NF)

Not in Second Normal FormEmployee: (Emp_ID, Course_Title, Name, Dept_Name, Salary, Date_Completed)

Not fully functionally dependent on the primary key

Normal Forms Third Normal Form: No Transitive Dependencies

A schema is in third normal form if it has no transitive dependencies and it is in (2NF)

A transitive dependency of X Y is a transitive dependency if there is a set of attributes Z that is not a subset of any key and both X Z and Z Y

Must be dependent on the key this is not 3NF

Normal Forms Boyce-Codd Normal Form: No Non-Key Dependencies

It is similar to (3NF) but the table is in Boyce-Codd Normal Form if it has no non-key dependencies

Not in Boyce-Codd Normal Form

Supplier: (supplierID, supplierName, street, zipcode)

Functional Dependencies:

{supplierID, zipcode} supplierName, street *Candidate Key

{supplierName, zipcode} supplierID, street *Candidate Key

supplierName supplierID

supplierID supplierName

These are in (3NF) since they are part of the prime attributes but are not BCNF since supplierID supplierName isn't satisfied

BCNF would be broken into Supplier:(supplierID, street, zipcode) SupplierName:(supplierID, supplierName)