In the previous pages, we learned that entities are 'things with independent existence' and that entity sets collect similar entities together. But what defines 'similar'? What determines which attributes an entity possesses? What constraints govern valid entity values?

The answer lies in the entity type—the formal specification that defines the structure, properties, and rules for all entities of a particular kind. If an entity is a specific employee named Alice Chen, and an entity set is the collection of all employees, then the entity type is the definition of what it means to be an Employee: what information we store, what rules must be followed, what makes each employee unique.

Entity types are to entities what classes are to objects in programming, what blueprints are to buildings in architecture, what recipes are to dishes in cooking. They define the template from which actual instances emerge.

This page explores entity types in depth—their structure, their role in data modeling, their constraints, and how they enable powerful features like inheritance and specialization. Mastering entity types is essential for creating data models that are both expressive enough to capture complex domains and constrained enough to maintain data quality.

An entity type is formally defined as:

A category or class of entities that share a common structure (same attributes) and semantic meaning within the domain.

Let's analyze this definition component by component:

'A category or class' — An entity type represents a classification. Just as biological taxonomy classifies organisms into species, data modeling classifies real-world things into entity types. The Customer entity type represents the classification 'customer' as understood in the business domain.

'That share a common structure' — All entities of a given type have the same set of attributes. Every Customer has name, email, and registration_date. The structure is defined once at the type level and applies to all instances.

'Same attributes' — Attributes are the properties that describe entities. Entity types specify which attributes exist and what values they can hold. This is the schema aspect.

'Semantic meaning within the domain' — Entity types aren't arbitrary groupings. They reflect meaningful classifications in the problem domain. A bank has Customers and Accounts because those concepts are meaningful in banking, not because a programmer thought they'd be convenient.

Components of an Entity Type:

1. Name — The identifier for the entity type (e.g., Employee, Product, Order)

2. Attributes — The properties that describe entities of this type

   • Simple attributes: single-valued, atomic (e.g., first_name)
   • Composite attributes: structured (e.g., address with street, city, state)
   • Derived attributes: computed from other attributes (e.g., age from birth_date)
   • Multivalued attributes: can have multiple values (e.g., phone_numbers)

3. Key — Attribute(s) that uniquely identify each entity instance

   • Candidate keys: minimal sets of attributes that uniquely identify
   • Primary key: the chosen candidate key for identification
   • Alternate keys: candidate keys not chosen as primary

4. Constraints — Rules that valid entities must satisfy

   • Domain constraints: valid values for attributes
   • Uniqueness constraints: keys and unique attributes
   • Not-null constraints: required attributes
   • Business rules: semantic constraints

Not all entity types are created equal. A fundamental distinction exists between strong (or regular) entity types and weak entity types, based on how entities are identified.

Strong Entity Types:

A strong entity type can identify its instances using only its own attributes. It is independent—it doesn't rely on other entity types for its key.

Characteristics:

• Has a primary key composed only of its own attributes
• Entities exist independently of other entities
• Most entity types in a typical model are strong
• Represented in ER diagrams with single-line rectangle

Examples:

• Employee — Identified by employee_id
• Product — Identified by product_code
• Customer — Identified by customer_number
• Building — Identified by building_id

Weak Entity Types:

A weak entity type cannot identify its instances using only its own attributes. It depends on an owning (or identifying) entity type for part of its identification.

Characteristics:

• Has a partial key (or discriminator) that distinguishes entities within one owner
• Full identification requires owner's key + partial key
• Existence depends on the owning entity
• Represented in ER diagrams with double-line rectangle

Classic Weak Entity Example:

Building and Room:

• Building (strong): building_id (e.g., 'Main', 'Annex', 'Tower')
• Room (weak): room_number (e.g., '101', '102', '201')

Room 101 in the Main Building and Room 101 in the Tower are different rooms. The room_number alone (partial key) isn't unique globally—it's unique only within a building. Full identification requires:

(building_id, room_number) → ('Main', '101')
(building_id, room_number) → ('Tower', '101')

Employee and Dependent:

• Employee (strong): employee_id
• Dependent (weak): dependent_name (partial key)

An employee's dependents (spouse, children) might share names with other employees' dependents. 'John Smith' as a dependent is meaningful only in the context of a specific employee.

(employee_id, dependent_name) → ('E101', 'John Smith')
(employee_id, dependent_name) → ('E205', 'John Smith')  -- different person

