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 RELATIONAL MODEL :
A (slightly abstract) externals specification for a DBMS …
Bertrand Russell:
Writing can be either readable or precise, but not at the same time
Here’s a precise definition of the relational model! *

The relational model consists of five components …
* And by the way: There’s only one …
Copyright C. J. Date 2013

3. THE RELATIONAL MODEL :
An open ended set of types (including in particular type
BOOLEAN)
A relation type generator and an intended interpretation for relations of types generated thereby
Facilities for defining relation variables of such generated relation types
A relational assignment operation for assigning relation
values to such relation variables
A relationally complete (but otherwise open ended) set of generic operators for deriving relation values from other relation values
Copyright C. J. Date 2013

4. 1. TYPES : Necessary because relations are defined over types …
But note carefully that the question of what types are supported is independent of the question of support for the relational model as such
The relational model has NEVER prescribed a specific set of types ... /* popular misconception here! */
… with one exception (BOOLEAN), to be explained
… and one proscription, too: DB relations aren’t allowed to have any pointer valued attributes
Copyright C. J. Date 2013

5. User or system defined (“built in”)
Hence, a means must be available for users to define their own types (set of types is “open ended”)
Hence, a means must be available for users to define their
own operators (types without operators are useless)
Only required type is BOOLEAN (the most fundamental type of all), but a real system will surely support integers, strings, etc., as built in types as well
With support for “=” in particular /* for every type */
… with prescribed semantics !!!
Copyright C. J. Date 2013

6. 2. RELATION TYPE GENERATOR :
Cf. “array” type generator in programming languages
Allows users to specify individual relation types: e.g.,
RELATION { ENO CHAR , SALARY MONEY }
Hence, can define relation variables: e.g.,
VAR EMP BASE RELATION { ENO CHAR , SALARY MONEY }
KEY { ENO } ;
“Intended interpretation” for a given relation is basically the business of predicates and propositions
Copyright C. J. Date 2013

7. Associated with given relation type is a way of specifying literal relations of that type … E.g.:
RELATION { TUPLE { ENO 'E4' , SALARY MONEY ( ) } ,
TUPLE { ENO 'E7' , SALARY MONEY ( ) } , } …
Relational inclusion “” (etc.) as well as equality (“=”)
Copyright C. J. Date 2013

8. 3. RELATION VARIABLES :
Facilities for defining relvars must be available (of course), as already noted
Relvars are the only kinds of variables allowed inside a relational database—The Information Principle
Copyright C. J. Date 2013

9. 4. RELATIONAL ASSIGNMENT :
Variables are updatable by definition
Hence, every kind of variable is subject to assignment, and relation variables are no exception
INSERT, DELETE, and UPDATE shorthands (also D_INSERT and I_DELETE) are legal and indeed useful, but strictly speaking they’re only shorthands
Assignment must abide by The Assignment Principle
and The Golden Rule
/* see next page */
Copyright C. J. Date 2013

10. The Assignment Principle:
The Assignment Principle: After assignment of v to V, the comparison v = V must evaluate to TRUE
The Golden Rule: All integrity constraints must be satisfied at statement boundaries
Copyright C. J. Date 2013

11. 5. RELATIONAL OPERATORS :
Recap: A relationally complete (but otherwise open ended) set of generic operators for deriving relation values from other relation values
I.e., relational algebra (or calculus, or equivalent)
Relationally complete: Loosely, all possible queries
can be expressed
Implies closure
/* i.e., expressions can be nested */
Generic: Loosely, operators apply to all possible
relations
Copyright C. J. Date 2013

12. Operators allow writing of expressions that can be used for (e.g.):
Defining sets of tuples to be retrieved
Defining sets of tuples to be inserted / deleted / updated /
assigned
Defining security and integrity constraints /* see next page */
Defining views
/* see next page but one */
Basis for further theoretical investigations
Copyright C. J. Date 2013

13. ASIDE : SECURITY Examples: AUTHORITY SX1
GRANT RETRIEVE { SNO , SNAME } , DELETE ON S
WHERE CITY = 'London'
TO Jim , Fred , Mary ;
AUTHORITY SX2
GRANT ON
RETRIEVE , S
UPDATE
{ STATUS , CITY } TO
Dan , Misha ;
Copyright C. J. Date 2013

14. ASIDE : VIEWS Consider query “Get suppliers in London”:
S WHERE CITY = 'London'
Suppose this query is used repeatedly ... Can simplify matters by defining a view (“canned query”):
VAR LS VIRTUAL ( S WHERE CITY = 'London' ) ;
Query becomes: LS
Views work because of closure!
Copyright C. J. Date 2013

15. RECALL : suppliers, parts, and shipments (“logical DB”)
views provide
an extra layer
DB management system (DBMS)
data as physically stored (“physical DB”)
Copyright C. J. Date 2013

16. THE RELATIONAL MODEL : Information In Formation
An open ended set of types (including in particular type
BOOLEAN)
A relation type generator and an intended interpretation for relations of types generated thereby
Facilities for defining relation variables of such generated relation types
A relational assignment operation for assigning relation
values to such relation variables
A relationally complete (but otherwise open ended) set of generic operators for deriving relation values from other relation values
Copyright C. J. Date 2013