Relational Model

Overview

The relational model, introduced by Edgar F. Codd in his 1970 paper "A Relational Model of Data for Large Shared Data Banks," represents data as a collection of relations (tables) — each relation is a set of tuples (rows) with a fixed set of attributes (columns). Its foundational idea is data independence: you describe data logically (what tables and constraints exist) and query it declaratively, while the DBMS decides how to physically store and access it. This is a direct rejection of the hierarchical and network models' navigational, pointer-chasing approach.

How it works — a worked example

Students(student_id PK, name, dept_id FK)
Courses(course_id PK, title, credits)
Enrollments(student_id FK, course_id FK, grade, PRIMARY KEY(student_id, course_id))

To answer "which courses did Alice take, and what grades did she get," you don't navigate pointers — you write a declarative query:

sql
SELECT c.title, e.grade
FROM Students s
JOIN Enrollments e ON s.student_id = e.student_id
JOIN Courses c ON e.course_id = c.course_id
WHERE s.name = 'Alice';

The optimizer decides the join strategy and access path; you only state what you want. Foreign keys enforce referential integrity, and normalization (1NF/2NF/3NF/BCNF) eliminates redundancy: a student's name is stored once, not duplicated in every enrollment row (unlike the duplication problem in the hierarchical model).

Edge cases and trade-offs

• Many-to-many is trivial and clean: a junction/associative table like Enrollments naturally represents it — no duplication, no rigid predefined "sets" like the network model required.
• ACID transactions (Atomicity, Consistency, Isolation, Durability) are a hallmark strength, making relational databases the default choice for financial and transactional systems.
• Impedance mismatch: application code is usually written in object-oriented languages, but relational tables don't map 1:1 to objects/classes (an object's list-valued field needs a separate table + join). This mismatch is exactly what the Object-Relational (3.5) and Document (3.6) models try to reduce.
• Rigid schema, vertical scaling bias: adding a column to a huge table can be an expensive migration, and traditional RDBMS scale primarily by adding more powerful hardware (vertical scaling) rather than easily sharding across many cheap servers — a major reason NoSQL models emerged for very large, distributed workloads (see 3.10).
• Over-normalization can hurt performance: many joins across normalized tables can be slower than a single denormalized document read, which is one reason document databases exist for read-heavy, deeply nested data.