FDs Flashcards
How to identify “bad” schemas and improve them
- express constraints on the data: functional dependencies
2. use FDs to decompose the relation
Normalization
obtains a schema in the “normal form” that guarantees certain properties
Functional dependencies (FDs)
form of constraint that generalizes the concept of keys
A functionally determines B
if 2 tuples agree on the attributes A = A1, A2…An then they must agree on the attributes B = B1, B2, …Bm
A,B -> C,D can be split how?
A,B -> C
A,B -> D
Attributes on right are independently determined by A,B
A,B -> C,D
= A-> C,D and B->C,D?
cannot split this way
Trivial FDs
X->A
the attribute A belongs to the attribute set X
examples of trivial FDs
A -> A
A, B, C -> C
FD is domain knowledge
- inherent property of the application and data
- not something we can infer from a set of tuples
Given a table with a set of tuples, can we confirm FD is valid?
No, can only confirm FD seems valid or infer FD is invalid, can’t prove FD is valid
Why FDs?
- keys are special cases of FDs
- more integrity constraints
- help detect if schema has redundancies
Armstrongs Axioms
Reflexivity, Augmentation, Transitivity
Reflexivity
For any subset X in {A1..An}
A1, A2, …An -> X
examples reflexivity
A,B -> B
A,B,C -> A,B
A,B,C -> A,B,C
Augmentation
For any attribute sets X,Y,Z:
if X->Y, then X,Z -> Y,Z