Skip to content

The Relational Model

New Course Coming Soon:

Get Really Good at Git

The Relational Model is the most popular of the logic data models listed in the Data Models post, and it's at the basis of SQL databases.

The Relational Model is the most popular of the logic data models, and it’s at the basis of SQL databases.

The Relational Model is based on two simple concepts:

The relational model dates back to 1969 and the work of Edgar F. Codd, an English computer scientist. Although as computer programmers we’re used to look with curiosity at new shiny things, a technology that can be central in everything about computers for 50 years is definitely worth studying.

The fact that the model is based upon tables makes it very intuitive to use, because we are used to using tables to organize things. Think about an Excel spreadsheet, for example.

With SQL-based databases, like PostgreSQL, Oracle, MySQL, SQLite and MS SQL Server, and many others, the data analyzed using the ER Model can be modeled using the relational model and be almost immediately transformed into a SQL database format, which can be considered a real-world implementation of the relational model, but we’ll talk about this in other posts.

In this post I want to talk about the theory and the concepts that the relational model is based upon, not expressed in mathematical terms but what it means in practice.

If you’re a student, you might find that what I write here is not what is written on your textbook, but maybe you can read it more easily to grasp the more formal concepts expressed in your learning material.


In a relational model, a table is a collection of items.

It is organized in rows and columns:



Each entry in the table is called a tuple. You can also use the terms record or row.

A tuple represents a row of the table, like this:



An attribute is one single item in the tuple.

In this example:


”Flavio” is an attribute. 36 is another attribute.

Tuples are unique

Every tuple in the table is unique.

In the relational model, we can’t have duplicate data, meaning every row in the table must be different in at least one attribute.

The relation key

The thing that ensures a tuple is unique is the relation key.

The key is one attribute that must uniquely identify a tuple.

If the relation key is a set of attributes, it must be non-redundant. This means that if we remove one of the attributes of the key, the key can’t guarantee its uniqueness.

If more than one keys can be determined, one of those keys will be identified as the primary key.

Key integrity constraint

They key attribute(s) of any tuple in the table must never be null, and must never repeat.

Given a key, we must be able to point to a specific tuple/row without ambiguity.

The domain constraints

Every attribute has rules about what value it can hold.

If we decide to store numbers, we can’t store strings, for example. And we might decide to not store strings longer than 10 characters for names.

We can also call this type.

The referential integrity constraint

If a table contains reference to a secondary table, or other tuples in the same table, then we must abide to rules that prevent the reference to break.

In particular, we must avoid breaking the reference by:

A DBMS (Data Base Management System) will implement measures to help us implement referential integrity.

Are you intimidated by Git? Can’t figure out merge vs rebase? Are you afraid of screwing up something any time you have to do something in Git? Do you rely on ChatGPT or random people’s answer on StackOverflow to fix your problems? Your coworkers are tired of explaining Git to you all the time? Git is something we all need to use, but few of us really master it. I created this course to improve your Git (and GitHub) knowledge at a radical level. A course that helps you feel less frustrated with Git. Launching May 21, 2024. Join the waiting list!
→ Read my SQL Tutorial on The Valley of Code

Here is how can I help you: