Mental Model in DBMS: Thinking From First Principles

Introduction

A library dashboard shows “Maya: 3 loans.” That number is useful, but it cannot tell you which books she borrowed or when each loan began. To answer those questions, the database needs the individual borrowing records behind the count.

Before choosing columns or applying normalization rules, decide what the database must represent. This is the mental model of database design: understanding the things you track, the events you record, and how they relate.

Define What One Row Means

Thinking from first principles means starting with the basic facts and rules of a situation. In a relational database, a useful starting question is:

What does one row in this table represent?

For a library, different tables have different responsibilities:

This is often expressed as “one fact per row.” More precisely, a row represents one clearly defined thing, event, or relationship. It can contain several attributes, provided those attributes describe that same subject.

Reports still matter because they help identify which details you need. The aim is to preserve enough well-organized information to produce those reports reliably.

A Simple Example: Recording Library Loans

Assume each loan belongs to one member and covers one physical book copy. Maya has member_id 7, and Arjun has member_id 9. The Loans table contains these records:

Each loan_id identifies a different borrowing event. The repeated member_id 7 is expected: three separate loans belong to Maya.

If Maya borrows another copy, add another loan row. You do not need new columns such as book1, book2, and book3. The meaning of a row stays consistent as the number of loans grows.

Give Each Current Fact a Clear Home

The Members table maintains a member’s current name and contact details. Loans refers to that member through member_id. A primary key identifies a row, while a foreign key can enforce that a referenced member exists.

If Maya changes her phone number, update her Members record. Copying her current phone number into every loan would create several copies that could disagree.

Here, Members is the source of truth for current member details. This describes its responsibility; it is not a special SQL table type. Repeating member_id in Loans preserves a relationship without creating another independently maintained copy of Maya’s contact information.

Historical details have a different meaning. An address deliberately captured when a loan began records the address at that time. Changing today’s address should not silently rewrite that history.

Build Summaries From the Records

To find Maya’s loan count, count the rows whose member_id is 7. Loans 501, 502, and 504 match, so the result is:

Maya’s recorded loan count = 3.

The same records can show which copies she borrowed and when. Storing only the number 3 would lose those details.

The diagram follows the matching records into the calculated count. The individual events remain available after the summary is produced.

This count measures recorded borrowing events. Finding which books are still on loan would also require information about returns.

Stored summaries can still be useful. A busy dashboard may keep a calculated count for faster reads. That count must be updated or refreshed to reflect the underlying loan records. In this model, those records provide the evidence for checking or rebuilding the summary.

Use This Model Before Normalization

Before refining a table, check three things:

• Meaning: Can you complete “One row represents…” without combining unrelated subjects?

• Identity and links: Can you identify each row and connect it consistently to related records?

• Change: What happens when a detail changes or another event occurs? Can you maintain current facts and preserve needed history?

Normalization provides formal rules for examining dependencies and reducing avoidable duplication. This mental model gives those rules a purpose: organizing information according to what it means and how it changes.

Summary

Begin database design by defining what each row represents. Give current facts a clear home, connect related records through identifiers, and retain the events behind calculated summaries. Stored summaries can improve convenience when maintained correctly. This foundation makes normalization easier to understand because each table already has a clear responsibility.