Relational modelling is the craft of deciding which tables to create and how to link them. Good design stores each fact once, so the data cannot disagree with itself.
This page belongs to data and databases. Its natural follow-up is database development.
What does a weak design look like?
Take a club register where the name of the club leader is typed into every member row. Two members of Chess Club show “Mr Lim” and a third shows “Mr Lyn”. The data now disagrees, and nobody can tell which spelling is right.
Storing the leader once, in a Club table, and linking members by ClubID removes the problem. The four lessons below each show one way a design can fail and how to fix it.
What are the four lessons?
| Lesson | The design problem |
|---|---|
| Choosing a primary key when names are not unique | two rows look identical |
| Resolving a many-to-many relationship | one foreign key cannot hold the link |
| Explaining update anomalies | one fact is stored in many places |
| Checking a foreign key against sample rows | a link points to nothing |
Then test yourself on the relational data modelling practice set.
Who should start where?
A student who is new to keys should first finish choosing primary and foreign keys. A student who can draw tables but loses marks on “explain why” questions should start with update anomalies.
A student who wants a teacher to review a design can use the one-hour trial class (from RM50), a taught lesson on the Computer Science topic you choose. See also online one-to-one Computer Science tuition.