Entities and Entity Sets

In the previous page, we established what makes something an entity—a 'thing' with independent existence. But databases rarely deal with individual entities in isolation. A customer database doesn't store information about a single customer; it manages information about all customers. A product catalog doesn't describe one product; it describes the entire inventory.

This brings us to a fundamental organizing concept: the entity set. An entity set is the collection of all entities of a particular type that exist within the database at any given time. It's the conceptual equivalent of saying "all customers" or "all products"—a grouping that treats similar entities as a unified collection.

Understanding entity sets is essential because they bridge the gap between individual entities and the tables that will eventually store them. Every entity set in a conceptual model typically becomes a table in the physical database. More profoundly, entity sets align with set theory—the mathematical foundation underlying relational databases—enabling the powerful algebraic operations that make relational systems so flexible and expressive.

An entity set is formally defined as:

A collection of entities of the same type that share the same attributes.

Let's carefully unpack this definition:

'A collection of entities' — An entity set is a group, not a single entity. At any moment, an entity set contains zero or more individual entities. The set might be empty (a new system with no customers yet), small (a startup's product catalog), or massive (a social network's user base).

'Of the same type' — All entities within an entity set share the same fundamental nature. The Customer entity set contains only customer entities, never products or orders. This type consistency enables uniform treatment—every member of the set has the same structural properties.

'That share the same attributes' — This is the key characteristic. Every entity in an entity set is described by the same set of attributes. If Customer has name, email, and phone, then every customer in the Customer entity set has these three attributes (though values may differ or be null).

Mathematical Perspective:

From a set-theoretic viewpoint, an entity set is exactly what it sounds like—a set in the mathematical sense. It has:

• Extension — The actual entities currently in the set (the data)
• Intension — The definition of what can be in the set (the schema)

The extension changes constantly as entities are inserted, updated, and deleted. The intension remains stable, defining the structure that all set members must conform to.

Example Illustration:

Consider the Employee entity set:

Intension (Schema):

Employee(employee_id, first_name, last_name, email, hire_date, department_id, salary)

Extension (Sample Data):

{E101, 'Alice', 'Chen', 'alice@corp.com', '2020-03-15', 'D01', 85000}
{E102, 'Bob', 'Smith', 'bob@corp.com', '2019-07-22', 'D02', 72000}
{E103, 'Carol', 'Davis', 'carol@corp.com', '2021-01-10', 'D01', 91000}
...

The intension defines what every employee looks like. The extension is the current set of actual employees. A new hire adds to the extension; a resignation removes from it. But the intension—the structure—remains constant until the database schema changes.

Entity sets have several fundamental properties inherited from mathematical set theory, with additional constraints specific to database modeling:

1. Uniqueness (No Duplicates):

Like mathematical sets, entity sets cannot contain duplicate entities. Each entity in the set is unique, distinguished by its key. You cannot have two customers with the identical identity—even if their names and addresses happen to match, their identifiers differ.

This uniqueness is enforced through primary keys—attribute(s) that uniquely identify each entity within the set.

2. Homogeneity:

All entities in an entity set are of the same type and share the same attribute structure. You cannot mix customers and products in the Customer entity set. This homogeneity enables consistent operations across all set members.

3. Dynamic Extension:

The membership of an entity set changes over time as the real world changes:

• New entities enter through INSERT operations
• Entities exit through DELETE operations
• Entity attributes change through UPDATE operations

At any point in time, the entity set represents a snapshot of current reality.

4. Order Independence:

Mathematical sets have no inherent order—{A, B, C} and {C, A, B} are the same set. Entity sets inherit this property. While queries may return results in various orders, the entity set itself has no concept of 'first' or 'last' entity.

The terms 'entity set' and 'entity type' are sometimes used interchangeably, but they have distinct meanings that experienced data modelers carefully distinguish:

Entity Type:

An entity type is the schema—the definition, blueprint, or template that describes what an entity looks like. It specifies:

• The name of the entity category (e.g., "Employee")
• The attributes that all entities of this type possess
• Any constraints on those attributes

The entity type is intensional—it defines the structure without specifying actual data.

Entity Set:

An entity set is the collection of actual instances of an entity type at a given point in time. It is:

