1972: Encode the enterprise

SAP was founded in 1972 with the goal of integrating business processes and making data available when needed. Relational database research offered another important boundary: describe data through logical relations rather than forcing every application to depend on one physical storage arrangement. Codd's1970 paper and SAP's institutional history concern different contributions. Oracle's later commercial database work belongs in the broader account, but relational theory, database products, and enterprise applications should not be credited as a single invention.

An enterprise system coordinates facts across departments. A sale can affect stock, shipment, invoicing, payment, and accounting. If each department maintains its own independent truth, updates can arrive in different orders or use incompatible identifiers. A shared model makes some inconsistencies easier to prevent, while imposing definitions that local practices must accept or explicitly extend.

Take a fictional warehouse with ten units of a part. Two orders request seven and six units. Checking stock independently and accepting both creates thirteen commitments against ten units. A correct reservation operation must preserve available=on_hand−reserved and reject an operation that would make available negative under the chosen policy. A database transaction or another justified concurrency mechanism must protect the check and reservation together. A shared screen without an atomic state transition does not solve the race.

Now trace a returned item. Does it become available when the customer requests return, when the carrier scans it, when the warehouse receives it, or after inspection? That is a business rule encoded in state transitions. The schema needs to distinguish returned, received, inspected, restockable, and refunded if those distinctions affect obligations. Compressing all of them into a boolean “returned” can create incorrect inventory or financial reports.

Data independence separates logical questions from physical access paths. A query asks which unpaid invoices belong to a customer; an index may accelerate it without changing the answer. This permits optimization and reuse, but only when applications respect the abstraction. Hidden assumptions about row order, internal identifiers, or storage layout can recreate coupling. Codd's paper is an invitation to inspect this separation, not a promise that every SQL system perfectly implements it.

Packaged software spreads development cost across customers who share enough process structure. Customization can fit local needs, yet every special field and workflow adds upgrade and migration work. A useful implementation ledger records why each extension exists, who owns its meaning, which invariant it protects, and what would fail if it disappeared. Repeated customization without such evidence can preserve accidental practices rather than genuine requirements.

The institutional choice is therefore not simply standardize or customize. Identify which facts must be globally consistent, which variations are legitimate, and who may change their definitions. A schema distributes authority: the team controlling customer identity or invoice state can constrain everyone else's workflow. Good education makes that power inspectable through concrete transactions and failure cases.

Reconstruction exercise

The warehouse starts with ten units and no reservations. Process an order for seven, then one for six, under a policy forbidding negative availability. Show the accepted state and rejection. Design a minimal return state sequence that prevents a refund request alone from increasing saleable stock. Then name a customization worth preserving and one that should be challenged during migration.

Worked solution

After accepting seven, reserved=7 and available=10−7=3. The request for six cannot be accepted in full without violating the stated invariant, so it is rejected or moved into an explicitly modeled backorder state. A return might pass through requested, received, inspected, and restocked; only the last transition increases saleable on-hand stock. Refund authorization can be a separate workflow because payment and physical quality are different facts. A legally or operationally required inspection field may justify customization. A duplicated customer code maintained only because an old report expected it should be challenged and mapped to an authoritative identifier if possible. The decision needs evidence about meaning and obligations, not a blanket preference for either standard software or local tradition.

Test the limits and transfer the idea

1. Concurrency trace · allow 30 minutes

Repair a reservation race with a stated isolation contract

Inventory has on_hand=10 and reserved=0. T1 and T2 both read reserved=0. T1 wants 7 units, T2 wants 6. Each writes its requested reservation into a separate order row and reports success; a later sum finds 13 reserved. Give the interleaving and propose a single conditional update of a shared inventory row that preserves reserved≤on_hand. State the required atomicity and how an order row and reservation remain consistent if the process crashes.

Get a starting hint

Checking each transaction's private snapshot does not serialize a shared capacity constraint.

Compare your reasoning with the worked solution

Both transactions observe availability 10 and pass their checks, then commit distinct order rows totaling 13. The corrected operation can atomically execute reserved:=reserved+q only if reserved+q≤on_hand, and check whether one row was updated. If T1 wins, reserved becomes 7 and T2's condition fails; if T2 wins, it becomes 6 and T1 fails. The capacity check and update must be one atomic operation under the database's actual concurrency contract, not separate SELECT and UPDATE statements. The accepted order row must commit in the same transaction as its reservation, or a justified recovery protocol must reconcile them. Otherwise a crash can reserve stock without an order or create an order without reserved stock. Codd's logical-data paper does not by itself specify these transaction guarantees.

Check your reasoning

• Constructs the shared-capacity anomaly despite separate order rows.
• Makes the conditional check and update atomic.
• Includes crash consistency between inventory and order records.

2. Relational counterexample · allow 25 minutes

A schema decomposition can invent facts

A relation Delivery(supplier,part,site) contains exactly (S1,P1,X), (S1,P2,Y), and (S2,P1,Y). Someone decomposes it into SupplierPart(supplier,part) and SupplierSite(supplier,site), then joins on supplier to reconstruct deliveries. Enumerate the result and identify invented tuples. Explain what additional dependency assumption would make this decomposition legitimate, or give a lossless representation that preserves the original triples. This is a constructed relational example, not a quotation of Codd's tables.

Get a starting hint

For each supplier the join combines every listed part with every listed site.

Compare your reasoning with the worked solution

S1 has parts P1 and P2 and sites X and Y, so the join generates four tuples: (S1,P1,X), (S1,P1,Y), (S1,P2,X), (S1,P2,Y). S2 contributes (S2,P1,Y). The middle two S1 combinations are invented. Decomposition would be legitimate if the business relation genuinely represented independent part and site sets per supplier, meaning every such combination is valid; the input does not satisfy that assumption. Keeping the ternary relation, possibly with separate supplier/part/site entity tables and foreign keys, preserves the facts. Data independence concerns separating logical meaning from storage, not permission to discard a correlation. Codd's paper is a primary technical proposal; SAP's history is a later corporate account and cannot establish dependencies in this fictional schema.

Check your reasoning

• Enumerates five joined tuples and the two spurious ones.
• States the missing independence or join-dependency condition.
• Preserves the ternary relationship rather than assuming normalization always removes a column.

Check your understanding

Two transactions each see ten units available and reserve seven and six separately. What failed?

• The combined check-and-reserve invariant was not protected against concurrency.
• Sharing one database automatically prevents this outcome.
• A relational schema cannot represent inventory.
• The warehouse needs a more colorful dashboard.

Explanation

The check and update must be coordinated as one valid state transition under the chosen policy.

A return request immediately increases saleable stock before goods arrive. Which modeling change addresses the error?

• Run the same update more frequently.
• Store a larger integer in the existing returned flag.
• Assume every customer ships immediately.
• Separate requested, received, inspected, and restocked states with explicit transitions.

Explanation

Distinct operational facts should not be collapsed when they create different inventory obligations.

Sources and further reading

• The early years:1972–1980: SAP institutional history
• A Relational Model of Data for Large Shared Data Banks: Edgar Codd, IBM Research,1970