We've established that entity types define structure—the blueprint for what entities look like. But databases don't store blueprints; they store data. They store entity instances—the concrete, actual entities that exist in the database at any given moment.

When a company creates a customer record for Alice Chen with email alice@example.com, they're not creating an entity type—that already exists. They're creating an entity instance: a specific, uniquely identified entity that conforms to the Customer entity type.

This distinction—between the abstract definition (type) and concrete realization (instance)—is fundamental to understanding how databases work. Tables define structure; rows are instances. Entity types define what can exist; entity instances are what actually exists. Schema is potential; data is actual.

This page explores entity instances in depth: their lifecycle, their identity, how they differ from types, how they participate in relationships, and how they change over time. Understanding instances completes our picture of entities as the foundation of database modeling.

An entity instance (sometimes called an entity occurrence or simply an entity) is formally defined as:

A specific, uniquely identifiable occurrence of an entity type, existing in the database at a particular point in time.

Let's analyze this definition:

'A specific occurrence' — Not the general concept of 'customer', but a particular customer: Customer #10042, Alice Chen. One individual realization of the type.

'Uniquely identifiable' — Distinguished from every other instance of the same type by its key value. Two customers cannot have the same customer_id. The key makes the instance unique.

'Of an entity type' — The instance conforms to a type. It has exactly the attributes defined by the type, subject to the type's constraints.

'Existing in the database at a particular point in time' — Instances are temporal. They come into existence (INSERT), change (UPDATE), and cease to exist (DELETE). The database state at any moment is a snapshot of currently existing instances.

Mathematical Perspective:

In set theory terms:

• The entity type defines the domain (possible instances)
• The entity set is the current extension (actual instances)
• Each entity instance is a member (element) of the entity set

Example Illustration:

Entity Type Definition:

Employee(
    employee_id: INTEGER [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)
)

Entity Instances:

Each row represents one entity instance. Instance 1001 is Alice Chen. Instance 1002 is Bob Smith. Each is a unique occurrence of the Employee type, identifiable by employee_id, with specific values for each attribute.

Entity instances have a lifecycle—they're created, potentially modified, and eventually may be deleted. Understanding this lifecycle is crucial for database design and application development.

1. Creation (Birth):

An instance comes into existence when inserted into the database:

INSERT INTO Employee (employee_id, first_name, last_name, email, hire_date, salary)
VALUES (1004, 'David', 'Wilson', 'david@corp.com', '2023-06-01', 78000.00);

At this moment, a new entity instance exists. It has:

• A unique identifier (1004)
• Initial attribute values
• Begins participating in the entity set
• Can now participate in relationships

2. Active Life (Existence):

During its existence, an instance:

• Is retrievable via queries
• May have its attributes updated
• Participates in relationships with other entity instances
• Is counted in aggregations
• Triggers integrity checks when changes occur

3. Modification (Change):

Instances can be updated while preserving identity:

UPDATE Employee
SET salary = 82000.00, email = 'david.wilson@corp.com'
WHERE employee_id = 1004;

The instance is still the same entity (same employee_id). Only attributes changed. This is identity preservation—the instance remains the same 'thing' despite changing properties.

4. Deletion (Death):

An instance ceases to exist when removed from the database:

DELETE FROM Employee WHERE employee_id = 1004;

After deletion:

• The instance no longer exists in the entity set
• Queries no longer find it
• Relationships involving it are affected (cascading or restricted)
• Historical record may or may not be preserved (depends on design)

Soft Delete vs. Hard Delete:

Many systems distinguish between:

Hard Delete: The instance is physically removed from the database.

• Row is deleted from table
• Referential integrity may cascade or restrict
• Data is lost (unless backed up)

Soft Delete: The instance is marked as deleted but retained.

• A flag (is_deleted = TRUE) or status change (status = 'DELETED')
• Instance remains in database but is filtered from normal queries
• Preserves historical data and audit trail
• Allows for undo/restore functionality

A fundamental aspect of entity instances is their identity—what makes an instance 'that specific instance' and distinguishes it from all others.

Identity vs. Equality:

Identity asks: Are these references pointing to the same instance? Equality asks: Do these instances have the same attribute values?

Two instances might have identical names, addresses, and other attributes, yet be different instances because they have different identifiers:

Instance A: {id: 1001, name: 'John Smith', city: 'Boston'}
Instance B: {id: 1042, name: 'John Smith', city: 'Boston'}

