Due to the issues of the hierarchical and network models, they were model replaced by relational models as the third generation starting in the mid-1970s. The simplicity of the model made it quite easy to use and it is a big reason why it is still so heavily used even today. The relational model’s foundation came from the concept of a relation as a mathematical concept. 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.
The relational model was introduced by E.F. Codd from IBM. He had written a paper called “A Relational Model of Data for Large Shared Databanks” in the 1970s. This model was viewed as a technical breakthrough for users and designers of the database. It is one that model that is still consistently used for many databases.
When the model was created in the 1970s, the relational model created by E.F. Codd was an amazing solution but impractical as it simplified the concepts 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 relational database software that you see today.
These relational data models are implemented through a complex relational database management system (RDBMS) that we have looked at in a prior tutorial. The RDBMS itself helps hide the complexities of the relational model from the user so the user only sees the relational database as a collection of tables where the data is stored. All the underlying physical features of the model are completely hidden away.
The relationships in a relational model can be set up as one-to-one or one-to-many. Many-to-many relationships would be broken down into two one-to-many relationships with a table representing the many-to-many in between. The relational table is very similar to the concept of a file but the table has complete data and structural independence. This means how the data is physically stored in the database does not matter to the developer or end-user. With the relational data model, this is where we also started to see the use of the Structured Query Language (SQL) with the DML and DDL statements that originated from the network model that we discussed in the prior tutorial.
Think about how you interact with the database that we use, when you execute a SELECT statement, you do not have to know how it is gathering the data and processing it behind the scenes. Imagine if you had to create the code to pull the data from the tables and sort the data accordingly, this is a big reason why the network model added too much complexity. You as an end-user just specify what must be done without having to define how it is done. The use of SQL with the relational model makes it a lot easier to retrieve the data than in any other database that preceded it.
From a user perspective, any SQL-based relational database consists of three parts. The end-user interface is the first part where you would be able to interact with the data through the SQL code. For us, this would be through the web interface. There are many different types of user interfaces that can be used to connect to the same database. The second part would be 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. 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.