The relational model represents data as tables (relations) with rows (tuples) and columns (attributes). Each table has a schema defining column names and types. The relational model is based on mathematical set theory and provides a simple, powerful way to organize and query data.
Practice translating real-world concepts into tables—create schemas for a library, university, or e-commerce system and identify what entities and relationships need to be represented.
The relational model is not the same as having tables in a spreadsheet. Relational databases enforce constraints, support complex queries, and manage relationships between tables systematically.
From your introduction to database systems, you know that databases provide structured, persistent storage with guarantees that file systems and spreadsheets cannot offer. The relational data model is the theoretical foundation that makes those guarantees precise. At its core, a relation is a table — but not the loose, anything-goes kind you find in a spreadsheet. A relation has a fixed schema that declares the column names and their data types, and every row in that table must conform to the schema exactly. You cannot sneak a date into an integer column or leave a required field empty. This rigidity is the source of the model's power.
Each row in a relation is called a tuple, and each column is an attribute. A tuple represents a single fact — one student, one course enrollment, one sales transaction — and the combination of its attribute values distinguishes it from every other tuple. The mathematical ancestry matters here: if you recall the Cartesian product from your prerequisites, a relation is a subset of the Cartesian product of its attribute domains. A Students table with columns (name: string, age: integer, major: string) draws its rows from string × integer × string, but only the rows that represent actual students. This set-theoretic foundation is why relational operations — selection, projection, joining — are so well-defined and composable.
The key insight that separates the relational model from earlier approaches (hierarchical and network databases) is data independence: the logical structure of your data is separated from how it is physically stored. You describe *what* data you want, not *how* to retrieve it. When you design a relational schema, you are modeling the entities in your domain (students, courses, enrollments) and the relationships between them (a student enrolls in a course) as tables with columns. Each entity type gets its own table, and relationships are expressed by shared attribute values across tables — a student_id column appearing in both the Students table and the Enrollments table.
This structure may feel rigid compared to dumping everything into a single spreadsheet, but that rigidity is the point. Because every table enforces its schema, because every operation has precise mathematical semantics, and because the model separates logical design from physical storage, you can query data in ways the original designers never anticipated, restructure storage without breaking applications, and trust that constraints you declare will be enforced consistently. The relational model trades flexibility at the individual-cell level for reliability at the system level — and for nearly every structured data problem, that trade is overwhelmingly worth it.