These are equal in attributes but not identical—they're different people named John Smith.

Key-Based Identity:

In relational databases, identity is determined by the primary key. Two references point to the same instance if and only if they have the same primary key value.

-- Finding an instance by identity
SELECT * FROM Customer WHERE customer_id = 1001;

-- This returns exactly one instance (or none)

Identity Preservation:

When we update an entity instance, we change its attributes while preserving its identity:

-- Before: {customer_id: 1001, name: 'John Smith', email: 'john@old.com'}

UPDATE Customer
SET email = 'john@new.com', name = 'Jonathan Smith'
WHERE customer_id = 1001;

-- After: {customer_id: 1001, name: 'Jonathan Smith', email: 'john@new.com'}

The customer_id remains 1001. This is still the same customer—just with updated information. Relationships referencing customer_id 1001 still reference the same customer.

Why Identity Matters:

1. Relationships depend on it: Foreign keys reference primary keys. If identity weren't stable, relationships would break.

2. History tracking requires it: "What was Customer 1001's address in 2020?" requires stable identity across time.

3. Business logic assumes it: "This is the same customer who complained last month" requires persistent identity.

4. Concurrency depends on it: Locking 'row X' during updates requires stable identity.

Object Identity vs. Value Identity:

Some modeling approaches distinguish:

Object Identity: Instances are identified by their key, regardless of attributes. Used for entities.

Value Identity: Instances are identified by their attribute values. Used for value objects (e.g., a Money amount, a DateRange).

In ER modeling, entities always have object identity. Attributes are values.

Relationships in the ER model connect entity types conceptually, but at runtime, it's entity instances that actually participate in relationships.

Relationship Instances:

Just as entity types have entity instances, relationship types have relationship instances:

Relationship Type:

Customer --places--> Order

Relationship Instances:

