Entities and Entity Sets

Every database begins with a question: What are we storing data about? The answer to this question shapes every subsequent design decision—from table structures to query patterns, from performance characteristics to maintainability. In the Entity-Relationship model, this fundamental concept is captured by the notion of an entity.

The concept of an entity seems deceptively simple at first glance. A customer is an entity. A product is an entity. A transaction is an entity. But as we delve deeper, we discover that entity identification is both an art and a science—requiring careful analysis, domain expertise, and an understanding of how data will be used throughout the system's lifecycle.

This page explores the rigorous definition of entities, their philosophical foundations, and the practical techniques for identifying them from real-world requirements. Mastering entity recognition is the foundational skill upon which all other Entity-Relationship modeling capabilities are built.

In the Entity-Relationship model, introduced by Peter Chen in his seminal 1976 paper "The Entity-Relationship Model—Toward a Unified View of Data," an entity is formally defined as:

An entity is a 'thing' in the real world with an independent existence.

This definition, while elegant in its simplicity, carries profound implications. Let us unpack each component:

'A thing in the real world' — Entities represent objects, concepts, or phenomena that exist in the domain being modeled. They can be tangible (a person, a building, a product) or intangible (a course, an account, a reservation). The key requirement is that they have meaning within the problem domain.

'With an independent existence' — This is the critical distinguishing factor. An entity exists on its own merits, not merely as a property or characteristic of something else. A customer's name is not an entity—it's an attribute of the customer entity. But the customer themselves? That's an entity.

This independence criterion becomes particularly important when distinguishing entities from attributes (which describe entities) and from relationships (which connect entities).

The Independence Test:

To determine if something qualifies as an entity, apply the independence test:

1. Can it exist on its own? Does the 'thing' have meaning independent of other things?
2. Does it have an identity? Can you distinguish one instance from another?
3. Is it something you would want to store data about? Are there multiple pieces of information (attributes) that describe it?

If the answer to all three questions is 'yes,' you likely have an entity. If any answer is 'no,' reconsider—it may be an attribute, a relationship, or perhaps not database-relevant at all.

One of the most enlightening distinctions in entity classification is between tangible (physical) and intangible (conceptual) entities. Understanding this distinction prevents the common mistake of limiting entities only to physical objects.

Tangible Entities:

These are entities that correspond to physical objects in the real world. You can touch them, see them, or interact with them physically. They occupy space and have material existence.

Examples include:

• Employee — A physical person working for an organization
• Product — A tangible good that can be manufactured, stored, and sold
• Building — A physical structure with a location and dimensions
• Vehicle — A car, truck, or other physical transportation asset
• Equipment — Machines, tools, or physical devices

Intangible Entities:

These entities have no physical form but have independent conceptual existence. They represent abstractions, agreements, events, or intellectual constructs that the organization tracks and manages.

Examples include:

• Course — An educational offering with curriculum and structure
• Account — A financial abstraction representing monetary relationships
• Reservation — An agreement about future resource usage
• Policy — An insurance contract or organizational rule
• Project — A planned undertaking with goals and timeline
• Transaction — A record of business activity
• Skill — A capability that can be possessed and assessed

The Reality Check:

Consider a university database. The tangible entities are obvious: Students, Professors, Buildings, Books. But the intangible entities are often more numerous and more central to the university's operations:

• Courses — Abstract offerings that exist independent of any particular class session
• Enrollments — The concept of a student being registered in a course
• Degrees — Academic credentials with requirements and standards
• Grades — Assessments that have meaning within an academic context
• Semesters — Time periods that structure academic activity
• Transcripts — Official records of academic achievement
• Academic Programs — Structured paths toward educational goals

A model that captures only the tangible entities (students, professors, buildings) would be fundamentally incomplete. The intangible entities carry the business logic and represent the core value the university provides.

Identifying entities from natural language requirements or domain analysis is a skill that improves with practice. Several systematic techniques help ensure comprehensive entity discovery:

1. The Noun Analysis Technique:

This classic approach involves identifying nouns in requirements documents, user stories, or domain descriptions. Nouns often represent either entities or attributes; further analysis determines which.

