Introduction
Relational databases were made possible by the groundbreaking work of computer scientist Edgar F. Codd in the early 1970s. He proposed a set of twelve guidelines, referred to as Codd's rules, to specify what defines a relational database management system (RDBMS). These guidelines aid in preserving the accuracy and consistency of data and offer a framework for determining if a database system is relational.
Codd's 12 Rules
Rule 0. Foundation Rule
If a system can manage databases only using its relational capabilities, then it must be a relational database management system. This rule says that every system that calls itself a relational database has to manage data using its relational functions.
Rule 1. The Information Rule
All information in a relational database is represented explicitly at the logical level and in exactly one way: by values in tables. This ensures that the data is structured in a straightforward manner using rows and columns.
Rule 2. Guaranteed Access Rule
In a relational database, the table name, primary key (row identifier), and column name guarantee access to each particular data element (atomic value). This regulation guarantees accurate and speedy data access.
Rule 3. Systematic Treatment of Null Values
Regardless of the data type, null values must be supported to represent missing data systematically. They may be distinguished from zero or any other number, as well as from an empty character string or a string of blank characters.
Rule 4. Dynamic Online Catalog Based on the Relational Model
The catalog, or database description, is logically represented in the same way as regular data, allowing authorized users to query it using the same relational language as they would regular data.
Rule 5. Comprehensive Data Sublanguage Rule
A relational system can support several languages and different terminal usage modes, such as fill-in-the-blanks. Data definition, data manipulation, data integrity restrictions, and database transaction management procedures (begin, commit, and rollback) must all be able to be expressed in expressions of at least one language.
Rule 6. View Updating Rule
The system must be able to update any view that is updateable in theory. With views, users can work with a portion of the database or a mix of several databases. This rule makes sure that modifications made to views should show up in the foundation tables that underpin them.
Rule 7. High-Level Insert, Update, and Delete
The system needs to be able to manage numerous rows at once to support insert, update, and delete actions at a certain level. This rule improves the database's ability to carry out bulk operations effectively.
Rule 8. Physical Data Independence
Modifications to the logical level's structure (the way data is accessible) must not necessitate alterations to an application in order to make changes to the physical level (the way data is stored). This rule makes sure that any changes made to the data structure won't have an impact on the apps that use it.
Rule 9. Logical Data Independence
Modifications to the logical level (tables, columns, rows, and relationships) shouldn't necessitate alterations to an application because of the view level's structure (user views). This rule makes it possible to change the schema without having to rewrite the application applications.
Rule 10. Integrity Independence
Integrity restrictions need to be recorded in the catalog and specified independently of application programs. This rule makes sure that the DBMS, not the application, is in charge of managing and maintaining data integrity requirements, such as referential integrity.
Rule 11. Distribution Independence
Users of the database should not be able to see that parts of it have been distributed to multiple sites. This guideline makes sure that access to data shouldn't be impacted by the database's location, whether it is centralized or dispersed over several sites
Rule 12. Non-Subversion Rule.
The integrity constraints and regulations defined in the higher-level (multiple-records-at-a-time) relational language of a relational system cannot be circumvented or subverted by using the low-level (single-records-at-a-time) language of that system.
Conclusion
Codd's rules provide essential guidelines for ensuring data integrity and consistency in relational databases. Adhering to these principles helps create robust and reliable database systems. Understanding these rules is crucial for effective database design and management.