Rule 3 : Systematic treatment of null values
The database system must ensure a systematic treatment of null values. What this means is that NULL can have different interpretations, and may be applicable to different sets of data types, and should be uniformly dealt with. There is a difference between "missing data", "not applicable", or an integer "0".
Rule 4 : Active online catalog based on the relational model
A catalog describes the database. The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data.
Rule 5 : The comprehensive data sub language rule
The system must support at least one relational language that
has a linear syntax, can be used both interactively and within application programs, supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback). In short, there should be one language that rules all. If there is any other language which can be used to access the database, then that would be a violation of this rule.
Rule 6 : The view updating rule
All views that can be theoretically updated, must be updated by the system.
Rule 7 : High-level insert, update, and delete
The system must support high level insert, update, and delete operations on relations. Also, it should support operations such as union, minus, intersection etc.
Rule 8 : Physical data independence
Physical data independence means that data storage at physical location and application programs that utilize these data should be independent of each other. Any change in the database should not be accompanied by changes in application program and vice versa.
Rule 9 : Logical data independence
Logical data independence means that changes to the logical level must not require any change at the user view level. Logical data independence is more difficult to achieve than physical data independence.
Rule 10 : Integrity independence
Integrity constraints must be specified separately from application programs and stored in the catalog instead.
Rule 11 : Distribution independence
The user should not have to know about the distribution level of the database. Existing applications should continue to operate successfully even when a distributed version of the DBMS is first introduced or existing distributed data are redistributed around the system.
Rule 12: The non subversion rule
If the system provides a low-level interface or language, then that interface or language cannot be used to subvert or bypass the relational security or integrity constraints.
