Data modeling has a reputation for being technical, but its core ideas fit on a napkin. If you can describe your business to a new employee, you can model its data. This guide explains the three building blocks — entities, attributes and relationships — in plain language, with examples from a service business.
Entities: the things
An entity is a kind of thing you keep information about. Customers, properties, orders, invoices, vehicles, employees.
Two quick tests:
- Would you count them? “How many properties do we service?” Properties are an entity.
- Does each one have its own identity? Each property has an address that makes it that property.
Each individual thing — one particular customer, one particular property — is called an instance of the entity.
Attributes: what you know about each thing
An attribute is a piece of information about an entity: a customer’s name, a property’s street address, an invoice’s total.
Good attribute design comes down to three habits:
- One fact per attribute. “Name and phone” in one field is two facts sharing a box.
- A clear type. Dates as dates, amounts as numbers, identifiers as text.
- Rules where they help. Required or optional; a valid email format; a value from a fixed list.
Attributes that always travel together — street, city, state and postal code — form a natural group. Treating groups as reusable units is one of the most effective ways to keep data consistent across many forms and records.
Relationships: how things connect
A relationship describes how instances of one entity connect to instances of another. There are three shapes.
One-to-one
Each instance on one side connects to at most one on the other. Each property has exactly one site survey. One-to-one relationships often mean the two things could be modeled as one — or that one belongs to the other.
One-to-many
One instance connects to many. One customer can have many properties; each property belongs to one customer. This is the most common shape in business data.
Many-to-many
Many instances connect to many. A crew works at many properties; a property is visited by many crews. Many-to-many relationships usually need something in the middle — a visit that records which crew was at which property on which day. That middle thing often turns out to be an important entity in its own right.
Ownership vs. reference
It’s useful to distinguish two kinds of connection:
- Ownership — the child only makes sense as part of the parent. A site survey belongs to its property; if the property goes, so does the survey.
- Reference — two independent things point at each other. A service request refers to a customer, but the customer exists regardless.
Deciding which connections are ownership and which are references is one of the most important modeling choices you’ll make.
Common mistakes
- Duplicating attributes instead of relating entities. Copying a customer’s address onto every order means five slightly different copies of the same address.
- Modeling a process step as an entity. “Approving” isn’t a thing; an “approval” might be.
- One giant table. Putting customers, properties and jobs in one sheet forces repeated information and blank cells.
- Free text where structure matters. If you’ll ever filter, sort or report on it, give it a type and rules.
A worked example
A landscaping business might model:
- Customer — contact details. Owns nothing; referenced by properties and requests.
- Property — service address and site details. Related to one customer.
- Site survey — belongs to one property (ownership, one-to-one).
- Service visit — belongs to one property; references the crew that did the work.
- Crew — stands alone; referenced by visits.
Five entities, a handful of reusable attribute groups, and clear relationships. That’s a data model.
Normalization without the jargon
“Normalization” is the formal name for a simple habit: store each fact once, in the place it belongs.
If a customer’s phone number appears on the customer record, it should not also be copied onto every order. Orders refer to the customer; the phone number lives with the customer. When it changes, it changes once.
Two practical rules capture most of the benefit:
- Don’t repeat a fact across many rows. If the same value is typed repeatedly, it probably belongs to a different entity that those rows should reference.
- Don’t mix two entities in one place. A sheet holding both customer details and job details will repeat customer details on every job.
There are exceptions. Sometimes a value is deliberately captured at a point in time — the address a job was performed at, as it was then. That’s not duplication; it’s a historical fact, and it belongs with the job.
Identifiers matter more than they look
Every entity needs a way to say “this one, not that one”. Names are poor identifiers: they’re duplicated, misspelled and changed. A stable identifier — generated by the system — makes relationships reliable and matching across systems possible.
When integrating two systems, store each side’s identifier with the other’s record. That single habit prevents most duplicate-record problems.
From model to forms
A data model shapes the forms people fill in:
- Each attribute group becomes a section of a form.
- Required attributes become required fields.
- Relationships become references — pointing at an existing customer rather than retyping their details.
- Repeated measurements get captured separately from the profile information.
If a form asks for information that doesn’t fit anywhere in your model, that’s a prompt to extend the model rather than to add an untyped notes field.
A modeling checklist
- Have you listed the entities as nouns?
- Does each entity have a stable identifier?
- Are repeated attribute groups defined once and reused?
- Is each relationship classified as one-to-one, one-to-many or many-to-many?
- For many-to-many, have you identified the entity in the middle?
- Is each connection either ownership or reference, deliberately?
- Does the model handle three real cases from last week?
Frequently asked questions
How do I know when to split an entity? If a list of attributes contains two clearly different subjects, or if some attributes are blank for most instances, it’s probably two entities.
Should history be part of the model? Yes — decide explicitly which facts are current values and which are historical events. Events usually become their own entity.
Is this only for databases? No. The same thinking improves spreadsheets, forms and any system that holds business information.
Putting it into a system
In Stratosphere Atlas, these ideas map directly: entities become classifications, attribute groups become reusable data schemas, owned children become resources, and each individual thing is a topic with its records. See Modeling your business in Atlas and Data modules and resources.
