After conducting considerable research on the Relational Model of DB systems, Dr Edgar F. Codd devised his own set of principles that a DB must follow in order to be considered a true relational DB. The Codd’s rules can be applied to any DB system that merely has relational capabilities for managing stored data. This is a fundamental rule that serves as the foundation for all other rules.
In this article, we will dive deeper into Codd’s Rules in DBMS according to the GATE Syllabus for (Computer Science Engineering) CSE. Keep reading ahead to learn more.
Table of Contents
- What are the Codd’s Rules in DBMS?
- Rule 0: The Foundation Rule
- Rule 1: The Information Rule
- Rule 2: The Guaranteed Access Rule
- Rule 3: The Systematic Treatment of Null Values
- Rule 4: The Dynamic/Active Online Catalog on the basis of the Relational Model
- Rule 5: The Comprehensive Data SubLanguage Rule
- Rule 6: The View Updating Rule
- Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and Update) Rule
- Rule 8: The Physical Data Independence Rule
- Rule 9: The Logical Data Independence Rule
- Rule 10: The Integrity Independence Rule
- Rule 11: The Distribution Independence Rule
- Rule 12: The Non-Subversion Rule
What are the Codd’s Rules in DBMS?
Constraints can’t be referred to as a system of relational DBs because every DB has tables. A DB that solely contains a relational data model cannot be called a Relational DB Management System or RDBMS. Some rules determine if a DB is the correct RDBMS. Dr Edgar F. Codd, who has extensive knowledge on the DB system’s Relational Model, proposed these principles in 1985. Codd presents his 13 criteria for a DB to evaluate the concept of a DB Management System (DBMS) against the relational model. A DB that follows the rule is referred to as a real relational DB management system (RDBMS). Codd’s rules are a set of rules that are widely used in relational DBs.
Rule 0: The Foundation Rule
The DB must be structured in a relational manner so that the system’s relational capabilities can manage the DB.
Rule 1: The Information Rule
A DB comprises a variety of data, which must be recorded in the form of columns and rows in each and every cell of a table.
Rule 2: The Guaranteed Access Rule
A relational DB’s primary key value, column name, and table name can be used to conceptually retrieve any single or precise data (the atomic value).
Rule 3: The Systematic Treatment of Null Values
The treatment of Null values in DB records is defined by this rule. No value in a cell, missing data, unsuitable information, unknown data, the primary key that should not be null, etc., are all examples of null values in DBs.
Rule 4: The Dynamic/Active Online Catalog on the basis of the Relational Model
A DB dictionary is a logical representation of the whole logical structure of a descriptive DB that needs to be stored online. It grants users access to the DB and uses a query language that is comparable to that of the DB.
Rule 5: The Comprehensive Data SubLanguage Rule
The relational DB supports a variety of languages, and in order to access the DB, the language has to be linear, explicit, or a well-defined syntax, character strings. It must support the following operations: view definition, integrity constraints, data manipulation, data definition, as well as limit transaction management. It is considered a DB violation if the DB permits access to the data and information without the use of any language.
Rule 6: The View Updating Rule
A view table can theoretically be updated, and DB systems must update them in practice.
Rule 7: The Relational Level Operation (or High-Level Insert, Delete, and Update) Rule
In each level or single row, a DB system should adhere to high-level relational operations (for example, update, insert, and delete). The DB system also includes operations like intersection, union, and minus.
Rule 8: The Physical Data Independence Rule
To access a DB or an application, all stored data must be independent physically. Each piece of data should not be reliant on another piece of data or an application. External applications that access data from the DB will have no effect if data is altered or the physical structure of a given DB is modified.
Rule 9: The Logical Data Independence Rule
It’s similar to the independence of physical data. It indicates that any modifications made at the logical level (or the table structures) should not have an impact on the user’s experience (application). For example, if a table is split into two separate tables or into two table joins in order to produce a single table, the application at the user view should not be affected.
Rule 10: The Integrity Independence Rule
When we are using SQL to put data into table cells, a DB must guarantee integrity independence. All the entered values must not be changed, and the integrity of the data should not be reliant on any external component or application. It’s also useful for making each front-end app DB-independent.
Rule 11: The Distribution Independence Rule
This rule denotes that a DB must function properly even if it’s stored in multiple locations and used by various end-users. Let’s say a person uses an application to access the DB. In such a case, they must not be aware that another user is using the same data, and thus, the data they always obtain is only available on one site. The DB can be accessed by end-users, and each user’s access data must be independent in order for them to run SQL queries.
Rule 12: The Non-Subversion Rule
RDBMS is defined by this rule as a SQL language for storing and manipulating data in a DB. If a system uses a low-level or different language to access the DB system other than SQL, it should not bypass or subvert data integrity.
Keep learning and stay tuned to get the latest updates on the GATE Exam along with GATE Eligibility Criteria, GATE Syllabus for CSE (Computer Science Engineering), GATE CSE Notes, GATE CSE Question Paper, and more.
Also Explore,
Comments