Attributes are the descriptive properties defined within an entity type. The attribute structure of an entity type determines what information can be stored and how it can be queried. Let's examine attribute classifications in detail.

1. Simple (Atomic) Attributes:

Attributes that cannot be meaningfully subdivided. They hold single, indivisible values.

• employee_id: 'E12345'
• first_name: 'Alice'
• salary: 85000
• hire_date: '2020-03-15'
• is_active: true

Simple attributes map directly to table columns with appropriate data types.

2. Composite Attributes:

Attributes that can be divided into smaller, meaningful sub-parts. They represent structured values.

Example — Full Address:

address:
  ├── street: '123 Main Street'
  ├── city: 'San Francisco'
  ├── state: 'CA'
  ├── postal_code: '94102'
  └── country: 'USA'

Example — Full Name:

name:
  ├── first_name: 'Alice'
  ├── middle_name: 'Marie'
  └── last_name: 'Chen'

Composite attributes can be flattened into multiple simple columns or, in some databases, stored as structured types.

3. Single-Valued vs. Multivalued Attributes:

Single-valued: Hold exactly one value per entity.

• birth_date: one date
• email: one email (if we model it that way)

Multivalued: Can hold multiple values per entity.

• phone_numbers: ['415-555-1234', '415-555-5678']
• skills: ['Python', 'SQL', 'Machine Learning']
• degrees: ['BS Computer Science', 'MS Data Science']

Multivalued attributes create modeling challenges. In relational implementation, they typically become:

• A separate table (recommended for true set semantics)
• An array column (in databases supporting arrays)
• A denormalized string (problematic for querying)

4. Stored vs. Derived Attributes:

Stored: Captured and persisted in the database.

• birth_date: stored
• hire_date: stored

Derived: Computed from other attributes on demand.

• age: derived from birth_date and current date
• years_of_service: derived from hire_date
• full_name: derived by concatenating name components
• total_order_value: derived by summing line items

Derived attributes may be:

• Computed dynamically (always current)
• Computed and cached (faster but potentially stale)
• Materialized (stored and maintained via triggers)

Every entity type must have a mechanism for uniquely identifying each entity instance. This is accomplished through key attributes—attributes whose values distinguish one entity from another within the entity set.

Superkey:

A superkey is any set of attributes that, taken together, uniquely identifies each entity. A superkey may contain more attributes than necessary.

For Employee:

• {employee_id} — superkey
• {employee_id, name} — superkey (includes unnecessary attribute)
• {ssn} — superkey
• {email} — superkey (if unique)
• {employee_id, name, email} — superkey (redundant attributes)

Candidate Key:

A candidate key is a minimal superkey—no proper subset of it is also a superkey. Removing any attribute would make it non-unique.

For Employee:

• {employee_id} — candidate key
• {ssn} — candidate key
• {email} — candidate key (if business guarantees uniqueness)

Primary Key:

From among candidate keys, one is selected as the primary key. This becomes the official identification mechanism used in relationships.

Selection criteria:

• Simplicity: Fewer attributes preferred
• Stability: Values shouldn't change
• Familiarity: Meaningful to users when appropriate
• Performance: Efficient for indexing

Alternate Key:

Candidate keys not chosen as primary key become alternate keys. They're still unique and often get unique constraints/indices.

Natural Keys vs. Surrogate Keys:

A major design decision is whether to use natural or surrogate keys:

Natural Key:

• Uses real-world attributes
• Meaningful to users
• Examples: SSN, ISBN, VIN, email address

Pros: Already exists; no generation needed; meaningful in queries Cons: May change; may have format issues; potential privacy concerns

Surrogate Key:

• System-generated artificial identifier
• No real-world meaning
• Examples: auto-increment integer, UUID, GUID

Pros: Stable; compact; simple joins; no business-rule coupling Cons: Requires lookup for meaning; extra attribute to maintain

Industry Recommendation:

Most modern systems prefer surrogate primary keys with natural keys as alternate/unique:

CREATE TABLE Customer (
    customer_id INT PRIMARY KEY AUTO_INCREMENT,  -- surrogate
    email VARCHAR(255) UNIQUE NOT NULL,          -- natural alternate key
    ssn CHAR(11) UNIQUE,                          -- natural alternate key
    name VARCHAR(100) NOT NULL,
    ...
);

This provides stability (surrogate never changes) and business usability (natural keys for queries and constraints).

