Only custom-written papers / Professional writers / Always on-time delivery
Database models continue to evolve as the information management needs of organizations become more complex. From flat files to relational databases, the growing demands on data integrity, reliability and performance of database management systems (DBMS), has shaped the design of databases and their underlying models. In this document, three database models are discussed comparing and contrasting their major features. The three models in order of discussion are Hierarchical, Network and Relational database models.
Hierarchical Database Model
The hierarchical model is the oldest of the three models discussed here. This model is an improvement of the flat-file database system since it employs a simple data relationship scheme. The relationships in the hierarchical model are child/parent relationships. The name “hierarchical” is derived from one major restriction on the child/parent relationships, that is, although a parent entity can have several child entities, a child entity can only have one and only one parent. For this reason all the relationships form a hierarchy that traces back to one root. In fact, this model is often visualized as an upside down tree, where the entity at the top is seen as a root and as such all other entities sprout from the root. A simple example is shown in Figure 1 below:
“Products” in Figure 1 above is the root entity of the hierarchical model in the example.
As shown in the diagram, one major problem with the hierarchical model is the increased risk of data inconsistency. In the case above, a separate “Customers” table must exist for every product line due to the fact that a child entity cannot have more than one parent. However, there is a great chance that there are many customers who purchased more than one type of product. Consequently, information about those customers must exist in more than one table causing data redundancy. Another problem with the hierarchical model is the inflexibility of the model. For example, in the diagram above, the database is restricted to three product lines. Adding a new product line would require redesigning the database since all the relationships must be predefined. Finally, another problem with the hierarchical model is in the child/parent relationship restriction. Every child must have a parent. Therefore, in the example above, it is impossible to add new customers who have not bought any new products yet. To overcome some of the limitations of the hierarchical model, the network model was created.
Network Database Model
The network model is an improvement to its predecessor, the hierarchical model. In the network model, a child entity can have more than one parent. Therefore, the design can be visualized as several inverted trees interconnected by branches as opposed to the single inverted tree characteristic of the hierarchical model. Figure 2 below illustrates the network database model of the hierarchical database discussed previously.
As shown above, the network database model eliminates the need to maintain several “Customers” tables. Data in the network model can be accessed from an entity as opposed to the hierarchical model that requires access from the root entity. The relationships between entities occur through unique set structures. Therefore, although the entities are not duplicated, a unique set structure is required to facilitate each of the one-to-many relationships.
Like the hierarchical model, the network model is also navigational. This poses a big problem in complex designs since the user has to understand the database structure in order to us the database. Furthermore, with a predefined structure like in the hierarchical model, modifying the structure of the database becomes a difficult task. The relational model eliminates many of the problems presented in the network and hierarchical models.
Relational Database Model
The relational model is based on the mathematical set theory. In this model, “data is stored in relations which are perceived by the user as relations” (Hernandez, 1997). Relations are made up of tuples (also referred to as records or rows) and attributes (also known as fields or columns). Each record is identified by a column with a unique value. The order of the rows and columns is of importance. Therefore, the relational model is independent of physical implementation, a quality that makes this model more preferable to the hierarchical and database models. Relationships in this model can be one-to-one, one-to-many, or many-to-many. Regardless of the type of relationship, the model is transparent to the user, that is, the user does not need to understand the physical structure of the database in order to use it.
Relational databases also have their share of problems. The flexibility of the relational model comes with the price of performance speed since the relationships are not predefined like in the case of hierarchical and network databases. Flexibility, also introduces the complexity of enforcing integrity constraints. However, the existence of scientific rules for imposing integrity guarantees that database integrity can be ensured.
To sum it up, Table 1 below provides a concise analysis of the major differences between the hierarchical, network and relational database models. It is important to note that although the relational model is superior to its predecessors, there are situations that would warrant the use of the older models, especially where the application is simple and not likely to change.
Table 1: Major differences of the hierarchical, network and relational database models
Hierarchical Model Network Model Relational Model
Data access Navigational. Usually accessed from the root. User is required to understand database structure. Navigational. However, data access can start from an entity. User is required to understand database structure. Non-navigational. Database structure is completely transparent to the user.
Performance Faster because structure is predefined. Faster because structure is predefined. Slower because of the flexible arbitrary structure.
DBMS Not compatible with the other two models. Changes to the database structure must be reflected in the application as well. Compatible with the other two models. However, changes to database structure usually require changes in the application. Compatible with the other two models. The database structure is transparent.
Queries No query language unless it is predefined in to application. User needs to know the structure in order to query information. Versatile query language. Includes ability to run ad hoc queries.
Data integrity Plagued with redundancy due to the child/parent limitations Less redundancy than the hierarchical model. Since the network model is navigational it becomes harder to maintain integrity as the database’s complexity increases. Logical rules guarantee imposition of integrity constraints.
Changes Changes to the structure are difficult to implement since the entire structure is predefined. Changes to the structure are difficult to implement since the entire structure is predefined. Changes are easy to implement since the structure is transparent to the user and the application.