📚

Week 5 Lecture 1
Class BSCCS2001

Created @October 4, 2021 11:55 AM

Materials

Module # 21

Type Lecture

Week # 5

Relational Database Design

Features of Good Relational Design
Good Relational Design
Reflects real-world structure of the problem

Can represent all expected data over time

Avoids redundant storage of data over time

Provides efficient access to data

Supports the maintenance of data integrity over time

Clean, consistent and easy to understand

NOTE: These objectives are sometimes contradictory ඞ

What is a good schema?

Week 5 Lecture 1 1
 Consider combining relations

sec_class(sec_id, building, room_number) and

section(course_id, sec_id, semester, year)

No repetition in this case

Redundancy and Anomaly

Redundancy: Having multiple copies of the same data in the DB

This problem arises when a DB is not normalized

It leads to anomalies

Anomaly: Inconsistencies that can arise due to data changes in a database with insertion, deletion and update

These problems occur in poorly planned, un-normalized DBs where all the data is stored in one table (a flat-file
DB)

There can be 3 kinds of anomalies

Insertions anomaly

Deletion anomaly

Update anomaly

Insertions anomaly

When the insertion of a data record is not possible without adding some additional unrelated data to the record

We cannot add an Instructor in instructor_with_department if the department does not have a building or budget

Deletion anomaly

When deletion of a data record results in losing some unrelated information that was stored as part of the record
that was deleted from a table

We delete the last Instructor of a Department from instructor_with_department, we lose building and budget
information

Update anomaly

When a data is changed, which could involve many records having to be changed, leading to the possibility of
some changes being made incorrectly

When the budget changes for a Department having a large number of Instructors in instructor_with_department
application may miss some of them

Week 5 Lecture 1 2
 We have observed the following:

Redundancy ⇒ Anomaly

Relations instructor and department is better than instructor_with_department

What causes redundancy?

Dependency ⇒ Redundancy

dept_name uniquely decides building and budget

A department cannot have two different budget or building

So, building and budget depends on dept_name

How to remove, or at least minimize, redundancy?

Decompose (partition) the relation into smaller relations

instructor_with_department can be decomposed into instructor and department

Good Decomposition ⇒ Minimization of Dependency

Is every decomposition good?

No

It needs to preserve information, honor the dependencies, be efficient, etc

Various schemes of normalization ensure good decomposition

Normalization ⇒ Good decomposition

Decomposition
Suppose we had started with inst_dept

How would we know to split up (decompose) it into instructor and department?

Write a rule "if there were a schema (dept_name, building, budget), then dept_name would be a candidate key"

Denote as a functional dependency: dept_name → building, budget

In inst_dept, because dept_name is not a candidate key, the building and budget of a department may have to
repeated

This indicates the need to decompose inst_dept

Not all decompositions are good

Suppose we decompose

employee(ID, name, street, city, salary) into

employee1 (ID, name)

employee2 (name, street, city, salary)

Note that if name can be duplicate, then employee2 is a weak entity set and cannot exist without an identifying
relationship

Consequently, this decomposition cannot preserve the information

The next slide shows how we lose information — we cannot reconstruct the original employee relation — and so, this
is a lossy decomposition

Decomposition: Lossy Decomposition

Week 5 Lecture 1 3
 Decomposition: Lossless-join Decomposition
Lossless Join Decomposition

Decomposition of R = (A, B, C)
R1 = (A, B), R2 = (B, C)

Lossless Join Decomposition is a decomposition of a relation R into relations R1 , R2 such that if we perform
natural join of two smaller relations it will return the original relation

R1 ∪ R2 = R, R1 ∩ R2 = ϕ
∀r ∈ R, r1 = ⊓R 1 (r), r2 = ⊓R 2 (r)
r1 ⋈ r2 = r
This is effective in removing the redundancy from DBs while preserving the original data

Week 5 Lecture 1 4
 In other words, by lossless decomposition it becomes feasible to reconstruct the relation R from decomposed tables
