Joe Celko s SQL for Smarties - Advanced SQL Programming P5 pptx

12 CHAPTER 1: DATABASE DESIGN
When you use NULLs in math calculations, they propagate in the
results so that the answer is another
NULL. When you use them in
logical expressions or comparisons, they return a logical value of
UNKNOWN and give SQL its strange three-valued logic. They sort either
always high or always low in the collation sequence. They group
together for some operations, but not for others. In short,
NULLs cause a
lot of irregular features in SQL, which we will discuss later. Your best bet
is just to memorize the situations and the rules for
NULLs when you
cannot avoid them.
CHECK() Constraint
The CHECK() constraint tests the rows of the table against a logical
expression, which SQL calls a search condition, and rejects rows whose
search condition returns
FALSE. However, the constraint accepts rows
when the search condition returns
TRUE or UNKNOWN. This is not the
same rule as the
WHERE clause, which rejects rows that test UNKNOWN.
The reason for this “benefit-of-the-doubt” feature is so that it will be easy
to write constraints on
NULL-able columns.
The usual technique is to do simple range checking, such as CHECK
(rating BETWEEN 1 AND 10), or to verify that a column’s value is in
an enumerated set, such as
CHECK (sex IN (0, 1, 2, 9)), with
this constraint. Remember that the sex column could also be set to
NULL, unless a NOT NULL constraint is also added to the column’s

declaration. Although it is optional, it is a really good idea to use a
constraint name. Without it, most SQL products will create a huge, ugly,
unreadable random string for the name, since they need to have one in
the schema tables. If you provide your own, you can drop the constraint
more easily and understand the error messages when the constraint is
violated.

