如果你想设计一个数据库管理系统，看看这里

这是数据库之父 对实现关系型数据库管理系统的 12条实现建议 

Codd's 12 Rules 

Dr. E.F. Codd, an IBM researcher, first developed the relational data 

model in 1970. In 1985, Dr. Codd published a list of 12 rules that concisely

 define an ideal relational database, which have provided a guideline for the 

design of all relational database systems ever since. 

I use the term "guideline" because, to date, no commercial relational database 

system fully conforms to all 12 rules. They do represent the relational ideal, 

though. For a few years, scorecards were kept that rated each commercial 

product's conformity to Codd's rules. Today, the rules are not talked about 

as much but remain a goal for relational database design. 

Following is a list of Codd's 12 rules, including his original name for each rule 

and a simplified description. I also have included a note where certain 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 will fill in the details. 

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: 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. Over the life of this newsletter, 

I will be expanding on the concepts covered by each of Codd's rules. I will use the relational 

query language of choice, SQL, to illustrate these concepts and explain relational database

 structure in detail. 

====================================================

另附：

标题 关系数据库之父 Fenng（转贴） 

关键字 Edgar F. Codd 数据库 传记 

出处  http://www.oracle.com/global/cn/oramag/oracle/03-jul/index.html?content.html 

Edgar (Ted) Codd, 1923-2003 

纪念关系数据库之父

大家都说，Edgar F. Codd（通常被称为Ted）是一个才华横溢的人。他的成就之一，是在二十世纪七十年代初开发了一个关系型数据管理模型--存储和操作大量业务数据的一个复杂、完整的理论。根据Codd的设计构建的关系数据库成为了当今企业的基础；银行依赖关系数据库来跟踪资金流动；零售商使用它们来监控库存水平；人力资源部门使用它们来管理员工账户；图书馆、医院和政府机构在其中存储数百万条记录；事实上，世界上几乎所有的企业都在使用某种容量的关系数据库。自从Codd公布其理论以来的30年中，关系数据库已经成为一个年收入近130亿美元的行业。 

早期生活 

Ted Codd于1923年出生在英格兰多塞特郡波特兰市的一个大家庭中。他曾经就读于牛津大学，主修数学和化学专业，第二次世界大战期间曾在皇家空军服役。第二次世界大战后，Codd动身前往纽约并成为IBM的一名数学编程员。Codd所做的第一个项目是帮助构建一个称为可选顺序电子计算器（Selective Sequence Electronic Calculator，SSEC）的早期计算机，据说该计算机占据了一栋市区办公楼中的两层。 在二十世纪六十年代中期，Codd获得了密歇根大学计算机科学专业的博士学位。之后，他调到了IBM位于加利福尼亚州圣何塞市的开发实验室，在那里，他开始从事关系型数据管理模型（这是一个在很大程度上依赖于数学的模型）的开发。 改进数据库早期的计算机太大、太昂对了，以至于不能广泛地应用于企业。在二十世纪六十年代，计算机开始变得经济有效，并逐渐被私营机构所采用，同时专门针对企业应用开发了许多标准和语言。其中有两个用于处理数据的模型：层次模型和关系网络模型。 在层次模型中，数据记录以层次方式相互关联；主要记录位于上层，后续的各个记录类型在下层分支。在网络模型中，一层中的记录集可能属于邻近的上层中的两个不同的包含层次中。对于这两种模型，编写查询语句来检索信息要求深入了解数据本身的导航结构，因而这是一个复杂的任务，一般都是由专门的编程人员来完成的。 

Codd提出了一个新的解决方案。在最终收集到1970年具有创新性的技术论文--"A Relational Model of Data for Large Shared Data Banks"（大型共享数据库的关系数据模型）中的一系列报告中，Codd建议将数据独立于硬件来存储，程序员使用一个非过程语言来访问数据。Codd的解决方案的关键，是将数据保存在由行和列组成的简单表中（在这种表中，相似数据的列将各个表相互联系起来），而不是将数据保存在一个层次结构中。按照Codd的想法，数据库用户或应用程序不需要知道数据结构来查询该数据。发表了该论文之后不久，Codd又发布了更为详细的指导原则，提出了其指导创建关系数据库的12项原则。在Codd的理论公开之后，并没有立即被ＩＢＭ所采纳。ＩＢＭ已经对一个称为IMS的层次型数据库进行了大量投资，因而它让其他公司和企业家去考虑如何进一步发展Codd的理论。其中的领袖人物是拉里o埃利森，他在１９７７年与Ed Oates和Bob Miner一起研制了世界上第一个商用关系型数据库管理系统，在此过程中，创办了一个公司，后来成为Oracle公司。其余要说的就是数据库的历史了。 但是对Ted Codd来说，历史并没有停留在那儿。虽然直至二十世纪八十年代初，Codd一直就职于IBM，但他也与长期的合作者Chris Date共同创建了一家咨询服务公司，而且，直到其今年的早些时候去世，Codd还一直继续研究和发表关于数据的规范化、分析和数据建模等主体的文章。

了解关于Edgar (Ted) Codd的更多信息

www.wikipedia.org/wiki/Edgar_F._Codd 

文章来源：

http://www.oracle.com/global/cn/oramag/oracle/03-jul/index.html?content.html