R1 and R2 by using Joins

Atomic Domains and First Normal Form

First Normal Form (1NF)
A domain is atomic if its elements are considered to be indivisible units

Examples of non-atomic domains:

Set of names, composite attributes

Identification numbers like CS101 that can be broken up into parts

A relational schema R is in First Normal Form (1NF) if

the domains of all attributes of R are atomic

the value of each attribute contains only a single value from that domain

Non-atomic values complicate storage and encourage redundant (repeated) storage of data

Example: Set of accounts stored with each customer, and set of owners stored with each account

We assume all relations are in the first normal form

Atomicity is actually a property of how the elements of the domain are used

Strings would normally be considered indivisible

Suppose that students are given roll numbers which are strings of the form CS0012 or EE1127

If the first two characters are extracted to find the department, the domain of the roll numbers is not atomic

Doing so is a bad idea ...

It leads to encoding of the information in application program rather than in the database

The following is not in 1NF

A telephone number is composite

Telephone number is multi-valued

Consider:

is in 1NF if telephone number is not considered composite

However, conceptually, we have two attributes for the same concept

Arbitrary and meaningless ordering of the attributes

Week 5 Lecture 1 5
 How to search telephone numbers

Why only two numbers?

Is the following in 1NF?

Duplicated information

ID is no more the key

Key is (ID, Telephone Number)

Better to have 2 relations:

One-to-Many relationship between parent and child relations

Incidentally, satisfies 2NF and 3NF

Decomposition helps to attain 1NF for the embedded one-to-many relationship

Week 5 Lecture 1 6
 📚
Week 5 Lecture 2
Class BSCCS2001

Created @October 4, 2021 2:41 PM

Materials

Module # 22

Type Lecture

Week # 5

Relational Database Design (part 2)

Functional Dependencies
Goal: Devise a theory for good relations
Decide whether a particular relation R is in "good" form

In the case that a relation R is not in "good" form, decompose it into a set of relations {R1 , R2 , ..., Rn } such that

each relation is in good form

the decomposition is a lossless-join decomposition

The theory is based on:

Functional dependencies

Multi-valued dependencies

Other dependencies

Functional Dependencies
Constraints on the set of legal relations

Require that the values for a certain set of attributes determines uniquely the value for another set of attributes

A functional dependency is a generalization of the notion of a key

Let R be a relation schema

α ⊆ R and β ⊆ R

Week 5 Lecture 2 1
 The functional dependency or FD

α→β
holds on R if and only if for any legal relations r(R), whenever any two tuples t1 and t2 on r agree on the attributes
α, they also agree on the attributes β
That is:

t1 [α] = t2 [α] ⇒ t2 [β] = t2 [β]

Example: Consider r(A, B) with the following instance of r

On this instance, A → B does NOT hold, but B → A does hold

So, we cannot have tuples like (2, 4) or (3, 5) or (4, 7) added to the current instance

K is a superkey for relation schema R if and only if K → R

K is a candidate key for R if and only id
K → R and
for no α ⊂ K, α → R
Functional dependencies allows us to express constraints that cannot be expressed using superkeys

Consider the schema:

inst_dept(ID, name, salary, dept_name, building, budget)

We expect these functional dependencies to hold:

dept_name → building

dept_name → budget

ID → budget

but would NOT expect the following to hold:

dept_name → salary

We use functional dependencies to:

test relations to see if they are legal under a given set of functional dependencies

If a relation r is legal under a set F of functional dependencies, we say that r satisfies F

specify constraints on the set of legal relations

We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F

NOTE: A specific instance of a relation schema may satisfy a functional dependency even if the functional
dependency does not hold on all legal instances

For example, a specific instance of instructor may, by chance, satisfy

name → ID

In such cases, we do not say that F holds on R

A functional dependency is trivial if it is satisfied by all instance of the relation

Example:

ID, name → ID

name → name

Week 5 Lecture 2 2
 In general, α → β is trivial if β ⊆ α