Beyond structural definitions (attributes and keys), entity types include constraints—rules that valid entity instances must satisfy. Constraints encode business rules and maintain data quality.

1. Domain Constraints:

Specify valid values for each attribute:

• Data type: salary is DECIMAL(10,2), not TEXT
• Range: salary >= 0, temperature between -50 and 150
• Format: email matches pattern, phone has 10 digits
• Enumeration: status IN ('active', 'inactive', 'pending')

2. Key Constraints:

Enforce uniqueness for key attributes:

• Primary key: exactly one per entity, never null, unique
• Unique constraints: alternate keys and other unique attributes

3. Not-Null Constraints:

Require values for certain attributes:

• Required attributes: name NOT NULL, email NOT NULL
• Optional attributes: middle_name (nullable), fax_number (nullable)

4. Entity Integrity Constraint:

The primary key of an entity can never be null. This fundamental rule ensures every entity is identifiable.

5. Business Rule Constraints:

Domain-specific rules beyond basic data validation:

• "End date must be after start date"
• "Manager must be in the same department"
• "Discount cannot exceed 50%"
• "At least one phone number required if customer_type is 'premium'"

Entity types can be organized into hierarchies through specialization (top-down) and generalization (bottom-up). This enables inheritance of attributes and more precise domain modeling.

Supertype and Subtype:

A supertype is a general entity type that can be specialized into more specific subtypes:

Person (supertype)
├── Employee (subtype)
├── Customer (subtype)
└── Vendor (subtype)

Subtypes:

• Inherit all attributes of the supertype
• Add their own local attributes
• May have their own relationships
• May have their own subtypes (multi-level hierarchies)

Example — Account Hierarchy:

Account (supertype)
├── account_number
├── balance
├── open_date
└── customer_id (FK)
    ├── CheckingAccount (subtype)
    │   ├── overdraft_limit
    │   └── check_fee
    └── SavingsAccount (subtype)
        ├── interest_rate
        └── min_balance

Every CheckingAccount has account_number, balance, open_date (inherited) PLUS overdraft_limit, check_fee (local).

Specialization vs. Generalization:

Specialization (Top-Down):

• Start with general type
• Identify subgroups with distinct attributes
• Create subtypes for each
• "What kinds of Accounts exist?"

Generalization (Bottom-Up):

• Start with specific types
• Recognize common attributes
• Create supertype that captures commonality
• "What do Car, Truck, and Motorcycle have in common?"

Both processes result in the same hierarchy structure; they differ in how you arrive at it.

Constraints on Hierarchies:

Disjoint vs. Overlapping:

• Disjoint: Entity can be in only one subtype
  • A vehicle is either a Car OR a Truck, not both
• Overlapping: Entity can be in multiple subtypes
  • A person can be both Employee AND Customer

Total vs. Partial:

• Total: Every supertype instance must be in some subtype
  • Every Payment is either Cash, Credit, or Debit
• Partial: Supertype instances may not be in any subtype
  • A Person might be neither Employee nor Customer (just a contact)

Designing entity types well is crucial for creating maintainable, flexible data models. Here are established best practices:

1. One Entity Type, One Concept:

Each entity type should represent exactly one concept from the domain. Don't combine unrelated concepts, and don't split a single concept across multiple types unnecessarily.

Bad: PersonOrOrganization (mixed concepts) Good: Person and Organization as separate types (possibly with Party supertype)

2. Meaningful Names:

Entity type names should reflect domain vocabulary, not implementation details:

Bad: tbl_cust, record_type_01 Good: Customer, Employee, Order

Use singular nouns (Customer, not Customers). Be specific when needed (SalesOrder vs PurchaseOrder).

3. Complete Attribute Sets:

Identify all relevant attributes during design. Missing attributes create problems later:

Consider:

• What information describes this entity?
• What questions will users ask about it?
• What reports will include it?
• What calculations need it?

4. Appropriate Key Selection:

Choose keys carefully:

• Use surrogate keys for stability
• Define natural alternate keys for business queries
• Avoid composite keys when simple keys suffice
• Never use mutable attributes as keys

We've explored entity types—the structural blueprints that define what entities are, what attributes they possess, and what rules govern their instances. Entity types are central to ER modeling, enabling precise, enforceable data definitions.

What's next:

Now that we understand entity types as structural definitions, we'll examine entity instances—the actual entities that exist in the database at runtime. Understanding the distinction between types and instances deepens our grasp of how abstract definitions translate to concrete data.