The Relational Model

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:

• tables
• relations

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.

Tables

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

It is organized in rows and columns:

Tuples

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:

Attributes

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:

• avoiding deleting or editing the primary key of the record that we point to, in the other table.
• avoid inserting a new record with a non-existing key to point to in the other table.
• avoid changing the key of the record we point to, without ensuring that the new key exists in the other table.

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