Functional dependencies are:

StudentID → Semester

StudentID, Lecture → TA

{StudentID, Lecture} → {TA, Semester}

Functional dependencies are:

EmployeeID → EmployeeName

EmployeeID → DepartmentID

DepartmentID → DepartmentName

Functional Dependencies: Armstrong's Axioms

Given a set of Functional Dependencies F , we can infer new dependencies by the Armstrong's Axioms:

Reflexivity: if β ⊆ α, then α → β
Augmentation: if α → β , then γα → γβ
Transitivity: if α → β and β → γ , then α → γ
These axioms can be repeatedly applied to generate new FDs and added to F

A new FD obtained by applying the axioms is said to the logically implied by F

The process of generations of FDs terminate after infinite number of steps and we call it the Closure Set F + for FDs
F
This is the set of all FDs logically implied by F

Clearly, F ⊆ F+
These axioms are:

Sound (generate only functional dependencies that actually hold) and

Week 5 Lecture 2 3
 Complete (eventually generate all functional dependencies that hold)

Prove the axioms from definitions of FDs

Prove the soundness and completeness of the axioms

Functional Dependencies: Closure of a Set of FDs

F = {A → B, B → C}
F + = {A → B, B → C, A → C}

Week 5 Lecture 2 4
 📚
Week 5 Lecture 3
Class BSCCS2001

Created @October 4, 2021 3:28 PM

Materials

Module # 23

Type Lecture

Week # 5

Relational Database Design (part 3)

Functional Dependency Theory
Functional Dependencies: Closure of a Set FDs
R = (A, B, C, G, H, I)
F = {A → B
A→C
CG → H
CG → I
B → H}
Some members of F +

A→H
by transitivity from A → B and B → H
AG → I
by augmenting A → C with G, to get AG → CG and then transitivity with CG → I
CG → HI
by augmenting CG → I with CG to infer CG → CGI and augmenting CG → H with I to infer CGI →
HI and then transitivity

Functional Dependencies: Closure of a Set FDs: Computing F +

Week 5 Lecture 3 1
 To compute the closure of a set of functional dependencies F :
F+ ← F
repeat

for each functional dependency f in F +

apply reflexivity and augmentation rules on f

add the resulting functional dependencies to F +

for each pair of functional dependencies f1 and f2 in F +

if f1 and f2 can be continued using transitivity

then add the resulting functional dependency to F +

until F + does not change any further

NOTE: We shall see an alternative procedure for this task later

Functional Dependencies: Armstrong's Axioms: Derived Rules

Additional Derived Rules:

Union: if α → β holds and α → γ holds, then α → βγ holds

Decomposition: if α → βγ holds, then α → β holds and α → γ holds
Pseudotransitivity: if α → β holds and γβ → δ holds, then αγ → δ holds
The above rules can be inferred from basic Armstrong's axioms (and hence are not included in the basic set)

They can be proven independently too

Reflexivity: if β ⊆ α, then α → β
Augmentation: if α → β , then γα → γβ
Transitivity: if α → β and β → γ , then α → γ
Prove the rules from:

Basic axioms

The definitions of FDs

Functional Dependencies: Closure of Attribute Sets

Given a set of attributes α, define the closure of α under F (denoted by α+ ) as the set of attributes that are
functionally determined by α under F

Algorithm to compute α+ , the closure of α under F

result ← α
while (changes to result) do

for each β → γ in F do
begin

if β ⊆ result then result ← result ∪ γ

end

Functional Dependencies: Closure of Attribute Sets: Example

R = (A, B, C, G, H, I)
F = {A → B, A → C, CG → H, CG → I, B → H}
(AG)+
result = AG

result = ABCG (A → C and A → B)

result = ABCGHI (CG → H and CG → AGBC )
result = ABCGHI (CG → I and CG → AGBCH )
Is AG a candidate key?

Week 5 Lecture 3 2
 Is AG a super key?

Does AG → R? == Is (AG)+ ⊇ R
Is any subset of AG a superkey?

