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.
In everyday SQL, a relation is commonly presented as a table: rows represent records and columns represent attributes. A key identifies rows, while foreign keys express references between tables. The relational model is more than “tables linked together”; it also gives a formal way to define valid data and query results.
SQL is the most common language used with relational database systems, though implementations add different types, functions, and behaviors. PostgreSQL, SQLite, MySQL, and SQL Server all use SQL but are not interchangeable in every detail.
If every order stores a customer's address, changing that address requires updating many rows and risks contradictions. A normalized design stores customer facts once and references the customer from each order. Joins combine the related rows when a query needs them. Constraints can enforce uniqueness and referential integrity; see primary and foreign keys and normalization.
Many relational systems support transactions and constraints, which help keep related changes valid. These features have engine-specific behavior and configuration. Relational databases can also scale and replicate, but those properties depend on the particular system and design; they are not guaranteed merely by the relational model.
Choose a relational design when the data has meaningful structure, relationships, and queries that benefit from joins and constraints. Compare with non-relational database models when access patterns suggest a specialized model.
A customers table can have customer_id as its key, while an orders table stores customer_id as a foreign key. The database can reject an order for a nonexistent customer. A query can join both tables to show the customer's name beside each order without storing that name repeatedly in every order row. This separation avoids some update anomalies, while the join reconstructs the information when needed. The result still needs an explicit ORDER BY if its sequence matters.
If every order stores both customer_id and customer_name, a customer's name change requires updating all their orders. Keeping the current name in one customer row avoids those contradictory copies. An order can still store the name as a historical snapshot if the business requirement is to show the name used at the time of purchase. The key is to state whether a field is current entity data or historical event data. Relations and keys make that distinction explicit in the schema.
About to run: press normalised. Before it does — what happens to the readout?
Committing to an answer first is the point — the reveal runs the experiment on the visualisation above and reads the real value back, so nothing here is scripted.
Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.
What does this module say about “What “relational” means”?
What does this module say about “Why separate related facts”?
What does this module say about “Transactions and limits”?
Store data in normalised tables linked by foreign keys and see how one update in one row propagates correctly through every join.