For example, you can enforce the rule that a firm must not hire
anyone younger than 21 years of age for a job that requires a liquor-
serving license by using a single check clause to check the applicant’s
birth date and hire date. However, you cannot put the current system
date into the
CHECK() clause logic for obvious reasons, it is always
changing.
The real power of the
CHECK() clause comes from writing complex
expressions that verify relationships with other rows, with other tables,
or with constants. Before SQL-92, the
CHECK() constraint could only
reference columns in the table in which it was declared. In Standard
SQL, the
CHECK() constraint can reference any schema object. As an
example of how complex things can get, consider a database of movies.
1.1 Schema and Table Creation 13
First, let’s enforce the rule that no country can export more than ten
titles.
CREATE TABLE Exports
(movie_title CHAR(25) NOT NULL,
country_code CHAR(2) NOT NULL, use 2-letter ISO nation codes
sales_amt DECIMAL(12, 2) NOT NULL,

PRIMARY KEY (movie_title, country_code),
CONSTRAINT National_Quota
CHECK ( reference to same table
10 <= ALL (SELECT COUNT(movie_title)
FROM Exports AS E1
GROUP BY E1.country_code))
);
When doing a self-join, you must use the base table name and not all
correlation names. Let’s make sure no movies from different countries
have the same title.
CREATE TABLE ExportMovies
(movie_title CHAR(25) NOT NULL,
country_code CHAR(2) NOT NULL,
sales_amt DECIMAL(12, 2) NOT NULL,
PRIMARY KEY (movie_title, country_code),
CONSTRAINT National_Quota
CHECK (NOT EXISTS self-join
(SELECT *
FROM ExportMovies AS E1
WHERE ExportMovies.movie_title = E1.movie_title
AND ExportMovies.country_code <> E1.country_code)
);
Here is way to enforce the rule that you cannot export a movie to its
own country of origin.
CREATE TABLE ExportMovies
(movie_title CHAR(25) NOT NULL,
country_code CHAR(2) NOT NULL,
sales_amt DECIMAL(12, 2) NOT NULL,
PRIMARY KEY (movie_title, country_code),
CONSTRAINT Foreign_film

14 CHAPTER 1: DATABASE DESIGN
CHECK (NOT EXISTS reference to second table
(SELECT *
FROM Movies AS M1
WHERE M1.movie_title = ExportMovies.movie_title
AND M1.country_of_origin = ExportMovies.country_code)));
These table-level constraints often use a NOT EXISTS() predicate.
Despite the fact that you can often do a lot of work in a single constraint,
it is better to write a lot of small constraints, so that you know exactly
what went wrong when one of them is violated.
Another important point to remember is that all constraints are true if
the table is empty. This is handled by the
CREATE ASSERTION
statement, which we will discuss shortly.
UNIQUE and PRIMARY KEY Constraints
The UNIQUE constraint says that no duplicate values are allowed in the
column or columns involved.
<unique specification> ::= UNIQUE | PRIMARY KEY
File system programmers understand the concept of a PRIMARY
KEY, but for the wrong reasons. They are used to a file, which can have
only one key because that key is used to determine the physical order of
the records within the file. Tables have no order; the term
PRIMARY KEY
in SQL has to do with defaults in referential actions, which we will
discuss later.
There are some subtle differences between
UNIQUE and PRIMARY
KEY. A table can have only one PRIMARY KEY but many UNIQUE
constraints. A
PRIMARY KEY is automatically declared to have a NOT

NULL constraint on it, but a UNIQUE column can have NULLs in a row
unless you explicitly add a
NOT NULL constraint. Adding the NOT NULL
whenever possible is a good idea, as it makes the column into a proper
relational key.
There is also a multiple-column form of the
<unique
specification>, which is usually written at the end of the column
declarations. It is a list of columns in parentheses after the proper
keyword, and it means that the combination of those columns is
unique. For example, I might declare
PRIMARY KEY (city,
department) so I can be sure that though I have offices in many
cities and many identical departments in those offices, there is only
one personnel department in Chicago.
1.1 Schema and Table Creation 15
REFERENCES Clause
The
<references specification> is the simplest version of a
referential constraint definition, which can be quite tricky. For now, let
us just consider the simplest case:
<references specification> ::=
[CONSTRAINT <constraint name>]
REFERENCES <referenced table name>[(<reference column>)]
This relates two tables together, so it is different from the other
options we have discussed so far. What this says is that the value in this
column of the referencing table must appear somewhere in the
referenced table’s column named in the constraint. Furthermore, the
referenced column must be in a
UNIQUE constraint. For example, you

can set up a rule that the Orders table can have orders only for goods
that appear in the Inventory table.
If no
<reference column> is given, then the PRIMARY KEY
column of the referenced table is assumed to be the target. This is one of
those situations where the
PRIMARY KEY is important, but you can
always play it safe and explicitly name a column. There is no rule to
prevent several columns from referencing the same target column. For
example, we might have a table of flight crews that has pilot and copilot
columns that both reference a table of certified pilots.
A circular reference is a relationship in which one table references a
second table, which in turn references the first table. The old gag about
“you cannot get a job until you have experience, and you cannot get
experience until you have a job!” is the classic version of this.
Notice that the columns in a multicolumn
FOREIGN KEY must
match to a multicolumn
PRIMARY KEY or UNIQUE constraint. The
syntax is:
[CONSTRAINT <constraint name>]
FOREIGN KEY (<column list>)
REFERENCES <referenced table name>[(<reference column list>)]
Referential Actions
The
REFERENCES clause can have two subclauses that take actions when
a database event changes the referenced table. This feature came with
Standard SQL and took a while to be implemented in most SQL
products. The two database events are updates and deletes, and the
subclauses look like this:

16 CHAPTER 1: DATABASE DESIGN
<referential triggered action> ::=
<update rule> [<delete rule>] | <delete rule> [<update rule>]
<update rule> ::= ON UPDATE <referential action>
<delete rule> ::= ON DELETE <referential action>
<referential action> ::= CASCADE | SET NULL | SET DEFAULT | NO
ACTION
When the referenced table is changed, one of the referential actions is
set in motion by the SQL engine.
1. The CASCADE option will change the values in the referencing
table to the new value in the referenced table. This is a very
common method of DDL programming that allows you to set
up a single table as the trusted source for an identifier. This way
the system can propagate changes automatically.
This removes one of the arguments for nonrelational system-
generated surrogate keys. In early SQL products that were based
on a file system for their physical implementation, the values
were repeated for both the referenced and referencing tables.
Why? The tables were regarded as separate units, like files.
Later SQL products regarded the schema as a whole. The
referenced values appeared once in the referenced table, and
the referencing tables obtained them by following pointer
chains to that one occurrence in the schema. The results are
much faster update cascades, a physically smaller database,
faster joins, and faster aggregations.
2. The
SET NULL option will change the values in the referencing
table to a
NULL. Obviously, the referencing column needs to be
NULL-able.

3. The
SET DEFAULT option will change the values in the
referencing table to the default value of that column.
Obviously, the referencing column needs to have some
DEFAULT declared for it, but each referencing column can have
its own default in its own table.
4. The
NO ACTION option explains itself. Nothing is changed in
the referencing table, and it is possible that some error message
about reference violation will be raised. If a referential
1.1 Schema and Table Creation 17
constraint does not specify any ON UPDATE or ON DELETE
rule in the update rule, then
NO ACTION is implicit. You will
also see the reserved word
RESTRICT in some products instead
of
NO ACTION.
Standard SQL has more options about how matching is done
between the referenced and referencing tables. Most SQL products have
not implemented them, so I will not mention them anymore.
Standard SQL has deferrable constraints. This option lets the
programmer turn a constraint off during a session, so that the table can
be put into a state that would otherwise be illegal. However, at the end of
a session, all the constraints are enforced. Many SQL products have
implemented these options, and they can be quite handy, but I will not
mention them until we get to the section on transaction control.
1.1.4 UNIQUE Constraints versus UNIQUE Indexes
UNIQUE constraints are not the same thing as UNIQUE indexes.
Technically speaking, indexes do not even exist in Standard SQL. They

were considered too physical to be part of a logical model of a language.
In practice, however, virtually all products have some form of “access
enhancement” for the DBA to use, and most often, it is an index.
The column referenced by a
FOREIGN KEY has to be either a
PRIMARY KEY or a column with a UNIQUE constraint; a unique index
on the same set of columns cannot be referenced, since the index is on
one table and not a relationship between two tables.
Although there is no order to a constraint, an index is ordered, so the
unique index might be an aid for sorting. Some products construct special
index structures for the declarative referential integrity (DRI) constraints,
which in effect “pre-
JOIN” the referenced and referencing tables.
All the constraints can be defined as equivalent to some
CHECK
constraint. For example:
PRIMARY KEY = CHECK (UNIQUE (SELECT <key columns> FROM <table>)
AND (<key columns>) IS NOT NULL)
UNIQUE = CHECK (UNIQUE (SELECT <key columns> FROM <table>))
NOT NULL = CHECK (<column> IS NOT NULL)
These predicates can be reworded in terms of other predicates and
subquery expressions, and then passed on to the optimizer.
18 CHAPTER 1: DATABASE DESIGN
1.1.5 Nested UNIQUE Constraints
One of the basic tricks in SQL is representing a one-to-one or many-to-
many relationship with a table that references the two (or more) entity
tables involved by their primary keys. This third table has several
popular names, such as “junction table” or “join table,” but we know that
it is a relationship. This type of table needs constraints to ensure that the
relationships work properly.

For example, here are two tables:
CREATE TABLE Boys
(boy_name VARCHAR(30) NOT NULL PRIMARY KEY
);
CREATE TABLE Girls
(girl_name VARCHAR(30) NOT NULL PRIMARY KEY,
);
Yes, I know using names for a key is a bad practice, but it will make
my examples easier to read. There are a lot of different relationships that
we can make between these two tables. If you don’t believe me, just
watch the Jerry Springer Show sometime. The simplest relationship table
looks like this:
CREATE TABLE Couples
(boy_name VARCHAR(30) NOT NULL
REFERENCES Boys (boy_name)
ON UPDATE CASCADE
ON DELETE CASCADE,
girl_name VARCHAR(30) NOT NULL,
REFERENCES Girls(girl_name)
ON UPDATE CASCADE
ON DELETE CASCADE);
The Couples table allows us to insert rows like this:
('Joe Celko', 'Hilary Duff')
('Joe Celko', 'Lindsay Lohan')
('Toby McGuire', 'Lindsay Lohan')
('Joe Celko', 'Hilary Duff')
1.1 Schema and Table Creation 19
Oops! I am shown twice with Hilary Duff, because the Couples table
does not have its own key. This mistake is easy to make, but the way to
fix it is not obvious.

CREATE TABLE Orgy
(boy_name VARCHAR(30) NOT NULL
REFERENCES Boys (boy_name)
ON DELETE CASCADE
ON UPDATE CASCADE,
girl_name VARCHAR(30) NOT NULL,
REFERENCES Girls(girl_name)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (boy_name, girl_name)); compound key
The Orgy table gets rid of the duplicated rows and makes this a
proper table. The primary key for the table is made up of two or more
columns and is called a compound key because of that fact. These are
valid rows now.
('Joe Celko', 'Hilary Duff')
('Joe Celko', 'Lindsay Lohan')
('Toby McGuire’, 'Lindsay Lohan')
But the only restriction on the couples is that they appear only once.
Every boy can be paired with every girl, much to the dismay of the Moral
Majority. I think I want to make a rule that guys can have as many gals as
they want, but the gals have to stick to one guy.
The way I do this is to use a
NOT NULL UNIQUE constraint on the
girl_name column, which makes it a key. It is a simple key, since it is
only one column, but it is also a nested key, because it appears as a
subset of the compound
PRIMARY KEY.
CREATE TABLE Playboys
(boy_name VARCHAR(30) NOT NULL
REFERENCES Boys (boy_name)

ON UPDATE CASCADE
ON DELETE CASCADE,
girl_name VARCHAR(30) NOT NULL UNIQUE, nested key
REFERENCES Girls(girl_name)
ON UPDATE CASCADE
20 CHAPTER 1: DATABASE DESIGN
ON DELETE CASCADE,
PRIMARY KEY (boy_name, girl_name)); compound key
The Playboys is a proper table, without duplicated results, but it also
enforces the condition that I get to play around with one or more ladies.
('Joe Celko', 'Hilary Duff')
('Joe Celko', 'Lindsay Lohan')
The women might want to go the other way and keep company with a
series of men.
CREATE TABLE Playgirls
(boy_name VARCHAR(30) NOT NULL UNIQUE nested key
REFERENCES Boys (boy_name)
ON UPDATE CASCADE
ON DELETE CASCADE,
girl_name VARCHAR(30) NOT NULL,
REFERENCES Girls(girl_name)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY (boy_name, girl_name)); compound key
The Playgirls table would permit these rows from our original set.
('Joe Celko', 'Lindsay Lohan')
('Toby McGuire', 'Lindsay Lohan')
Think about all of these possible keys for a minute. The compound
PRIMARY KEY is now redundant. If each boy appears only once in the
table, or each girl appears only once in the table, then each (boy_name,

girl_name) pair can appear only once. However, the redundancy can be
useful in searching the table, because it will probably create extra
indexes that give us a covering of both names. The query engine then
can use just the index and touch the base tables.
The Moral Majority is pretty upset about this Hollywood scandal and
would love for us to stop running around and settle down in nice stable
couples.
CREATE TABLE Marriages
(boy_name VARCHAR(30) NOT NULL UNIQUE nested key
REFERENCES Boys (boy_name)
1.1 Schema and Table Creation 21
ON UPDATE CASCADE
ON DELETE CASCADE,
girl_name VARCHAR(30) NOT NULL UNIQUE nested key,
REFERENCES Girls(girl_name)
ON UPDATE CASCADE
ON DELETE CASCADE,
PRIMARY KEY(boy_name, girl_name)); redundant compound key!!
Since one of the goals of an RDBMS (relational database management
system) is to remove redundancy, why would I have that compound
primary key? One reason might be to get a covering index on both
columns for performance. But the more likely answer is that this is an
error that a smart optimizer will spot. I leave same-sex marriages as an
exercise for the reader.
The Couples table allows us to insert these rows from the original set.
('Joe Celko', 'Hilary Duff')
('Toby McGuire', 'Lindsay Lohan')
However, SQL products and theory do not always match. Many
products make the assumption that the
PRIMARY KEY is somehow

special in the data model and will be the way that they should access the
table most of the time.
In fairness, making special provision for the
PRIMARY KEY is not a
bad assumption, because the
REFERENCES clause uses the PRIMARY
KEY of the referenced table as the default. Many new SQL programmers
are not aware that a
FOREIGN KEY constraint can also reference any
UNIQUE constraint in the same table or in another table. The following
nightmare code will give you an idea of the possibilities. The multiple
column versions follow the same syntax.
CREATE TABLE Foo
(foo_key INTEGER NOT NULL PRIMARY KEY,

self_ref INTEGER NOT NULL
REFERENCES Foo(fookey),
outside_ref_1 INTEGER NOT NULL
REFERENCES Bar(bar_key),
outside_ref_2 INTEGER NOT NULL
REFERENCES Bar(other_key),
);