Does A → R? == Is (A)+ ⊇ R
Does G → R? == Is (A)+ ⊇ R

Functional Dependencies: Closure of Attribute Sets: Use

There are several uses of the attributes closure algorithm:

Testing for superkey:

To test is α is a superkey, we compute α+ and check if α+ contains all attributes of R

Testing functional dependencies

To check if a functional dependency α → β holds (or, in other words, is in F + ), just check if β ⊆ α+

That is, we compute α+ by using attribute closure and then check if it contains β

Is a simple and cheap test, and very useful

Computing closure of F

For each γ ⊆ R, we find the closure γ + and for each S ⊆ γ + , we output a functional dependency γ → S

Decomposition using Functional Dependency

BCNF: Boyce-Codd Normal Form
A relations schema R is in BCNF w.r.t a set F of FDs if for all FDs in F + of the form

α → β , where α ⊆ R and β ⊆ R at least one of the following holds:

α → β is trivial (that is, β ⊆ α)
α is a superkey for R
Example schema not in BCNF:

instr_dept (ID, name, salary, dept_name, building, budget)

because the non-trivial dependency dept_name → building, budget holds on instr_dept, but dept_name is not a
superkey

BCNF: Decomposition
If in schema R and non-trivial dependency α → β causes a violation of BCNF, we decompose R into:
α∪β
(R − (β − α))
In our example:

α = dept_name
β = building, budget
dept_name → building, budget
inst_dept is replaced by

(α ∪ β) = (dept_name, building, budget)

dept_name → building, budget
(R − (β − α)) = (ID, name, salary, dept_name)
ID → name, salary, dept_name

Lossless Join
If we decompose a relation R into relations R1 and R2 :

Decomposition is lossy if R1 ⋈ R2 ⊃ R

Week 5 Lecture 3 3
 Decomposition is lossless if R1 ⋈ R2 = R
To check if lossless join decomposition using FD set, the following must hold:

Union of Attributes of R1 and R2 must be equal to attribute of R

R1 ∪ R2 = R
Intersection of Attributes of R1 and R2 must not be NULL

R1 ∩ R2 =
ϕ
Common attribute must be a key for at least one relation (R1 or R2 )

R1 ∩ R2 → R1 or R1 ∩ R2 → R2
Prove that BCNF ensures Lossless Join

BCNF: Dependency Preservation

Constraints, including FDs, are costly to check in practice unless they pertain to only one relation

If it is sufficient to test only those dependencies on each individual relation of a decomposition in order to ensure that
all functional dependencies hold, then that decomposition is dependency preserving

It is not always possible to achieve both BCNF and dependency preservation

Consider:

R = CSZ, F = {CS → Z, Z → C}
Key = CS

CS → Z satisfies BCNF, but Z → C violates

Decompose as: R1 = ZC, R2 = CSZ − (C − Z) = SZ
R1 ∪ R2 = CSZ = R, R1 ∩ R2 = Z = ϕ and R1 ∩ R2 = Z → ZC = R1
So, it has lossless join

However, we cannot check CS → Z without doing a join

Hence, it is not dependency preserving

We consider a weaker normal form, known as Third Normal Form (3NF)

3NF: Third Normal Form

A relation schema R is in third normal form (3NF) if for all:

α → β ∈ F+
at least one of the following holds:

α → β is trivial (that is, β ⊆ α)

α is a superkey for R
Each attribute A in β − α is contained in a candidate key for R
(NOTE: Each attribute may be in a different candidate key)

If a relation is in BCNF it is in 3NF (since in BCNF one of the first two conditions must hold)

Third condition is a minimal relaxation of BCNF to ensure dependency preservation

Goals of Normalization
Let R be a relation scheme with a set F of functional dependencies

Decide whether a relation scheme R is in "good" form

In the case that a relation scheme R is not in "good" form, decompose it into a set of relation scheme
{R1 , R2 , ..., Rn } such that
each relation scheme is in good form

