File: Notes1.

doc
Printed at: 15:37 on Friday, 7 March, 2008

Introduction to Relational Databases

(notes for introductory lecture)

1. Cover slide
These notes are adapted from the ones given to Hugh Darwen's students at Warwick University.
Paragraphs in italics, like this one, are ones I have added for the benefit of M359 students, mostly
addressing slight mismatches between my Warwick course and M359.
Introductory Remarks
In Block 2 of M359, Relational Databases: Theory and Practice, we study the theory upon which
relational databases are based. Or perhaps it would be better to say, “should be based”, or “were
intended to be based (by its original proponent)”. We will also study a database language that is
firmly based on this theory and in so doing take note of some general principles of good computer
language design.
Block 3 of M359 introduces you to the “state of the art” of relational database support in the
industry. This takes the form of SQL, the language that was dubbed “intergalactic dataspeak” by
database guru Michael Stonebraker in the 1980s (since when its use and its number of
implementations have grown enormously). You are strongly encouraged to compare and contrast
the theory of Block 2 and the practice of SQL!
Section 1: Introduction
Section 1 (i.e., this first lecture) gives a very broad overview of
• what a database is
• what a relational database is
• what a database management system (DBMS) is
• what a DBMS does
• how a relational DBMS does what a DBMS does
We start to familiarise ourselves with terminology and notation used on this course.
We get a brief introduction to each topic that will be considered in more detail in later sections of
the course (this remark applies reasonably well to M359 as well as the Warwick course).

2. Some Preliminaries
Note that the word “database” had not been coined when Ted Codd, actually a hardware specialist
working on for IBM on its mainframe architecture at the time, did this important work for which he
was later a recipient of the Turing Award. Codd died in 2003.
What follows is only partially relevant to M359 students. On M359 we use our own notation for
our study of the theory in Block 2. It is very similar to Tutorial D and for many operations it is
identical.
Tutorial D (which is always written that way, in bold face) was invented in the late 1990s by Hugh
Darwen and C.J. (Chris) Date for the very purpose that its name suggests—teaching, as opposed to
commercial use. It is used for examples and exercises in several books coauthored by them and in
particular in the two books by Chris Date that are recommended reading for this course. The
official definition of the language is given in their book, “Databases, Types, and The Relational
Model: The Third Manifesto” (Addison-Wesley, 2005, ISBN 0-321-39942-0), but this book is not
suitable for an introductory course of this nature and in any case we will not use all of the language.

M359: Notes for introductory lecture. — Page 1 of 8

Rel has been made available to the academic community at large as an Open Source product by its
author, Dave Voorhis of the University of Derby. (It is a happy coincidence that Rel’s author is
located not only in the same country as our university, but also quite nearby!) Rel is not yet a
complete implementation of Tutorial D, but it does support nearly all of the components needed for
CS252 (and M359, Block 2!).

3. What Is a Database?
The organised, machine-readable collection of symbols is what you “see” if you “look at” a
database at a particular point in time. It is to be interpreted as a true account of the enterprise at that
point in time. Of course it might happen to be incorrect, incomplete or inaccurate, so perhaps it is
better to say “believed to be true” rather than just “true”.
The alternative view of a database as a collection of variables reflects the fact that the account of the
enterprise has to change from time to time, depending on the frequency of change in the details we
choose to include in that account.
The suitability of a particular kind of database (such as “relational”, or “object-oriented”) might
depend to some extent on the requirements of its user(s). When E.F. Codd developed his theory of
relational databases (first published in 1969), he sought to minimise that extent. Thus, when
designing a relational database we should be able to focus on the level of detail of the account
without having to anticipate the uses to which it will be put. That is perhaps the distinguishing
feature of the relational approach, and you should bear it in mind as we explore some of its
ramifications on this course.

4. “Organised Collection of Symbols”

Can you guess what this tabular arrangement of symbols might be trying to tell us? What might it
mean, for symbols to appear in the same row? In the same column? In what way might the
meaning of the symbols in the very first row differ from the meaning of those below them?
Do you intuitively guess that the symbols below the first row in the first column are all student
identifiers, those in the second column names of students, and those in the third course identifiers?
Do you guess that student S1’s name is Anne? And that Anne is enrolled on courses C1 and C2?
And that Cindy is enrolled on neither of those two courses? If so, what features of the organisation
of the symbols led you to those guesses?
Remember those features. In an informal way they form the foundation of relational theory. Each
of them has a formal counterpart in relational theory, and those formal counterparts are the only
constituents of the basic structure of a relational database.

5. “To Be Interpreted as a True Account”

