Exploring Different Approaches to Database Design: From Hierarchical to Relational Models

Every time you search a library catalogue, withdraw cash from an ATM, or check your exam results on a university portal, a database is working quietly behind the scenes. But databases were not always built the same way. Over the last six decades, computer scientists have proposed several distinct approaches to organising data, each solving the problems left behind by the one before it. Understanding these approaches, from the early hierarchical model to the dominant relational model, helps you grasp not just how data is stored, but why modern information systems are so flexible and reliable.

What we mean by a database 🔗

Before comparing approaches, it helps to settle on what a database actually is. At its simplest, a database is a collection of related pieces of data organised to meet the data management needs of an institution. Other definitions describe it as a shared collection of logically related data designed to serve multiple users. A telephone directory, a card index in a library, and a spreadsheet of student marks all qualify as databases in this broad sense.

The key idea is that the data is logically related and organised. Random, disconnected facts do not make a database. The information must serve a defined purpose and be structured so it can be searched, retrieved, and updated efficiently.

Database versus database system 🔗

A common point of confusion is treating the words “database” and “database system” as the same thing. They are not. According to the standard computing definition, the database is the organised collection of data itself, while the software that interacts with users, applications, and the data is called a Database Management System (DBMS). The combination of the database, the DBMS, and the associated applications together forms a complete database system.

Think of it this way: the database is the content, the DBMS is the tool that manages that content, and the database system is the whole working arrangement. The DBMS handles core tasks such as data storage, retrieval, security, concurrency control, backup and recovery, and query processing. This distinction matters because the “approaches to database” we discuss next are really approaches to how the data is structured and how the DBMS organises relationships between records.

The hierarchical model: data in a tree 🔗

The hierarchical model was one of the earliest approaches to database design. It was developed by IBM in the 1960s and used in early mainframe DBMS software, where records were arranged in a tree-like structure. In this arrangement, the topmost record is the root, and every other record connects to a single parent through branches.

The defining rule of the hierarchical model is that each child node has exactly one parent, while a parent can have many children. This makes it excellent for representing one-to-many relationships. Consider a university record where the department is the parent, courses are its children, and enrolled students sit below each course. To retrieve any piece of information, the system traverses the tree from the root downward.

Strengths and limitations 🔗

The hierarchical approach offers fast navigation when the access path is predictable and the data naturally forms a strict hierarchy, such as file systems or organisational charts. However, the model has a serious weakness. Many-to-many relationships require data duplication or redesign, and the structure is rigid. One early criticism was the model’s close dependence on application-specific implementation, which meant programs could break whenever the data structure changed.

The network model: allowing many parents 🔗

The network model emerged as an improvement over the hierarchical approach, addressing its biggest limitation. It uses directed graphs instead of a strict tree, which allows a child record to have more than one parent. This single change made it possible to model many-to-many relationships naturally, something the hierarchical model could not handle gracefully.

The network model was formally defined by the Conference on Data Systems Languages (CODASYL) in 1971. Its core building block is the set construct, where a set consists of an owner record type, a set name, and a member record type. In this terminology, parent records are owners and child records are members.

Returning to a library example, a single book could belong to several categories at once, such as fiction, mystery, and bestseller, without the data being duplicated. The trade-off is complexity. The network approach offers more flexibility, but navigating it requires detailed knowledge of the database structure, and applications remain tightly coupled to how the data is physically linked.

The relational model: organising data into tables 🔗

The breakthrough came in 1970, when Edgar F. Codd, a mathematician at the IBM San Jose Research Lab, published “A Relational Model of Data for Large Shared Data Banks”. Codd proposed something radical for its time: store information in simple two-dimensional tables, with columns of related data linking one table to another, instead of relying on rigid hierarchies and complex navigational pointers.

