In data modeling, an entity is a distinct thing, person, place, event or concept about which an organization needs to store data, and which can be uniquely identified. Customer, Product, Order and Invoice are typical entities in databases. Each entity is described by attributes, such as a name or a date, and is connected to other entities through relationships.
Strictly speaking, modelers distinguish an entity type, the category such as Customer, from an entity instance, one specific customer. In everyday modeling language, “entity” usually means the type, and in a relational database it typically becomes a table, while each instance becomes a row. The term is also called a data entity.
What makes something an entity in data modeling
A candidate becomes an entity when it passes three tests: the business needs to keep data about it, it has more than one instance, and each instance can be told apart from the others by an identifier. A company name that appears once in the system is a configuration value, not an entity; Customer, with thousands of instances, is.
Entities usually correspond to nouns in business language. During requirements analysis, modelers collect nouns from interviews and documents, then filter them: some become entities, some become attributes of other entities, and some are synonyms of the same concept. Verbs between nouns, such as “customer places order”, point to relationships.
| Element | Meaning | Example for Customer |
|---|---|---|
| Entity type | The category of things | Customer |
| Entity instance | One concrete occurrence | Customer number 10482 |
| Attribute | A property describing the instance | Name, email, date of registration |
| Identifier (key) | Attributes that make an instance unique | Customer number |
| Relationship | A link to another entity | Customer places Order |
Types of entities
Entities differ in how they are identified and what role they play. The classic entity-relationship model introduced by Peter Chen distinguishes strong and weak entities, and later modeling practice added further categories that appear in almost every ER diagram.
| Entity type | Characteristic | Example |
|---|---|---|
| Strong entity | Identified by its own attributes | Customer, Product |
| Weak entity | Identified only together with its owner | Order line within an Order |
| Associative entity | Resolves a many-to-many relationship | Enrollment between Student and Course |
| Subtype entity | Specialization of a general entity | Business customer and private customer |
| Reference entity | Small, stable code list | Country, Currency |
An associative entity often grows its own attributes. Enrollment, for example, records the grade and the enrollment date, which belong neither to Student nor to Course. Recognizing such entities early prevents a many-to-many relationship from hiding important business data.
Subtype entities need two extra decisions. Completeness states whether every instance of the supertype must belong to a subtype, and disjointness states whether an instance may belong to more than one subtype at once. A person who is both an employee and a customer, for example, requires overlapping subtypes, which changes how keys and tables are designed.
Entities across the levels of a data model
The same entity looks different at each level of abstraction. In a conceptual model it is a business concept with a name and a definition; in a logical model it gains keys and normalized attributes; in a physical model it becomes a table with data types, constraints and indexes for a specific database system.
| Level | Representation of the entity | Typical details |
|---|---|---|
| Conceptual data model | Named business concept | Definition, main relationships |
| Logical data model | Entity with attributes and keys | Primary keys, foreign keys, cardinality, normalization |
| Physical data model | Table or set of tables | Data types, indexes, partitioning, surrogate keys |
The mapping is not always one to one. A subtype hierarchy may be stored in a single table or in one table per subtype, and in a star schema one business entity may be denormalized into a wide dimension table. The entity remains the stable business meaning behind these physical choices.
Entity, attribute or relationship
The hardest modeling decisions are about what deserves to be an entity. A good rule is to promote a concept to an entity when it has its own attributes, its own lifecycle or relationships to more than one other entity.
| Concept | Model as | Reason |
|---|---|---|
| Customer address, one per customer, no history | Attribute group | No independent identity or lifecycle |
| Addresses with history and several uses | Entity | Own attributes, validity dates, shared by orders |
| Product color from a fixed list | Reference entity | Controlled values reused across products |
| Employee works on project with hours | Associative entity | The relationship carries its own data |
In software design, a related but different meaning exists: in domain-driven design, an entity is an object with a persistent identity in code, contrasted with a value object. The data modeling entity is a database concept, although the two often describe the same business thing.
Common modeling mistakes
Most entity problems come from unclear definitions rather than technical errors. Without a written definition, two teams can model Customer differently, one including prospects and one only paying clients, and their data will never reconcile.
- Modeling reports instead of things: an entity named Monthly sales summary is a query result, not a business object.
- Merging different concepts: one Party table for everything hides rules that apply only to customers or suppliers.
- Splitting one concept: separate tables for Web customer and Shop customer duplicate data and identity.
- Relying on unstable identifiers: email addresses change, so a surrogate key plus a unique business key is safer.
- Skipping cardinality: an entity without defined relationships leaves join rules to guesswork.
The idea in brief
An entity is any kind of thing a business wants to keep records about. A library, for example, keeps records about books, members and loans. Each of those is an entity, and each individual book or member is one example of it.
Think of an entity as a labeled drawer in a filing cabinet. The drawer label says Members, every card inside describes one member, and the lines on each card are the attributes, such as name and phone number.
A practical scenario
A regional clinic group plans a new appointment system. In workshops with receptionists and doctors, the data modeler collects nouns such as patient, doctor, appointment, room, insurance and diagnosis, and writes a one-sentence definition for each.
The analysis shows that Appointment is an associative entity linking Patient, Doctor and Room, with its own attributes for date, duration and status. Insurance turns out to need its own entity because one patient can have several policies with validity dates, while blood type stays an attribute of Patient.
The resulting logical model with eleven clearly defined entities becomes the basis for the database tables. Because definitions were agreed before coding, the reporting team later finds that appointment statistics match across all clinics without manual reconciliation.