On this page
When you write SELECT name FROM student WHERE marks > 80, you never say where the data sits on the disk, in what order, or how to find it. The database works that out. That freedom is not an accident of software. It was the central argument of a 1970 paper by Edgar Codd, and it is why the tables, keys and relations in your CBSE computer science syllabus look the way they do. This post explains his idea with a worked example.
Who was Edgar Codd?
IBM's history page on Codd gives the outline. He was born in 1923 on the Isle of Portland in Dorset, England, and earned mathematics and chemistry degrees from Exeter College, Oxford. He flew with the Royal Air Force in the Second World War, moved to New York in 1948, and joined IBM a year later as a mathematical programmer. In 1970 he was working at the IBM San Jose Research Laboratory in California.
What problem did the relational model solve?
Codd's paper, A relational model of data for large shared data banks, published in Communications of the ACM in June 1970, opens with the problem. Its abstract says future users of large data banks "must be protected from having to know how the data is organized in the machine". Programs and users at terminals should keep working even when the internal representation of the data changes.
The systems of the time, the abstract says, gave users tree-structured files or slightly more general network models. In those, a program often had to follow the path the data was stored along. Change the storage and the programs broke.
Codd proposed instead a model based on n-ary relations, a normal form for database relations, and a universal data sublanguage. In plain words: store everything as tables, keep the tables tidy, and use one general language to ask questions of them.
How does the relational model work, in a worked example?
Here is a table with sample data that breaks Codd's rules.
(R01, Asha, 12A, Physics, Mr Rao)
(R01, Asha, 12A, Chemistry, Ms Iyer)
(R02, Vikram, 12B, Physics, Mr Rao)
The columns are RollNo, Name, Class, Subject, Teacher. Problems:
Redundancy. Asha's name and class are stored twice. Mr Rao's link to Physics is stored twice.
Update anomaly. If Asha moves to 12B and you change only one row, the data now contradicts itself.
Deletion anomaly. Delete Vikram's only row and you may lose the fact that Mr Rao teaches Physics.
Split it into three relations.
Student(RollNo, Name, Class): (R01, Asha, 12A), (R02, Vikram, 12B). Primary key: RollNo.
Subject(Subject, Teacher): (Physics, Mr Rao), (Chemistry, Ms Iyer). Primary key: Subject.
Enrolment(RollNo, Subject): (R01, Physics), (R01, Chemistry), (R02, Physics). RollNo and Subject are foreign keys.
Now each fact is stored once. Counting cells: the original table held 3 rows × 5 columns = 15 values. The split holds 2 × 3 + 2 × 2 + 3 × 2 = 6 + 4 + 6 = 16 values. With three rows, splitting saves nothing. Now scale up with sample numbers: 1,000 students, each taking 5 of 10 subjects. The single table needs 5,000 rows × 5 columns = 25,000 values. The split needs Student 1,000 × 3 = 3,000, Subject 10 × 2 = 20 and Enrolment 5,000 × 2 = 10,000, a total of 13,020 values, and every name, class and teacher is stored exactly once. Tidy design pays off as data grows.
The original rows come back with a join: match Enrolment to Student on RollNo and to Subject on Subject. Our guide to SQL basics for CBSE shows how to write that join.
How did the idea become SQL?
The IBM page says the system had to be tested, and that a group of programmers in 1973 began an implementation called System R. The team included Don Chamberlin, who with Raymond Boyce created Structured Query Language (SQL), and Patricia Selinger, who developed a cost-based optimiser. IBM's DB2 first shipped in 1983. The same page notes that Relational Software, later renamed Oracle, produced the first commercially available relational database in 1977.
Codd received the ACM Turing Award in 1981. His Turing Award lecture, published in 1982, records that he was cited for "fundamental and continuing contributions to the theory and practice of database management systems", and credits him with relational algebra, relational calculus and normalisation as well as the model itself. He died in 2003.
What mistakes do students make with relational ideas?
Treating a relation as any table. In the relational model, every row is unique and each cell holds one value. A cell containing "Physics, Chemistry" breaks the rule.
Confusing primary and foreign keys. A primary key identifies a row in its own table; a foreign key points to a primary key in another table.
Thinking the row order matters. Relations have no built-in order. Use ORDER BY when you need one.
What can a student take from Codd's way of working?
Name the real problem. His abstract starts with users, not machines.
Use mathematics to make software simpler. Relations come from set theory; the payoff was everyday practicality.
Expect ideas to need builders. Codd's paper needed System R and SQL to change the industry.
If a step in a query or a key relationship confuses you, the Fermi Concept Library explains every concept in computing alongside physics, chemistry, biology and mathematics. For the exam terms, read our guide to database concepts for CBSE.
Next step: take any table from your practical file, find one repeated fact, and split it into two relations with a key.
