Relational Models

1. Historical Background

Owing to the issues of the hierarchical and network models, they were replaced by a relational model beginning in the mid-1970s. The simplicity of the relational model made it quite easy to use, which is a big reason why it is still so commonly used even today. The relational model’s foundation was based on mathematical set theory and the idea of representing data as independent relations. A relation, which you know as a table, is just a structure that has rows and columns. Each row is called a tuple (a record) and each column represents an attribute. This model was viewed as a technical breakthrough for users and designers of the database.

did you know

The relational model was introduced by E.F. Codd from IBM, who wrote a paper called “A Relational Model of Data for Large Shared Databanks” in the 1970s.

When the model was created in the 1970s, it was somewhat impractical as it simplified the concepts at the expense of the computing overhead. However, computing power grew exponentially, as did the operating system’s efficiency, which allowed many different companies to implement the relational database software that you see today.

2. Model Features

Relational data models were implemented through a complex relational database management system (RDBMS), which we've looked at in a prior tutorial. The RDBMS helps to hide the complexities of the relational model from the user, so that the user only sees the relational database as a collection of tables where the data is stored. All of the underlying physical features of the model are completely hidden.

The relationships in a relational model can be set up as one-to-one or one-to-many. Many-to-many relationships are broken down into two one-to-many relationships, with a table representing the transition between the many-to-many relationships. The relational table is very similar to the concept of a file, but the table has complete data and structural independence. This means that how the data is physically stored in the database does not matter to the developer or end user.

The relational data model is where you start to see the use of Structured Query Language (SQL) with the Data Manipulation Language (DML) and Data Definition Language (DDL) statements that originated from the earlier network model. Recall that the network model, though, contained too much complexity, requiring programmers to create the code to run even the simplest reports.

think about it

In contrast, think about how you have interacted with the Postgres database. When you execute a SELECT statement, you do not have to know how it is gathering the data and processing it behind the scenes. As an end user, you need only specify what must be done, without having to define how it is done. The use of SQL with the relational model made it a lot easier to retrieve data than in any other database that preceded it.

3. Parts of a Relational Database

From a user perspective, an SQL-based relational database consists of three parts.

1. The end-user interface is the part where you can interact with the data through the SQL code. For us, this is through the web interface. There are many different types of user interfaces that can be used to connect to the same database.
2. The second part is the collection of tables that are presented to the end user. Each of those tables is independent of one another, and the rows in the tables are related to each other through some common values in common attributes.
3. The last part is the SQL engine. This is the part that is mostly hidden away from the end user. The SQL engine is part of the database management software that runs all of the SQL queries and data requests.