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

OK ... Now we can start using the DB for real work! To be specific, we can issue “queries” (retrieval requests), using operators of the relational algebra /* see next page */ Copyright C. J. Date 2013

CODD’S ORIGINAL RELATIONAL ALGEBRA : AN OVERVIEW product restrict project a b c x y a x y b c intersect union difference (natural) join a1 b1 c1 a2 b2 c2 a3 b3 c3 a1 a2 a3 b1 b1 b2 c1 c1 c2 Copyright C. J. Date 2013

ASIDE : Actually “Codd’s original algebra” included another operator, viz. relational division Deliberately omitted here, because: There’s a better approach to “division style” queries, using image relations (see later) Relational division didn’t solve the problem anyway Copyright C. J. Date 2013

Now we can start using the DB for real work! To be specific, we can issue “queries” (retrieval requests), using operators of the relational algebra Important: Operators are all READ-ONLY and SET LEVEL Important: Relations form a CLOSED SYSTEM under the operators of the algebra !!! I.e., result of every relational operation is ANOTHER RELATION … so we can write nested relational expressions /* analogy with arithmetic */ Copyright C. J. Date 2013

RESTRICT : Get part information for parts whose weight is less than 12.5: P WHERE WEIGHT < 12.5 Result has same heading as P and body = tuples of P for which specified restriction condition evaluates to TRUE: PNO PNAME COLOR WEIGHT CITY P1 P5 Nut Cam Red Blue 12.0 London Paris Copyright C. J. Date 2013

PROJECT : For each part, get part number, color, and city: P { PNO , COLOR , CITY } or P { ALL BUT PNAME , WEIGHT } Result has heading as specified and body = corresponding (sub)tuples of P: PNO COLOR CITY P1 Red London P2 Green Paris P3 Blue Oslo P4 P5 P6 Copyright C. J. Date 2013

ASIDE : Let A be a set; then every subset of A is a set. It follows that: Every subset of a tuple is a tuple (“every subtuple is a tuple”) Every subset of a heading is a heading Every subset of a body is a body /* see restriction */ Copyright C. J. Date 2013

PROJECT (cont.) : What part color / city combinations currently exist? P { COLOR , CITY } or P { ALL BUT PNO , PNAME , WEIGHT } Result has heading as specified and body = corresponding (sub)tuples of P: “Duplicates eliminated” !!! (Duplicate elimination occurred in the previous example too, of course, but had no effect) COLOR CITY Red London Green Paris Blue Oslo Copyright C. J. Date 2013

CLOSURE : AN EXAMPLE Get part number, color, and city for parts whose weight is less than 12.5: ( P WHERE WEIGHT < 12.5 ) { PNO , COLOR , CITY } Note use of parentheses (so restriction done first, then projection) /* attribute order insignificant */ PNO CITY COLOR P1 P5 London Paris Red Blue Copyright C. J. Date 2013

RESTRICT AND PROJECT : Tutorial D syntax (restrict and project): rx WHERE bx boolean expression that can be evaluated for any tuple t of r by examining t in isolation — actually Tutorial D allows bx to be arbitrarily complex /* so does SQL */ relational expression denoting relation r rx { [ ALL BUT ] attribute name commalist } relational expression subset of heading of r denoting relation r Copyright C. J. Date 2013

S { CITY } UNION P { CITY } CITY Operands must be of same type (i.e., have same heading); result is of same type also Get cities such that at least one supplier or at least one part is located in that city: S { CITY } UNION P { CITY } CITY /* note appeal to closure */ Athens London Oslo Paris “Duplicates eliminated” !!! Copyright C. J. Date 2013

UNION (cont.) : Operands must be of same type (i.e., have same heading); result is of same type also Suppose parts have extra attribute STATUS, of type INTEGER Get status / city pairs such that at least one supplier or part has that combination: P { STATUS , CITY } UNION S { CITY , STATUS } /* attribute order insignificant */ /* operand order ditto */ Copyright C. J. Date 2013

INTERSECT : Operands must be of same type (i.e., have same heading); result is of same type also Get cities such that at least one supplier and at least one part are both located in that city: S { CITY } INTERSECT P { CITY } CITY London Paris “Duplicates eliminated” ??? Copyright C. J. Date 2013

INTERSECT (cont.) : Operands must be of same type (i.e., have same heading); result is of same type also Suppose parts have extra attribute STATUS, of type INTEGER Get status / city pairs such that at least one supplier and at least one part both have that combination: S { STATUS , CITY } INTERSECT P { CITY , STATUS } /* attribute order insignificant */ /* operand order ditto */ Copyright C. J. Date 2013

DIFFERENCE : Operands must be of same type (i.e., have same heading); result is of same type also Get cities such that at least one supplier is located in that city and no part is: S { CITY } MINUS P { CITY } CITY Athens “Duplicates eliminated” ??? Copyright C. J. Date 2013

