CODD’s RULES
The founder of the relational data base theory Dr. E F Codd has outlined twelve rules (modified to 333 rules) to test whether a product that is claimed to be fully relational really is an RDBMS. The twelve rules are based on a single foundation principle which is called as rule zero.
RULE ZERO : For any system that is claimed to be RDBMS, that system must be able to manage databases entirely through its relational capabilities.
RULE ONE Information representation
All information in RDB is represented explicitly as values in tables.
[ The metadata i.e., table name, column name etc. should also be stored in tables]
RULE TWO Guaranteed access
Each and every data item (atomic values) in a relational data base is guaranteed to be logically accessible by giving the table name, primary key value and column name.
[This rule specifies the need for a primary key to access the data in the data base]
RULE THREE Systematic treatment of null values
Null values are supported for representing missing information and inapplicable information in a systematic way, independent of data type.
[The systematic, uniform representation means that only one technique can be used for dealing with null values]
RULE FOUR Dynamic online catalogue (Data dictionary) based on relational data model The data base description is represented at the logical level in the same way as ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data.
[Only one data model is used for data and metadata, and only one manipulation sublanguage is used for querying]
RULE FIVE Comprehensive Data Sublanguage
A relational system may support several languages and various models for terminal use. But these must be at least one language whose statements can express all of the following items:
1. Data Definitions, 2. View definitions, 3. Data Manipulation [interactive and by Program], 4. Integrity Constraints, 5. Authorization, 6. Transaction Boundaries [Begin, Commit and Roll back]
RULE SIX View updating
All views that are theoretically updateable are also updateable by system.
RULE SEVEN High level insert, update and delete
The capability of handling a base relation and a derived relation or view on a single operand applies not only to the retrieval of data but also to the insertion, updating and deletion of data.
[This means that all the operators are set operators, not records or tuple operators i.e., a set of rows can be deleted in one statement (in one command) or a set of rows can all be modified or inserted]
RULE EIGHT Physical Data Independence
Application programs and terminal activities remain logically unaffected whenever any changes are made in either storage representation and access methods.
RULE NINE Logical Data Independence
Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairement, are made to the base tables.
RULE TEN Integrity Independence
Integrity constraints specific to a particular data base must be definable in the relational sub language and storable in catalogue, not in the application program.
RULE ELEVEN Distribution Independence
The data manipulation sub language of a relational DBMS must enable application programs and queries to remain logically the same whether and whenever the data are physically centralized or distributed. [In a distributed data base data are physically dispersed (distributed) across several remote computer sites and data processing requests at any one of these sites may require data stored at several of the sites. Each program treats the data base as it were all local. So Distribution and redistribution do not change the logic of the program]
RULE TWELVE Non Subversion
If a relational system has a low level (single record at a time) language, that low level language cannot be used subvert or bypass the integrity rules and constraints expressed in the higher level relational language. (Multiple records at a time).
[This means that all DML supported by the DBMS must rely only on the stored data base definition, including integrity rules and security constraints for processing of data.]
The founder of the relational data base theory Dr. E F Codd has outlined twelve rules (modified to 333 rules) to test whether a product that is claimed to be fully relational really is an RDBMS. The twelve rules are based on a single foundation principle which is called as rule zero.
RULE ZERO : For any system that is claimed to be RDBMS, that system must be able to manage databases entirely through its relational capabilities.
RULE ONE Information representation
All information in RDB is represented explicitly as values in tables.
[ The metadata i.e., table name, column name etc. should also be stored in tables]
RULE TWO Guaranteed access
Each and every data item (atomic values) in a relational data base is guaranteed to be logically accessible by giving the table name, primary key value and column name.
[This rule specifies the need for a primary key to access the data in the data base]
RULE THREE Systematic treatment of null values
Null values are supported for representing missing information and inapplicable information in a systematic way, independent of data type.
[The systematic, uniform representation means that only one technique can be used for dealing with null values]
RULE FOUR Dynamic online catalogue (Data dictionary) based on relational data model The data base description is represented at the logical level in the same way as ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data.
[Only one data model is used for data and metadata, and only one manipulation sublanguage is used for querying]
RULE FIVE Comprehensive Data Sublanguage
A relational system may support several languages and various models for terminal use. But these must be at least one language whose statements can express all of the following items:
1. Data Definitions, 2. View definitions, 3. Data Manipulation [interactive and by Program], 4. Integrity Constraints, 5. Authorization, 6. Transaction Boundaries [Begin, Commit and Roll back]
RULE SIX View updating
All views that are theoretically updateable are also updateable by system.
RULE SEVEN High level insert, update and delete
The capability of handling a base relation and a derived relation or view on a single operand applies not only to the retrieval of data but also to the insertion, updating and deletion of data.
[This means that all the operators are set operators, not records or tuple operators i.e., a set of rows can be deleted in one statement (in one command) or a set of rows can all be modified or inserted]
RULE EIGHT Physical Data Independence
Application programs and terminal activities remain logically unaffected whenever any changes are made in either storage representation and access methods.
RULE NINE Logical Data Independence
Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairement, are made to the base tables.
RULE TEN Integrity Independence
Integrity constraints specific to a particular data base must be definable in the relational sub language and storable in catalogue, not in the application program.
RULE ELEVEN Distribution Independence
The data manipulation sub language of a relational DBMS must enable application programs and queries to remain logically the same whether and whenever the data are physically centralized or distributed. [In a distributed data base data are physically dispersed (distributed) across several remote computer sites and data processing requests at any one of these sites may require data stored at several of the sites. Each program treats the data base as it were all local. So Distribution and redistribution do not change the logic of the program]
RULE TWELVE Non Subversion
If a relational system has a low level (single record at a time) language, that low level language cannot be used subvert or bypass the integrity rules and constraints expressed in the higher level relational language. (Multiple records at a time).
[This means that all DML supported by the DBMS must rely only on the stored data base definition, including integrity rules and security constraints for processing of data.]
Comments
Post a Comment