1. STRUCTURE OF PRESENTATION :
1. Basic database concepts **
Entr’acte
2. Relations 8.
SQL tables
3. Keys and foreign keys 9.
SQL operators I
4. Relational operators I
10. SQL operators II
Relational operators II 11.
Constraints and predicates 12.
The relational model A.
SQL constraints
SQL vs.
the relational model References
Copyright C. J. Date 2013

2. ENTR’ACTE :
Transactions
Database Design
Copyright C. J. Date 2013

3. DATABASE DESIGN :
As already mentioned, Codd’s introduction of the relational model paved the way for research into numerous aspects of DB management
DB design is one such … In fact, there’s now a very rich
theory of DB design /* and we can only scratch the surface here */
Design theory is part of relational theory in general, but it isn’t part of the relational model as such … It’s a separate theory that’s built on top of that model
So this is “part of RDB” but not “part of RM” (to understand DB technology you need to know something about it, but— like transactions—it’s a little tangential to our main theme)
Copyright C. J. Date 2013

4. RECALL : Relations are always normalized (i.e., in “1NF”)
/* which just means every tuple in the body conforms */
/* to the heading … */
Copyright C. J. Date 2013

5. Relations are always normalized (i.e., in “1NF”)
/* which just means every tuple in the body conforms */
/* to the heading … */
Relvar R is in first normal form (1NF) if and only if every relation r that can ever be assigned to R is in 1NF … i.e., if and only if every relation r that can ever be assigned to R is such that each tuple t of r contains (a) exactly one value (of the appropriate type) in every attribute position and (b) nothing else
Every relvar is in 1NF !!!
Copyright C. J. Date 2013

6. That’s why first normal form is called first
But we can define a series of higher normal forms (2NF, 3NF, BCNF, etc.), such that if a relvar is in one of those higher normal forms, then it possesses certain desirable properties that a relvar that’s only in 1NF doesn’t
That’s why first normal form is called first
BCNF implies 3NF implies 2NF implies 1NF
Note: Other normal forms do exist, but the details are beyond the scope of this presentation … As far as we’re concerned (and often in practice, in fact), BCNF is the important one
Copyright C. J. Date 2013

7. a given city and status appears several times, in general
EXAMPLE :
Consider relvar SPCT, with sample value:
SNO
PNO
QTY
CITY
STATUS S1 P1
300
London 20 P2
200 ..
...
...... S2
Paris 10
400
Note the redundancy … The fact that a given supplier has
a given city and status appears several times, in general
Copyright C. J. Date 2013

8. EXAMPLE (cont.) :
Design is “obviously” bad /* but that’s partly because the example is so simple */
Copyright C. J. Date 2013

9. EXAMPLE (cont.) :
SPCT design is “obviously” bad because it involves redundancy … And redundancy causes “update anomalies”: e.g.,
INSERT anomaly: Can’t insert the fact that the city for supplier S5 is Athens until S5 supplies a part
DELETE anomaly: If we delete the only tuple for supplier
S3, we lose S3’s city
UPDATE anomaly: Might change (“modify”) the city for
supplier S1 in one tuple and not another ... Then what ???
Copyright C. J. Date 2013

10. EXAMPLE (cont.) :
Design is “obviously” bad /* but that’s partly because the example is so simple */
Solution to the problem is “obvious” too—replace SPCT by:
SNO
PNO
QTY S1 P1
300 P2
200 ..
... S2
400
SNO
CITY
STATUS S1
London 20 S2
Paris 10 ..
......
/* ignore SNAME for simplicity */
Copyright C. J. Date 2013

11. EXAMPLE (cont.) :
Note that the two replacement relvars are projections of relvar SPCT …
… and if we join those projections together, we get back to where we started*
So 2NF, 3NF, etc. are all about decomposing a relvar via projection in such a way that (a) redundancies are removed and (b) the original relvar is equal to the join of those
projections
/* note reliance on the relational model! */
Further normalization = nonloss decomposition
* Strictly speaking, “projection” and “join” should be in quotes here
Copyright C. J. Date 2013

12. EXAMPLE (cont.) :
Observe that there’s a business rule—and hence an integrity constraint—in effect that needs to be enforced:
For a given supplier, there’s just one city
That integrity constraint is in fact a functional dependency
(FD) … Very important notion!
/* “not quite fundamental, but very nearly so” */
Definition:
Copyright C. J. Date 2013
page 200

13. FUNCTIONAL DEPENDENCIES :
Let X and Y be subsets of the heading of relvar R;
then the FD
X  Y
/* “determinant arrow dependant” */
holds in R if and only if, whenever two tuples of R agree on
X, they also agree on Y
E.g., the FD {SNO}  {CITY} holds in relvar SPCT
Copyright C. J. Date 2013

