Functional Dependency by Shashi

8/7/2019 Functional Dependency by Shashi

1/22

Relational Database DesignRelational Database Design

Functional DependenciesFunctional Dependencies


2/22

2

Functional Dependencies (FD)Functional Dependencies (FD) -- DefinitionDefinition

Let R be a relation scheme and X, Y be sets of attributes in R.

A functional dependency from X to Y exists if and only if:

Forevery instance of |R| of R, if two tuples in |R| agree on the values of theattributes in X, then they agree on the values of the attributes in Y

We writeXp Yand say thatX determines Y

Example on Student (sid, name, supervisor_id, specialization):

{supervisor_id}p {specialization} means

If two student records have the same supervisor (e.g., Dimitris), then theirspecialization (e.g., Databases) must be the same

On the other hand, if the supervisors of2students are different, we do not careabout their specializations (they may be the same or different).

Sometimes, Iomit the brackets for simplicity:

supervisor_idp specialization


3/22

3

Trivial FDsTrivial FDs

A functional dependency Xp

Y is trivialif Y is a subset of X {name, supervisor_id}p {name}

If two records have the same values on both the name and supervisor_id attributes,

then they obviously have the same name.

Trivial dependencies hold for all relation instances

A functional dependency Xp Y is non-trivialif YX =

{supervisor_id}p {specialization}

Non-trivial FDs are given implicitly in the form of constraints when designing a

database.

For instance, the specialization of a students must be the same as that of thesupervisor.

They constrain the set of legal relation instances. For instance, ifItry to insert two

students under the same supervisor with different specializations, the insertion will be

rejected by the DBMS


4/22


5/22

5

Superkeys and Candidate KeysSuperkeys and Candidate Keys

A set of attributes that determine the entire tuple is a superkey {sid, name} is a superkey for the student table.

Also {sid, name, supervisor_id} etc.

A minimalset of attributes that determines the entire tuple is a candidate key

{sid, name} is not a candidate key because Ican remove the name.

sid is a candidate key so is HKID (provided that it is stored in the table).

If there are multiple candidate keys, the DB designer chooses designates one as the

primary key.


6/22

6

Reasoning about Functional DependenciesReasoning about Functional Dependencies

It is sometimes possible to infer new functional dependencies from a set of given functionaldependencies independently from any particular instance of the relation scheme or of any additional

knowledge

Example:

From

{sid}p {first_name} and

{sid}p{last_name}

We can infer

{sid}p {first_name, last_name}


7/22

7

Armstrongs AxiomsArmstrongs Axioms

Be X, Y, Z be subset of the relation scheme of a relation RReflexivity:

If YX, then XpY (trivial FDs)

{name, supervisor_id}p{name}

Augmentation:

If XpY , then XZpYZ

if{supervisor_id}p{spesialization} ,

then {supervisor_id, name}p{spesialization, name}

Transitivity:

If XpYandYpZ, then XpZ

if{supervisor_id}p{spesialization} and{spesialization}p{lab}, then

{supervisor_id}p{lab}


8/22

8

Properties of Armstrongs AxiomsProperties of Armstrongs Axioms

Armstrongs axioms are sound(i.e., correct) andcomplete (i.e., they can produce allpossible FDs)

Example: TransitivityLet X, Y, Z be subsets of the relation R

If XpYandYpZ, then XpZ

Proof of soundness:Assume two tuples T1 andT2of |R| are such that, for all attributes in X, T1.X = T2.X.We want to prove that if transitivity holds andT1.X = T2.X, then indeedT1.Z = T2.Z

since XpY andT1.X = T2.X then, T1.Y = T2.Y

since YpZ andT1.Y = T2.Y then

T1.Z = T2.Z


9/22

9

Additional Rules based on Armstrongs axiomsAdditional Rules based on Armstrongs axioms

Armstrongs axioms can be used to produce additional rules that are not basic, but useful:

Weak Augmentation rule: Let X, Y, Z be subsets of the relation R

If XpY , then XZpY

Proof of soundness for Weak Augmentation

If XpY(1) Then by Augmentation XZpYZ

(2) And by ReflexivityYZpYbecause Y YZ

(3) Then byTransitivity of (1) and (2) we have XZp Y

Other useful rules:

If Xp Y and Xp Z, then Xp YZ (union)

If Xp YZ, then Xp Y and X p Z (decomposition)

If Xp Y and ZYp W, then ZXp W (pseudotransitivity)


10/22

10

Closure of a Set of Functional DependenciesClosure of a Set of Functional Dependencies

For a set F of functional dependencies, we call the closure of F, noted F+, the setof all the functional dependencies that can be derived from F (by the application

of Armstrongs axioms).

Intuitively, F+ is equivalent to F, but it contains some additional FDs that are only

implicit in F.

Consider the relation scheme R(A,B,C,D) withF = {{A}p{B},{B,C}p{D}}

F+ = {

{A}p{A}, {B}p{B}, {C}p{C}, {D}p{D}, {A,B}p{A,B}, [],

{A}p{B}, {A,B}p{B}, {A,D}p{B,D}, {A,C}p{B,C}, {A,C,D}p{B,C,D}, {A}

p{A,B},

{A,D}p{A,B,D}, {A,C}p{A,B,C}, {A,C,D}p{A,B,C,D},

{B,C}p{D}, [], {A,C}p{D}, []}


