The Role of Databases in Effective Information System Design

Every time you book a train ticket on IRCTC, withdraw cash from an ATM, or check your university results online, you are interacting with a database. These quiet, structured collections of information sit behind almost every digital service we use. For students of library and information science, understanding databases is not optional knowledge-it is the foundation of how modern information systems are designed, organised, and made useful. A well-designed information system stands or falls on the quality of the database at its core. This post breaks down what databases are, how they protect the accuracy of our data, how they evolved over decades, and why their internal structure matters so much.

Defining databases in the digital era 🔗

A database is a structured set of data stored electronically so that it can be easily accessed, managed, and updated. The key word here is structured. A pile of documents in a drawer is data, but it is not a database. A database arranges information in a deliberate, logical way so that a computer can find, sort, and link records in fractions of a second.

In the early days of computing, data was kept in flat files-plain text files with a fixed format. These file-based systems lacked flexibility, because any change to the structure or relationships within the data forced significant modifications to both the physical files and the application programs that read them. Imagine a college keeping separate files for admissions, examinations, and the library, each storing a student’s name and roll number independently. Update one file and the others fall out of sync. Databases were created precisely to solve this problem.

Today, databases power everything from a small clinic’s patient records to the massive systems behind national digital identity and banking. They are the engines that turn raw, scattered facts into organised, retrievable information-which is exactly why they form the backbone of any serious information system.

Database versus database management system 🔗

It helps to draw a clear line between two terms that are often confused. A database is the actual collection of stored data. A database management system (DBMS) is the software that lets you create, read, update, and control that data. The DBMS sits between the user and the raw data, handling requests, enforcing rules, and managing access. When you run a search on a library catalogue, you are sending a request to a DBMS, which then retrieves the matching records from the underlying database.

Database management systems: ensuring data integrity 🔗

One of the biggest reasons databases replaced loose file systems is their ability to control data redundancy and protect data integrity. Redundancy refers to the unnecessary duplication of the same data in multiple places. Redundancy is a concern because it can lead to inconsistencies, update anomalies, and increased storage requirements-all of which damage the reliability of an information system.

Consider what happens when a student’s address is stored in three separate places. If the student moves and only one record is updated, the database now holds two different “correct” addresses. Which one does the system trust? This is the core danger of redundancy: it quietly erodes the accuracy of the entire collection.

How a DBMS keeps data consistent 🔗

A DBMS reduces redundancy and inconsistency through several built-in mechanisms. It enforces referential integrity using foreign keys to create reliable relationships between tables, so that linked records stay synchronised when data is inserted, deleted, or updated. It also uses a data dictionary, which stores the definitions, data types, and constraints of every element, allowing the system to handle data consistently across the whole database.

Rather than storing the same fact repeatedly, a good design stores each piece of information once and links to it wherever it is needed. For example, customer details can live in a single “customer” table, with orders connected to that customer through a customer ID. This keeps the data accurate and consistent across the system while dramatically reducing duplication. The result is a single, trustworthy source of truth-the quality that separates a professional information system from an unreliable one.

The evolution of database systems 🔗

Databases did not arrive fully formed. They evolved over decades in response to the growing demands organisations placed on their data. Understanding this journey helps explain why today’s systems work the way they do.

The hierarchical and network models 🔗

The first true database systems emerged in the 1960s when businesses recognised the need for better data management. The earliest was the hierarchical model, which organised data in a tree-like structure where each record had a single parent and could have multiple children. IBM’s Information Management System (IMS) was the most notable example. This approach offered efficient retrieval for naturally tree-shaped data, such as organisational charts, but it was rigid.

The network model followed, standardised by the Conference on Data Systems Languages (CODASYL). It offered more flexibility by allowing records to have multiple relationships rather than a single parent. However, this came at a cost. Records were linked using physical pointers, and accessing data meant navigating through a network of pointers, which limited query capability and made the system brittle if those physical addresses became corrupted.

The relational revolution 🔗

The turning point came in 1970, when Edgar F. Codd, a mathematician at IBM, proposed the relational model in his landmark paper on data for large shared data banks. Codd’s model organised data into tables, or relations, and allowed users to query it using a logical language rather than navigating physical pointers. Built on the mathematics of set theory, it freed application programs from depending on how data was physically stored.