DIFFERENCE (cont.) : Operands must be of same type (i.e., have same heading); result is of same type also Suppose parts have extra attribute STATUS, of type INTEGER Get status / city pairs such that at least one supplier has that combination and no part does: S { STATUS , CITY } MINUS P { CITY , STATUS } /* attribute order insignificant */ Copyright C. J. Date 2013

UNION, INTERSECT, MINUS : Tutorial D syntax (UNION, INTERSECT, DIFFERENCE): rx op ry UNION or INTERSECT or MINUS relational expressions denoting relations of same type Alternatively (“n-adic” version): op { relational expression commalist } UNION or INTERSECT (not MINUS!) Copyright C. J. Date 2013

UNION bis : Operands must be of same type (i.e., same attribute-name / type-name pairs) …So what about: Get names such that at least one supplier or at least one part has that name: /* assume this query makes sense !!! */ Must rename at least one of the two “name” attributes before we can do the UNION … E.g., ( ( S RENAME { SNAME AS NAME } ) { NAME } ) UNION ( ( P RENAME { PNAME AS NAME } ) { NAME } ) /* I’ve renamed both attributes for symmetry … overall result heading has single attribute, called NAME, of type CHAR */ Copyright C. J. Date 2013

RENAME : S RENAME { CITY AS SCITY } Result identical to current value of S except for renaming SNO SNAME STATUS SCITY S1 Smith 20 London S2 Jones 10 Paris S3 Blake 30 S4 Clark S5 Adams Athens Needed primarily as a preliminary to either UNION or JOIN Tutorial D syntax (RENAME): rx RENAME { renaming commalist } Copyright C. J. Date 2013

EXERCISES : 1. We have a formal reason for prohibiting duplicate tuples in relations (what is it?), but can you think of a pragmatic reason? Copyright C. J. Date 2013

EXERCISES (cont.) : What do the following expressions denote? You can assume that projection has higher precedence than the other relational operators. P { PNO } MINUS ( SP WHERE SNO = 'S2' ) { PNO } ( S { CITY } INTERSECT P { CITY } ) UNION P { CITY } S { SNO } MINUS ( S { SNO } MINUS SP { SNO } ) SP MINUS SP S INTERSECT S ( S WHERE CITY = 'Paris' ) UNION ( S WHERE STATUS = 20 ) Copyright C. J. Date 2013

EXERCISES (cont.) : Write Tutorial D expressions for the following queries: Get all shipments Get part numbers for parts supplied by supplier S2 Get suppliers with status in the range 15 to 25 inclusive Get supplier numbers for suppliers with a status lower than that of supplier S2 Get part numbers for parts supplied by all suppliers in Paris Copyright C. J. Date 2013

EXERCISES (cont.) : You really ought to try some queries of your own ... Copyright C. J. Date 2013

CODD’S ORIGINAL RELATIONAL ALGEBRA : AN OVERVIEW product restrict project a b c x y a x y b c intersect union difference (natural) join a1 b1 c1 a2 b2 c2 a3 b3 c3 a1 a2 a3 b1 b1 b2 c1 c1 c2 Copyright C. J. Date 2013

(Natural) JOIN : EXAMPLE For each shipment, get part number and quantity and corresponding supplier information: SP JOIN S SNO PNO QTY SNAME STATUS CITY S1 P1 300 Smith 20 London P2 200 .. ... ..... S4 P5 400 Clark 20 London Copyright C. J. Date 2013

