Previous | Table of Contents | Next
Page 17
- Physical data independence. An application cannot depend on physical restructuring. If
a file supporting a table was moved from one disk to another, or renamed, then this
should have no impact on the application.
- Logical data independence. An application should not depend on logical restructuring.
If a single table must be split into two, then a view would have to be provided joining
the two back together so that there would be no impact on the application.
- Integrity independence. Integrity rules should be stored in the data dictionary.
Primary key constraints, foreign key constraints, check constraints, triggers, and so forth
should all be stored in the data dictionary.
- Distribution independence. A database should continue to work properly even if
distributed. This is an extension of rule 8, except rather than only being distributed on a
single system (locally), a database may also be distributed across a network of
systems (remotely).
- The nonsubversion rule. If low-level access is allowed, it must not bypass security
nor integrity rules, which would otherwise be obeyed by the regular data access language.
A backup or load utility, for example, should not be able to bypass authentication,
constraints, and locks. However, vendors often provide these abilities for the sake of
speed. It is then the DBA's responsibility to ensure that security and integrity, if
momentarily compromised, are reinstated. An example is disabling and re-enabling constraints for
a VLDB load.
If a DBMS can meet all of the fundamental principles discussed in this chapter (two-part
definition, six properties, relational operations, and two integrity rules) and these twelve rules,
it may be designated an RDBMS. Codd summed up all of this with his Rule Zero: "For a
system to qualify as an RDBMS, that system must use its relational facilities exclusively to manage
the database."l
Page 18
Previous | Table of Contents | Next
|