Relational Database Design (I)

1

Roadmap of This Lecture

■ Features of Good Relational Design■ Atomic Domains and First Normal Form■ Decomposition Using Functional Dependencies■ Functional Dependency Theory■ Algorithms for Functional Dependencies

2

Goal of Design

■ Generate a set of relational schemas that● Do not have unnecessary redundancies;● Allow easy retrieval of data.

■ General approach is to design schemas that are in a desireable normal form.

■ We may need more info about the real world enterprise than what�s in the E-R diagram.

3

Larger Schemas?

■ Suppose we combine instructor and department into inst_dept● (No connection to relationship set inst_dept)

■ Result is possible repetition of information

4

A Combined Schema Without Repetition

■ Consider combining relations ● sec_class(sec_id, building, room_number) and ● section(course_id, sec_id, semester, year) into one relation● section(course_id, sec_id, semester, year,

building, room_number)■ No repetition in this case

5

What About Smaller Schemas?

■ Suppose we had started with inst_dept. How would we know to split up (decompose) it into instructor and department?

6

Decomposition

■ A rule “if there were a schema (dept_name, building, budget), then dept_name would be a candidate key”

■ Can be denoted 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 be repeated. ● This indicates the need to decompose inst_dept

■ Not all decompositions are good. Suppose we decomposeemployee(ID, name, street, city, salary) intoemployee1 (ID, name)employee2 (name, street, city, salary)

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

7

A Lossy Decomposition

8

Example of Lossless-Join Decomposition

■ Lossless join decomposition■ Decomposition of R = (A, B, C)

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

A B

ab

12

A

ab

B

12

r ÕB,C(r)

ÕA (r) ÕB (r) A B

ab

12

C

AB

B

12

C

AB

C

AB

ÕA,B(r)

9

First Normal Form

■ Domain is atomic if its elements are considered to be indivisible units● Examples of non-atomic domains:

4 Set of names, composite attributes4 Identification numbers like CS101 that can be broken up into

parts■ A relational schema R is in first normal form if the domains of all

attributes of R are atomic■ 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 first normal form (and revisit this

later in Object Based Databases)

10

First Normal Form (Cont�d)

■ Atomicity is actually a property of how the elements of the domain are used.● Example: 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 roll numbers is not atomic.● Doing so is a bad idea: leads to encoding of information in

application program rather than in the database.

11

Goal — Devise a Theory for the Following

■ 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

■ Our theory is based on:● functional dependencies● multivalued dependencies

12

Functional Dependencies

■ Constraints on the set of legal relations.■ Require that the value 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.

13

Functional Dependencies (Cont.)

■ Let R be a relation schemaa Í R and b Í R

■ The functional dependencya ® b

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 a, they also agree on the attributes b. That is,

t1[a] = t2 [a] Þ t1[b ] = t2 [b ] ■ Example: Consider r(A,B ) with the following instance of r.

■ On this instance, A ® B does NOT hold, but B ® A does hold.

1 41 53 7

14

Functional Dependencies (Cont.)

■ K is a superkey for relation schema R if and only if K ® R■ K is a candidate key for R if and only if

● K ® R, and● for no a Ì K, a ® R

■ Functional dependencies allow 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® buildingand ID à building

but would not expect the following to hold: dept_name ® salary

15

Use of Functional Dependencies

■ We use functional dependencies to:● test relations to see if they are legal under a given set of functional

dependencies. 4 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

4 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.

16

Functional Dependencies (Cont.)

■ A functional dependency is trivial if it is satisfied by all instances of any relation● Example:

4 ID, name ® ID4 name ® name

● In general, a ® b is trivial if b Í a

17

Closure of a Set of Functional Dependencies

■ Given a set F of functional dependencies, there are certain other functional dependencies that are logically implied by F.● For example: If A ® B and B ® C, then we can infer that A ® C

■ The set of all functional dependencies logically implied by F is the closure of F.

■ We denote the closure of F by F+.■ F+ is a superset of F.

18

Boyce-Codd Normal Form

■ a ® b is trivial (i.e., b Í a)■ a is a superkey for R

A relation schema R is in BCNF with respect to a set F of functional dependencies if for all functional dependencies in F+ of the form

a ® b

where a Í R and b Í R, at least one of the following holds:

Example schema not in BCNF:

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

because dept_name® building, budgetholds on instr_dept, but dept_name is not a superkey

19

Decomposing a Schema into BCNF

■ Suppose we have a schema R and a non-trivial dependency a ® bcauses a violation of BCNF.We decompose R into:• (a U b )• ( R - ( b - a ) )

■ In our example, ● a = dept_name● b = building, budgetand inst_dept is replaced by● (a U b ) = ( dept_name, building, budget )● ( R - ( b - a ) ) = ( ID, name, salary, dept_name )

20