the decomposition is a lossless-join decomposition

Preferably, the decomposition should be dependency preserving

Week 5 Lecture 3 4
 Problems with Decomposition
There are 3 potential problems to consider:

May be impossible to re-construct the original relation (Lossiness)

Dependency checking may require joins

Some queries become more expensive

What is the building for an instructor?

Tradeoff: Must consider these issues vs redundancy

How good is BCNF?

There are DB schemas in BCNF that do not seem to be sufficiently normalized

Consider a relation

inst_info (ID, child_name, phone)

where an instructor may have more than one phone and can have multiple children

There are no non-trivial functional dependencies and therefore the relation is in BCNF

Insertion anomalies — that is, if we add a phone 981-992-3443 to 99999, we need to add two tuples

(99999, David, 981-992-3443)

(99999, William, 981-992-3443)

Therefore, it is better to decompose inst_info into:

This suggests the need for higher normal forms such as the Fourth Normal Form (4NF)

Week 5 Lecture 3 5
Week 5 Lecture 3 6
 📚
Week 5 Lecture 4
Class BSCCS2001

Created @October 4, 2021 6:10 PM

Materials

Module # 24

Type Lecture

Week # 5

Relational Database Design (part 4)

Algorithms for Functional Dependencies
Attribute Set Closure
R = (A, B, C, G, H, I)
F = {A → B, A → C, CG → H, CG → I, B → H}
(AG)+
result = AG

result = ABCG (A → C and A → B)

result = ABCGH (CG → H and CG ⊆ AGBC)
result = ABCGHI (CG → I and CG ⊆ AGBCH)
is AG a candidate key?

is AG a super key?

Does AG → R? == is (AG)+ ⊇ R
is any subset of AG a superkey?

Does A → R? == is (A)+ ⊇ R
Does G → R? == is (G)+ ⊇ R

Attribute Set Closure: Uses

Week 5 Lecture 4 1
 There are several uses of the attribute closure algorithm

Testing for a superkey:

To test if α is a superkey, we compute α+ and check if α+ contains all the attributes of R

Testing functional dependencies

To check if a functional dependency α → β holds (or, in other words, is in F + ), just check if β ⊆ α+

That is, we compute α+ by using attribute closure and then check if it contains β

It is a simple and cheap test, and very useful

Computing closure of F

For each γ ⊆ R, we find the closure γ + and for each S ⊆ γ + , we output a functional dependency γ → S

Extraneous Attributes
Consider a set F of FDs and the FD α → β in F
Attribute A is extraneous in α if A ∈ α and F logically implies
(F − {α → β}) ∪ {(α − A) → β}
Attribute A is extraneous in β if A ∈ β and the set of FDs
(F − {α → β}) ∪ {α → (β − A)} logically implies F
NOTE: Implication in the opposite direction is trivial in each of the cases above, since a "stronger" functional
dependency always implies a weaker one

Example: Given F = {A → C, AB → C}
B is extraneous in AB → C because {A → C, AB → C} logically implies A → C
(that is, the result of dropping B from AB → C)
A+ = AC in {A → C, AB → C}
Example: Given F = {A → C, AB → CD}
C is extraneous in AB → CD since AB → C can be inferred even after deleting C
AB+ = ABCD in {A → C, AB → D}

Extraneous Attributes: Tests

Consider a set F of functional dependencies and the functional dependency α → β in F
To test if attribute A ∈ α is extraneous in α
Compute ({α} − A)+ using the dependencies in F

Check that ({α} − A)+ contains β ; if it does, A is extraneous in α

To test if attribute A ∈ β is extraneous in β

Compute α+ using only the dependencies in

F ′ = (F − {α → β}) ∪ {α → (β − A)}
Check that α+ contains A; if it does, A is extraneous in β

Equivalence of Sets of Functional Dependencies