14. FDs (cont.) :
In fact, the FD {SNO}  {STATUS} holds in SPCT as well Thus, we can say the following FD holds:
{ SNO }  { CITY , STATUS }
Note the braces … X and Y are sets of attributes, and their values are tuples
Just as keys are sets of attributes and key values are tuples
Copyright C. J. Date 2013

15. ... which brings us to the next point:
If K is a key for relvar R, then the FD
K  { A }
necessarily holds for all attributes A of R
Equivalently: If K is a key for relvar R, then the FD
K  X
necessarily holds for all subsets X of the heading of R
Loosely speaking, it’s if there are any other FDs (i.e., FDs
“not out of keys”) that the design is bad
Copyright C. J. Date 2013

16. IRREDUCIBLE FDs :
If X  Y holds, then X'  Y' holds for all proper supersets X' of X and all proper subsets Y' of Y
E.g., { SNO }  { CITY , STATUS } holds in relvar SPCT
... so { SNO , PNO }  { CITY } holds too
If X  Y holds but X'  Y doesn’t hold for any proper subset X' of X, then X  Y is irreducible
E.g., in relvar SPCT:
{ SNO , PNO }  { QTY } is irreducible
{ SNO , PNO }  { CITY } isn’t
Copyright C. J. Date 2013

17. SECOND NORMAL FORM (2NF) :
Relvar R is in 2NF if and only if, for every key K of R and every nonkey attribute A of R, K  {A} is irreducible
The problem with SPCT is that it’s not in 2NF, because:
{SNO,PNO} is a key
The FDs {SNO,PNO}  {CITY} and {SNO,PNO} 
{STATUS} therefore hold
But they’re reducible
And they’re the source of the redundancies in SPCT
Copyright C. J. Date 2013

18. 2NF (cont.) :
So if relvar R isn’t in 2NF, the principles of further normalization say: Decompose it into projections that are!
(That’s what we did in the SPCT example)
Heath’s Theorem: Let X, Y, and Z be subsets of the heading H of relvar R such that the union of X, Y, and Z is equal to H. Let XY denote the union of X and Y, and similarly for XZ. If r satisfies the FD X  Y, then R is equal to the join of its projections R1 on XY and R2 on XZ.
(So it can be nonloss decomposed into those projections)
Copyright C. J. Date 2013

19. HEATH’S THEOREM (cont.) :
Assume for simplicity that X, Y, and Z are individual attributes.
Then:
R { X , Y , Z } /* satisfying {X}  {Y} */ can be nonloss decomposed into R1 { X , Y } KEY { X }
R2 { X , Z } FOREIGN KEY { X } REFERENCES R1
But note that the theorem doesn’t require X, Y, and Z to be individual attributes … It doesn’t even require them to be disjoint!
Copyright C. J. Date 2013

20. 2NF : ALTERNATIVE DEFINITION
Relvar R is in 2NF if and only if, for every key K of R and every nonkey attribute A of R, K  {A} is irreducible
Equivalently: Relvar R is in 2NF if and only if, for every nontrivial FD X  Y that holds in R,
X is a superkey, or
Y is a subkey, or
X is not a subkey
This definition requires some explanation!
Copyright C. J. Date 2013

21. TRIVIAL FDs :
An FD is trivial if and only if it can’t possibly fail to hold ...
E.g., { SNO , PNO }  { SNO }
{ SNO }
 { SNO }
In fact, an FD is trivial if and only if the dependant (right side) is a subset of the determinant (left side)
Copyright C. J. Date 2013

22. SUPERKEYS :
A superkey for relvar R is a subset SK of the heading of R that has the uniqueness property but not necessarily the irreducibility property*
/* so all keys are superkeys, but “most” superkeys aren’t keys ... a superkey that isn’t a key is a proper superkey */
If SK is a superkey for R, the FD SK  {A} holds in R for all attributes A of R
I.e., always have “arrows out of superkeys” (and hence out
of keys in particular)
* “Irreducibility” here refers to the definition of key, q.v.
Copyright C. J. Date 2013

23. EXERCISES : Relvar S has just one key, viz. {SNO}
Q: How many superkeys does it have? A:
Copyright C. J. Date 2013

24. SUBKEYS : A subkey for relvar R is a subset of a key of R
/* so all keys are subkeys, but “most” subkeys aren’t keys
... a subkey that isn’t a key is a proper subkey */
Copyright C. J. Date 2013

25. EXERCISES : Relvar SP has just one key, viz. {SNO,PNO}
Q: How many subkeys does it have? A:
Copyright C. J. Date 2013

