Who's Related to Whom: Entities, Attributes, and Relationships

Opening Scene

At a family reunion, someone pins a big poster board near the entrance: photos of every relative, with names underneath, and lines connecting parents to children, siblings to siblings, spouses to each other. A cousin you’ve never met can study that board for two minutes and understand the whole family — who belongs to whom, and how. That poster board didn’t happen by accident. Someone had to decide who counts as “family,” what details are worth noting under each photo, and how the lines should be drawn.

In Plain English

Every data model is built from three simple ingredients: the “things” we care about (like people, products, or orders), the details that describe each thing (like a name or a price), and the connections between things (like “this person is married to that person”). In modelling language these are called entities, attributes, and relationships. Almost everything else in data modelling is just a more elaborate way of organizing these three ingredients.

The Old Way

Building the family reunion poster the traditional way takes patience and judgment:

Entities are the “people” on the board — but deciding who gets their own photo is a real decision. Is a long-time family friend an entity, or just a note under someone else’s photo? In modelling terms: is “Customer” its own entity, or just an attribute of “Order”? Getting this wrong early causes awkward redesigns later.
Attributes are the details written under each photo — birthday, hometown, occupation. In modelling terms, these are the specific facts you choose to record about an entity, like Customer Name or Date of Birth. Not every true fact deserves a place on the board; attributes should matter to the questions you’ll eventually ask.
Relationships are the lines connecting photos — “parent of,” “married to,” “sibling of.” In modelling terms, these describe how entities connect, and they often carry their own meaning (a “married to” line behaves differently from a “parent of” line).

Traditionally, a modeller draws this out by hand or in a diagramming tool, entity by entity, relationship by relationship, refining definitions through interviews and review sessions with the people who actually know the business.

What’s Changing (and Why AI Is the Reason)

AI can infer a first draft of the board from messy source material. Given a pile of spreadsheets, form fields, or even a plain-English description of “how our business works,” AI-assisted modelling tools can now propose a starting set of entities, attributes, and relationships — work that used to require multiple stakeholder interviews just to get a rough draft.
AI is good at noticing relationships humans miss. By scanning actual data values rather than just column names, AI tools can surface relationships that aren’t obvious from documentation alone — for instance, noticing that two seemingly separate fields always move together, hinting at a hidden relationship worth modelling explicitly.
AI shifts the human task toward naming and judgment, not transcription. A model is only as good as whether its entities and relationships actually reflect how the business thinks, not just how the data happens to be laid out. AI can suggest the poster board’s first layout; a person still has to decide whether “Customer” and “Account Holder” are truly the same entity or quietly different ones — a distinction that matters enormously and that source data alone won’t settle.

The Metaphor, Fully Extended

Family Reunion Element	Data Modelling Concept
A person’s photo on the board	An entity (e.g., Customer, Product)
The name under the photo	The entity’s primary identifying attribute
Birthday, hometown, occupation notes	Other attributes (e.g., Date of Birth, City)
A line connecting two photos	A relationship between two entities
The label on the line (“married to,” “parent of”)	The relationship’s name or type
Deciding who gets their own photo vs. a footnote	Deciding what qualifies as its own entity
The poster board’s overall layout	The conceptual/logical model as a whole
A family friend added later, off to the side	A newly discovered entity added during refinement
Someone double-checking the board for accuracy	Validating the model against real stakeholders

For Beginners: What to Actually Do

Start any new model by listing the “nouns” of the business in plain language before worrying about technical structure — that list is your first draft of entities.
For each entity, ask “what do we actually need to know about this?” rather than recording every fact available — that discipline becomes your attribute list.
Draw relationships as simple lines with a plain-English label before trying to formalize them — “a Customer places an Order” is a perfectly good first draft.
When using an AI tool to draft a model, read its proposed entity list out loud to someone who knows the business and ask, “does this match how you’d describe it?”

For Practitioners and Leaders: The Deeper Layer

Watch for “entity creep,” where attributes of one entity quietly deserve to be their own entity (e.g., an Address field that should become its own Address entity once multiple addresses per Customer become possible) — this is one of the most common refactors in real systems.
Be deliberate about relationship semantics, not just their existence — a relationship’s meaning (mandatory vs. optional, time-bound vs. permanent) often matters more than the fact that it exists at all.
When reviewing AI-suggested entities and relationships derived from raw data, distinguish between relationships that reflect genuine business rules and ones that are just incidental patterns in a particular dataset — only the former belong in the model.
Maintain a living glossary of entity and attribute definitions agreed upon by the business; this is what keeps “Customer” meaning the same thing across every team, AI-assisted or not.

Quick Recap

Every data model is built from three ingredients: entities, attributes, and relationships.
Entities are the “things” worth their own record; attributes describe them; relationships connect them.
Deciding what counts as its own entity is a genuine design judgment, not a mechanical step.
AI can now draft entities and surface hidden relationships from raw data quickly.
The human task is shifting toward naming things correctly and validating that a model truly reflects business meaning.

Where This Fits in the Series

Article 1 introduced the three layers a model passes through — conceptual, logical, and physical. This article zoomed into the logical layer’s core ingredients: entities, attributes, and relationships. Next, Article 3 looks at how individual records get uniquely identified and linked together, through the lens of primary, foreign, and candidate keys.

Image Instructions

Image 1 — Header banner (~1600×600px, wide format): A wide illustration of a family reunion entry table, split left-to-right. On the left (“old way”), a large physical poster board stands on an easel, covered in printed photos, hand-written name tags, and string connecting relatives — rendered in muted gray/blue tones, slightly worn at the edges. On the right (“new way”), the same poster board’s right half dissolves into a glowing digital family-tree visualization, with nodes and connecting lines in electric teal/blue, auto-arranging themselves with a soft glow as new relatives appear. Bitt the Beaver stands beside the easel holding a small name tag in one paw. Flat vector illustration style, clean lines, minimal in-image text.

Image 2 — Supporting diagram (~1200×800px): Placed directly after “The Metaphor, Fully Extended” table. A simplified, abstract infographic showing three labeled icon clusters side by side: a single labeled box representing an “Entity,” a small list icon beneath it representing “Attributes,” and a connecting line with an arrowhead representing a “Relationship” linking it to a second entity box. The entity boxes and attribute list are rendered in muted gray/blue; the relationship line glows in electric teal, with a small annotation icon suggesting “AI-detected” near the glowing line. Bitt the Beaver appears small in the corner pointing at the teal relationship line. Flat vector illustration, clean lines, minimal text, soft glow reserved only for the teal AI element.

Cross-series visual identity note: In every image across this series, muted gray/blue always represents “the old/traditional way” and electric teal/blue glow always represents “AI/the new layer.” Bitt the Beaver, the series’ recurring mascot, appears in every header banner and most supporting diagrams, with its prop or pose adapted to each article’s metaphor while its core design stays recognizable. Style is flat vector illustration with clean lines, minimal in-image text, and soft glow/gradient reserved exclusively for AI/new elements.