DataslopeThinking in Entities
The first step of data modeling — spotting the "things" in a problem, their attributes, and the relationships between them.
Before writing a single CREATE TABLE, good database design starts
on paper (or in your head) by asking: what are the real things this
system is about, and how do they relate? This habit is called
data modeling, and its core unit is the entity.
What is an entity?
An entity is a distinct "thing" your data is about — something you would naturally talk about in the real world: a customer, a product, an order, a student, a course. Each entity usually becomes a table, and each real instance of it becomes a row.
A simple test: if you find yourself saying "each one has..." or "we have many of these," you have probably found an entity.
Finding entities in a description
Data modeling often begins with a plain-English description. The nouns are your candidate entities; the facts about them are their attributes. Read this sentence:
"A bookstore sells books to customers, who place orders."
The nouns — bookstore, book, customer, order — are candidate entities. Now ask of each: what do we need to know about it? Those become attributes (columns):
Notice attributes describe one instance of the entity: one book has one title and one price. If a "fact" really describes many values (a customer's many orders), that is a sign of a relationship to another entity, not an attribute.
Attributes vs. relationships
Telling these two apart is the heart of modeling:
- An attribute is a single value owned by one row — a book's
price, a customer'semail. - A relationship is a connection to another entity — a customer places orders, an order contains books.
The verbs in the description — sells, places, contains — point
to relationships. The "many" symbols on the diagram (o{) capture
how many of each side participate, just as you saw with foreign keys
and junction tables.
A worked example
Let's turn a short description into a model. Imagine a library:
"A library lends books to members. Each loan records when a book was borrowed and when it is due."
Working through it:
- Entities (nouns):
books,members, andloans— a loan is a real thing we track, so it is its own entity. - Attributes: books have a
title; members have aname; loans have aborrowed_onanddue_on. - Relationships: a member has many loans; a book appears in
many loans.
loansconnects the two — it is a junction-like entity that also carries its own dates.
Every noun became a table, every fact-about-one-thing became a column, and every verb became a foreign-key relationship. That is the entire modeling reflex in miniature.
Model before you build
Spending a few minutes naming entities, attributes, and relationships before creating tables prevents the most common beginner mistake: cramming many different things into one giant table.
Check your understanding
In data modeling, what is an entity?
A single column in a table.
A distinct real-world "thing" the data is about, which usually becomes a table.
A connection between two tables.
A query that summarizes data.
When turning a plain-English description into a model, which words are the best clues to entities?
The adjectives.
The nouns.
The verbs.
The numbers.
A customer can have many orders. How should "the customer's orders" be modeled?
As a single column on the customers table listing all order ids.
As a relationship to a separate orders entity, linked by a foreign key.
As an attribute, since every fact about a customer is an attribute.
It cannot be modeled in a relational database.