Unit-4 Relational DB

8/18/2019 Unit-4 Relational DB

1/50

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan

Seewww.db-book.com for conditions on re-use

Chapter 7: Relational Database DesignChapter 7: Relational Database Design

http://www.db-book.com/http://www.db-book.com/


2/50

©Silberschatz, Korth and Sudarshan7.2Database System Concepts - 5th Edition, July 28, 2005.

Chapter 7: Relational Database DesignChapter 7: Relational Database Design

Features of Good Relational Design

Atomic Domains and First Normal Form

Decomposition Using Functional Dependencies

Decomposition Using Multivalued Dependencies


3/50


The Banking SchemaThe Banking Schema branch = (branch_name,branch_city,assets)

customer = (customer_id,customer_name,customer_street,customer_city)

loan = (loan_number,amount)

account = (account_number,balance)

employee = (employee_id.employee_name,telephone_number,start_date)

dependent_name = (employee_id,dname)

account_branch = (account_number,branch_name)

loan_branch = (loan_number,branch_name)

borrower = (customer_id,loan_number)

depositor = (customer_id,account_number)

cust_banker = (customer_id,employee_id,type)

works_for = (worker_employee_id,manager_employee_id)

payment = (loan_number,

payment_number, payment_date, payment_amount)

savings_account = (account_number,interest_rate)

checking_account = (account_number,overdraft_amount)


4/50


Combine Schemas?Combine Schemas?

Suppose we combineborrower andloan to get

bor_loan = (customer_id,loan_number,amount)

Result is possible repetition of information (L-100 in example below)


5/50


A Combined Schema Without RepetitionA Combined Schema Without Repetition

Consider combiningloan_branch andloan

loan_amt_br = (loan_number,amount,branch_name)

No repetition (as suggested by example below)


6/50


What About Smaller Schemas?What About Smaller Schemas?

Suppose we had started withbor_loan.How would we know to split up

(decompose) it intoborrowerandloan? Write a rule “if there were a schema (loan_number, amount), thenloan_numberwould be a candidate key”

Denote as afunctional dependency:

loan_number → amount

Inbor_loan, becauseloan_number is not a candidate key, the amount of a loanmay have to be repeated. This indicates the need to decomposebor_loan.

Not all decompositions are good. Suppose we decomposeemployee into

employee1 = (employee_id,employee_name)

employee2 = (employee_name,telephone_number,start_date)

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


7/50©Silberschatz, Korth and Sudarshan7.7Database System Concepts - 5th Edition, July 28, 2005.

A Lossy DecompositionA Lossy Decomposition



First Normal FormFirst Normal Form

Domain isatomic 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 intoparts

A relational schema R is infirst normal form if the domains of allattributes 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 ofowners stored with each account

We assume all relations are in first normal form (and revisit this inChapter 9)


9/50



Goal — Devise a Theory for the FollowingGoal — Devise a Theory for the Following

Decide whether a particular relationR is in “good” form.

In the case that a relationR is not in “good” form, decompose it into aset 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



Functional DependenciesFunctional Dependencies

Constraints on the set of legal relations.

Require that the value for a certain set of attributes determinesuniquely the value for another set of attributes.

A functional dependency is a generalization of the notion of akey.



Functional Dependencies (Cont.)Functional Dependencies (Cont.)

LetR be a relation schema

α ⊆ R andβ ⊆ R

The functional dependency

α → β holds on R if and only if for any legal relationsr(R), whenever anytwo tuplest1 andt2 ofr agree on the attributesα, they also agree

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

Example: Considerr(A,B) with the following instance ofr.

1 41 53 7




K is a superkey for relation schemaR if and only ifK→ R

K is a candidate key forR if and only if

K→ R, and

for noα ⊂ K,α → R

Functional dependencies allow us to express constraints that cannot

be expressed using superkeys. Consider the schema:bor_loan= (customer_id, loan_number, amount).

We expect this functional dependency to hold:

loan_number → amount

but would not expect the following to hold:

amount→ customer_name



Use of Functional DependenciesUse of Functional Dependencies

We use functional dependencies to:

test relations to see if they are legal under a given set of functionaldependencies.

If a relationr is legal under a setF of functional dependencies, wesay thatr satisfiesF.

specify constraints on the set of legal relations

We say thatF holds on R if all legal relations onR satisfy the set offunctional dependenciesF.

Note: A specific instance of a relation schema may satisfy a functionaldependency even if the functional dependency does not hold on all legalinstances.