Example requirement: "The hospital system must track patients, their appointments, the doctors who treat them, and the medications prescribed during each visit."

Nouns identified: hospital, system, patients, appointments, doctors, medications, visit

• Entities: Patient, Appointment, Doctor, Medication, Visit
• Not entities: Hospital (system scope, not data item), system (technical, not data)

2. The Questions Technique:

Ask yourself what questions the system needs to answer. The subjects of these questions suggest entities.

• Who are our customers? → Customer entity
• What products do we sell? → Product entity
• Which orders are pending? → Order entity
• When did transactions occur? → Transaction entity
• Where are our warehouses? → Warehouse entity

3. The Domain Expert Interview Technique:

Engage with people who understand the business domain. Ask open-ended questions:

• "What are the main things you deal with in your daily work?"
• "What records do you keep?"
• "What would you need to look up frequently?"
• "What do you report on?"

Domain experts naturally speak in terms of the entities relevant to their work. A warehouse manager talks about shipments, inventory items, suppliers, and orders. A hospital administrator discusses patients, appointments, procedures, and insurance claims.

4. The Document Analysis Technique:

Examine existing forms, reports, spreadsheets, and paper records. The sections and headers often correspond to entities, and the fields represent attributes.

A customer invoice contains:

• Header section → Invoice entity
• Customer information block → Customer entity
• Line items → Product entity (and perhaps Order Line entity)
• Payment information → Payment entity

While every domain has unique entities, certain entity patterns recur across virtually all business applications. Recognizing these patterns accelerates the modeling process and ensures you don't overlook fundamental entities.

Party Entities:

Almost every system deals with people and organizations:

• Person — Individual human beings (customers, employees, contacts)
• Organization — Companies, departments, agencies, groups
• Customer — A role-based specialization of Person or Organization
• Employee — Another role-based specialization
• Vendor/Supplier — External parties providing goods or services

Product/Service Entities:

Most systems track what is bought, sold, or provided:

• Product — Tangible goods offered
• Service — Intangible offerings
• Product Category — Classifications and hierarchies
• Inventory Item — Physical instances of products

Transaction Entities:

Records of activities and events:

• Order — Requests for products or services
• Transaction — Completed business activities
• Payment — Monetary exchanges
• Invoice — Billing documents
• Shipment — Movement of goods

One of the most challenging decisions in data modeling is determining whether something should be modeled as an entity or as an attribute. This decision has lasting implications for flexibility, query complexity, and maintenance.

The Fundamental Difference:

• An attribute describes a property of an entity—a characteristic that has meaning only in the context of that entity
• An entity has independent existence and typically has its own attributes and relationships

The Color Example:

Consider modeling products in an e-commerce system where each product has a color.

As an attribute:

Product(product_id, name, price, color)

This works when:

• Color is just descriptive text
• No relationships involve colors specifically
• You don't need to track additional information about colors
• The set of colors is simple and rarely changes

As an entity:

Product(product_id, name, price, color_id)
Color(color_id, name, hex_code, rgb_values, pantone_reference, is_metallic)

This works when:

• Colors have their own properties (hex codes, RGB values, Pantone references)
• You need consistency ("Red" vs "red" vs "RED" problem)
• Reports analyze products by color
• Color is referenced in multiple places (products, campaigns, themes)

The Address Conundrum:

Addresses illustrate this distinction perfectly. A customer's address could be:

Simple attribute approach:

Customer(id, name, address)

• Works for basic use cases
• Address is just stored text
• No structure, hard to query by city or state

Structured attribute approach:

Customer(id, name, street, city, state, zip, country)

• Better structure
• Can query by location components
• Still duplicates if multiple customers share an address

Entity approach:

Customer(id, name, primary_address_id)
Address(id, street, city, state, zip, country, lat, lng, validated)

• Full flexibility
• Addresses can be reused, normalized, geocoded
• Supports complex scenarios (billing vs. shipping addresses)
• More complex to implement

The Right Choice Depends on Requirements:

For a simple contact list, attribute is fine. For an e-commerce platform with shipping logistics, address as an entity is essential. There's no universally correct answer—only the answer that fits your requirements.