Let F & G are two functional dependency sets
These two sets F & G are equivalent F + = G+
That is: (F + = G+ ) ⇔ (F + ⇒ G and G+ ⇒ F )
Equivalence means that every functional dependency in F can be inferred from G and every functional
dependency in G can be inferred from F

F and G are equal only if

F covers G: Means that all functional dependency of G are logically numbers of functional dependency set
F ⇒ F+ ⊇ G

Week 5 Lecture 4 2
 G covers F : Means that all functional dependency of F are logically numbers of functional dependency set
G ⇒ G+ ⊇ F

Canonical Cover
Sets of FDs may have redundant dependencies that can be inferred from the others

Can we have some kind of "optimal" or "minimal" set of FDs to work with?

A Canonical Cover for F is a set of dependencies Fc such that ALL the following properties are satisfied:

F + = Fc+
F logically implies all dependencies in Fc
Fc logically implies all dependencies in F
No functional dependency in Fc contains an irrelevant attribute

Each left side of functional dependency in Fc is unique

That is, there are no two dependencies α1 → β1 and α2 → β2 in such that α1 → α2

Intuitively, a Canonical cover of F is a minimal set of FDs

Equivalent to F

Having no redundant FDs

No redundant parts of FDs

Minimal / Irreducible Set of Functional Dependencies

Canonical Cover: Example

For example: A → C is redundant in {A → B, B → C, A → C}
Parts of a functional dependency may be redundant

For example: on RHS: {A → B, B → C, A → CD} can be simplified to {A → B, B → C, A → D}

Canonical Cover: RHS

Week 5 Lecture 4 3
 Canonical Cover: LHS

Canonical Cover
To compute a canonical cover for F :
repeat

Use the union rule to replace any dependencies in F

α1 → β1 and α1 → β2 with α1 → β1 β2
Find a functional dependency α → β with an
irrelevant attribute either in α or in β

/* NOTE: test for irrelevant attributes done using Fc , not F */

If an irrelevant attribute is found, delete it from α →β

until F does not change

NOTE: Union rule may become applicable after some irrelevant attributes have been deleted, so it has to be re-
applied

Canonical Cover: Example

Week 5 Lecture 4 4
 Practice Problems on Functional Dependencies

Week 5 Lecture 4 5
Week 5 Lecture 4 6
 📚
Week 5 Lecture 5
Class BSCCS2001

Created @October 4, 2021 8:05 PM

Materials

Module # 25

Type Lecture

Week # 5

Relational Database Design (part 5)

Lossless Join Decomposition
For the case of R = (R1 , R2 ), we require that for all possible relations r on schema R
r = πR 1 (r) ⋈ πR 2 (r)
A decomposition of R into R1 and R2 is lossless join if at least one of the following dependencies is in F + :

R1 ∩ R2 → R1
R1 ∩ R2 → R2
The above functional dependencies are a sufficient condition for lossless join decomposition; the dependencies are a
necessary condition only if all constraints are functional dependencies

Lossless Join Decomposition: Example

