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

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

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

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

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

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

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

(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

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

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

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

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

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

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