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 :
An integrity constraint is, loosely, a boolean expression that must evaluate to TRUE
Any attempt to update the DB in such a way as to cause some constraint to evaluate to FALSE must fail …
… and, in the relational model, fail IMMEDIATELY !!!
/* this is The Golden Rule */
We’ve already talked about key and foreign key constraints, but constraints of arbitrary complexity are possible, and do indeed occur in practice (“business rules”) ... and they’re IMPORTANT!
Copyright C. J. Date 2013

3. EXAMPLES : 1. Supplier status values must be in the range 1 to 100
inclusive:
CONSTRAINT CX1
IS_EMPTY ( S WHERE STATUS < 1 OR STATUS > 100 ) ;
Or:
CONSTRAINT CX1 AND ( S , STATUS ≥ 1 AND STATUS ≤ 100 ) ;
Note: AND here could reasonably be pronounced “for all”
Copyright C. J. Date 2013

4. 2. Suppliers in London must have status 20:
CONSTRAINT CX2
IS_EMPTY ( S WHERE CITY = 'London' AND STATUS  20 ) ;
Or:
CONSTRAINT CX2 AND ( S , CITY  'London' OR STATUS = 20 ) ;
Copyright C. J. Date 2013

5. 3. Supplier numbers must be unique:
CONSTRAINT CX3 COUNT ( S ) = COUNT ( S { SNO } ) ;
In practice would use KEY shorthand /* see earlier */
Copyright C. J. Date 2013

6. 4. Suppliers with status less than 20 aren’t allowed to
supply part P6:
CONSTRAINT CX4 IS_EMPTY
( ( S JOIN SP ) WHERE STATUS < 20 AND PNO = 'P6' ) ;
/* multirelvar constraint */
/* checking in SQL would probably be DEFERRED ...
violates Golden Rule !!! */
Copyright C. J. Date 2013

7. 5. Every supplier number in SP must also appear in S:
CONSTRAINT CX5 SP { SNO }  S { SNO } ;
Foreign key constraint from SP to S
In practice would use FOREIGN KEY shorthand
Copyright C. J. Date 2013

8. (Very important!) WAY OF THINKING ABOUT RELVARS :
Heading corresponds to a predicate (truth valued function): e.g.,
Supplier SNO is under contract, is named SNAME, has
status STATUS, and is located in city CITY
Parameters (SNO, SNAME, STATUS, CITY in the example)
stand for values of the relevant types
Tuples represent true propositions (“instantiations” of the predicate that evaluate to TRUE), obtained by substituting arguments for the parameters: e.g.,
Supplier S1 is under contract, is named Smith, has status 20, and is located in city London
Copyright C. J. Date 2013

9. THUS : Every relvar has an associated relvar predicate (or meaning or
intended interpretation or intension)
If relvar R has predicate P, then every tuple t in R at time x represents proposition p, derived by invoking (or instantiating) P at time x with t’s attribute values as arguments
Body of R at time x is extension of P at time x
The Closed World Assumption: Relvar R contains, at any given time, all and only the tuples that represent true propositions (true instantiations of the predicate for R) at the time in question
Loosely:
Everything the DB says (or implies) is true,
everything else is false
Copyright C. J. Date 2013

10. RELATIONS are (true) statements about those things!
RELATIONS vs. TYPES :
TYPES are sets of things we can talk about;
RELATIONS are (true) statements about those things!
Note three very important corollaries ...
Copyright C. J. Date 2013

11. 1. Types and relations are both NECESSARY
They’re not the same thing
They’re SUFFICIENT (as well as necessary)*
A DB (plus its operators) is a logical system !!!
This was Codd’s great insight ... and it’s why RM is rock solid, and “right,” and will endure ... and why other “data models” are just not in the same ballpark
* Need relvars too for changes over time
Copyright C. J. Date 2013

12. PREDICATES vs. CONSTRAINTS :
Relvar predicate for R is “intended interpretation” for R … but it (and corresponding propositions) aren’t and can’t be understood by the system
System can’t know what it means for a “supplier” to
“be located” somewhere, etc.—that’s interpretation
System can’t know a priori whether what the user tells
it is true!—can only check the integrity constraints ... If OK, system accepts user assertion as true from this point forward
System can’t enforce truth, only consistency !!!
Copyright C. J. Date 2013

13. Correct implies consistent
Converse not true
Inconsistent implies incorrect
DB is correct if and only if it fully reflects the true state of affairs in the real world ... but the best the system
can do is ensure the DB is consistent (= satisfies all known integrity constraints)
Copyright C. J. Date 2013

14. EXERCISES : Give (plausible) predicates for relvars S, P, and SP.
Which operations have the potential to violate constraints CX1-CX5 ?
CX1: Status values must be in the range 1 to 100 inclusive CX2: Suppliers in London must have status 20
CX3: Supplier numbers must be unique
CX4: Suppliers with status less than 20 aren’t allowed to supply P6 CX5: Every supplier number in SP must also appear in S
Copyright C. J. Date 2013