Consider Supplier_Parts schema: Supplier_Parts(S#, Sname, City, P#, Qty)

Having dependencies: S# → Sname, S# → City, (S#, P#) → Qty

Decompose as: Supplier (S#, Sname, City, Qty): Parts (P#, Qty)

Week 5 Lecture 5 1
 Take natural join to reconstruct: Supplier ⋈ Parts

We get extra tuples! Join is lossy

Common attribute Qty is not a superkey in Supplier or in Parts

Does not preserve (S#, P#) → Qty

Consider Supplier_Parts schema: Supplier_Parts(S#, Sname, City, P#, Qty)

Having dependencies: S# → Sname, S# → City, (S#, P#) → Qty

Decompose as: Supplier (S#, Sname, City, Qty): Parts (P#, Qty)

Take natural join to reconstruct: Supplier ⋈ Parts

We get the original relation. Join is lossless.

Common attribute S# is a superkey in Supplier

Preserve all the dependencies

R = (A, B, C)
F = {A → B, B → C}
Can be decomposed in two different ways

R1 = (A, B), R2 = (B, C)

Lossless-join decomposition:

R1 ∩ R2 = {B} and B → BC
Dependency preserving

R1 = (A, B), R2 = (A, C)

Lossless-join decomposition:

R1 ∩ R2 = {A} and A → AB
Not dependency preserving

(cannot check B → C without computing R1 ⋈ R2 )

Practice Problem on Lossless join

Week 5 Lecture 5 2
 Dependency Preservation
Let Fi be the set of dependencies F + that include only attributes in Ri

A decomposition is dependency preserving if

(F1 ∪ F2 ∪ ... ∪ Fn )+ = F +
If it is not, then checking updates for violation of functional dependencies may require computing join, which is
expensive

Let R be the original relational schema having FD set F. Let R1 and R2 having FD set F1 and F2 respectively, are the
decomposed sub-relations of R. The decomposition of R is said to be preserving if

F1 ∪ F2 ≡ F {Decomposition Preserving Dependency}

If F1 ∪ F2 ⊂ F {Decomposition NOT Preserving Dependency} and
F1 ∪ F2 ⊃ F {this is not possible}

Dependency Preservation: Testing

To check if a dependency α → β is preserved in a decomposition of R into D = {R1 , R2 , ..., Rn } we apply the
following test (with attribute closure done with respect to F)

The restriction of F + to Ri is the set of all functional dependencies in F + that include only attributes of Ri

compute F + ;

for each schema Ri in D do

begin

Fi = the restriction of F + to Ri ;
end

F′ = ϕ
for each restriction Fi do

begin

F ′ = F ′ ∪ Fi
end

compute F ′+ ;

if (F ′+ = F + ) then return (true)

else return (false);

The procedure for checking dependency preservation takes exponential time to compute F + and (F1 ∪ F2 ∪ ... ∪
+
Fn )

Dependency Preservation: Example

R (A, B, C, D, E, F )

Week 5 Lecture 5 3
 F = {A → BCD, A → EF , BC → AD, BC → E, BC → F , B → F , D → E}
Decomposition: R1(A, B, C, D) R2(B, F ) R3(D, E)

A → BCD, BC → AD are preserved on table R1

B → F is preserved on table R2
D → E is preserved on table R3
We have to check whether the remaining FDs: A → E , A → F , BC → E , BC → F are preserved or not

F ′ = F1 ∪ F2 ∪ F3
Checking for: A → E , A → F in F ′+
A → D (from R1), D → E (from R3) : A → E (By transitivity)
A → B (from R1), B → F (from R2) : A → F (By transitivity)
Checking for: BC → E , BC → F in F ′+
BC → D (from R1), D → E (from R3) : BC → E (by transitivity)
B → F (from R2) : BC → F (by augmentation)

R(A, B, C, D)
F = {A → B, B → C, C → D, D → A}
Decomposition: R1(A, B) R2(B, C) R3(C, D)

A → B is preserved on table R1
B → C is preserved on table R2
C → D is preserved on table R3
We have to check whether the one remaining FD: D → A is preserved or not

F ′ = F1 ∪ F2 ∪ F3
Checking for: D → A in F ′+
D → C (from R3), C → B (from R2), B → A (from R1) : D → A (by transitivity)
Hence, all dependencies are preserved

Dependency Preservation: Testing

To check if a dependency α → β is preserved in a decomposition of R into R1 , R2 , ..., Rn , we apply the following
test (with attribute closure done with respect to F )

result = α

while (changes to result) do

for each Ri in the decomposition

t = (result ∩ Ri )+ ∩ Ri
result = result ∪ t

If result contains all attributes in β , then the functional dependency α → β is preserved

We apply the test of all dependencies in F to check if a decomposition is dependency preserving

Week 5 Lecture 5 4
 This procedure takes polynomial time, instead of the exponential time required to compute F + and (F1 ∪ F2 ∪ ... ∪
+
Fn )

Dependency Preservation: Example

Week 5 Lecture 5 5