“Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).”E. F. Codd · A Relational Model of Data for Large Shared Data Banks · 1970 · A Relational Model of Data for Large Shared Data Banks, Communications of the ACM 13(6), 1970 — prima propoziție a rezumatului
Every attribute depends on the key, the whole key, and nothing but the key.
In 1970 Codd proposed something that now looks obvious: tables (relations) with rows and columns, primary keys that identify a row and foreign keys that link tables, plus a declarative language in which you state the result you want rather than which files the machine should open. Normalisation comes from the same idea: if a customer's address appears in a thousand orders, you correct it in a thousand places or in none. Third normal form fits in one sentence: every attribute depends on the key, the whole key, and nothing but the key. For a data warehouse, normalisation is a choice, not a law. Sources are normalised so they can write without anomalies; the warehouse denormalises on purpose so it can read without ten joins. What stays untouched is Codd's principle: the logical model separated from the physical one. That is why you can change indexes, partitions and storage formats without rewriting queries — and why the later lessons on indexes and memory never touch the SQL at all.
Passage 1. Data independence has a hidden cost: someone must translate your request into physical steps. That someone is the optimizer. When you write a query, you don't pick indexes or join order. You pick the engine. It's like giving a taxi driver only the address, not the route. He knows the streets, the jams, the shortcuts. If we dictate the route, we lose exactly what Codd gave us: the freedom to change the map without changing the destination. But what happens when the optimizer picks the wrong route? That's where the next lesson begins.
The same separation has a second face: the data itself must live in one place. If a customer's address is copied across a thousand orders, a move means a thousand corrections — and a thousand chances to forget one. Normalization says: write the address once, in its own row, and link the rest through a key. It is like a student ID at a university: you don't rewrite the student's name in every register, only the code. The golden rule of third normal form fits in one sentence: every value depends on the key, the whole key, and nothing but the key. But what if you want to read fast, not write cleanly? There, normalization becomes a choice, not a law.
Why it matters Every optimisation lesson in this course rests on the logical–physical split. Lose it and you end up rewriting reports every time a table moves.