Download - Functional Dependency by Shashi
-
8/7/2019 Functional Dependency by Shashi
1/22
Relational Database DesignRelational Database Design
Functional DependenciesFunctional Dependencies
-
8/7/2019 Functional Dependency by Shashi
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
-
8/7/2019 Functional Dependency by Shashi
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
-
8/7/2019 Functional Dependency by Shashi
4/22
-
8/7/2019 Functional Dependency by Shashi
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.
-
8/7/2019 Functional Dependency by Shashi
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}
-
8/7/2019 Functional Dependency by Shashi
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/7/2019 Functional Dependency by Shashi
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
-
8/7/2019 Functional Dependency by Shashi
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)
-
8/7/2019 Functional Dependency by Shashi
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}, []}
-
8/7/2019 Functional Dependency by Shashi
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
-
8/7/2019 Functional Dependency by Shashi
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}
-
8/7/2019 Functional Dependency by Shashi
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)
-
8/7/2019 Functional Dependency by Shashi
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)
-
8/7/2019 Functional Dependency by Shashi
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
-
8/7/2019 Functional Dependency by Shashi
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})
-
8/7/2019 Functional Dependency by Shashi
17/22
-
8/7/2019 Functional Dependency by Shashi
18/22
-
8/7/2019 Functional Dependency by Shashi
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.
-
8/7/2019 Functional Dependency by Shashi
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.
-
8/7/2019 Functional Dependency by Shashi
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)
-
8/7/2019 Functional Dependency by Shashi
22/22
22
Thank youThank you
For further clarification
Contact: [email protected]