Compared to a file system, how does a database management system avoid redundancy in data through a database?

Exercises · Q4

Q. Compared to a file system, how does a database management system avoid redundancy in data through a database?

Rajasthan RbseTextbookSubjective· 3mImportance★★★★★est

36% · 5/14 Questions

🔒 Locked · start free trial →

You're viewing a preview — the full solution, concept, methods & PYQ mapping are locked.

Start your 14-day free trial to unlock the full solution →

Concept understanding — Data Redundancy Elimination

Data Redundancy Elimination

Think about your wardrobe. You own one black blazer that works for every formal occasion — but somehow you end up with three nearly identical black blazers, each taking up space, each needing to be cleaned and maintained. That extra space in your cupboard is wasted. That extra effort in upkeep is wasted. Now imagine that same problem, but with data stored across a large organisation.

Data redundancy elimination is the process of identifying and removing duplicate copies of the same piece of information from a database or storage system. It is not about deleting data you need — it is about ensuring that the same fact, figure, or record is stored exactly once, and every other place that needs it simply points back to that single original.

Why does redundancy happen in the first place?

In any real-world organisation, data enters through many doors. A customer's address might be recorded by the sales team when they place an order, by the support team when they register a complaint, and by the marketing team when they run a campaign. Each team works in its own system, often unaware that the same address already exists elsewhere. Over time, the same customer name, the same product code, or the same transaction record gets stored in multiple places — sometimes with slight differences, sometimes as exact copies.

This is not a technical glitch. It is a natural consequence of how organisations grow and how different departments work independently.

What makes redundancy a problem?

Redundancy is not harmless. It creates three serious issues:

Wasted storage space — every duplicate copy consumes disk space, memory, and backup capacity. For a small business this may be trivial, but for a bank, a government department, or an e-commerce platform, the cost of storing millions of duplicate records adds up fast.
Data inconsistency — this is the more dangerous problem. If a customer's address is stored in five places and they move house, updating all five copies is tedious and error-prone. One copy gets updated, another is forgotten. Now the same customer has two different addresses in the same system. Which one is correct? The system cannot tell you. The data has lost its integrity.
Slower performance — searching through a bloated database, running reports, or generating invoices takes longer when the system has to wade through duplicate records. Every query becomes heavier than it needs to be.

Important

Data redundancy elimination is not about saving disk space alone. Its primary purpose is to preserve data integrity — ensuring that every fact in the system is stored once, updated once, and trusted by everyone who uses it.

How is it done in practice?

The process works at two levels.

At the database design level, redundancy is prevented before it happens. This is done through a technique called normalisation — breaking a large table into smaller, related tables so that each piece of information lives in exactly one place. For example, instead of storing a customer's name and address alongside every order they place, you store the customer details once in a separate table and link each order to that single record using a customer ID.

At the storage system level, redundancy is removed after the fact. Special software scans the stored data, identifies identical blocks or files, and replaces duplicates with pointers to a single copy. This is common in backup systems and cloud storage, where the same file might be saved by hundreds of users.

A concrete example …

Start your 14-day free trial to unlock the full solution →

In a file-processing system each application (library, exams, fees…) maintains its own files, so the same student's details are stored again and again — redundancy, wasted space, and eventual inconsistency. A DBMS stores every fact once in a central, shared database; other tables refer to that fact through a primary-key/foreign-key link instead of copying it, and key constraints stop duplicates from being entered at all.

How redundancy arises in a file system

Picture a school before databases. The library software has library.dat with (RollNo, Name, Address, BooksIssued). The examination software has exam.dat with (RollNo, Name, Address, Marks). The fee software has fees.dat with (RollNo, Name, Address, FeePaid). The name and address of every student are stored three times — once per application file. That is data redundancy, and it brings two evils: wasted storage, and inconsistency when the student's address is updated in one file but not the others.

What a DBMS does differently

1. One central, shared database. All applications (library, exams, fees) talk to the same database through the DBMS instead of each owning private files. The student's name and address are stored once, in one STUDENT relation, and every application reads that single copy.

2. Related data is linked, not copied. The relational design splits data into separate relations and connects them with keys. The library module doesn't store the student's address — it stores only the student's RollNo (a foreign key) and looks up the rest:

CREATE TABLE STUDENT (
  RollNo  INT PRIMARY KEY,
  Name    VARCHAR(30) NOT NULL,
  Address VARCHAR(60)
);

CREATE TABLE BOOK_ISSUE (
  IssueID INT PRIMARY KEY,
  RollNo  INT,                 -- just a reference, not a copy of the student
  BookNo  INT,
  FOREIGN KEY (RollNo) REFERENCES STUDENT(RollNo)
);

-- Any application reconstructs the "combined file" on demand:
SELECT S.Name, S.Address, B.BookNo
FROM   STUDENT S JOIN BOOK_ISSUE B ON S.RollNo = B.RollNo;

Name	Address	BookNo
Asha	12, MG Road	501
Asha	12, MG Road	517

The join displays the address next to each issued book, but it is still stored only once in STUDENT. Key line: FOREIGN KEY (RollNo) REFERENCES STUDENT(RollNo) — a 4-byte reference replaces a full duplicated record, and it can never point to a non-existent student. …

Start your 14-day free trial to unlock the full solution →

←Previous questionQ3 — Differentiate between: a) Database state and database schema b) Primar…→Next questionQ5 — What are the limitations of file system that can be overcome by a rela…

Q.Compared to a file system, how does a database management system avoid redundancy in data through a database?

🎓Unlock everything free for 14 days

Unlock everything free for 14 days