For example, a specific instance ofloan may, by chance, satisfyamount→ customer_name.




Afunctional dependency istrivial if it is satisfied by all instances of a

relation Example:

customer_name, loan_number→ customer_name

customer_name→ customer_name

In general,α → β is trivial if β ⊆ α

Cl f StfF ti lCl f StfF ti l



Closure of a Set of FunctionalClosure of a Set of Functional

DependenciesDependencies

Given a setF of functional dependencies, there are certain other

functional dependencies that are logically implied byF. For example: If A → B andB → C, then we can infer that A → C

The set ofall functional dependencies logically implied byF is theclosure ofF.

We denote theclosureofF byF+.

F+ is a superset ofF.



Boyce-Codd Normal FormBoyce-Codd Normal Form

α → β is trivial (i.e.,β ⊆ α)

α is a superkey forR

A relation schemaR is in BCNF with respect to a setF of

functional dependencies if for all functional dependencies inF+

ofthe form

α→ β

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

Example schemanot in BCNF:

bor_loan = (customer_id, loan_number, amount )

becauseloan_number → amount holds onbor_loan butloan_number isnot a superkey



Decomposing a Schema into BCNFDecomposing a Schema into BCNF

Suppose we have a schemaRand a non-trivial dependencyα→β

causes a violation of BCNF.We decomposeR into:

• (αUβ )

• (R - (β -α ) )

In our example,

α =loan_number

β = amount

andbor_loan is replaced by

(αUβ ) = (loan_number, amount )

(R - (β -α ) ) = (customer_id, loan_number )



BCNF and Dependency PreservationBCNF 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 thatall functionaldependencies hold, then that decomposition isdependency

preserving.

Because it is not always possible to achieve both BCNF anddependency preservation, we consider a weaker normal form, knownasthird normal form.



Third Normal FormThird Normal Form

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

α → β inF+

at least one of the following holds:

α → β is trivial (i.e.,β ∈ α)

α is a superkey forR

Each attribute A inβ –α is contained in a candidate key forR.

(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 twoconditions above must hold).

Third condition is a minimal relaxation of BCNF to ensure dependency

preservation (will see why later).



Goals of NormalizationGoals of Normalization

LetR be a relation scheme with a set F of functional

dependencies. Decide whether a relation schemeR is in “good” form.

In the case that a relation schemeR 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 dependencypreserving.



How good is BCNF?How good is BCNF?

There are database schemas in BCNF that do not seem to be

sufficiently normalized Consider a database

classes(course, teacher, book)

such that (c, t, b)∈ classes means thatt is qualified to teachc, andb

is a required textbook forc

The database is supposed to list for each course the set of teachersany one of which can be the course’s instructor, and the set of books,all of which are required for the course (no matter who teaches it).



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

Insertion anomalies – i.e., if Marilyn is a new teacher that can teachdatabase, two tuples need to be inserted

(database, Marilyn, DB Concepts)(database, Marilyn, Ullman)

course teacher book

database

databasedatabasedatabasedatabasedatabaseoperating systemsoperating systemsoperating systemsoperating systems

Avi

AviHankHankSudarshanSudarshanAviAviPetePete

DB Concepts

UllmanDB ConceptsUllmanDB ConceptsUllmanOS ConceptsStallingsOS ConceptsStallings

classes

How good is BCNF? (Cont.)How good is BCNF? (Cont.)


24/50


Therefore, it is better to decomposeclassesinto:

course teacher

databasedatabasedatabaseoperating systems

operating systems

AviHankSudarshanAvi

Jim

teaches

course book

databasedatabaseoperating systemsoperating systems

DB ConceptsUllmanOS ConceptsShaw

text

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

How good is BCNF? (Cont.)How good is BCNF? (Cont.)


25/50


Functional-Dependency TheoryFunctional-Dependency Theory

We now consider the formal theory that tells us which functional

dependencies are implied logically by a given set of functionaldependencies.

We then develop algorithms to generate lossless decompositions intoBCNF and 3NF

We then develop algorithms to test if a decomposition is dependency-

preserving


26/50


27/50


ExampleExample

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

F ={ A→ B A→ CCG→ HCG→ I B→ H}

some members ofF+

A→ H

by transitivity from A→ B and B→ H

AG→ I

by augmenting A→ Cwith G, to get AG→ CG

and then transitivity withCG→ I

CG→ HI

by augmentingCG→ Ito inferCG→ CGI,

and augmenting ofCG→ Hto infer CGI→ HI,

and then transitivity


28/50

