|
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.
以下這12條規(guī)則的中文由 SilentKiller 翻譯，不保證全部正確。
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.
1，信息準則
關系數(shù)據(jù)庫中的所有信息都應在邏輯層上用表中的值顯式的表示。
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.
2，保證訪問準則
依于表名，主鍵和列名，保證能以邏輯方式訪問數(shù)據(jù)庫中的每個數(shù)據(jù)項。
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.
3，空值的系統(tǒng)化處理
RDBMS支持空值（不同于空的字符串或空白字符串，并且不為0）系統(tǒng)化的
表示缺少的信息，且與數(shù)據(jù)類型無關。
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，基于關系模型的聯(lián)機目錄
數(shù)據(jù)庫的描述在邏輯上應該和一般數(shù)據(jù)采用同樣的方式，使得授權用戶可以
使用查詢一般數(shù)據(jù)所用的關系語言來查詢數(shù)據(jù)庫的描述信息。
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.
5，合理廣泛的子語言準則
一個關系系統(tǒng)可以具有幾種語言和多種終端使用方式（表格填空方式，命令
方式等）。但是必須有一種語言，它的語句可以表示為具有嚴格語法規(guī)定的
字符串，并能全面的支持以下功能：數(shù)據(jù)定義，視圖定義，數(shù)據(jù)操作，完整約束
，授權，事物控制。
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.
6，視圖更新準則
所有理論上可更新的視圖也應該允許由系統(tǒng)更新。
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.
7，高階的插入，更新和刪除
把一個基本關系或導出關系作為一個操作對象進行數(shù)據(jù)的檢索以及插入，更新和刪除。
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.
8，數(shù)據(jù)的物理獨立性
無論數(shù)據(jù)庫的數(shù)據(jù)在存儲表示上或存取方法上做任何變化，應用程序和終端活動要都保持邏輯上的不變性。
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.
9，數(shù)據(jù)的邏輯獨立性
當基本表中進行理論上信息不受損害的任何變化時，應用程序和終端和終端活動都要保持邏輯上的不變性。
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.
10，數(shù)據(jù)完整的獨立性
關系數(shù)據(jù)庫的完整性約束必須是用數(shù)據(jù)子語言定義并存貯在目錄中的，而不是在應用程序中加以定義的。至少要支持以下兩種約束：實體完整性：主鍵中的屬性不允許為NULL ； 參照完整性：對于關系數(shù)據(jù)庫中每個不同的非空的外碼值，必須存在一個取自同一個域匹配的主鍵值。
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.
11，分布的獨立性
一個RDBMS應該具有分布獨立性。用戶不必了解數(shù)據(jù)庫是否是分布式的。（無論數(shù)據(jù)庫是否有部分處于復雜多重環(huán)境中）
Rule 12: Nonsubversion Rule
There should be no way to modify the database structure other than through the multiple row database language (like SQL).
12，無破壞準則
若RDBMS有某種低級語言，這一低級語言不能違背或繞過完整性準則以及高級關系
語言表達的約束。
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.
出處：oracle.com
責任編輯：cjj
◎進入論壇網絡編程版塊參加討論
|
