12 rules for CODD's 12 Rules Codd
Dr. EF 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 Dr. EF Codd is an IBM researcher, and he proposed a relational data model in 1970. In 1985, Dr. CODD issued 12 rules that definitely define a relationship of a relational database, which is used as a design guidance policy for all relational database systems until today.
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 Talkay, The Rules Are Not Talked About As Much But Remain A Goal For Relational Database Design. I use the "Guideline" word because there is no commercial RDBS completely in all 12 principles. Although they are all claimed. In many years, the rules of CODD are an important part of each commercial product. Today, these principles are not as frequent as they have been, but they are still valuable 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. Do not worry if some of these items are confusing to you, as We move Further Through this newsletter Series We will Fill in The Details. The following is the 12 principles of CODD, including their initial names and simple descriptions. I also included some records in some principles about implementation. Don't worry that you will be confused by it, we can discuss more detailed discussions through news mail.
Rule 1: The Information Rule Principles 1: Information principles
All Data Should Be Presened to The User In Table Form. Last Week's Newsletter Already Discussed The Basics Of this rule. All data should be provided to the user in the table. Last week's news emails have discussed the basic principles in this principle. (Take a look at last week's news email ...)
Rule 2: Guaranteed Access Rule Principles 2: Make sure Access Principles All Data Should Be Access Iout Ambiguity. This Can Be Accomplished Through A Combination of the Table Name, Primary Key, And Column Name. All data should be accessible, no Ambiguity. These can be done by the collaboration of the table name, the primary key, and the column name (field name).
Rule 3: Systematic Treatment of Null Values Principles 3: Treatment of the system
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 not 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 should be allowed to be kept empty. This supports an null value, which is very different from the empty string and zero value. Of course, this is not supported for the primary key. In addition, most of the database implementation supports the NUN-NULL field concept, which will prevent the NULL specified 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 Principle 4. : Dynamic online catalogs are based on relational model A, and the relational database must provide the same tool to access its structure with the same tool. This is usually implemented by the save structure as a system table.
Rule 5: CompRehensive Data Sublanguage Rule Principle 5: Inclusive data sub-language principles
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. Database At least one exact definition language must be supported, including data definition, data manipulation, data complete, and database transaction control. All business relationship databases are built in standard SQL (Structured Query Language) as their supported inclusive language.
Rule 6: View Updating Rule Rules 6: View update principles
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. Data can be provided to the user in different logical portfolios, known as views. Each view should support the same full range of data manipulation and access the table directly. In reality, providing updates and deleting access logical views is very difficult, and any database cannot fully support. Rule 7: High-Level INSERT, UPDATE, AND DELETE Principle 7: Advanced 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. Data can be reused from the relational database, constructed from multiple columns and / or multiple tables. This rule illustrates the insertion, update, and delete operations should be supported by all acquired data sets, and even more than one separate column is placed in a single table.
Rule 8: Physical Data Independence Principle 8: Physical Data None
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. The user should find the physical storage database and heavy The method is isolated. Changes to the underlying architecture (hardware, disk storage methods) do not affect user access.
Rule 9: Logical Data Independence 9: Logic Data None
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 When the logical structure of the database (table structure) changes, the user's view data should not change. This principle is clearly difficult to ensure. Most databases need to rely on strong links between user view data and actual underlying table structures.
Rule 10: Integrity Independence 10: Unrelated
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 musting. Database language (such as SQL) should support constraint user input to maintain database integrity . This rule cannot be fully supported in most major versions. At least, all databases have two constraints: no one of the primary key has an null value. If an foreign key is defined in a table, all of which must be present as the primary key in another table.
Rule 11: Distribution Independence Rules 11: Distribution None
. 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. A user should fully consider how the database is distributed (regardless of some of the databases in many locations). Various reasons make this rule difficult to achieve; when we discuss distributed databases, I will spend the time to explain this problem.
Rule 12: NonsUBVersion Rule Rules 12: No Subset Rules
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. There should be no way more than multi-column database languages (such as SQL) to modify the database structure . Most today's database supports the data structure directly to the data structure in some administrative tools. At the end of this series of emails, I will detail the rules of each CODD. I will use the selected relationship query language, SQL, and explain these specific contents and explain the details of the relational database structure.