• The collection of all entities conforming to the entity type
• Extensional—it is the actual data
• Time-varying as entities come and go

Analogy — Class vs. Instances:

In object-oriented programming:

• Entity Type is like a class definition
• Entity Set is like the collection of all objects instantiated from that class
• Entity (individual) is like a single object instance

In Practice:

When designing a database, you define entity types—deciding what attributes each category of entity will have. When operating the database, you work with entity sets—inserting entities, querying entities, relating entities.

Common Usage:

In casual conversation and even in many textbooks, 'entity type' and 'entity set' are used loosely. Authors might say "the Employee entity" when they mean the entity type/set. Context usually clarifies the meaning:

• "Employee has attributes..." → Entity Type
• "Employee contains 500 records..." → Entity Set
• "Each Employee must have..." → Entity (individual)

For formal work and exam purposes, understanding the precise distinction matters. Entity types define structure; entity sets hold data.

In Entity-Relationship diagrams, entity sets are represented visually using standardized notation. While several notation styles exist, the core concepts remain consistent:

Chen Notation (Original):

Peter Chen's original ER notation, from his 1976 paper, represents entity sets as rectangles:

• Entity set name in singular form ("Customer", not "Customers")
• Name typically centered in the rectangle
• Connected to attribute ovals via lines
• Key attributes underlined or marked specially

Crow's Foot (IE) Notation:

The Information Engineering (IE) or Crow's Foot notation, popular in industry tools:

• Entity sets as rectangles
• Attributes listed inside the rectangle
• Primary key marked with PK or placed above a line
• Used by many commercial modeling tools

UML Class Diagram Style:

When using UML for data modeling:

• Entity sets as class boxes
• Three compartments: name, attributes, operations (often empty for data models)
• Primary keys marked with «PK» stereotype

IDEF1X Notation:

Used in some government and enterprise settings:

• Rounded or square corners indicate entity dependencies
• Primary keys above horizontal line within box
• Detailed notation for various constraint types

Naming Conventions for Entity Sets:

Consistent naming is crucial for diagram readability:

1. Singular vs. Plural:

• Singular (recommended): "Customer", "Product", "Order"
• Represents the entity type/set conceptually
• Matches natural language ("A Customer has...", "Each Order contains...")

2. Case Conventions:

• PascalCase: CustomerOrder, ProductCategory
• Title Case: Customer Order, Product Category
• ALL CAPS: CUSTOMER, PRODUCT (common in older systems)

3. Descriptive Names:

• Avoid abbreviations when possible: "Employee" not "Emp"
• Use domain vocabulary: "Physician" if that's what the business calls them, not "Doctor"
• Be specific: "SalesOrder" vs "PurchaseOrder" rather than just "Order"

4. Avoid Technical Prefixes:

• "Customer" not "tbl_Customer" or "Customer_T"
• Physical naming conventions belong in implementation, not conceptual models

Cardinality of an entity set refers to the number of entities it contains at any given time. Understanding cardinality is important for capacity planning, performance considerations, and constraint specification.

Types of Cardinality:

1. Set Cardinality (Size):

The total count of entities in the set. This is descriptive—real-world data:

• Small: 1-100 entities (e.g., departments, configuration records)
• Medium: 100-10,000 entities (e.g., products, employees)
• Large: 10,000-1,000,000 entities (e.g., customers, transactions)
• Massive: 1,000,000+ entities (e.g., events, log entries, social posts)

2. Growth Rate:

How the set cardinality changes over time:

• Static: Rarely changes (countries, status codes)
• Slow growth: Gradual increase (customers, products)
• High volume: Rapid continuous growth (transactions, events)
• Volatile: Frequent inserts and deletes (sessions, temporary data)

3. Minimum Cardinality:

Some business rules specify minimum set sizes:

• "The system must always have at least one administrator"
• "Every department must have at least one employee"

These are constraint expressions, not just observations.

Cardinality Estimation:

During requirements gathering, estimate entity set cardinalities:

1. Current Size: How many entities exist now?
2. Growth Rate: How many new entities per day/month/year?
3. Retention: How long are entities kept before archival/deletion?
4. Peak Projection: What's the expected size in 1, 3, 5 years?

