Data split across tables and stitched back together by keys. Click a row to follow its relationships, then flatten everything into one table to see exactly what normalisation is protecting you from.
Fifty years on, the relational model is still the default way to store business data. This is why.
A relational database stores data in tables of rows and columns, where every table describes one kind of thing — customers, orders, products — and tables are connected by shared key values rather than by nesting data inside each other.
That enforcement is called referential integrity, and it is a guarantee the database makes on your behalf — not something your application code has to remember.
Switch this lab to one flat table and look at the red cells. The customer's name and city now repeat on every order they ever placed. That redundancy causes three classic problems:
Normalisation is the process of splitting tables until each fact is stored exactly once. The cost is that answering a question often requires a JOIN — and that trade, correctness for a little query effort, is the central bargain of the relational model.
Relational systems also guarantee that transactions are Atomic (all steps or none), Consistent (constraints always hold), Isolated (concurrent transactions do not corrupt each other) and Durable (committed data survives a crash). If you are moving money between accounts, this is not a nice-to-have.
Store each fact once, identify it with a primary key, and reference it with a foreign key. The database then enforces the relationships for you. Flattening everything looks simpler until the first time you have to change something.
Data split across tables and stitched back together by keys. Click a row to follow its relationships, then flatten everything into one table to see exactly what normalisation is protecting you from.