Evolution of Database Models

Before the advent of databases, the only way to store data was from unrelated files. Programmers had to go to great lengths to extract the data, and their programs had to perform complex parsing and relating. Accessing the data from files is a challenging task. 

Without a standard way to access data, systems are more prone to errors, are slower to develop, and are more difficult to maintain. Data redundancy (where data is duplicated unnecessarily) and poor data integrity (where data is not changed in all locations, leading to wrong or outdated data being supplied) are frequent consequences of the file access method of data storage.

For these reasons, database management systems (DBMS) were developed to provide a standard and reliable way to access and update data. They provide an intermediary layer between the application and the data, and the programmer is able to concentrate on developing the application, rather than worrying about data access issues.

A database model is a logical model concerned with how the data is represented. Instead of database designers worrying about the physical storage of data, the database model allows them to look at a higher, more conceptual level, reducing the gap between the real-world problem for which the application is being developed and the technical implementation.

Hierarchical Database Model

The earliest model was the hierarchical database model, resembling an upside-down tree. Files are related in a parent-child manner, with each parent capable of relating to more than one child, but each child only being related to one parent.

It is similar to how most file systems work. There is usually a root, or top-level, directory that contains various other directories and files. Each sub directory can then contain more files and directories, and so on. Each file or directory can only exist in one directory itself - it only has one parent.

This model has some serious disadvantages. It represents one-to-many relationships well (one parent has many children; for example, one company branch has many employees), but it has problems with many-to-many relationships. Relationships such as that between a product and orders are difficult to implement in a hierarchical model. Specifically, an order can contain many products, and a product can appear in many orders.

Also, the hierarchical model is not flexible because adding new relationships can result in complete change to the existing structure, which in turn means all existing applications need to change as well.

Network Database Model

The network database model was a progression from the hierarchical database model. Instead of only allowing each child to have one parent, this model allows each child to have multiple parents (it calls the children members and the parents owners).

It is more difficult to implement and maintain, and, although more flexible than the hierarchical model, it still has flexibility problems.

Relational Database Model

The relational database model was a huge leap forward from the network database model. Instead of relying on a parent-child or owner-member relationship, the relational model allows any file to be related to any other by means of a common field

The complexity of the design was greatly reduced because changes could be made to the database schema without affecting the system's ability to access data. Because access was from a direct relationship between files, new relations between these files could easily be added.

Relational databases go hand-in-hand with the development of SQL. The simplicity of SQL is a large part of the reason for the popularity of the relational model.

Any two tables can relate to each other simply by creating a field they have in common.

 

Subscribe for Free Updates

Please enable the javascript to submit this form