This just confirms that your guesses were correct.
An important thing to note on this slide is that only certain symbols from the sentence in quotes
appear in the table—S1, C1, and Anne. None of the other words appear in the table. The symbols
in the top row of the table (column headings?) might help us to guess “student”, “named”, and
“course”, but nothing in the table hints at “enrolled”. And even if those assumed column headings
had been A, B and C, or X, Y and Z, the given interpretation might still be the intended one.
Another important point is that the interpretation takes the form of a declarative sentence of which
it can be said, “that is true” or “that is false”. Such declarative sentences are what logicians call
propositions.

Page 2 of 8 — M359: Notes for introductory lecture.

Now, we can take the sentence shown on the slide and replace each of S1, Anne, and C1 by the
symbol at the top of the column in each case. That would give “Student StudentId, named Name, is
enrolled on course CourseId”. This is also a declarative sentence, but not one of which it can be
said, “that is true” or “that is false”, because StudentId doesn’t designate a particular student
identifier, nor Name a particular name, nor CourseId a particular course identifier. Declarative
sentences with “placeholders” such as StudentId, Name and CourseId in them are what logicians
call predicates.
If you substitute a designator for each placeholder in a predicate, you obtain a proposition.
By thus interpreting each row below the column headings in the table, we obtain a set of
propositions that constitutes what we believe to be a true account of (part of) our enterprise.

6. “Collection of Variables”
Under our agreed interpretation, we can conclude that the following sentences are all true:
Student S1, named Anne, is enrolled on course C1.
Student S1, named Anne, is enrolled on course C2.
Student S2, named Boris, is enrolled on course C1.
Student S3, named Cindy, is enrolled on course C3.
Student S4, named Devinder, is enrolled on course C1.
Notice that in English we can join all these sentences together to form a single sentence, using
conjunctions like “and”, “or”, “because” and so on. If we join them using “and” in particular, we
get a single sentence that is logically equivalent to the given set of sentences in the sense that it is
true if each one of them is true (and false if any one of them is false). A database, then, can be
thought of as a representation of an account of the enterprise expressed as a single sentence!
We might also be able to conclude that the following sentences (for example) are false:
Student S2, named Boris, is enrolled on course C2.
Student S2, named Beth, is enrolled on course C1.
Whenever the variable is updated, the set of true sentences represented by its value changes in some
way. This usually reflects perceived changes in the enterprise, affecting our beliefs about it and
therefore our account of it.
Note that if the variable were updated by the addition or removal of a column, that would not
necessarily reflect a perceived change in the enterprise. Rather, it would reflect a decision to
change the structure of the variable, thereby also changing the form of our account under the
interpretation of that structure.

7. What Is a Relational Database?

Happily, the visual representation we have been using thus far is suited particularly well to
relational databases. So much so that many people use the word table as an alternative to relation.
Relation is formal term in mathematics, in particular, in the logical foundation of mathematics.
Relational database theory is built around the concept of a relation. The theory includes, and we
will study:
The anatomy of a relation.
Relational algebra: a set of mathematical operators that operate on relations.

M359: Notes for introductory lecture. — Page 3 of 8

Relation variables: their creation and destruction, and operators for updating them. M359 doesn't
use the term "variable" in this context.
Relational comparison operators, allowing consistency rules to be expressed as constraints
(commonly called integrity constraints). M359 doesn't teach relational comparison operators but
it does teach the equally effective is empty operator (which has a counterpart in Tutorial D too).
And we will see how these, and other constructs, can form the basis of a database language
(specifically, a relational database language).

8. Relation  Table
The title of this slide is trying to say that the terms “relation” and “table” are not synonymous. A
table is one way of denoting a particular relation, but several different tables can all denote the same
relation, because we can change the left-to-right order in which the columns are shown and/or the
top-to-bottom order in which the rows are shown and yet still be depicting (denoting) the same
relation.
What does it mean, to say that the order of columns and the order of rows doesn’t matter? We will
find out the answer to this question when we later study the typical operators that are defined for
operating on relations (e.g., to compute results of queries against the database) and relation
variables (e.g., to update the database). None of these operators will depend on the notion of some
row or some column being the first or last, or immediately before or after some other row.

9. Anatomy of a Relation
Because of the distinction I have noted between the terms “relation” and “table”, we prefer not to
use the terminology of tables for the anatomical parts of a relation. We use instead the terms
proposed by E.F. Codd, the researcher who first proposed relational theory as a basis for database
technology, in 1969.
Try to get used to these terms. You might not find them very intuitive. Their counterparts in the
tabular representation might help:
relation = table
(n-)tuple = row
attribute = column
Also (repeating what is shown in the slide):
The degree is the number of attributes.
The cardinality is the number of tuples.
The heading is the set of attributes (note set, because the attributes are not ordered in any
way and no attribute appears more than once).
The body is the set of tuples (again, note set—the tuples are not ordered and no tuple
appears more than once).
An attribute has an attribute name, and no two have the same name.
Each attribute has an attribute value in each tuple.