For each shipment, get part number and quantity and corresponding supplier information: SP JOIN S (Important!): Operands must be JOINABLE ... Definition: Relations are joinable if and only if attributes with the same name are of the same type I.e., set theory union of headings is a legal heading page ... concept relevant to other ops as well as join */ /* see next Copyright C. J. Date 2013

“Duplicates eliminated”! ... by definition Let A and B be sets. Then their (set theory) union is the set of all elements x such that x appears in A or B or both. “Duplicates eliminated”! ... by definition Copyright C. J. Date 2013

JOIN (cont.) : For each shipment, get part number and quantity and corresponding supplier information: SP JOIN S Result heading = set theory union of headings of SP and S ... Result body = set of all tuples t where t is the set theory union of a tuple from SP and a tuple from S SNO PNO QTY SNAME STATUS CITY S1 P1 300 Smith 20 London P2 200 .. ... ..... S4 P5 400 Clark 20 London Copyright C. J. Date 2013

“Duplicates eliminated”! ... by definition In the definition of join: Let A and B be sets. Then their (set theory) union is the set of all elements x such that x appears in A or B or both. “Duplicates eliminated”! ... by definition In the definition of join: “Set theory union of headings”: OK, headings are definitely sets “Set theory union of tuples”: Yes, tuples are sets too! Copyright C. J. Date 2013

ANOTHER EXAMPLE : Get part and supplier information for parts and suppliers that are colocated (i.e., have the same city): P JOIN S Result heading = set theory union of headings of P and S ... Result body = set of all tuples t where t is the set theory union of a tuple from P and a tuple from S PNO PNAME COLOR WEIGHT CITY SNO SNAME STATUS P1 Nut Red 12.0 London S1 Smith 20 .. ... .... ...... ..... P6 Cog Red 19.0 London S4 Clark 20 Copyright C. J. Date 2013

JOIN : Tutorial D syntax (JOIN): rx JOIN ry Note: The join is always “on the basis of common attributes” ... thus, attribute renaming might sometimes be required Alternatively (“n-adic JOIN”): JOIN { relational expression commalist } Copyright C. J. Date 2013

(Cartesian) PRODUCT : Get all current supplier number / part number pairs: S { SNO } TIMES P { PNO } Result heading = set theory union of headings of S{SNO} and P{PNO} ... Result body = set of all tuples t where t is the set theory union of a tuple from S{SNO} and a tuple from P{PNO} … Just as for JOIN, in fact, except that for TIMES the input relations must have no attribute names in common TIMES is a special case of JOIN !!! Copyright C. J. Date 2013

... and set theory union of headings is indeed a legal heading Recall: Relations are joinable if and only if attributes with the same name are of the same type … So relations with no common attribute names are certainly joinable !!! ... /* certainly there aren’t any attributes with the same name that aren’t of the same type */ ... and set theory union of headings is indeed a legal heading rx TIMES ry Alternatively (“n-adic TIMES”): TIMES { relational expression commalist } Copyright C. J. Date 2013

ANOTHER EXAMPLE : Get SNO / PNO pairs such that supplier SNO doesn’t supply part PNO: ( S { SNO } TIMES P { PNO } ) MINUS ( SP { SNO , PNO } ) Or: ( S { SNO } JOIN P { PNO } ) /* TIMES is supported primarily for psychological reasons */ Copyright C. J. Date 2013

WHAT’S MORE : INTERSECT is a special case of JOIN as well !!! Recall: Get cities such that at least one supplier and at least one part are both located in that city: S { CITY } INTERSECT P { CITY } CITY could be JOIN London Paris /* INTERSECT is supported primarily for psychological reasons */ Copyright C. J. Date 2013

WHICH OPERATORS ARE PRIMITIVE ??? So INTERSECT and TIMES can be defined in terms of join ... i.e., not all operators are primitive Difference between primitive and useful !!! One possible primitive set: restrict project join union difference /* could replace by semidifference … see later */ But what about rename? /* again, see later */ Aside: In fact it’s possible to define a version of the algebra that has just two primitives! Copyright C. J. Date 2013

RELATIONAL COMPARISONS* : Must be able to test relations for equality, of course ... E.g.: S { CITY } = P { CITY } /* FALSE */ Other useful comparison ops:      relational inclusion Useful shorthands: IS_EMPTY ( rx ) IS_NOT_EMPTY ( rx ) * Are these algebraic operators as such ??? Copyright C. J. Date 2013

NOW I CAN EXPLAIN … R := rx /* relational assignment—generic form */ “INSERT R rx” is shorthand for: R := R UNION rx But what about “inserting a tuple that already exists” ??? ... “D_INSERT R rx” is shorthand for: R := R D_UNION rx “disjoint union” Copyright C. J. Date 2013

“DELETE R rx” is shorthand for: R := R MINUS rx But what about “deleting a tuple that doesn’t exist” ??? ... “I_DELETE R rx” is shorthand for: R := R I_MINUS rx “included minus” “DELETE [ R ] R WHERE bx” is shorthand for: R := R WHERE NOT ( bx ) Copyright C. J. Date 2013 page 100

“UPDATE R WHERE bx : { ... }” is shorthand too … attribute assignment commalist … but the details are a little complicated, so I’ll skip them Copyright C. J. Date 2013

EXERCISES : What do the following expressions denote? You can assume that projection has higher precedence than the other relational operators. ( S { SNO , CITY } JOIN P { PNO , CITY } ) { PNO , SNO } JOIN { S , SP , P } JOIN { ( S RENAME { CITY AS SC } ) { SC } , ( P RENAME { CITY AS PC } ) { PC } } SP { SNO } I_MINUS S { SNO } ( S WHERE STATUS = 20 ) { CITY } D_UNION ( P WHERE COLOR = 'Blue' ) { CITY } Copyright C. J. Date 2013

EXERCISES (cont.) : Write Tutorial D expressions for the following: Get part numbers for parts supplied by a supplier in London Get part numbers for parts not supplied by any supplier in London Get pairs of part numbers such that some supplier supplies both of the indicated parts Copyright C. J. Date 2013

EXERCISES (cont.) : Again, you really ought to try some queries of your own ... Copyright C. J. Date 2013