BCNF and Dependency Preservation

■ Constraints, including functional dependencies, 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.● That is no need to test a à b where a is in one relation and b is in

another.■ Because it is not always possible to achieve both BCNF and

dependency preservation, we consider a weaker normal form, known as third normal form.

21

Third Normal Form

■ A relation schema R is in third normal form (3NF) if for all:a ® b in F+

at least one of the following holds:● a ® b is trivial (i.e., b Î a)● a is a superkey for R● Each attribute A in b – a 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 above must hold).■ Third condition is a minimal relaxation of BCNF to ensure dependency

preservation (will see why later).

22

Goals of Normalization

■ Let R be a relation schema with a set F of functional dependencies.■ Decide whether a relation schema R is in “good” form.■ In the case that a relation schema R is not in “good” form,

decompose it into a set of relation schemas {R1, R2, ..., Rn} such that ● each relation schema is in good form ● the decomposition is a lossless-join decomposition● Preferably, the decomposition should be dependency preserving.

23

How good is BCNF?■ There are database 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

ID child_name phone

99999999999999999999

DavidDavidWilliamWilliam

512-555-1234512-555-4321512-555-1234512-555-4321

inst_info

24

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

■ Insertion anomalies – i.e., 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)

How good is BCNF? (Cont.)

25

■ Therefore, it is better to decompose inst_info into:

This suggests the need for higher normal forms, such as Fourth Normal Form (4NF), which we shall see later.

How good is BCNF? (Cont.)

ID child_name

99999999999999999999

DavidDavidWilliamWillian

inst_child

ID phone

99999999999999999999

512-555-1234512-555-4321512-555-1234512-555-4321

inst_phone

26

Functional-Dependency Theory

■ We now consider the formal theory that tells us which functional dependencies are implied logically by a given set of functional dependencies.

■ We then develop algorithms to generate lossless decompositions into BCNF and 3NF

■ We finally develop algorithms to test if a decomposition is dependency-preserving

27

Closure of a Set of Functional Dependencies

■ We can find F+, the closure of F, by repeatedly applying Armstrong’s Axioms:● if b Í a, then a ® b (reflexivity)● if a ® b, then g a ® g b (augmentation)● if a ® b, and b ® g, then a ® g (transitivity)

■ These rules are ● sound (generate only functional dependencies that actually hold),

and ● complete (generate all functional dependencies that hold).

28

Example■ R = (A, B, C, G, H, I)

F = { A ® BA ® C

CG ® HCG ® I

B ® H}■ some members of F+

● A ® H 4 by transitivity from A ® B and B ® H

● AG ® I 4 by augmenting A ® C with G, to get AG ® CG

and then transitivity with CG ® I ● CG ® HI

4 by augmenting CG ® I to infer CG ® CGI, and augmenting of CG ® H to infer CGI ® HI,

and then transitivity

29

Procedure for Computing F+

■ To compute the closure of a set of functional dependencies F:

F + = Frepeat

for each functional dependency f in F+

apply reflexivity and augmentation rules on fadd the resulting functional dependencies to F +

for each pair of functional dependencies f1and f2 in F +if f1 and f2 can be combined 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

30

Closure of Functional Dependencies (Cont.)

■ Additional rules:● If a ® b holds and a ® g holds, then a ® b g holds (union)● If a ® b g holds, then a ® b holds and a ® g holds

(decomposition)● If a ® b holds and g b ® d holds, then a g ® d holds

(pseudotransitivity)

■ Quiz 1: Derive the above three rules using the Armstrong’s axioms (reflexivity, augmentation, transitivity).

31

Closure of Attribute Sets

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

■ Algorithm to compute a+, the closure of a under F

result := a;while (changes to result) do

for each b ® g in F dobegin

if b Í result then result := result È gend

■ Quiz 2: What is the complexity of the algorithm on the size of F?A) Linear B) Quadratic C) Cubic

32

Example of Attribute Set Closure■ R = (A, B, C, G, H, I)■ F = {A ® B

A ® C CG ® HCG ® IB ® H}

■ (AG)+

1. result = AG2. result = ABCG (A ® C and A ® B)3. result = ABCGH (CG ® H and CG Í ABCG)4. result = ABCGHI (CG ® I and CG Í ABCGH)

■ Is AG a candidate key? 1. Is AG a super key?

1. Does AG ® R? == Is R Í (AG)+ ?2. Is any subset of AG a superkey?

1. Does A ® R? == Is R Í (A)+ ?2. Does G ® R? == Is R Í (G)+?

33

Uses of Attribute Closure

There are several uses of the attribute closure algorithm:■ Testing for superkey:

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

■ Testing functional dependencies● To check if a functional dependency a ® b holds (or, in other

words, is in F+), just check if b Í a+. ● That is, we compute a+ by using attribute closure, and then check

