翻譯：Codd 的12條規則

Codd's 12 Rules

Codd 的12條規則

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.

E.F. Codd 博士是IBM研究員，他在1970年第一個提出了關系型資料模型。在1985年，Codd 博士釋出了12條規則，這些規則簡明的定義出一個關系型資料庫的理念，它們被作為所有關系資料庫系統的設計指導性方針，直到今天依然如此。

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.

我使用“指導性方針”（guideline）這個詞是因為，沒有一個商業 RDBS完全合乎所有12條原則。盡管它們都聲稱如此。在很多年裡，合乎 Codd 的規則是評價每一個商用産品的重要得分部分。今天，這些原則已不像從前那樣提得頻繁，但對于關系型資料庫設計仍然很有價值。

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.

以下是 Codd 的12條原則，包括它們最初的名稱和簡單的描述。我也包括進來了一些記錄，是某些原則中關于實作的疑問之處。不要擔心會被其中的内容搞糊塗，我們可以通過新聞郵件進行更詳細的讨論。

Rule 1: The Information Rule

原則 1: 資訊原則

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

原則 2: 確定通路原則

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

原則 3: 系統的對待空值

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.

一個字段應該允許被保持為空。這樣能支援一個空值，它與空字元串和零值截然不同。當然，這對于主鍵是不支援的。另外，大部分的資料庫實作支援 nun-null 字段概念，這将預防用 null 規定表列。

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.

原則 4: 動态線上編目以關系模型A為基礎，關系型資料庫必須提供用通路資料相同的工具通路其結構的功能。這通常通過儲存結構定義為系統表來實作。

Rule 5: Comprehensive Data Sublanguage Rule

原則 5: 包容性資料子語言原則

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.

資料庫必須支援至少一個确切的定義語言包括資料定義，資料操縱，資料完整和資料庫事務控制等功能。所有的商業關系資料庫都建立在标準 SQL（結構化查詢語言）作為它們支援的包容性語言。

Rule 6: View Updating Rule

規則 6: 視圖更新原則

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

原則 7: 進階插入、更新和删除

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

原則 8: 實體資料無關性

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

原則 9: 邏輯資料無關性

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

原則 10: 完整性無關性

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.

資料庫語言（比如SQL）應該支援限制使用者輸入來維護資料庫的完整性。這條規則在大多數主要版本裡不能被完全支援。至少，所有的資料庫的SQL都有兩條限制被保留：

沒有一個主鍵部分具有一個空值。

如果一個外鍵定義在一個表中，其中的所有值必須在另一個表裡作為主鍵存在。

Rule 11: Distribution Independence

規則 11: 分布無關性

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

規則 12: 沒有子版本規則

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.

應該沒有超過多列資料庫語言（如SQL）的途徑來修改資料庫結構。大多數今天的資料庫支援用一些管理工具直接對資料結構進行操縱。在這系列郵件的最後，我将詳述具體每一個 Codd 的規則。我将用所選的關系查詢語言，SQL，來詳闡述這些具體内容，并解釋關系型資料庫結構的詳細情況。

原文來自: http://www.zhanling.com/zhanling/qiu/blogview.asp?logID=83&cateID=3