Just as entities and attributes must be distinguished, so must entities and relationships. Sometimes what appears to be a simple relationship between entities actually warrants promotion to entity status itself—a concept called reifying a relationship.

The Basic Scenario:

Consider students enrolling in courses:

As a simple relationship:

Student --enrolls_in-- Course

This captures the basic fact: "Student X is enrolled in Course Y."

As a reified entity (Enrollment):

Student --has-- [Enrollment] --for-- Course

The Enrollment is now an entity with its own properties:

• enrollment_date
• grade
• status (enrolled, dropped, completed)
• section_number
• attendance_record

When to Reify Relationships:

Promote a relationship to an entity when:

1. The relationship has attributes — If data describes the relationship itself (not just the participants), consider an entity

2. The relationship has relationships — If the relationship connects to other things, it needs independent existence

3. History matters — If you need to track changes over time (when did enrollment start? when did it end?)

4. The relationship has cardinality constraints — A person can have multiple enrollments in the same course (different semesters)

5. Business significance — The relationship is so important it has its own lifecycle and business rules

The Evolution Pattern:

Many models evolve through these stages:

Stage 1 — Simple relationship: "Employees work in departments."

Stage 2 — Relationship with attributes: "We need to track when each employee started in their department and their role."

Stage 3 — Full entity: "Employees can have multiple assignments over time, each with start/end dates, supervision relationships, and budget allocations. Assignment history must be preserved for audit."

Recognizing when you've reached Stage 3 is crucial. The signals are:

• Multiple attributes on the relationship
• Historical tracking requirements
• The relationship itself participating in other relationships
• Business rules that apply specifically to the relationship

At this point, the relationship has become an entity with its own identity and lifecycle.

The concept of entities in database modeling draws from centuries of philosophical inquiry into the nature of objects, identity, and classification. Understanding these foundations deepens our modeling intuition.

Ontology and Data Modeling:

Ontology—the philosophical study of being—asks fundamental questions that parallel data modeling challenges:

• What kinds of things exist? → What entities should our model contain?
• What makes something the thing it is? → What defines entity identity?
• How do things relate to one another? → How do we model relationships?
• What properties do things have? → What attributes describe entities?

Data modeling is, in essence, applied ontology for a specific domain.

Identity and Individuation:

Ancient philosophers grappled with the Ship of Theseus: if every plank of a ship is gradually replaced, is it still the same ship? Database designers face the same question:

• If a customer changes their name, address, and email, is it still the same customer?
• The answer: Yes, if we maintain identity through a stable identifier.

This is why entities have keys—stable identifiers that persist regardless of attribute changes. The entity's identity is defined by its key, not its current attributes.

Natural Kinds vs. Nominal Kinds:

Philosophers distinguish:

• Natural kinds — Categories that exist independently of human classification (e.g., gold, water)
• Nominal kinds — Categories we create for convenience (e.g., 'premium customer', 'overdue invoice')

Some entities correspond to natural kinds—a Person is a Person due to biological reality. Others are nominal—a 'VIP Customer' is defined by business rules that could change.

This distinction matters for modeling stability:

• Natural kind entities tend to be stable across systems and time
• Nominal kind entities may need more flexibility (status flags, type attributes)

The Reality Criterion:

Philosopher W.V.O. Quine proposed we are committed to the existence of whatever our best theories quantify over. In data modeling terms: entities are the things your business logic makes claims about.

If business rules say "customers must have valid addresses" or "orders must be shipped within 3 days," then Customer and Order are real entities in your domain—things your system makes formal commitments about.

Practical Implications:

These philosophical considerations lead to practical guidelines:

1. Identify by keys, not attributes — Attributes change; identity persists
2. Model stable structures — Natural kinds change less than nominal kinds
3. Separate identity from classification — An entity can change type without changing identity
4. Respect business ontology — Model what the business believes exists, not just what programmers find convenient

We've explored the foundational concept of entities in the Entity-Relationship model—the building blocks upon which all database designs are constructed. Let's consolidate our understanding:

What's next:

Now that we understand what entities are individually, we'll explore how entities are organized into entity sets—collections of similar entities that share common attributes and behaviors. This collective view enables us to model not just individual things, but categories of things, laying the groundwork for database tables and their schemas.