10. What Is a DBMS?

Before looking at the components we expect to find in a relational DBMS, we need to briefly
review what is expected of a DBMS in general.

Page 4 of 8 — M359: Notes for introductory lecture.

The term data sublanguage is sometimes used instead of database language. The “sub-” prefix
refers to the fact that application programs are sometimes written in some more general-purpose
programming language (the “host” language), in which the database language imperatives are
embedded in some prescribed style. Sometimes the embedding style is such that the embedded
statements are unrecognised by the host language compiler or interpreter, and some special
preprocessor is used to replace the embedded statements by, for example, CALL statements in the
host language.
Some people prefer to use the term “command” instead of “imperative”. The less appropriate
“statement” is also very commonly used, especially for specific kinds of imperative, such as the
CALL statement referred to above.
A query is an expression that, when evaluated, yields some result derived from the database.
Queries are what make databases useful. Note that a query is not an imperative. The DBMS might
support some kind of command to evaluate a given query and make the result available for access,
also using DBMS commands, by the application program. The application program might execute
such commands in order to display a result in tabular form in a window.

11. What Does a DBMS Do?

To amplify some of the terms used in this slide:
The requests take the form of imperatives written in the database language supported by the
DBMS.
The variables are the constituents of the database, like the ENROLMENT variable we looked at
earlier.
Constraints (sometimes called integrity constraints) are rules governing permissible values and
permissible combinations of values, of the variables. For example, it might be possible to tell the
DBMS that no student’s assessment score can be less than zero. A database that violates a
constraint is false, by definition. A database that satisfies all its constraints is said to be consistent,
even though it cannot in general be guaranteed to be true.
Authorisations are for security what constraints are for integrity. Some of the data in a database
might represent sensitive information whose accessibility is restricted to certain privileged users
only. Similarly, it might be desired to allow some users to access certain parts of the database
without also being able to update those parts.
Note the three parts of an authorisation: who, what, and to what. “Who” is a user of the database;
“what” is one of the operations that are defined for operating on the variables in the database; “to
what” is one of those variables.

12. Create and Destroy Variables

The example shown on this slide is not applicable in M359. RAS doesn't include language
constructs for creation and destruction of database variables, though we do learn a similar way of
writing a relation variable definition. Note that most of the literature, especially the older
literature, does not make the careful terminological distinction I make between a relation and a
relation variable. That includes both M359 and SQL! So in Block 2 the term relation does double
duty, just as the term table does in SQL.
In case the distinction is not clear to you, think of integers and integer variables. Examples of
numbers are 1, 2, -3 and so on. They are not subject to change. 1 always has been 1 and always
will be 1. But an integer variable, named X, say, declared as part of some computer program,
certainly is subject to change. The program might assign 1 to X at some point and later assign
X + 1 to X, in which case the value assigned to X changes from being the number 1 to being the

M359: Notes for introductory lecture. — Page 5 of 8

number 2. The same observation applies to variables like ENROLMENT except that the values
assigned to them are the composite values we call relations instead of the simple values we call
numbers.
The syntax shown on the slide is explained as follows:
VAR is a key word indicating that a variable is being created.
ENROLMENT is the variable’s name.
BASE, which can also be spelled REAL, is a key word indicating that the variable is to be part of
the database.
The text from RELATION to the closing brace specifies the declared type of the variable, meaning
that every value ever assigned to ENROLMENT must be a value of that type.
The declared type of enrolment is a relation type, indicated by the key word RELATION and a
heading specifcation. A heading specification consists of a list of attribute name/type pairs
(enclosed in braces), so that each attribute of the heading also has a declared type.
We will learn more about types in the next part of the course.
KEY indicates that the variable is subject to a certain kind of constraint, in this case declaring that
no two tuples in the relation assigned to ENROLMENT can ever have the same combination of
attribute values for StudentId and CourseId (i.e., we cannot enrol the same student on the same
course more than once, so to speak).
We will learn more about constraints in general and key constraints in particular later in the course.
Advance warning on current limitation in Rel:
The Tutorial D statement shown on this slide is not fully supported by Rel, for reasons to be
explained later. The capitalised words SID and CID need to be replaced in each case by the word
CHAR.

13. Take Note of Integrity Rules

