Tables and the relational model

A database table stores data in rows and columns, like a spreadsheet. Each row is one record, such as one user or one session. Each column is a field on that record, such as country or plan. A table is useful because you can add many rows of the same shape and reliably refer to the same column across all of them.

The relational model is the idea that you should not cram everything into one giant table. Instead, you split data into focused tables that each describe one kind of thing. A users table holds one row per user. A sessions table holds one row per session. This avoids repeating a user's details on every session row. If a user's country changes, you update it once in users, not across all their session records.

Keys are how tables connect. A primary key uniquely identifies each row in a table. For example, user_id is the primary key of users, and session_id is the primary key of sessions. A foreign key is a column in one table that points to a unique key in another: usually the primary key, but any column guaranteed unique (a candidate key) can be the target. Foreign keys are normally enforced: the database rejects a session whose user_id matches no user, so orphan rows are prevented, not just discouraged. Here, sessions.user_id is a foreign key pointing to users.user_id. That link is what makes the data relational: it encodes "this session belongs to this user."

The payoff is that splitting data keeps it clean and free of repetition, but it also means the information you need is spread across tables. To answer a question like "show each session with the user's country," you have to recombine rows using the keys. That recombination is exactly what a join does, and it is why joins exist.

Linking rows with keys

Data model

Two tables linked by a key

usersuser_idPKcountryplan5USpro14JPfree20USfree31JPfreesessionssession_idPKuser_idFKstarted_at152025-01-102312025-01-113142025-01-124202025-01-1214312025-01-19
PKprimary key: uniquely identifies a rowFKforeign key: points to a unique key in another table

The data is not one giant table. It is split into focused tables connected by keys, which is what "relational" means, and why combining them needs a join.

selected
users.user_id = 31
linked sessions
2
foreign key
sessions.user_id

The tables are a small hand-picked slice of the site's shared seed dataset, four users and five sessions chosen so the key relationship is easy to see. The row linking is real: highlights come from filtering sessions by the clicked user's key, not from an authored mapping.