In a conceptual data model, how do you decide whether something like a customer's address should be modeled as an entity in its own right or as an attribute of the customer?
answer
- identity, multiplicity, description, lifecycle
- attributes describe exactly one instance
- needs its own attributes -> entity
- shared or repeating -> entity
- same concept differs per domain
basics
~20 sAn entity is a thing with its own identity, its own describing facts and its own lifecycle. An attribute is one fact about a single entity instance. If addresses repeat, need describing, or are referenced on their own, model an entity.
solid answer
~50 sI ask four questions. **Identity**: do I ever refer to this thing on its own, apart from its owner? **Multiplicity**: can one owner have several at once (home, billing, shipping)? **Description**: does the thing itself need attributes (validated flag, geocode, valid-from date)? **Lifecycle**: is it created, changed or removed independently, or shared between owners? Any yes pushes it toward being an entity; all no means it is just a group of attributes on Customer. In a simple retail model where each customer has exactly one address nobody else uses, address is a composite attribute — street, city, postcode grouped under one name. In a logistics model where addresses repeat, get validated and geocoded and are shared across customers and shipments, Address is an entity with its own relationships. The mistake is answering in the abstract: the same concept is an attribute in one domain and an entity in another, and only the domain decides.
go deeper
Recall the definitions and give one clean example each way: birth date is an attribute, Customer is an entity, and address depends on whether it repeats.
Lead with the tests — identity, multiplicity, own attributes, lifecycle — and show the same concept flipping between attribute and entity as the domain changes.
Add the consequences: repeating columns and CSV fields when you under-model, join sprawl and unmaintained lookup tables when you over-model. Mention that the decision should come from business language.
Frame it as scope control: entities are the things the organisation manages, audits and shares, so promoting one commits you to a lifecycle, ownership and often an API. Discuss deferring the promotion until the business actually manages the thing.
## The two building blocks A conceptual (ER) model describes what a business talks about, before any tables exist. An **entity** is a class of things with independent existence and identity — Customer, Order, Product, Flight. Identity means you can tell two instances apart and keep referring to the same one over time even as every fact about it changes. An **attribute** is a single descriptive fact belonging to exactly one entity instance — a customer's date of birth, an order's placed-at timestamp. Attributes have no life of their own: the value "blue" is meaningless until it is the colour of some car. ## The four tests **Identity.** Do you need to point at the thing independently — to list them, count them, correct one in place, or attach other things to it? Attributes are never pointed at; they are read through their owner. **Multiplicity.** Can one owner hold several values at the same time? A single-valued fact stays an attribute. Several simultaneous values means the thing is either a multivalued attribute or a separate entity. **Description.** Does the candidate need attributes of its own? The moment you want to record an address's verified-at timestamp or its latitude, it is behaving like an entity, because only entities have attributes. **Lifecycle and sharing.** Is it created and retired on a different schedule from its owner, or shared by more than one owner? Shared, independently-lived things are entities; anything that lives and dies exactly with its owner can be attributes. ## Worked example: address A payroll system stores one home address per employee, never searches by it, never validates it. Address is a **composite attribute**: a named group of simpler attributes (street, city, postcode) on Employee. A delivery system needs several addresses per customer, distinguishes their kinds, geocodes them, keeps the address a parcel was actually sent to even after the customer edits their profile, and reuses one warehouse address for thousands of shipments. Every test says entity. ## Relationships are not attributes A common error is listing "customer id" as an attribute of Order in the conceptual model. A link from one entity to another is a **relationship**, drawn as a line, not an attribute. Foreign key columns are an artifact of turning the model into tables, not part of the conceptual picture. Keeping them out is what lets you discuss cardinality honestly before committing to a physical shape. ## Why the call matters Under-modelling shows up as repeating groups — address1, address2, address3 — or comma-separated strings, both of which make querying and constraining the data awkward. Over-modelling shows up as a swarm of single-column satellite entities that add joins and buy nothing: promoting a status code to an entity when it has no attributes of its own, is never referenced independently, and never repeats, costs more than it returns unless the business really manages that list as data. ## How to decide quickly Ask the domain expert whether they ever talk about the thing on its own — "we deduplicate addresses", "we archive addresses" — or only ever as a property of something else. Business language is the strongest signal available at conceptual-modelling time, and it is far cheaper to change the model than the shipped schema.
- Give an example where promoting a concept to an entity is the wrong call.A single-valued status code with no attributes of its own, never managed by the business as data, is best left as an attribute. Promoting it creates a one-column satellite that every query must join to, adds a lifecycle nobody maintains, and buys no new expressiveness. Promote it only if the business wants descriptions, ordering, or effective dates on the list.
- Should the foreign key that links Order to Customer appear in the conceptual model?No. In the conceptual model that link is a relationship drawn between the two entities, with cardinality and optionality on it. Foreign keys are the physical device that implements the relationship once you map to tables. Adding them early hides the modelling question — whether an order may exist without a customer, and whether one customer may have many orders.
Colour is an attribute of a car; the paint shop that applied it is an entity — you can visit it, describe it, and other cars point at it.
saying these in an interview costs you the question
- Claiming address is always an entity (or always an attribute) regardless of the domain
- Listing foreign keys such as customer_id as conceptual attributes of the entity
- Treating anything that gets its own table as an entity, so the answer becomes circular
- Promoting every code list to an entity for its own sake, adding joins with no attributes behind them
- Confusing an attribute with a column type decision — conceptual modelling is not about VARCHAR sizes