Home » SQL & PL/SQL » SQL & PL/SQL » E.F.COdd
E.F.COdd [message #193488] Sun, 17 September 2006 19:26 Go to next message
Messages: 2
Registered: September 2006
Location: India
Junior Member
Please Provide me the 12 golden rules of E.F.Codd regarding relational databases.
Re: E.F.COdd [message #193490 is a reply to message #193488] Sun, 17 September 2006 19:31 Go to previous messageGo to next message
Messages: 25531
Registered: January 2009
Location: SoCal
Senior Member
No, do your own research & homework.
What does this have to do with Oracle?
Re: E.F.COdd [message #193597 is a reply to message #193490] Mon, 18 September 2006 07:22 Go to previous messageGo to next message
Messages: 252
Registered: April 2001
Location: Chennai
Senior Member
hi you can find your answer here E.F.Codd
guys lock this one..
Re: E.F.COdd [message #193611 is a reply to message #193488] Mon, 18 September 2006 08:00 Go to previous messageGo to next message
Messages: 4758
Registered: February 2005
Location: East Coast USA
Senior Member
Wow, you know how to join a forum and post a message, yet you have no idea that you can use a search engine to find asnwers to basic questions as this? In Firefox or Opera (these are known as browsers), type in the follwing in the blank space at the top of the browser: google.com
Then hit enter.
You will then be brought to a search engine called google, where you would then type: E.F. Codd
Then hit enter again.
Your results will now be displayed. Click on any of the million answers.

[Updated on: Mon, 18 September 2006 08:04]

Report message to a moderator

Re: E.F.COdd [message #193695 is a reply to message #193488] Tue, 19 September 2006 00:47 Go to previous message
Messages: 137
Registered: September 2006
Senior Member

Rule 1: The Information Rule
All data should be presented to the user in table form. Last week's newsletter already discussed the basics of 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.

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 nun- null field constraint that prevents null values in a specific table column.

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.

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. All commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language.

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.

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.

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.

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.

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.

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; I will spend time addressing these reasons when we discuss distributed databases.

Rule 12: Non-subversion 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 data structure.

Previous Topic: Regarding Ref Cursors ...
Next Topic: join query
Goto Forum:

Current Time: Sun Jul 23 17:49:08 CDT 2017

Total time taken to generate the page: 0.04208 seconds