ClosureofFunctionalDependenciesClosureofFunctionalDependencies


29/50


Closure of Functional DependenciesClosure of Functional Dependencies

(Cont.)(Cont.)

We can further simplify manual computation ofF+ by using the

following additional rules. Ifα → β holds andα → γ holds, thenα → β γ holds(union)

Ifα → β γ holds, thenα → β holds andα → γ holds(decomposition)

Ifα → β holds andγ β → δ holds, thenα γ → δ holds

(pseudotransitivity)

The above rules can be inferred from Armstrong’s axioms.


30/50


Closure of Attribute SetsClosure of Attribute Sets

Given a set of attributesα, define theclosure ofα under F (denoted by

α+) as the set of attributes that are functionally determined byα underF

Algorithm to computeα+, the closure ofα underF

result:=α;while (changes toresult)do

for eachβ → γ in F dobeginifβ ⊆ result thenresult:=result∪ γ

end


31/50


Example of Attribute Set ClosureExample of Attribute Set Closure

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

F ={ A→ B A→ CCG→ HCG→ IB→ H}

( AG)+

1.result = AG

2.result = ABCG (A→ Cand A→ B)

3.result = ABCGH (CG→ H andCG⊆ AGBC)

4.result = ABCGHI(CG→ I andCG⊆ AGBCH)


32/50


Uses of Attribute ClosureUses of Attribute Closure

There are several uses of the attribute closure algorithm:

Testing for superkey:

To test ifα is a superkey, we computeα+, and check ifα+ containsall attributes ofR.

Testing functional dependencies

To check if a functional dependencyα → β holds (or, in otherwords, is inF+), just check ifβ ⊆ α+.

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

Is a simple and cheap test, and very useful

Computing closure of F For eachγ ⊆ R,we find the closureγ +, and for eachS ⊆ γ +, weoutput a functional dependencyγ → S.


33/50


Lossless-join DecompositionLossless-join Decomposition

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

relationsr on schemaRr =∏R1 (r) ∏R2 (r)

A decomposition ofR intoR1 andR2 is lossless join if and

only if at least one of the following dependencies is inF+:

R1 ∩ R2 → R1

R1 ∩ R2 → R2


34/50

D d P i


35/50


Dependency PreservationDependency Preservation

LetFi be the set of dependenciesF+ that include only attributes in

Ri. A decomposition isdependency preserving, if

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

If it is not, then checking updates for violation of functionaldependencies may require computing joins, which is

expensive.

T ti f D d P tiT ti f D d P ti


36/50


Testing for Dependency PreservationTesting for Dependency Preservation

To check if a dependencyα → β is preserved in a decomposition ofR into

R1,R2, …,Rn we apply the following test (with attribute closure done withrespect toF)

result=αwhile (changes toresult) dofor each Ri in the decomposition

t = (result∩

Ri)+∩ Ri

result = result∪ t

Ifresult contains all attributes inβ, then the functional dependencyα → β is preserved.

We apply the test on all dependencies inF to check if a decomposition is

dependency preserving This procedure takes polynomial time, instead of the exponential timerequired to computeF+ and (F1 ∪ F2 ∪ … ∪ Fn)+


37/50


ExampleExample

R =( A, B, C)

F ={ A → B B→ C}

Key = { A}

R is not in BCNF

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

R1 andR2 in BCNF

Lossless-join decomposition

Dependency preserving

NFE l


38/50


3NF Example3NF Example

Relation R:

R =( J, K, L)F ={ JK→ L, L→ K}

Two candidate keys: JKand JL

R is in 3NF

JK→ L JKis a superkeyL→ K Kis contained in a candidate key

R d d i3NFR d d i3NF


39/50


Redundancy in 3NFRedundancy in 3NF

J

j1

j2

j3

null

Ll1

l1

l1

l2

Kk1

k1

k1

k2

repetition of information (e.g., the relationshipl1,k1)

need to use null values (e.g., to represent the relationship l2,k2 where there is no corresponding value for J).

There is some redundancy in this schema

Example of problems due to redundancy in 3NF

R =( J, K, L)F ={ JK→ L, L→ K}

iC i fBCNF d3NF


40/50


Comparison of BCNF and 3NFComparison of BCNF and 3NF

It is always possible to decompose a relation into a set of relations

that are in 3NF such that: the decomposition is lossless

the dependencies are preserved

It is always possible to decompose a relation into a set of relations thatare in BCNF such that:

the decomposition is lossless

it may not be possible to preserve dependencies.

D i G lD i G l


41/50


