Question : 12 Rules of Codd and Oracle

Hello Experts, Please tell me  : Does the Oracle satisfy all the 12 Rules of Codd? What about Access and SQL-Server?
How does Access maintain its data-dictionary? Is it accessible by the user as specified by "Information Rule" (1st rule of Codd).
Thanks.
Sandeep.

Answer : 12 Rules of Codd and Oracle

Oracle, Access and SQL-Server all satisfy some of the rules but not all.

Rule 1: The Information Rule: All data should be presented to the user in table form.

Oracle, Access and SQL-Server all satisfy this rule.

Rule 2: Guaranteed Access Rule: All data should be accessible without ambiguity. (This can be accomplished through a combination of the table name, primary key, and column name.)

Oracle, Access and SQL-Server all satisfy this rule.

Rule 3: Systematic Treatment of Null Values : A field should be allowed to remain empty. (This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a non-null field constraint that prevents null values in a specific table column.)

Oracle, Access and SQL-Server all satisfy this rule.

Rule 4: Dynamic On-Line Catalog Based on the Relational Model: A relational database must provide access to its structure through the same tools that are used to access the data. (This is usually accomplished by storing the structure definition within special system tables.)

Oracle satisfies this rule. I believe SQL-Server also satisfies this rule.
Access has "hidden" tables that I think provides some access to the data structure.

Rule 5: Comprehensive Data Sublanguage Rule: The database must support at least one clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. (Most commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language.)

Oracle, Access and SQL-Server satisfy this rule as they support SQL (although with some syntax variations).

Rule 6: View Updating Rule: Data can be presented to the user in different logical combinations, called views. (Each view should support the same full range of data manipulation that direct-access to a table has available. In practice, providing update and delete access to logical views is difficult and is not fully supported by any current database.)

None of Oracle, Access and SQL-Server support this. They do provide some limited view-updating for simple views. Oracle provides the facility to programmatically allow view updating via "instead-of" triggers.

Rule 7: High-level Insert, Update, and Delete: Data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. (This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.)

None of Oracle, Access and SQL-Server support this, for the same reason as for Rule 6.

Rule 8: Physical Data Independence: The user is isolated from the physical method of storing and retrieving information from the database. (Changes can be made to the underlying architecture (hardware, disk storage methods) without affecting how the user accesses it.)

Oracle, Access and SQL-Server satisfy this rule (as far as I know).

Rule 9: Logical Data Independence: How a user views data should not change when the logical structure (tables structure) of the database changes. (This rule is particularly difficult to satisfy. Most databases rely on strong ties between the user view of the data and the actual structure of the underlying tables.)

If they supported Rules 6 and 7 this rule would also be easy to support. But they don't.

Rule 10: Integrity Independence: The database language (like SQL) should support constraints on user input that maintain database integrity. (This rule is not fully implemented by most major vendors. At a minimum, all databases do preserve two constraints through SQL: No component of a primary key can have a null value. (see rule 3) If a foreign key is defined in one table, any value in it must exist as a primary key in another table.)

All three DBMS's do support integrity constraints of various forms, but none support all integrity constraints as defined in the literature (domain, tuple, relation and database constraints).

Rule 11: Distribution Independence: A user should be totally unaware of whether or not the database is distributed (whether parts of the database exist in multiple locations). (A variety of reasons make this rule difficult to implement.)

Oracle and SQL-Server certainly provide a lot of support for this rule. I don't know how good Access is for distribution independence.

Rule 12: Nonsubversion Rule: There should be no way to modify the database structure other than through the multiple row database language (like SQL). (Most databases today support administrative tools that allow some direct manipulation of the datastructure.)

Generally it is possible to only use SQL and get the most out of all three of these databases; however to get reasonable performance it is often necessary to resort to other tools that manipulate the physical database structure directly.

In summary, most of Codd's ideas have been implemented, but not all - there is a new DBMS in development currently that purports to support all of them, including full view updateability. It remains to be seen whether it becomes a commercial success.

Jeff