(Customer#1001, Order#5001)  -- Alice placed Order 5001
(Customer#1001, Order#5002)  -- Alice placed Order 5002
(Customer#1042, Order#5003)  -- Bob placed Order 5003

Each is a relationship instance connecting two entity instances.

Foreign Keys as Relationship Implementation:

In relational databases, relationships are implemented via foreign keys. The foreign key value in one row references the primary key of another row:

-- Order table
CREATE TABLE Order (
    order_id INT PRIMARY KEY,
    order_date DATE,
    customer_id INT REFERENCES Customer(customer_id)  -- FK
);

-- Data
| order_id | order_date  | customer_id |
|----------|-------------|-------------|
| 5001     | 2023-01-15  | 1001        |  -- Order 5001 placed by Customer 1001
| 5002     | 2023-01-16  | 1001        |  -- Order 5002 placed by Customer 1001
| 5003     | 2023-01-17  | 1042        |  -- Order 5003 placed by Customer 1042

The customer_id value in each Order instance creates the relationship with a Customer instance.

Cardinality at the Instance Level:

Cardinality constraints describe limits on relationship participation:

1:1 — One instance relates to at most one other:

• One employee has one (or zero) parking spot
• {Employee#1001 ↔ ParkingSpot#A15}, {Employee#1002 ↔ ParkingSpot#B22}

1:N — One instance relates to many others:

• One customer can have many orders
• {Customer#1001 ↔ [Order#5001, Order#5002, Order#5003]}

M:N — Many instances relate to many others:

• Students enroll in multiple courses; courses have multiple students
• {Student#101 ↔ [Course#CS101, Course#CS201]}, {Course#CS101 ↔ [Student#101, Student#102, Student#103]}

Participation at the Instance Level:

Total Participation: Every instance must participate.

• Every order must have a customer (no orphan orders)
• Every Order instance has a non-null customer_id

Partial Participation: Instances may not participate.

• Not every customer has placed an order
• Some Customer instances have no related Order instances

Each entity instance has a state—the current values of all its attributes at a given moment. Understanding how state works is essential for data modeling and application development.

Current State:

At any moment, an instance has exactly one value (or NULL) for each attribute:

Customer#1001 State (as of 2023-06-15):
{
    customer_id: 1001,
    name: 'Alice Chen',
    email: 'alice@company.com',
    tier: 'GOLD',
    registration_date: '2020-03-15',
    total_purchases: 15420.50
}

This is the current state. When any attribute changes, the state changes.

State Changes:

States change through UPDATE operations:

-- State transition: GOLD → PLATINUM
UPDATE Customer SET tier = 'PLATINUM' WHERE customer_id = 1001;

-- New state includes tier: 'PLATINUM'

The instance identity remains constant; only state changes.

Valid States:

Constraints define which states are valid:

-- Valid state
{customer_id: 1001, name: 'Alice', email: 'alice@co.com', tier: 'GOLD'}

-- Invalid state (violates NOT NULL on name)
{customer_id: 1001, name: NULL, email: 'alice@co.com', tier: 'GOLD'}

-- Invalid state (violates CHECK on tier)
{customer_id: 1001, name: 'Alice', email: 'alice@co.com', tier: 'DIAMOND'}

The DBMS prevents transitions to invalid states by rejecting violating INSERTs and UPDATEs.

Entity instances appear in different forms across the modeling and implementation stack. Understanding these representations helps connect conceptual understanding to practical implementation.

Conceptual Level (ER Model):

In ER diagrams, we typically show types, not instances. However, we can illustrate instances as specific examples:

[CUSTOMER]          [ORDER]
Alice (1001) ──────→ Order 5001
             │──────→ Order 5002
Bob (1042) ────────→ Order 5003

Such diagrams help validate cardinality and participation.

Logical Level (Relational Schema):

At the logical level, instances become tuples (rows):

Customer(customer_id, name, email, registration_date)
─────────────────────────────────────────────────────
(1001, 'Alice Chen', 'alice@co.com', '2020-03-15')
(1042, 'Bob Smith', 'bob@co.com', '2019-07-22')

Each tuple is one instance. The schema (first row) is the type.

Physical Level (Storage):

At the physical level, instances are stored in database pages as records:

Page 42:
[Record 1: {1001, 'Alice Chen', 'alice@co.com', ...}]
[Record 2: {1042, 'Bob Smith', 'bob@co.com', ...}]
[Free Space]

Indexes provide efficient access to instances by key.

Application Level (Objects):

In application code, instances often become objects:

const customer = await Customer.findById(1001);
// customer = { id: 1001, name: 'Alice Chen', email: 'alice@co.com', ... }

ORMs (Object-Relational Mappers) bridge database rows and application objects.

Entity instances must satisfy constraints defined by their entity type and by relationships. Validation ensures instances represent legitimate entities.

Types of Validation:

1. Attribute-Level Validation:

• Data type conformance: salary must be numeric
• Domain constraints: status must be in predefined list
• Format validation: email must match pattern
• Range validation: age must be positive

2. Entity-Level Validation:

• Key uniqueness: primary key must be unique across all instances
• Entity integrity: primary key cannot be NULL
• Cross-attribute constraints: end_date >= start_date

3. Referential Validation:

• Foreign key validity: referenced entity must exist
• Cascading rules: what happens to references when target is deleted

4. Business Rule Validation:

• Complex domain rules: "Manager must be in same department"
• State transition rules: "Status can go from 'pending' to 'approved', not reverse"
• Calculated constraints: "Order total must equal sum of line items"

Validation Timing:

Immediate (Synchronous):

• Validated during INSERT/UPDATE
• Transaction rejected if invalid
• Maintains consistency at all times
• Example: PRIMARY KEY, NOT NULL, CHECK constraints

Deferred (Within Transaction):

• Validated at commit time, not during individual statements
• Allows temporarily inconsistent states during transaction
• Useful for circular references
• Example: DEFERRABLE foreign key constraints

Application-Level:

• Validated in application code before database operations
• Can provide better user feedback
• Should NOT be the only validation layer
• Example: Form validation before submit

Layered Defense:

Best practice is defense in depth:

[User Input]
    ↓ Application validation (user feedback)
[Application Layer]
    ↓ Business logic validation
[Service Layer]
    ↓ API validation
[Database Layer]
    ↓ Database constraints (final guarantee)
[Storage]

Even if application validation fails, database constraints provide final protection.

We've explored entity instances—the concrete realizations of entity types that constitute the actual data in our databases. Instances bring the abstract world of types to life, existing at a point in time with specific attribute values and relationships.

What's next:

With our understanding of entities, entity sets, entity types, and entity instances complete, we'll turn to a critical practical topic: naming conventions. Proper naming of entities, attributes, and relationships is essential for creating maintainable, understandable data models that stand the test of time.