11/22

11

FindingFinding KeysKeys

Example: Consider the relation scheme R(A,B,C,D) with functional dependencies {A}p

{C}and{B}p{D}.

Is {A,B} a candidate key?

For{A,B} to be a candidate key, it must

determine all attributes (i.e., be a superkey)

be minimal

{A,B} is a superkey because:

{A}p{C} {A,B}p{A,B,C} (augmentation by AB)

{B}p{D} {A,B,C}p{A,B,C,D} (augmentation by A,B,C)

We obtain {A,B}p{A,B,C,D} (transitivity)

{A,B} is minimal because neither{A} nor{B} alone are candidate keys


12/22

12

Closure of a Set of AttributesClosure of a Set of Attributes

For a set X of attributes, we call the closure of X (with respect to a set of functionaldependencies F), noted X+, the maximum set of attributes such that XpX+

(as a consequence of F)

Consider the relation scheme R(A,B,C,D) with functional dependencies {A}p{C}

and{B}p{D}.

{A}+ = {A,C} {B}+ = {B,D}

{C}+={C}

{D}+={D}

{A,B}+ = {A,B,C,D}


13/22

13

Algorithm for Computing the Closure of a Set of AttributesAlgorithm for Computing the Closure of a Set of Attributes

Input:

R a relation scheme

F a set of functional dependencies

X R (the set of attributes for which we want to compute the closure)

Output:

X+ the closure of X w.r.t. F

X(0) := X

Repeat

X(i+1) := X(i) Z, where Z is the set of attributes such that

there exists YpZ in F, and

YX(i)

Until X(i+1) := X(i)

Return X(i+1)


14/22

14

Closure of a Set of Attributes: ExampleClosure of a Set of Attributes: Example

R = {A,B,C,D,E,G}

F = {{A,B}p{C}, {C}p{A}, {B,C}p{D}, {A,C,D}p{B}, {D}p{E,G}, {B,E}p{C}, {C,G}p{B,D},

{C,E}p{A,G}}

X = {B,D}

X(0) = {B,D}

{D}p{E,G},

X(1) = {B,D,E,G},

{B,E}p{C}

X(2)

= {B,C,D,E,G}, {C,E}p{A,G}

X(3) = {A,B,C,D,E,G}

X(4) = X(3)


15/22

15

Uses of Attribute ClosureUses of Attribute Closure

There are several uses of the attribute closure algorithm:

Testing for superkey

To test if X is a superkey, we compute X+, and check if X+ contains all attributes of R. X is acandidate key if none of its subsets is a key.

Testing functional dependencies

To check if a functional dependency Xp Y holds (or, in other words, is in F+), just check if Y

X+

.Computing the closure of F

For each subset X R, we find the closure X+, and for each YX+, we output a functionaldependency Xp Y.

Computing if two sets of functional dependencies F and G are equivalent, i.e., F+ = G+

For each functional dependency YpZ in F

Compute Y+ with respect to G

If Z Y+ then YpZ is in G+

And vice versa


16/22

16

Redundancy of FDsRedundancy of FDs

Sets of functional dependencies may have redundant dependencies that can beinferred from the others

{A}p{C} is redundant in: {{A}p{B}, {B}p{C},{A}p {C}}

Parts of a functional dependency may be redundant

Example ofextraneous/redundantattribute on RHS:

{{A}p{B}, {B}p{C}, {A}p{C,D}} can be simplified to

{{A}p{B}, {B}p{C}, {A}p{D}}

(because {A}p{C} is inferred from {A}p {B}, {B}p{C})

Example ofextraneous/redundantattribute on LHS:

{{A}p{B}, {B}p{C}, {A,C}p{D}} can be simplified to

{{A}p{B}, {B}p{C}, {A}p{D}}

(because of{A}p{C})


17/22


18/22


19/22

19

Pitfalls in Relational Database DesignPitfalls in Relational Database Design

Functional dependencies can be used to refine ER diagrams or independently

(i.e., by performing repetitive decompositions on a "universal" relation that

contains all attributes).

Relational database design requires that we find a good collection of relation

schemas. A bad design may lead to

Repetition ofInformation.

Inability to represent certain information.

Design Goals:

Avoid redundant data

Ensure that relationships among attributes are represented

Facilitate the checking of updates for violation of database integrity constraints.


20/22

20

Example of Bad DesignExample of Bad Design

Consider the relation schema: Lending-schema = (branch-name, branch-city, assets, customer-name,loan-number, amount) where:

{branch-name}p{branch-city, assets}

Bad Design

Wastes space. Data for branch-name, branch-city, assets are repeated for each loan that abranch makes

Complicates updating, introducing possibility of inconsistency of assets value

Difficult to store information about a branch if no loans exist. Can use null values, but they aredifficult to handle.


21/22

21

Usefulness of FDsUsefulness of FDs

Use functional dependencies to 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

if possible,preserve dependencies

In our example the problem occurs because there FDs ({branch-name}p{branch-city, assets}) where the LHSis not a key

Solution: decompose the relation schema Lending-schema into:

Branch-schema = (branch-name, branch-city,assets)

Loan-info-schema = (customer-name, loan-number, branch-name, amount)


22/22

22

Thank youThank you

For further clarification

Contact: [email protected]

Functional Dependency by Shashi

Documents

Transcript of Functional Dependency by Shashi