Chapter 1: Creating 3

Rule Zero. A relational database manages all of its data through the capabilities
defined by Rules 1 through 12.
It must not be necessary to break these rules for any reason, such as achiev-
ing better performance. This means you can trust the rules without worrying
about special exceptions.
Rule 1. Tables must be used to logically represent all the data in a database.
Thats it everythings in tables. You dont have to learn about different
layouts or arrangements. No variable-format records, arrays, pointers, heaps,
stacks, or lists.
Rule 2. The table name, column name, and primary key value may be used to
uniquely identify every data element.
This means every table must have a primary key: one or more non-null col-
umns whose composite value is unique for each row in the table. SQL
Anywhere 9 lets you create a table without a primary key, but thats a really bad
idea for many reasons including performance. Its up to you to obey Rule 2, and
SQL Anywhere 9 provides facilities for defining an artificial primary key if you
cant or dont want to specify one that is based on business-related data.
Rule 3. Null values must be available to systematically represent missing or
inapplicable data. Null values must be independent of the data type, and they
must be distinct from all other values such as the empty string, blank string, or
zero. It must be possible to specify "nulls not allowed" for primary key and
other columns.
Rule 4. Tables must be used to logically represent the database description or
system catalog. Authorized users must be able to query the system catalog in the
same manner as ordinary tables.
In other words, the system catalog is stored as data in the database, and
Rule 1 applies.
Rule 5. There must be at least one single programming language that supports
all of the data definition, data manipulation, integrity constraints, user authori-
zation, and transaction control operations.
Today that language is SQL, and it contains all the different kinds of com-
mands such as CREATE, UPDATE, GRANT, and COMMIT.
Rule 6. Every view must be updatable if it is theoretically updatable.
This rule applies to inserts and deletes as well as updates. A view is a query
involving one or more tables. It is theoretically updatable if it is possible to
determine which rows in which base tables must be updated to achieve the
requested effect on the view. For example, a view defined as SELECT * FROM
t1 is updatable because everything about the base table t1 is known from the
view, but a view defined as SELECT 1 is not updatable because it doesnt even
refer to a table.
Rule 7. Set-oriented insert, update, and delete operations must be available.
Set-oriented operations are often more efficient to write and execute than
row-by-row operations.
Rule 8. Application programs must not be affected by changes in the physical
data representation.