A record and an original worked study

1970

Codd: What Projections Lose

Project an original three-column relation, join the resulting pairs and identify the extra tuples before deciding what information would permit recovery.

Three invented student-course-tutor tuples become two projections whose join creates five tuples, including two spurious combinations.
3โ†’5
Invented original-to-join tuple counts
2
Spurious tuples in the fixture

The short answer

Keeping every value is not the same as keeping every association. A small relation lets us identify exactly which coupling disappears in a projection.

Selected record and original analysis

Values survive while coupling can disappear

Read the stated model and observation separately.

Fixtures are invented; none reconstructs historical measurements.
QuestionRecord or stipulated inputInterpretation
OriginalThree-way tuplesEach tutor is attached to a particular course.
ProjectedTwo separate sets of pairsA studentโ€™s courses and tutors remain.
RejoinedFive tuplesTwo associations were permitted but never originally stated.

Chronology

A timeline of the turning points

  1. Selected paper

    Published the relational-model account.

A relational problem in the paper

Codd treats a relation as a set of tuples. In discussing projection and joining, he shows that joins of projected relations can be ambiguous: the smaller relations need not uniquely specify the original.

This is a statement about the information represented, not a failure of a particular storage device. The task therefore uses set semantics, without SQL duplicates, null values or unspecified query behaviour.

Sources for this section: [1]

An original relation and two views

Invent R(Student, Course, Tutor) with three tuples: (Ada, Logic, Lin), (Ada, Algebra, Rao), (Ben, Logic, Rao). Project it onto (Student, Course) and separately onto (Student, Tutor). Discard duplicate pairs as required by set semantics.

Join the two projections on Student, meaning pair each course for a student with each tutor recorded for that student. List the result. Could a different three-column relation have exactly the same two projections?

Sources for this section: [1]

Reference answer: find the lost coupling

The first projection is {(Ada, Logic), (Ada, Algebra), (Ben, Logic)}. The second is {(Ada, Lin), (Ada, Rao), (Ben, Rao)}. Their join has the three original tuples plus (Ada, Logic, Rao) and (Ada, Algebra, Lin): five tuples in total.

For Ada, the projections say which courses and which tutors occur, but do not say which tutor accompanies which course. Indeed, the five-tuple join itself has exactly the same two projections as the original three-tuple relation. The projection pair therefore cannot distinguish those two candidate originals.

Retaining the three-way association, or adding a justified constraint that rules out the extra combinations, would provide more information. The exercise supplies no such constraint, so it must not be silently invented.

Sources for this section: [1]

What the example does not condemn

Some decompositions preserve the needed information under appropriate dependencies. This one deliberately does not assume them. Its lesson is to test the recovery claim against the represented associations instead of assuming that an executable join must be the historical inverse of a projection.

Sources for this section: [1]

Continue the chronology

Biography context

Explore United States through connected lives

Connected biographies

The working life behind the record

Quick answers

Common questions

Does the exercise prove that all decomposition is lossy?
No. Its specific projections and missing constraints produce the counterexample.
Is this a test of SQL null or duplicate behaviour?
No. It uses explicitly defined sets of tuples.

Primary and institutional sources

How this history was checked

These selected records support the historical account. Invented inputs and their original reference answers are identified explicitly. This article was reviewed on 31 October 2026.

  1. E. F. Codd, CACM 13(6), 377โ€“387, 1970; retained retypeset copyA Relational Model of Data for Large Shared Data Banks