A Relational Model of Data for Large Shared Data Banks

Describe facts without prescribing pointer traversal

Codd argues for protecting applications from unnecessary dependence on storage representation and access paths. Relations describe tuples of values, enabling a logical view that need not expose the physical route used to retrieve them. The paper introduces its own normal-form discussion and relational operations; it should not be presented as a complete specification of modern SQL or every later normalization theorem.

Consider original teaching data for a small shop. Customer contains tuples (customer_id,name), and Purchase contains (purchase_id,customer_id,item). Let Customer contain (7,Ada) and (9,Bo). Let Purchase contain (101,7,book), (102,7,pen), and (103,9,book). The question “which customers bought a book?” can be stated by a condition on values rather than by instructions to follow a particular disk pointer chain.

Trace a relational expression

Select Purchase tuples whose item equals book. The intermediate relation contains (101,7,book) and (103,9,book). Join those tuples with Customer on equal customer_id, yielding the corresponding names. Project the name attribute to obtain {Ada,Bo}. Under the mathematical set model, projecting duplicate name values would remove duplicates; names therefore do not necessarily preserve customer identity.

If two distinct customer identifiers both have name Ada, projecting only name merges them in the result. That is not a database error. It follows from the requested attribute and set semantics. If the task is to identify customers, retain customer_id. Logical precision begins with the question and schema, not with whichever output happens to look plausible.

The engine can implement the join by nested loops, a hash table, or an index lookup. These choices can have different costs while producing the same logical relation. Data independence does not mean physical design becomes irrelevant. It means a physical change should not require rewriting the application’s meaning when the logical contract remains unchanged.

Make redundancy and constraints explicit

Suppose every purchase row also repeats the customer’s phone number. If customer_id determines one current phone number, changing that number requires updating all repeated copies. Updating only one row creates inconsistent facts. A separate CustomerContact(customer_id,phone) relation stores the dependency once, while purchases retain only the customer reference.

The decomposition needs a declared constraint: one phone value per customer under this particular model. If customers may have multiple phone numbers, the schema and query must represent that multiplicity. Normalization is not achieved by splitting tables at random. A decomposition can lose relationships or introduce spurious combinations if the relevant dependencies are ignored.

For example, storing only PersonLanguage(person,language) and PersonCity(person,city) cannot reconstruct which language was used in which city. Joining them creates every language-city combination for that person, potentially asserting relationships never observed. The original relation may have encoded a genuine three-way fact. A join is an operation, not a guarantee of semantic truth.

Keep the implementation contract separate

An unordered relation does not promise row order. A test that succeeds only because records happen to be returned in insertion order has leaked a physical assumption into the application. Later SQL systems also use bags by default in many operations and introduce NULL-related semantics; those features need their own precise treatment.

The enduring design discipline is to state keys, domains, dependencies, and desired result relations before choosing storage or access methods. Then test that alternative implementations preserve the logical answer. This approach supports evolution without pretending that schema design, consistency constraints, or query cost disappear.

S = {'a','b','c','d'}
R = {('a','p1'),('a','p2'),('b','p1'),('c','p2')}
def supplies_all(required):
    missing = {(s,p) for s in S for p in required} - R
    return S - {s for s,p in missing}
assert supplies_all({'p1','p2'}) == {'a'}
assert supplies_all(set()) == S

• A Relational Model of Data for Large Shared Data Banks: University of Pennsylvania