if it contains b. ● Is a simple and cheap test, and very useful

■ Computing closure of F● For each g Í R, we find the closure g+, and for each S Í g+, we

output a functional dependency g ® S.

34

Canonical Cover

■ Sets of functional dependencies may have redundant dependencies that can be inferred from the others● For example: A ® C is redundant in: {A ® B, B ® C, A ® C}● Parts of a functional dependency may be redundant

4 E.g.: on RHS: {A ® B, B ® C, A ® CD} can be simplified to

{A ® B, B ® C, A ® D} 4 E.g.: on LHS: {A ® B, B ® C, AC ® D} can be simplified

to {A ® B, B ® C, A ® D}

■ Intuitively, a canonical cover of F is a “minimal” set of functional dependencies equivalent to F, having no redundant dependencies or redundant parts of dependencies

35

Extraneous Attributes

■ Consider a set F of functional dependencies and the functional dependency a ® b in F.● Attribute A is extraneous in a if A Î a

and F logically implies (F – {a ® b}) È {(a – A) ® b}.● Attribute A is extraneous in b if A Î b

and the set of functional dependencies (F – {a ® b}) È {a ®(b – 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 (I.e. the result of dropping B from AB ® C).■ Example: Given F = {A ® C, AB ® CD}

● C is extraneous in AB ® CD since AB ® C can be inferred from A ® C, and then by union rule AB ® CD.

36

Testing if an Attribute is Extraneous

■ Consider a set F of functional dependencies and the functional dependency a ® b in F.

■ To test if attribute A Î a is extraneous in a

1. compute ({a} – A)+ using the dependencies in F2. check that ({a} – A)+ contains b; if it does, A is extraneous in a

■ To test if attribute A Î b is extraneous in b1. compute a+ using only the dependencies in

F’ = (F – {a ® b}) È {a ®(b – A)}, 2. check that a+ contains A; if it does, A is extraneous in b

37

Canonical Cover

■ A canonical cover for F is a set of dependencies Fc such that ● F logically implies all dependencies in Fc, and ● Fc logically implies all dependencies in F, and● No functional dependency in Fc contains an extraneous attribute, and● Each left side of functional dependency in Fc is unique.

■ To compute a canonical cover for F:repeat

Use the union rule to replace any dependencies in Fa1 ® b1 and a1 ® b2 with a1 ® b1 b2

Find a functional dependency a ® b with an extraneous attribute either in a or in b/* Note: test for extraneous attributes done using Fc, not F */

If an extraneous attribute is found, delete it from a ® buntil F does not change

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

38

Computing a Canonical Cover■ R = (A, B, C)

F = {A ® BCB ® CA ® B

AB ® C}■ Combine A ® BC and A ® B into A ® BC

● Set is now {A ® BC, B ® C, AB ® C}■ A is extraneous in AB ® C

● Check if the result of deleting A from AB ® C is implied by the other dependencies4 Yes: in fact, B ® C is already present!

● Set is now {A ® BC, B ® C}■ C is extraneous in A ® BC

● Check if A ® C is logically implied by A ® B and the other dependencies4 Yes: using transitivity on A ® B and B ® C.

– Can use attribute closure of A in more complex cases■ The canonical cover is: A ® B

B ® C

39

Lossless-join Decomposition

■ For the case of R = (R1, R2), we require that for all possible relations ron schema R

r = ÕR1 (r ) ÕR2 (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 above dependencies are a necessary condition only if all constraints are functional dependencies

40

Example

■ 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)

41

Dependency Preservation

■ Let Fi be the set of dependencies in F + that include only attributes in Ri.

4 Fi is called the restriction of F to Ri.4 A decomposition is dependency preserving, if

(F1 È F2 È … È Fn )+ = F +

4 If it is not, then checking updates for violation of functional dependencies may require computing joins, which is expensive.

■ Quiz 3: The complexity of the computation of (F1 È F2 È … È Fn )+ = F + on the size of F isA) Linear B) Quadratic C) Cubic D) Exponential

42

Testing for Dependency Preservation

■ To check if a dependency a ® b is preserved in a decomposition of Rinto R1, R2, …, Rn we apply the following test (with attribute closure done with respect to F)● result = a

while (changes to result) dofor each Ri in the decomposition

t = (result Ç Ri)+ Ç Riresult = result È t

● If result contains all attributes in b, then the functional dependency a ® b is preserved.

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

■ Quiz 4: This procedure takesA) Linear time B) Quadratic timeC) Cubic Time D) Exponential Time

43

Example

■ R = (A, B, C )F = {A ® B

B ® C}Key = {A}

■ R is not in BCNF■ Decomposition R1 = (A, B), R2 = (B, C)

● R1 and R2 in BCNF● Lossless-join decomposition● Dependency preserving

44

End

45