Introduction
The relational model, introduced by Edgar F. Codd in 1970, is the foundational theory behind most databases in use today. Instead of organizing data as nested records or free-form documents, the relational model represents all data as relations — which, in practice, are simply tables made up of rows and columns.
Cricket analogy: Just as Sunil Gavaskar helped establish modern batting technique in the 1970s, Edgar Codd in 1970 established the relational model, replacing messy nested scorecards with clean tables of rows (innings) and columns (runs, balls, fours).
This simple, uniform structure turned out to be extremely powerful: it lets you describe complex relationships between different kinds of data (customers, orders, products) using a small, consistent set of concepts, and it lets you query that data using declarative languages like SQL instead of writing custom retrieval code.
Cricket analogy: The same simple table structure can describe batsmen, matches, and venues together, and instead of writing custom code to find "all centuries at Lord's," you simply declare the question in SQL and let the engine fetch it.
Key Concepts
In relational terminology: a 'relation' is a table, a 'tuple' is a row (a single record), and an 'attribute' is a column (a named field with a specific data type). Every table has a schema that defines its columns and their types. Rows in one table can reference rows in another table through keys, which is how the relational model represents relationships without duplicating data.
Cricket analogy: A "relation" is the scorecard table, a "tuple" is one batsman's row, and an "attribute" is a column like runs or strike rate; the schema fixes those column types, and each innings row links to the match table by match_id instead of repeating the venue name.
A 'relation' in the mathematical sense (from set theory) is what we casually call a table. The word 'relational' refers to this formal structure, not directly to 'relationships between tables' — though relationships between tables are also a central feature of relational databases.
Example
-- Two related tables: customers and orders
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
full_name VARCHAR(100) NOT NULL
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INTEGER REFERENCES customers(customer_id),
order_total NUMERIC(10, 2) NOT NULL,
order_date DATE DEFAULT CURRENT_DATE
);
-- Query that combines data across both relations
SELECT c.full_name, o.order_total, o.order_date
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id;Analysis
Here, customers and orders are two separate relations. The orders.customer_id column is a foreign key that references customers.customer_id, linking each order tuple to exactly one customer tuple without storing the customer's name redundantly inside the orders table. The JOIN in the query reconstructs the connection at query time. This separation — store data once, link it by key, combine it when needed — is the essence of the relational model and is what allows data to stay consistent as it grows.
Cricket analogy: Players and matches are separate relations; the innings.player_id foreign key references players.player_id, so a century isn't stored with the player's full bio -- the JOIN reconstructs the link only when the scorecard report is generated.
Key Takeaways
- The relational model represents all data as relations (tables) of tuples (rows) and attributes (columns).
- Relationships between tables are expressed through keys, not by duplicating data.
- Data is stored once and combined at query time using operations like JOIN.
- The relational model is declarative: you describe what data you want, not how to fetch it step by step.
Practice what you learned
1. In relational model terminology, what is a 'tuple'?
2. How does the relational model typically represent a relationship between two tables, such as customers and orders?
3. Who introduced the relational model, and in what decade?
4. What does it mean for SQL to be a 'declarative' query language in the relational model?
Was this page helpful?
You May Also Like
Introduction to Databases
Learn what a database is, why software applications need one, and how databases evolved from flat files to modern systems.
Primary and Foreign Keys
Understand how primary keys uniquely identify rows and foreign keys enforce relationships between tables.
Normalization: 1NF to 3NF
Learn the step-by-step process of eliminating data redundancy and anomalies through the first three normal forms.