4 Chapter 1: Creating

Application programs must only deal with the logical view of data offered
by SQL, not the underlying physical layout or access methods. In particular,
application programs should not care about the physical order of rows in a table,
or the order of columns in a row. This was a big advance over other technolo-
gies, which often required program changes when file names, locations, record
layouts, or sort orders were changed.
Rule 9. Application programs must not necessarily be affected by logical data
design changes that preserve information.
For example, if tables are split or combined in a way that preserves the
original data, it should be possible do this without changing the application pro-
gram logic. This means it is often possible to enhance or repair the database
design without rewriting applications.
Rule 10. Integrity constraint definitions must be stored in the system catalog
tables rather than application programs. Entity integrity must be satisfied for
every table: No component of the primary key may be null. Referential integrity
must be satisfied for every foreign key relationship: There must be a matching
primary key value for each non-null foreign key value.
Integrity constraints ensure data consistency in the long term because they
are built in to the database and cannot be avoided. They also help in the short
term by catching application programming errors that violate data integrity.
Rule 11. If distributed data is supported, application programs must not be
affected when data is distributed.
For example, it must be possible to write a program involving multiple
tables in the same way whether the tables reside in the same or different loca-
tions. SQL Anywhere 9 uses proxy tables to support distributed data in a way
that satisfies this rule.
Rule 12. It must not be possible to bypass the integrity rules or constraints when
manipulating the data.
The same rules apply whether set-oriented or row-by-row operations are
performed, and there must be no low-level access method that breaks these
rules. In practice, however, some rule checking may be deferred on a temporary
basis to solve some application design problems.

1.3 Five Types of Tables

The CREATE TABLE statement comes in seven different formats to create five
different types of tables. The different statement formats have the same basic
purpose: to define the name and layout of a new table, the names and data types
of the columns in each row, and the constraints which apply to the table and col-
umns. The table types differ as to whether a table is available to different
connections (global versus local), whether the schema and data are permanent
or temporary, and where the data resides (remote versus proxy).
<create_table> ::= <create_global_permanent_table>
| <create_remote_and_proxy_table>
| <create_proxy_table>
| <create_global_temporary_table>