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

Shape of Question

This is a plain theory question asking for an explanation of how a DBMS eliminates data redundancy compared to a file system.

How a DBMS Avoids Data Redundancy

In a file system, each application maintains its own separate data files. If multiple applications need the same information—say, a customer's address—that data is duplicated across files. When the address changes, every file must be updated independently, leading to inconsistency and wasted storage.

A database management system eliminates this redundancy through centralized storage and normalization. All data resides in a single repository, and multiple applications access the same physical record. When a customer's address is stored once in a Customer table, every application retrieves it from that single location. An update propagates automatically to all users.

Normalization is the formal technique: data is organized into related tables, each storing a distinct entity, with relationships maintained through keys rather than duplication. For example, instead of repeating a department's name and location in every employee record, you store departments once in a Department table and link employees to it via a DeptID foreign key. This design enforces the rule that each fact appears exactly once.

The Core Problem: Redundancy in File Systems

In a traditional file system, each application maintains its own data files. If multiple programs need the same information—say, a customer's address—each program stores its own copy. This creates data redundancy: the same fact exists in multiple places.

Consider a school that tracks students. The attendance system keeps a file with student names and classes. The library system keeps another file with student names and classes. The exam system keeps yet another. Now the same student's class appears in three different files. When a student changes class, all three files must be updated independently. Miss one, and the data becomes inconsistent.

How a DBMS Eliminates Redundancy

A database management system solves this through three mechanisms:

1. Centralized Storage with Normalization

The DBMS stores each piece of information exactly once. Using our school example, there would be a single Student table:

CREATE TABLE Student (
    StudentID INT PRIMARY KEY,
    Name VARCHAR(50),
    Class VARCHAR(10)
);

Every application—attendance, library, exams—queries this one table. The class is stored once, not three times.

2. Relationships Through Foreign Keys

Instead of duplicating student details in every table, other tables reference the student by ID:

CREATE TABLE Attendance (
    AttendanceID INT PRIMARY KEY,
    StudentID INT,
    Date DATE,
    Status VARCHAR(10),
    FOREIGN KEY (StudentID) REFERENCES Student(StudentID)
);

CREATE TABLE LibraryIssue (
    IssueID INT PRIMARY KEY,
    StudentID INT,
    BookID INT,
    IssueDate DATE,
    FOREIGN KEY (StudentID) REFERENCES Student(StudentID)
);

The Attendance and LibraryIssue tables don't repeat the student's name or class. They store only the StudentID, which links to the master record. When you need the student's name, you join:

SELECT A.Date, S.Name, S.Class, A.Status
FROM Attendance A
JOIN Student S ON A.StudentID = S.StudentID;

3. Enforced Integrity Constraints

The DBMS enforces rules that prevent inconsistency. If you try to insert an attendance record for a non-existent StudentID, the foreign key constraint rejects it. If you update a student's class in the Student table, every query automatically sees the new value—there's no second copy to fall out of sync.

Normalization: The Formal Technique

Database normalization is the process of organizing tables to minimize redundancy. The most common forms are:

• 1NF (First Normal Form): Eliminate repeating groups; each cell holds a single value.
• 2NF (Second Normal Form): Remove partial dependencies; non-key attributes depend on the entire primary key.
• 3NF (Third Normal Form): Remove transitive dependencies; non-key attributes depend only on the primary key, not on other non-key attributes.

For example, suppose you had a table: