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 : 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

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

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

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

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

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

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

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

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

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

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

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

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

“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

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

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

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

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