26. 2NF : ALTERNATIVE DEFINITION bis
Relvar R is in 2NF if and only if, for every key K of R and every nonkey attribute A of R, K  {A} is irreducible
Equivalently: Relvar R is in 2NF if and only if, for every nontrivial FD X  Y that holds in R,
X is a superkey, or
Y is a subkey, or
X is not a subkey
The definitions are equivalent ... Trust me!
Copyright C. J. Date 2013

27. SO WHAT ABOUT 3NF ???
Suppose the FD {CITY}  {STATUS} holds in relvar S …
Sample value
/* note revised status for supplier S2 */ : S
SNO
SNAME
STATUS
CITY S1
Smith 20
London S2
Jones 30
Paris S3
Blake S4
Clark S5
Adams
Athens
This revised version of relvar S is in 2NF but not 3NF and therefore suffers from redundancy ...
Copyright C. J. Date 2013

28. THIRD NORMAL FORM (3NF) :
Relvar R is in 3NF if and only if for every nontrivial FD X  Y that holds in R, (a) X is a superkey or (b) Y is a subkey
Caveat: Many definitions of “3NF” in the literature
are actually definitions of BCNF!
… i.e., they effectively omit “or Y is a subkey”
3NF implies 2NF (obvious by virtue of alternative definition of 2NF)
Copyright C. J. Date 2013

29. THIRD NORMAL FORM (3NF) :
Relvar R is in 3NF if and only if for every nontrivial FD X  Y that holds in R, (a) X is a superkey or (b) Y is a subkey
The problem with the revised version of relvar S is that it’s not in 3NF (though it is in 2NF), because:
The FD {CITY}  {STATUS} holds
But {CITY} isn’t a superkey and {STATUS} isn’t a
subkey
And that FD is the source of the redundancies
Copyright C. J. Date 2013

30. 3NF (cont.) :
So if relvar R isn’t in 3NF, the principles of further normalization say: Decompose it into projections that are!
In the example, replace S by projections on {CITY,STATUS} and {ALL BUT STATUS}
Heath’s Theorem: Let X, Y, and Z be subsets of the heading H of relvar R such that the union of X, Y, and Z is equal to H. Let XY denote the union of X and Y, and similarly for XZ. If r satisfies the FD X  Y, then R is equal to the join of its projections R1 on XY and R2 on XZ.
Copyright C. J. Date 2013

31. BOYCE/CODD NORMAL FORM (BCNF) :
The normal form with respect to FDs !!!
Relvar R is in BCNF if and only if for every nontrivial
FD X  Y that holds in R, X is a superkey
Loosely: Every fact is a fact about the key, the whole key, and nothing but the key
Better: The only arrows are “out of superkeys”
Copyright C. J. Date 2013

32. BCNF (cont.) :
Why is BCNF superior to 3NF ??? … Well, compare the definitions:
Relvar R is in 3NF iff for every nontrivial FD X  Y that holds in R, X is a superkey or Y is a subkey
So BCNF implies 3NF
Copyright C. J. Date 2013

33. A RELVAR IN 3NF AND NOT BCNF:
Suppose (a) supplier names are necessarily unique
(b) relvar SP has extra attribute SNAME
Keys {SNO,PNO},
{SNAME,PNO}
/* neither primary! */
SNO
SNAME
PNO
QTY
S1 S1 ..
Smith Smith
…..
P1 P2
300
200 ….
{SNO}  {SNAME} and {SNAME}  {SNO} both hold and
aren’t “arrows out of superkeys” … but dependant is a subkey
in both cases, so 3NF
/* and suffers from redundancy */
Some amusing (?) history here …
Copyright C. J. Date 2013

34. ASIDE :
Question: Given that BCNF is “the” normal form with respect to FDs, why do we bother with 2NF and 3NF at all?
Answer: They give some insight into what goes wrong
if the relvar isn’t in BCNF ... and they recapitulate history
Another way to look at it: BCNF says “the only FDs are out of keys” ... How can a relvar violate this requirement? Two possible ways:
FD out of proper subkey:
FD out of nonkey:
Relvar not in 2NF
Relvar not in 3NF
Copyright C. J. Date 2013

35. SOME FINAL REMARKS :
BCNF is the final normal form with respect to FDs ...
But it’s certainly not the final normal form!
Relational DBMSs, and the relational model, don’t care
what level of normalization any given relvar is in
Higher levels help the user (partly by making the DB easier to understand) and might help the DBMS (partly by making certain integrity constraints easier to enforce), but they’re not required
There’s more to design theory than just normal forms
Copyright C. J. Date 2013