The 12 Rules for an RDBMS (Codd' s Rule)
Rule 1: The information Rule
All Information is explicitly and logically represented in exactly one way i.e by data values in tables.
Rule 2: The rule of guaranteed access
Every item of data must be logically addressable by resorting to a combination of a Table name, Primary key and column name.
Rule 3: The systematic treatment of null value
This rule states that support for null values must be consistent throughout the DBMS, and independent of the data type of the field.
Rule 4: The Database Description Rule
A description of the database is held and maintained using the same logical structures used to define the data. This allows users to query such information in the same way and using the same language, as they would do for any other data in the database.
Rule 5: Comprehensive sub-language Rule
There must be at least one language whose statements can be expressed as character strings confirming to some well-defined syntax, which is comprehensive in supporting the following:
- Data definition, view Definition, Data Manipulation
- Integrity Constraints
- Authorization
- Transaction Boundaries
All the above topics are manageable through Structural Query Language (SQL) statement.
Rule 6: The view-updating Rule
All views that are theoretically updateable are also updated by the system.
A view is a table is non-existent in its own right, but instead derived from one or more base tables.
Rule 7: The High Level Insert, Update and Delete Rule
The capability to handling a base relation, or infact a derived relation, as a single operand must hold good for all retrieve, update, delete and insert activity.
This means that the major DML commands, namely SELECT, UPDATE, DELETE and INSERT must be available and operational on sets of rows in a relation.
Rule 8: The physical independence Rule
The user access to the database remains logically consistent even if the storage representation is changed.
Rule 9: The logical data independence Rule
Application programs and terminal activities must remain logically unimpaired whenever information preserving changes of any kind, that are theoretically permitted, are made to the base tables.
Rule 10: Integrity independence Rule
All integrity constraint defined for a database must be definable in the language and stored in the database as data in tables.
The following integrity rules should apply every relational database
Entity Integrity: No component of a primary key can have missing values or null values.
Referential Integrity: For each distinct foreign key value there must exist a matching primary key value in the same domain.
Rule 11: Distribution Rule
A RDBMS must have distribution independence. Application running on a non-distributed database must remain logically unimpaired if that data becomes distributed in the context of a distributed relational database.
Rule 12: Non-Subversion Rule
If an RDBMS supports a lower level language that permits for example, row-at-a-time processing, then this language must not be able to bypass any integrity rules or constraints defined in the higher level, set-at-a-time, relational language.
Rule 1: The information Rule
All Information is explicitly and logically represented in exactly one way i.e by data values in tables.
Rule 2: The rule of guaranteed access
Every item of data must be logically addressable by resorting to a combination of a Table name, Primary key and column name.
Rule 3: The systematic treatment of null value
This rule states that support for null values must be consistent throughout the DBMS, and independent of the data type of the field.
Rule 4: The Database Description Rule
A description of the database is held and maintained using the same logical structures used to define the data. This allows users to query such information in the same way and using the same language, as they would do for any other data in the database.
Rule 5: Comprehensive sub-language Rule
There must be at least one language whose statements can be expressed as character strings confirming to some well-defined syntax, which is comprehensive in supporting the following:
- Data definition, view Definition, Data Manipulation
- Integrity Constraints
- Authorization
- Transaction Boundaries
All the above topics are manageable through Structural Query Language (SQL) statement.
Rule 6: The view-updating Rule
All views that are theoretically updateable are also updated by the system.
A view is a table is non-existent in its own right, but instead derived from one or more base tables.
Rule 7: The High Level Insert, Update and Delete Rule
The capability to handling a base relation, or infact a derived relation, as a single operand must hold good for all retrieve, update, delete and insert activity.
This means that the major DML commands, namely SELECT, UPDATE, DELETE and INSERT must be available and operational on sets of rows in a relation.
Rule 8: The physical independence Rule
The user access to the database remains logically consistent even if the storage representation is changed.
Rule 9: The logical data independence Rule
Application programs and terminal activities must remain logically unimpaired whenever information preserving changes of any kind, that are theoretically permitted, are made to the base tables.
Rule 10: Integrity independence Rule
All integrity constraint defined for a database must be definable in the language and stored in the database as data in tables.
The following integrity rules should apply every relational database
Entity Integrity: No component of a primary key can have missing values or null values.
Referential Integrity: For each distinct foreign key value there must exist a matching primary key value in the same domain.
Rule 11: Distribution Rule
A RDBMS must have distribution independence. Application running on a non-distributed database must remain logically unimpaired if that data becomes distributed in the context of a distributed relational database.
Rule 12: Non-Subversion Rule
If an RDBMS supports a lower level language that permits for example, row-at-a-time processing, then this language must not be able to bypass any integrity rules or constraints defined in the higher level, set-at-a-time, relational language.