The relational model addressed the data dependency problems that had plagued earlier systems. By the late 1980s, the hierarchical model was becoming outdated, and Codd’s approach had become the dominant replacement. The Structured Query Language (SQL) emerged as the standard way to interact with these systems, and the first commercial relational database, Oracle, was released in 1979, soon followed by IBM’s DB2 and Microsoft SQL Server.

Beyond relational: RDBMS and ORDBMS 🔗

The relational database management system (RDBMS) became the workhorse of modern computing. But as organisations began storing complex data such as images, multimedia, and spatial information, the simple table-and-row structure showed limits. This led to the object-relational database management system (ORDBMS), which extends the relational model by incorporating object-oriented features.

An ORDBMS supports objects, classes, and inheritance while still retaining the familiar relational structure and SQL-style querying. It allows users to define their own complex data types and methods, making it well suited to applications that need to store richer information than plain text and numbers. Major vendors including Oracle, IBM, and PostgreSQL adopted this hybrid approach, sitting between pure relational systems and fully object-oriented databases.

The importance of data structure in DBMS 🔗

The power of a database comes not just from storing data, but from how that data is structured. A poorly structured database is slow, error-prone, and difficult to maintain, no matter how powerful the software running it. This is where the design discipline of normalisation becomes essential.

What normalisation does 🔗

Normalisation is the process of organising the columns and tables of a relational database to minimise redundancy and improve integrity. The goal is simple: store each piece of information in the most logical place and only once. When data is normalised, any addition, deletion, or modification of a record happens in just one location, which keeps the database easy to maintain as it grows.

Normalisation works through a series of increasingly strict rules called normal forms. First Normal Form (1NF) ensures each column holds only single, indivisible values and each row is uniquely identifiable. Higher forms such as Second and Third Normal Form progressively remove dependencies that could cause anomalies. The process was first proposed by Codd himself, who argued that breaking larger tables into smaller, simpler ones makes altering a database less error-prone and limits the impact of changes.

Keys: the glue of structured data 🔗

Structure depends on two crucial tools. A primary key is a unique identifier for each record in a table-a roll number, an ISBN, or a customer ID-that guarantees there are no duplicate entries. A foreign key is a field in one table that links back to the primary key in another, creating a relationship between them. Together, these keys allow a DBMS to connect related information across tables while keeping each fact stored only once, which is the practical heart of avoiding redundancy.

It is worth noting that perfect normalisation is not always the goal. In practice, designers sometimes deliberately back out of some normalisation for performance reasons, a technique known as denormalisation. Large-scale and big-data systems often use denormalised structures to speed up retrieval. The skill of good information system design lies in balancing the integrity that normalisation provides against the speed that some applications demand.

Why this matters for information systems 🔗

For anyone designing or managing an information system, data structure is the difference between a tool people trust and one they work around. A normalised, well-keyed database retrieves information quickly, stays consistent under heavy use, and scales gracefully as records multiply. These are exactly the qualities a library catalogue, an institutional repository, or a digital archive must have. The structure decisions made at the design stage echo through every search query and every report the system will ever produce.

What do you think? If you were designing a database for your own institution’s library, how would you balance the data integrity that normalisation offers against the retrieval speed that users expect? And as data grows ever more complex with images, audio, and other rich formats, do you think the traditional relational model will remain the dominant approach, or will object-relational and other systems take its place?

References

1. https://medium.com/poatek/the-birth-of-databases-5573c57a154a
2. https://unstop.com/blog/data-redundancy-in-dbms
3. https://www.ibm.com/think/topics/data-redundancy
4. https://celerdata.com/glossary/how-database-management-systems-have-evolved-over-time
5. https://practicaldatamodeling.substack.com/p/a-very-brief-history-of-the-relational
6. https://www.geeksforgeeks.org/dbms/history-of-dbms/
7. https://www.geeksforgeeks.org/dbms/difference-between-rdbms-and-ordbms/
8. https://www.fivetran.com/learn/data-normalization
9. https://www.ibm.com/think/topics/database-normalization
10. https://agiledata.org/essays/datanormalization.html