Example Analysis:

E-Commerce Platform Cardinality Estimates:

This analysis reveals that ClickEvent requires special handling (partitioning, archival), while Product can likely remain a simple table structure.

Entity sets don't exist in isolation—they connect to each other through relationships. While we'll explore relationships fully in later modules, it's important to understand how entity sets serve as the endpoints of relationships.

Entity Sets as Participants:

A relationship in the ER model is defined over entity sets, not individual entities. When we say "Customers place Orders," we're describing a relationship between:

• The Customer entity set, and
• The Order entity set

This relationship then applies to individual entity pairs—a specific customer placing a specific order.

Degree of Relationships:

Relationships can involve different numbers of entity sets:

• Binary (degree 2): Between two entity sets

  • Customer —places→ Order
  • Employee —works_in→ Department

• Ternary (degree 3): Among three entity sets

  • Supplier —supplies→ Part —to→ Project
  • Doctor —prescribes→ Medication —to→ Patient

• Unary (degree 1): An entity set related to itself

  • Employee —manages→ Employee
  • Person —married_to→ Person

Role Names:

When an entity set participates multiple times in the same relationship (especially in unary relationships), role names clarify participation:

Employee (as manager) —manages→ Employee (as subordinate)
Person (as husband) —married_to→ Person (as wife)

Relationship Sets:

Just as entities form entity sets, relationship instances form relationship sets. The "places" relationship set contains all current instances of customers placing orders:

places = {
  (Customer#1001, Order#5001),
  (Customer#1001, Order#5002),
  (Customer#1042, Order#5003),
  ...
}

This is again a mathematical set—with uniqueness, no order, and time-varying membership.

Subset and Superset Relationships:

Entity sets can have subset/superset relationships with each other (specialization/generalization):

• Employee ⊃ Manager ⊃ Senior Manager
• Vehicle ⊃ {Car, Truck, Motorcycle}
• Account ⊃ {CheckingAccount, SavingsAccount}

Subset entity sets inherit attributes from their superset while adding specialized attributes. This is explored in detail in EER (Enhanced Entity-Relationship) modeling.

Universal and Existential Considerations:

Relationships can express universal or existential constraints:

• Every order must have a customer (total participation)
• Some customers have orders (partial participation)

These participation constraints shape data integrity rules in the eventual database.

One of the most important aspects of entity sets is their direct correspondence to relations (tables) in the relational model. Understanding this mapping illuminates why ER modeling is such a powerful design tool.

The Mapping:

Example Transformation:

ER Model:

Entity Set: Employee
Attributes: employee_id (PK), first_name, last_name, email, hire_date, salary

Relational Schema:

CREATE TABLE Employee (
    employee_id INT PRIMARY KEY,
    first_name VARCHAR(50) NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE,
    hire_date DATE NOT NULL,
    salary DECIMAL(10,2)
);

The entity set becomes a table. Each attribute becomes a column. The primary key attribute becomes the primary key constraint.

Why This Matters:

The entity set → relation mapping is why ER modeling is such an effective design tool:

1. Conceptual Clarity: Entity sets capture what we're storing without how we're storing it

2. Mechanical Translation: The mapping from ER to relational is systematic—not artistic interpretation

3. Quality Assurance: Problems in entity set design (missing keys, redundant data, ambiguous relationships) surface early, before implementation

4. Communication: Business stakeholders can understand entity sets; database developers can implement them; the mapping provides precise translation

The Set Theory Foundation:

Both entity sets and relations are grounded in set theory:

• An entity set is a set of entities
• A relation is a set of tuples
• Relational algebra operations (select, project, join, union) are set operations

This mathematical foundation means relational databases have well-understood properties, optimization strategies, and correctness guarantees. The path from entity sets to relations preserves these mathematical properties, ensuring that conceptual design quality translates to implementation quality.

We've explored the concept of entity sets—the fundamental grouping mechanism that collects entities of the same type. Entity sets bridge individual entities and database tables, providing the structural foundation for relational systems.

What's next:

Now that we understand how entities are grouped into entity sets, we'll explore entity types in greater depth—examining how types define structure, constrain values, and enable powerful inheritance hierarchies through specialization and generalization.