Data Redundancy

The Running Example

Every topic in this chapter uses the same badly-designed table, so keep it in mind — you will watch it get fixed step by step over the next 17 topics:

StudentCourse(StudentID, StudentName, CourseID, CourseName,
              InstructorID, InstructorName, InstructorOffice, EnrollmentDate)

One row per (student, course) enrollment. Sample data:

What Redundancy Looks Like Here

Look at the values, not just the schema:

• "Asha" appears twice (once for C1, once for C2) — every course she takes repeats her full name.
• "Dr. Rao" / "Room 204" appears three times, once per student enrolled in C1. If 200 students take Database Systems, "Dr. Rao, Room 204" is stored 200 times.
• "Database Systems" is stored once per enrolled student, not once per course.

This is data redundancy: the same fact (a student's name, an instructor's office) is physically stored in more places than the number of times that fact actually needs to exist. The fact "InstructorID I1 sits in Room 204" is a single real-world fact, but this schema stores it once per enrollment row that happens to touch I1.

Why It's a Problem

1. Wasted storage — at scale (thousands of students, hundreds of courses) the repeated strings dwarf the actual unique information. A table that should hold ~500 distinct facts (150 students + 20 courses + 15 instructors) instead holds tens of thousands of duplicated field values.
2. Inconsistency risk — because the same fact is stored in multiple physical locations, nothing stops those copies from drifting apart. If "Dr. Rao" is corrected to "Dr. K. Rao" in the C1/S1 row but not the C1/S2 and C1/S3 rows, the database now contains contradictory answers to "what is I1's name?" depending on which row you read.
3. It is the root cause of anomalies — the insertion, update, and deletion anomalies (next three topics) are not separate problems; they are the direct symptoms of this redundancy. Fix the redundancy and the anomalies disappear.

Edge Cases

• Redundancy caused by a derived/computed column (e.g., storing AgeAtEnrollment alongside DateOfBirth) is a different, sometimes-acceptable kind of redundancy — it's a deliberate denormalization (see 21.18), not an unnoticed design flaw.
• Not all repetition is redundancy — a foreign key value like CourseID appearing in every enrollment row is expected and necessary; it's the dependent, non-key attributes riding along with it (CourseName, InstructorName, InstructorOffice) that constitute the problem.

Key Takeaways / Interview Angle

• Q: Is redundancy the same thing as duplication of a primary key? No — a key value must be repeated so rows can be linked (that's normal). Redundancy specifically means a non-key, functionally-dependent fact is duplicated unnecessarily.
• Q: Why does normalization exist? Its entire purpose is to organize attributes into relations such that each fact is stored exactly once, eliminating this redundancy and the anomalies it causes.
• Q: Can redundancy ever be "zero"? Fully normalized (BCNF/higher) schemas minimize but don't always reduce redundancy to mathematically zero in every case — but for this chapter's purposes, normalization is the redundancy-elimination process.