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. INTEGRITY CONSTRAINTS :
Every database is subject to certain integrity constraints,
which update operations must never be allowed to violate
E.g., supplier status values must be in the range 1-100
inclusive; part weights must be greater than zero; etc.
In particular, every relvar is subject to at least one key
constraint (i.e., has at least one key) /* why? */
E.g., {SNO}, {PNO}, {SNO,PNO} for S, P, SP, respectively
Note: {SNAME} is not a key for relvar S !!!
Copyright C. J. Date 2013

3. DEFINITION : KEY
Let K be a subset of the heading of relvar R. Then K is a
key for R if and only if: 1.
Uniqueness:
No possible relation that can ever be assigned to R
has two distinct tuples with the same value for K 2.
Irreducibility:
No proper subset of K has the uniqueness property
E.g.:
{SNO}, {PNO}, {SNO,PNO} for S, P, SP, respectively
/* note the braces! */
Copyright C. J. Date 2013

4. ASIDE : Let A and B be sets. Then:
“A is a subset of B” (“A is included in B”, written A  B)
means every element of A is an element of B
“A is a proper subset of B” (“A is properly included in B”, written A  B) means A is a subset of B and there exists at least one element of B that’s not an element of A
Every set is a subset of itself (but no set is a proper subset of itself)
Similarly for supersets (B  A , B  A)
Copyright C. J. Date 2013

5. AND ANOTHER : Important!
The empty set { } is the unique set with no elements
It’s a subset of every set
It’s sometimes called the null set ... but avoid this term! It’s sometimes written Ø
Nullology: The study of the empty set ... Whenever the set concept crops up, you should immediately ask yourself: What happens if this set is empty?
Copyright C. J. Date 2013

6. BACK TO KEYS : A relvar can certainly have more than one key ... e.g.:
TAX_BRACKET { LOW ... , HIGH ... , RATE ... } KEY { LOW }
KEY { HIGH }
KEY { RATE }
ROSTER { DAY ... , HOUR ... , GATE ... , PILOT ... } KEY { DAY , HOUR , GATE }
KEY { DAY , HOUR , PILOT }
PLUS { A ... , B ... , C ... , ... }
KEY { A , B }
KEY { B , C }
KEY { C , A }
/* A + B = C */
Copyright C. J. Date 2013

7. If relvar R has more than one key, then:
It’s usual, but not required, to choose one key as primary
If relvar R has just one key, then:
It’s usual, but not required, to call that key primary
Keys are fundamental, but primary keys aren’t
On slides, however, when there’s just one key, I’ll mark it as primary by double underlining
Copyright C. J. Date 2013

8. CONSTRAINTS (cont.) :
To repeat: Every relvar is subject to at least one key constraint (i.e., has at least one key) … Some relvars are subject to foreign key constraints as well
E.g., {SNO} in SP is a foreign key referencing {SNO} in S;
{PNO} in SP is a foreign key referencing {PNO} in P
/* note the braces again! */
Very loosely, we might say foreign key constraints are the
glue that holds the DB together
Copyright C. J. Date 2013

9. DEFINITION* : FOREIGN KEY
Let relvars R2 and R1 be such that:
K is a key for R1
FK is a subset of the heading of R2
At any given time, every FK value in R2 is required to be equal to some K value in R1
Then FK is a foreign key in R2 referencing K in R1
E.g., {SNO} and {PNO} in SP reference {SNO} in S and
{PNO} in P, respectively
* Slightly simplified
Copyright C. J. Date 2013

10. POINTS ARISING :
To repeat, foregoing definition is slightly simplified /* but it’s good enough for present purposes */
Terminology:
“Referential integrity” ... e.g., can’t delete a supplier tuple if to do so would leave any “dangling references”
R1 and R2 are the referenced (or target) and referencing
relvar, resp.
K is the referenced (or target) key
Copyright C. J. Date 2013

11. RELVAR S : DEFINITION Tutorial D:
VAR S BASE /* other kinds of relvars are mostly beyond the scope */
RELATION
{ SNO
SNAME
/* of this introductory presentation */
CHAR ,
STATUS INTEGER , CITY CHAR }
KEY { SNO } ;
Note: “RELATION { ... }” specifies the type of relvar S
/* see next page */
Note that the KEY specification is part of the definition of the relvar,
not part of the type specification
Copyright C. J. Date 2013

12. RELATION TYPES /* important! */ :
Relations are values; values have types; so relations have (relation) types!
Relvars are variables; variables have types; so relvars have
(relation) types!
In Tutorial D, relation types have names of the form RELATION heading
where heading takes the form
{ attribute-name attribute-type , … }
/* order in which attributes are specified is insignificant */
Copyright C. J. Date 2013

13. RELVAR P : DEFINITION Tutorial D: VAR P BASE RELATION
{ PNO PNAME COLOR
CHAR , CHAR , CHAR ,
WEIGHT RATIONAL , CITY CHAR }
KEY { PNO } ;
Copyright C. J. Date 2013

14. RELVAR SP : DEFINITION Tutorial D: VAR SP BASE RELATION { SNO PNO QTY
CHAR , CHAR , INTEGER }
KEY { SNO , PNO }
FOREIGN KEY { SNO } REFERENCES S
FOREIGN KEY { PNO } REFERENCES P ;
All base relvars are initially empty by default (i.e., value is the empty
relation of the applicable type)
Copyright C. J. Date 2013

15. “POPULATING” THE DATABASE :
S := RELATION
{ TUPLE { SNO 'S1' , SNAME 'Smith' ,
STATUS 20 , CITY 'London' } , TUPLE { SNO 'S2' , SNAME 'Jones' ,
STATUS 10 , CITY 'Paris' } ,
…………………………………………….
TUPLE { SNO 'S5' , SNAME 'Adams' ,
STATUS 30 , CITY 'Athens' } } ;
Expression on RHS is a relation literal
/* could use INSERT, of course */
Similarly for relvars P and SP
Copyright C. J. Date 2013

16. ASIDE :
In practice, base relvars are typically defined and “populated” (i.e., assigned their initial values) by a specially privileged user called the database administrator (DBA), using some kind of load utility
DBA is responsible for creating the database in the first place
… also for many other things, beyond the scope of this
presentation
Copyright C. J. Date 2013

17. RECALL : Types: INTEGER, array of INTEGERs, CHAR
Variables: i, n, sum, A
Assignment: “:=” ... for updating variables
Literals: 0, 1, 'The sum is '
Values: Denoted by expressions /* possibly literals or variable refs */ “Read-only” operators: “+” … for deriving “new” values from “old” Comparison operators: “<” ... /* special case of previous */
All of these concepts are directly relevant to databases!
Copyright C. J. Date 2013

18. SO FAR WE’VE SEEN : Types:
INTEGER, CHAR, RELATION { … } … also UDTs ...
(also note that attributes have types, too)
Variables: S, P, SP
Assignment: Relational assignment
(also INSERT, DELETE, UPDATE)
Literals: 'S1', 'Smith', 20, 'London', RELATION { … }
Values: Current values of S, P, SP (as well as literals)
“Read-only” operators (inc. comparisons): Still to be discussed
Copyright C. J. Date 2013

19. EXERCISES :
Consider:
VAR P BASE RELATION { PNO CHAR , PNAME , COLOR CHAR ,
WEIGHT RATIONAL , CITY CHAR }
KEY { PNO } ;
If attribute order were significant, how many different “parts relvars” could be defined?
Note the attribute naming discipline: e.g., part number attributes in relvars P and SP both have the same name PNO (instead of, say, PNO in one relvar and PNUM in the other) ... Is this a good idea?
Copyright C. J. Date 2013