Codd’s 12 Rules: The Foundations of Relational Databases
Краткое содержание
Pixel’s announcement explores the principles behind relational databases, from organizing student, course, and attendance data in tables to connecting records through relationships. It introduces Codd’s Rules, including the numbering from Rule 0 to Rule 12, and explains why these principles matter for understanding RDBMS design.
DEV Community
The 12 Rules That Shaped Relational Databases
Whenever we use an application, whether it's a banking app, an online shopping platform, or a college management system, a lot of information is stored and managed behind the scenes. But have you ever wondered how databases organize this information? And what actually makes a database relational? To understand this, let's go back to 1970, when computer scientist Edgar F. Codd introduced the relational model of databases. His idea transformed how we organize, store, and manage information. Later, Codd proposed a set of rules to describe what a true Relational Database Management System (RDBMS) should support. These principles are commonly known as Codd's 12 Rules. Let's understand them through a simple, real-world example. Imagine a college management system that stores: Student details Course information Attendance records Examination marks How should such a database organize and manage all this information? Let's explore. First, What Is a Relational Database? A relational database organizes information into tables. Each table contains rows and columns. For example, imagine a Students table: Student_ID Student_Name Department 101 Arun CSE 102 Priya AIML 103 Rahul ECE Here: Each row represents one student. Each column represents a particular type of information. Student_ID helps uniquely identify each student. We can also create separate tables for courses, attendance, and examination marks. These tables can be connected through relationships between their data. This is the basic idea behind a relational database. But Edgar F. Codd wanted to go beyond simply storing information in tables. He wanted to establish principles that relational database systems should follow. Understanding Codd's 12 Rules Before we begin, here's an interesting detail: Codd's rules are numbered from Rule 0 to Rule 12. So, although they are commonly called the 12 Rules, there are actually 13 numbered rules when Rule 0 is included. Let's understand each one. Rule 0 – The Foundation Rule A database system must manage its data entirely through its relational capabilities. In simple words: If a system claims to be a relational database, it should use the relational model to manage and access its data. Real-world example: Imagine our college management system uses relational tables to store student information. The system should manage that information through its relational database capabilities rather than depending on an entirely different mechanism for its core database operations. Rule 1 – The Information Rule All information in a relational database should be represented logically and consistently as values in tables. In simple words: Information should be represented in one consistent relational form. Real-world example: Student names, registration numbers, departments, and marks are stored as values in their respective table columns. The database should represent its information in this consistent tabular form. Rule 2 – Guaranteed Access Rule Every individual data value should be accessible using a combination of the table name, primary key value, and column name. In simple words: We should have a reliable way to find any particular piece of information. Real-world example: Suppose we want to find the department of the student whose Student_ID is 101. We can identify the information using: Table: Students Primary key: 101 Column: Department This gives us a clear and reliable way to access the required value. Rule 3 – Systematic Treatment of NULL Values A relational database should handle missing or unknown information consistently. In databases, NULL represents the absence of a known or applicable value. It is not the same as zero or an empty string. Real-world example: Imagine a student has not yet received their examination result. Instead of entering zero marks, the database can store NULL because the result is not yet available. This helps distinguish missing information from an actual result of zero. Rule 4 – Dynamic Online Catalog Based on ...

Powered by Readybot.io