DataslopeThinking in Entities
Learn how to spot the real-world things your database should track, and how those entities become tables and rows.
Suppose someone says, "Customers place orders for products." Before
we write a single CREATE TABLE, we have to ask a design question:
what kinds of things are worth tracking?
Those things are entities. Learning to see them is the first step from "I know SQL" to "I can design a database."
What an entity is
An entity is a distinct kind of thing your system cares about:
customer, order, product, invoice, student, appointment.
It is not one specific thing yet. It is the type of thing.
One entity type usually becomes one table. One real thing of that type becomes one row.
That distinction matters. customers is the table because it stores
many customers. Ada is one row because she is one real customer.
Start with the nouns
A practical way to begin is to read a description of the system and circle the nouns. Nouns are not automatically entities, but they are excellent candidates.
Customers place orders for products. Each order has a shipping address and a status.
The verbs matter too. "Place" hints that customers and orders are
connected. But the first pass is about finding the things.
Nouns are clues, not commands
Some nouns are only attributes. In "customer email," customer is an
entity, but email is probably a column on customers.
Candidate entities are boxes
Designers often sketch entities as boxes before deciding exact columns or SQL syntax. The box says, "this is a kind of thing we may need to store."
At this stage, the boxes are intentionally simple. You are building a map of the domain, not a finished schema.
One entity type, one table
Once an entity is real enough to track, it usually gets its own table. A table should hold rows that are all the same kind of thing.
Mixing different entity types into one table creates confusion. A customer row and a product row do not have the same meaning, the same attributes, or the same relationships.
The tables stay separate because they represent different entity types. Queries can combine them later when a question needs both.
Quick check
In the sentence "Students borrow books from a library," which pair is most likely to be modeled as entity types?
Borrow and from.
Students and books.
Library and from.
Students and borrow.
Test the idea with rows
A helpful question is: can I imagine many rows of this kind? If yes, you may have an entity type.
For an online shop, there are many customers, many orders, and many
products. Those are strong entity candidates. A single order's status
can have many possible values, but it describes an order rather than
standing alone as the main thing.
Entity names should be clear
Good entity names are ordinary words from the domain. Prefer
customers, orders, and products over vague names like data,
records, or items unless those are truly the business terms.
Clear names make the design easier to discuss. If the team cannot explain what belongs in a table, the entity is probably not clear yet.
Check your understanding
What is an entity in database design?
A single SQL query that returns rows.
A distinct kind of thing worth tracking, such as a customer, order, or product.
Any word that appears in a user interface.
A column that stores a number.
How does an entity type usually map to a relational table?
One entity type becomes one column.
One entity type becomes one database server.
One entity type becomes one table, and each real thing becomes one row.
Every entity type must be stored in the same table.
Why is "circle the nouns" a useful early modeling habit?
Because every noun must become a table.
Because nouns often reveal the things, people, places, or events the system cares about.
Because verbs are never useful in database design.
Because SQL table names are required to match every noun exactly.