如果你想設計一個資料庫管理系統，看看這裡

這是資料庫之父 對實作關系型資料庫管理系統的 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