The parent of the database 12 suggestions for implementing the relational database management system

Data | Database It's the father of the database. 12 recommendations for implementing a relational database management system:

Codd ' s Rules

Dr. E.f. Codd, an IBM researcher, the developed of the relational data model in 1970. In 1985, Dr. Codd published a list of rules that concisely define a ideal relational database, which have provided a G Uideline for the ' design ' all relational database systems ever since.

I use the term "guideline" because, to date, no commercial relational database system fully conforms to all rules. They do represent the relational ideal, though. For a few years, scorecards were kept this rated each commercial the product ' s conformity to Codd ' s rules. Today, the rules are isn't talked about as much but remain a goal for relational database design.

Following is a list of Codd's rules, including his original name to each rule and a simplified description. I also have included a note where certain the rules are problematic to implement.  Don ' t worry if some of these items are confusing to you, as we move further through this newsletter series we'll fill in The details.

Rule 1:the Information rule
All data should is 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 is accessible without ambiguity. This can is accomplished through a combination of the table name, primary key, and column name.

Rule 3:systematic treatment of Null Values
A field should is allowed to remain empty. This involves the support of a null value, which are distinct from a 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 I n A specific table column.

Rule 4:dynamic on-line Catalog Based on the relational Model A relational database must provide access to its structure T Hrough the same tools that are used to access the data. This are usually accomplished by storing the structure definition within system tables.

Rule 5:comprehensive Data sublanguage rule
The database must support at least one clearly defined language this includes for data definition, data functionality Pulation, data integrity, and database transaction control. All commercial relational databases use forms of the standard SQL (structured Query Language) as their supported sive 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 the views are difficult and are not fully Tabase.

Rule 7:high-level Insert, Update, and Delete
Data can is retrieved from a relational database in sets constructed of the data from multiple rows and/or multiple tables. This is states that insert, UPDATE, and delete operations should is supported for any retrievable set rather than just F Or a single row in a single table.

Rule 8:physical Data Independence
The user is isolated to 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 acces SES it.

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

Rule 10:integrity Independence
The database language (like SQL) should support constraints in user input that maintain database integrity. This was not a 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. (The Rule 3)
If a foreign key is defined at 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 isn't the database is distributed (whether parts to the database exist in Mul Tiple locations). A variety of reasons make this rule difficult to implement; I'll spend time addressing this reasons when we discuss distributed databases.

Rule 12:nonsubversion Rule
There should is no way to modify the database structure other than the through row database multiple (like SQL). Most databases today support administrative tools that allow some direct manipulation of the datastructure. Over the life of this newsletter, I'll be expanding on the concepts covered by each of the Codd ' s rules. I'll use the relational query language of choice, SQL, to illustrate these concepts and explain relational database Stru Cture in detail.


Turn from: http://www.zhanling.com/zhanling/qiu/blogview.asp?logID=83&cateID=3