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. THE SUPPLIERS-AND-PARTS DATABASE :
SNO
SNAME
STATUS
CITY S1
Smith 20
London S2
Jones 10
Paris S3
Blake 30 S4
Clark S5
Adams
Athens
SNO
PNO
QTY S1 P1
300 P2
200 P3
400 P4 P5
100 P6 S2 S3 S4 S SP
PNO
PNAME
COLOR
WEIGHT
CITY P1
Nut
Red
12.0
London P2
Bolt
Green
17.0
Paris P3
Screw
Blue
Oslo P4
14.0 P5
Cam P6
Cog
19.0 P
Copyright C. J. Date 2013

3. “DATA LOOKS RELATIONAL” :
The suppliers-and-parts DB contains three relations
A relation is a mathematical construct and has a precise and formal definition—but it can be thought of, and depicted, as a certain kind of table
Every relation has a heading and a body
Heading = set of attributes /* “columns” */
Body = set of tuples /* “rows” */ Note the terminology!
Copyright C. J. Date 2013

4. ATTRIBUTES :
Every attribute is declared to be of some type aka “domain”
/* typically not shown in pictures of relations, though */
E.g., for suppliers, we might have:
SNO :
SNAME :
SNO NAME
/* UDT - supplier numbers */
/* UDT - names */
STATUS :
INTEGER
/* system defined */
CITY :
CHAR
But for simplicity I’ll assume the only types we have to deal with are all system defined … In particular, I’ll assume SNO and SNAME are both of type CHAR
No. of attributes in heading = degree … If degree = n, relation is n-ary (unary, binary, ternary, …)
Copyright C. J. Date 2013

5. TUPLES : Every tuple in the body of a given relation conforms to the
heading of that relation
E.g., every tuple in body of S has:
SNO SNAME STATUS CITY
: value of type CHAR
: value of type INTEGER
No. of tuples in body = cardinality
If cardinality = 0, relation is empty
Copyright C. J. Date 2013

6. PROPERTIES OF RELATIONS :
Relations never contain duplicate tuples
/* formal reason: body is a mathematical set */
The tuples of a relation are unordered, top to bottom
The attributes of a relation are unordered, left to right
/* formal reason: heading is a mathematical set */
Relations are always normalized (i.e., in “1NF”)
/* which just means every tuple in the body conforms */
/* to the heading … */
Copyright C. J. Date 2013

7. RELATION VARIABLES :
S-SP-P picture shows the relation values existing in the database at a particular time … If we looked at a different time, we’d probably see different values
Thus S, SP, and P are really relation variables …
… which means they can be updated (i.e., assigned to)
For example:
Copyright C. J. Date 2013

8. current relation value
SNO
SNAME
STATUS
CITY S1
Smith 20
London S2
Jones 10
Paris S3
Blake 30 S
current relation value
relation
variable
Possible assignment:
S := S WHERE CITY ≠ 'Paris' ;
SNO
SNAME
STATUS
CITY S1
Smith 20
London
current
relation
value S
relation
variable
Copyright C. J. Date 2013

9. OR EQUIVALENTLY : current relation value relation variable
SNO
SNAME
STATUS
CITY S1
Smith 20
London S2
Jones 10
Paris S3
Blake 30 S
current relation value
relation
variable
Possible assignment:
DELETE S WHERE CITY = 'Paris' ;
SNO
SNAME
STATUS
CITY S1
Smith 20
London
current
relation
value S
relation
variable
Copyright C. J. Date 2013

10. IN OTHER WORDS :
In practice, DBMSs always support explicit DELETE, INSERT, and UPDATE operators on relation variables
/* examples to follow */ … but conceptually, at least, these are all just shorthand for certain relational assignments
Copyright C. J. Date 2013

11. FOR EXAMPLE : DELETE SP WHERE QTY < 150 ; INSERT SP RELATION
{ TUPLE { SNO 'S5' , PNO 'P1' , QTY 250 } ,
TUPLE { SNO 'S5' , PNO 'P3' , QTY 450 } } ;
UPDATE SP WHERE SNO = 'S2' :
{ QTY := 2 * QTY } ;
Copyright C. J. Date 2013

12. From this point forward: Relation means relation value
To repeat: In practice, DBMSs always support explicit DELETE, INSERT, and UPDATE operators on relation variables … but conceptually, at least, these are all just shorthand for certain relational assignments
DELETE, INSERT, and UPDATE (and “:=”) require a relation variable as their target … Read-only relational operators (e.g., restrict, project) operate on relation values
From this point forward:
Relation means relation value
Relvar means relation variable
Copyright C. J. Date 2013

13. EXERCISES : Which of the following statements are true?
Relations (and hence relvars) have no ordering to their
tuples
attributes
Relations (and hence relvars) never have any unnamed attributes
Relations (and hence relvars) never have two or more
attributes with the same name
Copyright C. J. Date 2013

14. EXERCISES (cont.) : Which of the following statements are true?
Relations (and hence relvars) never contain duplicate tuples
Relations (and hence relvars) are always in 1NF
The types over which relational attributes are defined can
be arbitrarily complex
Relations (and hence relvars) themselves have types
Copyright C. J. Date 2013