Again the language shown on this slide is Tutorial D, not RAS. You will be learning how to declare
constraints in RAS, but unfortunately RAS does not have a counterpart for the simple example I use
on this slide to illustrate what we mean by a constraint. Look out for RAS's is empty construct
though, when you get to the point in the course where we study constraints.
CONSTRAINT is a key word indicating that a constraint is being declared.
MAX_ENROLMENTS is the name of the constraint.
COUNT (ENROLMENT) is a Tutorial D expression yielding the cardinality (see slide 9,
“Anatomy of a Relation”) of the current value of ENROLMENT.
COUNT(ENROLMENT)  20000 is a truth-valued expression yielding true if the cardinality is less
than or equal to 20000, otherwise yielding false.
A truth-value expression typically consists of one or more comparisons connected together by the
logical operators AND and OR.
The declaration tells the DBMS that the database is inconsistent if the value of
MAX_ENROLMENTS—that is, the value of the truth-valued expression on which it is defined—is
ever false, and that the DBMS is therefore to reject any attempt to update the database that, if
accepted, would bring about that situation.

Page 6 of 8 — M359: Notes for introductory lecture.

14. Take Note of Authorisations
Tutorial D doesn’t include any imperatives for creating and destroying permissions (and nor does
RAS), because security and authorisation, though important, is not specifically a relational database
issue. If Tutorial D did include such imperatives, we can reasonably expect them to look like those
shown here. Note the syntactic consistency with imperatives we have already seen: a key word
indicating the kind of thing being created or destroyed, followed by the name of the thing, followed
by the specification of the thing.
How do you rate the computer languages you are already acquainted with, for syntactic
consistency? When you learn SQL, watch out for syntactic inconsistencies!
In M359 we learn how authorizations are handled in SQLwatch out for the GRANT statement in
SQL.

15. Updates Variables

Again the examples are in Tutorial D even for my M359 students, because RAS doesn't support
updating. SQL has very similar operators to these, which you will learn in Block 3.
Informally, the first example deletes all the tuples for student S4 and means “student S4 is not
enrolled on any courses”. More formally, it assigns to the variable ENROLMENT the relation
resulting from the removal, from the current value of ENROLMENT, of every tuple in which the
value of the StudentId attribute is the student identifier S4, and the retention of every other tuple in
the current value of ENROLMENT.
Informally, the second example updates each tuple for student S1, changing its Name value to
‘Ann’. More formally, it assigns to the variable ENROLMENT the relation that is identical to the
current value in all respects except for the value for the attribute Name in the tuples whose
StudentId value is the student identifier S1, which is the string ‘Ann’ in each case. (I would have
written “except possibly” had I not known that the existing Name value in those tuples is ‘Anne’ in
each case, allowing for the fact that in some circumstances—when S1's name is already recorded as
'Ann'—no change takes place as a result of executing this imperative.)
Informally, the third example adds a tuple to ENROLMENT indicating that student S4, still called
Devinder, is now enrolled on course C1. More formally, it assigns to the variable ENROLMENT
the relation consisting of every tuple in the current value of ENROLMENT and every tuple (there is
only one) in the relation denoted by the expression following the word ENROLMENT.
The first example has no effect on the database in the case where the current value of
ENROLMENT has no tuples for student S4.
The second example has no effect on the database in the case where the current value of
ENROLMENT has no tuples for student S1.
The third example has no effect on the database in the case where the current value of
ENROLMENT already contains the tuple representing the enrolment of student S4, named
Devinder, on course C1. It also has no effect on the database if the cardinality of the current value
of ENROLMENT is 20,000 and the constraint MAX_ENROLMENTS is in effect.

16. Provides Results of Queries

Again this particular Tutorial D example is one that cannot be done in RAS. It doesn't matter for
now because I am not yet trying to teach you relational algebra. I'm just trying to give you a feel
for the kind of thing to expect when you come to Block 2.

M359: Notes for introductory lecture. — Page 7 of 8

SUMMARIZE is the key word identifying the Tutorial D operator of that name. This operator
operates on a given relation and yields a relation. The set of operators that operate on and yield
relations constitutes the relational algebra, which we will study in detail later in the course.
BY CourseId specifies that each distinct CourseId value appearing in the operand (ENROLMENT)
is to yield a single tuple in the result, having that value for its CourseId attribute.
ADD specifies that the result is to have some further attributes in addition to CourseId.
COUNT ( ) AS No_of_Students specifies that one of those additional attributes (the only one, as it
happens) is named No_of_students and its value in each tuple is the number of tuples in
ENROLMENT that match the result tuple on the “BY” value (CourseId).

17. EXERCISE
Consider this table:

A B A
1 2 3
4 5
6 7 8
9 9 ?
1 2 3
Give three reasons why it cannot be representing a relation.By the way, this table is supported by
SQL, and the three reasons represent SQL's most serious and far-reaching deviations from relational
theory.

End of Notes

Page 8 of 8 — M359: Notes for introductory lecture.