Codd’s Relational Rules - Database Design and Development: An Essential Guide for IT Professionals - page 681

blanks mode). However, there must be at least one language whose statements are
expressible, per some well-defined syntax, as character strings, and that is compre-
hensive in supporting all of the following items:

• Data definitions
• View definitions
• Data manipulation (interactive and by program)
• Integrity constraints
• Authorization
• Transaction boundaries (begin, commit, and rollback)

Rule 6: View updating rule All views that are theoretically updateable are also

updateable by the system.

Rule 7: High-level insert, update, and delete The capability of handling a base rela-
tion or a derived relation (that is, a view) as a single operand applies not only to
the retrieval of data but also to the insertion, update, and deletion of data.

Rule 8: Physical data independence Application programs and terminal activities
remain logically unimpaired whenever any changes are made in either storage rep-
resentations or access methods.

Rule 9: Logical data independence Application programs and terminal activities
remain logically unimpaired when information-preserving changes of any kind that
theoretically permit unimpairment are made to the base tables.

Rule 10: Integrity independence Integrity constraints specific to a particular rela-
tional database must be definable in the relational data sublanguage and storable
in the catalog, not in the application programs.

Rule 11: Distribution independence The data manipulation sublanguage of a rela-
tional DBMS must enable application programs and inquiries to remain logically
the same whether and whenever data are physically centralized or distributed.

Rule 12: Nonsubversion rule If a relational system has a low-level (single-record-
at-a-time) language, that low level cannot be used to subvert or bypass the integrity
rules and constraints expressed in the higher-level relational language (multiple-
records-at-a-time).