Design GoalsDesign Goals

Goal for a relational database design is:

BCNF.

Lossless join.

Dependency preservation.

If we cannot achieve this, we accept one of

Lack of dependency preservation Redundancy due to use of 3NF

Interestingly, SQL does not provide a direct way of specifyingfunctional dependencies other than superkeys.

Can specify FDs using assertions, but they are expensive to test

Even if we had a dependency preserving decomposition, using SQLwe would not be able to efficiently test a functional dependency whoseleft hand side is not a key.

M li l dD d i (MVD)M lti l dD d i (MVD)


42/50


Multivalued Dependencies (MVDs)Multivalued Dependencies (MVDs)

LetR be a relation schema and letα ⊆ R andβ ⊆ R.The

multivalued dependency α β

holds onR if in any legal relationr(R), for all pairs for tuplest1andt 2 inr such thatt1[α] =t 2[α], there exist tuplest3 andt4 inr

such that:

t1[α] =t 2[α] =t3 [α] =t4 [α]t3[β] =t1[β]

t3[R –β] =t2[R –β]

t4[β] =t2[β]

t4[R –β] =t1[R –β]

MVD(C )MVD(C t)


43/50


MVD (Cont.)MVD (Cont.)

Tabular representation ofα β

E lE l


44/50


ExampleExample

LetR be a relation schema with a set of attributes that are partitioned

into 3 nonempty subsets.Y, Z, W

We say thatY Z(Y multidetermines Z)if and only if for all possible relationsr(R)

∈ r and ∈ r

then

∈ r and ∈ r

Note that since the behavior of Z andW are identical it follows that

Y ZifY W

E l(C t)E l(C t)


45/50


Example (Cont.)Example (Cont.)

In our example:

course teachercourse book

The above formal definition is supposed to formalize thenotion that given a particular value ofY(course) it hasassociated with it a set of values of Z (teacher)and a set of

values ofW (book), and these two sets are in some senseindependent of each other.

Note:

IfY→ ZthenY Z

Indeed we have (in above notation) Z1 = Z2

The claim follows.

U fM lti l dD d iU fM lti l dD d i


46/50


Use of Multivalued DependenciesUse of Multivalued Dependencies

We use multivalued dependencies in two ways:

1.To test relations todetermine whether they are legal under agiven set of functional and multivalued dependencies

2.To specifyconstraints on the set of legal relations. We shallthus concern ourselvesonly with relations that satisfy agiven set of functional and multivalued dependencies.

If a relationr fails to satisfy a given multivalued dependency, wecan construct a relationsr′ that does satisfy the multivalueddependency by adding tuples tor.

F thN lFFourthNormalForm


47/50


Fourth Normal FormFourth Normal Form

A relation schemaR is in 4NF with respect to a setD of functional and

multivalued dependencies if for all multivalued dependencies inD+

of theformα β, whereα ⊆ R andβ ⊆ R,at least one of the following hold:

α β is trivial (i.e.,β ⊆ α orα ∪ β = R)

α is a superkey for schemaR

If a relation is in 4NF it is in BCNF

R titi fM lti l dD d iRestrictionofMultivaluedDependencies


48/50


Restriction of Multivalued DependenciesRestriction of Multivalued Dependencies

The restriction of D to Ri is the set Di consisting of

All functional dependencies in D+ that include only attributes of Ri

All multivalued dependencies of the form

α (β ∩ Ri)

whereα ⊆ Riandα β is in D+

O llDtb D ig POverallDatabaseDesignProcess


49/50


Overall Database Design ProcessOverall Database Design Process

We have assumed schemaR is given

R could have been generated when converting E-R diagram to a set oftables.

R could have been a single relation containingall attributes that are ofinterest (calleduniversal relation).

Normalization breaksR into smaller relations.

R could have been the result of some ad hoc design of relations, whichwe then test/convert to normal form.

ERModelandNormalizationERModelandNormalization


50/50

ER Model and NormalizationER Model and Normalization

When an E-R diagram is carefully designed, identifying all entities

correctly, the tables generated from the E-R diagram should not needfurther normalization.

However, in a real (imperfect) design, there can be functionaldependencies from non-key attributes of an entity to other attributes ofthe entity

Example: anemployee entity with attributesdepartment_numberanddepartment_address, and a functional dependencydepartment_number→ department_address

Good design would have made department an entity

Functional dependencies from non-key attributes of a relationship set

possible, but rare --- most relationships are binary

Unit-4 Relational DB

Documents

Transcript of Unit-4 Relational DB