In the relational model, a table (formally called a relation) stores facts about one subject. Each row, or tuple, is a single record, and each column, or attribute, is a named property of that record. Relationships between tables are expressed logically using shared values known as keys, rather than through physical links. The relational model remains the most widely adopted database model precisely because of this elegant simplicity.

Why the relational model won 🔗

Codd’s model was initially met with skepticism and even lower performance than the existing network and hierarchical systems. Yet it gradually came to dominate. Relational databases allow ad hoc querying and reporting using SQL-based languages, which means users can ask questions of the data without predicting every query in advance. This was a decisive advantage over the older models, which forced designers to anticipate access paths during the design phase.

Codd later refined his ideas into twelve rules that a DBMS must follow to be considered truly relational, covering principles such as guaranteed access to all data and systematic treatment of null values. Most relational systems in use today, including the engines behind banking, e-commerce, and government record systems in India, descend directly from this work.

Data independence and application versatility 🔗

The single most important idea Codd introduced was data independence. The hierarchical and network models tightly coupled the data to its physical storage, so any change to the structure could break the programs that relied on it. The relational model separated the logical structure of data from the physical storage details, allowing applications to interact with data without knowing how it was stored on disk.

This separation comes in two forms. Physical data independence means changes to how data is stored, such as new hardware or file organisation, do not affect the logical structure or the way applications access it. Logical data independence means changes to the schema can be made without rewriting the application programs that depend on it.

Why this matters for real systems 🔗

Data independence is what makes modern databases so versatile. In Codd’s own words, the goal was the independence of application programs from growth in data types and changes in data representation. Before this, a programmer was forced to act almost like a navigator, manually charting a path through linked records. If the structure changed, the program failed.

With a relational database, a single centrally managed database can be shared by many applications at once, and the data layout can be reorganised for performance without disturbing any of them. A university could add a new column to its student table, switch its storage hardware, or build a fresh reporting tool, all without breaking the admissions portal or the examination system that already use the same data. That flexibility, more than raw speed, is why the relational approach reshaped how institutions handle information.

How the three approaches compare 🔗

Each model represents a different philosophy about how data should be structured. The hierarchical model is the most rigid but offers fast, predictable navigation for naturally tree-shaped data. The network model adds flexibility by supporting many-to-many relationships, at the cost of greater complexity and a steep learning curve. The relational model trades the older models’ navigational efficiency for ease of use, powerful querying, and the crucial benefit of data independence. Choosing the right data model greatly influences how effectively a database can store, retrieve, and alter data, so the decision still depends on the nature of the data and the needs of the application.

What do you think? If you were designing a database for your college library today, which model would suit it best, and why? And given how strongly data independence shaped the relational model’s success, can you think of a situation where the rigidity of the older hierarchical approach might still be the smarter choice?

References

1. https://www.geeksforgeeks.org/dbms/difference-between-database-and-dbms/
2. https://en.wikipedia.org/wiki/Database
3. https://rivery.io/data-learning-center/database-types-guide/
4. https://en.wikipedia.org/wiki/Hierarchical_database_model
5. https://airbyte.com/data-engineering-resources/hierarchical-vs-relational-database
6. https://www.geeksforgeeks.org/dbms/difference-between-hierarchical-and-network-data-model/
7. http://www.cs.iit.edu/~cs561/cs425/PANDURENGAN_VIGNESHRelationalDatabaseIntro/test/DBModels.html
8. https://www.ibm.com/history/relational-database
9. https://www.relationaldbdesign.com/database-design/module2/relational-database-model.php
10. https://www.datamation.com/big-data/hierarchical-vs-relational-data-models/
11. https://arxiv.org/pdf/cs/0305038
12. https://practicaldatamodeling.substack.com/p/a-very-brief-history-of-the-relational
13. https://www.bps-corp.com/post/therelationalmodelandedgarf-codds12rules
14. https://twobithistory.org/2017/12/29/codd-relational-model.html
15. https://www.geeksforgeeks.org/dbms/difference-between-hierarchical-network-and-relational-data-model/