Enhanced Entity-Relationship Model Overview

In the modern software development landscape, professionals encounter two powerful visual modeling languages:

EER (Enhanced Entity-Relationship): The database designer's tool, focused on data structures, relationships, and persistence. Born from Peter Chen's 1976 ER model and extended through the 1980s.

UML (Unified Modeling Language): The software engineer's tool, a comprehensive notation covering requirements, architecture, behavior, and structure. Standardized by OMG in 1997, synthesizing earlier OO notations.

These aren't competing standards—they're complementary perspectives on the same underlying domain. A skilled practitioner understands both and knows when to use each.

The relationship between EER and UML illuminates fundamental questions:

• How do database-centric and application-centric views of data differ?
• When is EER notation preferable to UML class diagrams (and vice versa)?
• How can models in one notation be translated to the other?

Understanding the UML-EER relationship requires appreciating their distinct origins and eventual convergence.

The ER/EER Lineage (Database Community)

1976: Chen's ER Model → Conceptual database design
1977-1985: Semantic extensions → Generalization, specialization
1985+: EER consolidation → Inheritance, categories, constraints

EER evolved within the database community, always focused on data persistence—what to store, how to structure it, what constraints to enforce.

The UML Lineage (Software Engineering Community)

1970s-1980s: Various OO notations
   - Booch Method (Grady Booch)
   - OMT - Object Modeling Technique (James Rumbaugh)
   - OOSE - Object-Oriented Software Engineering (Ivar Jacobson)
1994-1995: "Three Amigos" collaboration
1997: UML 1.0 standardized by OMG
2005: UML 2.0 major revision

UML evolved within software engineering, focused on complete system modeling—use cases, classes, sequences, states, components, and deployment.

The Convergence

Despite different origins, EER and UML class diagrams model similar concepts—entities/classes, attributes, relationships/associations, inheritance. This isn't coincidental: both emerged from efforts to represent real-world domains computationally.

James Rumbaugh, one of UML's creators, explicitly acknowledged ER/EER influence when developing OMT (Object Modeling Technique), which became UML's class diagram foundation. Many EER concepts appear in UML:

• EER generalization → UML generalization
• EER specialization constraints → UML generalization constraints
• EER relationship cardinality → UML association multiplicity
• EER weak entity → UML composite aggregation

Modern Practice

Today, professionals often need both:

• EER for database design documentation, DBA collaboration, and data modeling tools
• UML for application architecture, developer communication, and design documentation

Understanding the mapping enables translation between teams and tools.

The most direct comparison is between EER diagrams and UML class diagrams. Let's map the fundamental constructs.

Entity Type ↔ Class

Both represent templates for domain objects:

EER:                          UML:
┌───────────────┐             ┌─────────────────────┐
│   EMPLOYEE    │             │      Employee       │
├───────────────┤             ├─────────────────────┤
│ employee_id   │             │ - employeeId: int   │
│ name          │     →       │ - name: string      │
│ salary        │             │ - salary: decimal   │
└───────────────┘             ├─────────────────────┤
                              │ + getSalary()       │
                              │ + promote()         │
                              └─────────────────────┘

Key differences:

• UML includes methods (EER is data-only)
• UML uses visibility markers (+public, -private, #protected)
• UML explicitly shows types in attribute declarations

Relationship ↔ Association

EER Relationship:              UML Association:

EMPLOYEE ───┬─── works_for ───┬─── DEPARTMENT
         (N,1)              (1,1)

            ↓ translates to ↓

┌──────────┐    works_for     ┌────────────┐
│ Employee │ ────────────────→│ Department │
└──────────┘  *          1    └────────────┘
             (many)    (one)

Cardinality Notation Comparison:

Inheritance is where EER and UML align most closely—both directly support class/type hierarchies.

Basic Generalization Mapping

EER Specialization:           UML Generalization:

    EMPLOYEE                    ┌──────────┐
       │                        │ Employee │
      (d)                       └────▲─────┘
    ┌──┴──┐                          │
    │     │                    ┌─────┴─────┐
 HOURLY SALARIED              ┌┴─────┐ ┌───┴────┐
                              │Hourly│ │Salaried│
                              └──────┘ └────────┘

Both express: Hourly IS-A Employee, Salaried IS-A Employee.

Constraint Mapping

EER's specialization constraints have UML equivalents:

Complete Example with Constraints

EER:
    VEHICLE
       ║ (total participation)
    [d,vehicle_type] (disjoint, discriminator = vehicle_type)
    ┌──┴──┬───────┐
    │     │       │
  CAR   TRUCK  MOTORCYCLE


UML:
                    ┌─────────┐
                    │ Vehicle │
                    └────▲────┘
                         │{complete, disjoint}
                         │{discriminator = vehicleType}
              ┌──────────┼──────────┐
          ┌───┴──┐  ┌────┴────┐  ┌──┴────────┐
          │ Car  │  │  Truck  │  │Motorcycle │
          └──────┘  └─────────┘  └───────────┘

Abstract Classes

UML has explicit notation for abstract classes (italicized name or <<abstract>> stereotype). EER doesn't have a direct equivalent, but total specialization implies the supertype is effectively abstract—no instances exist that aren't also in a subtype.

Beyond basic correspondence, several advanced constructs require careful mapping.

1. Weak Entities ↔ Composite Aggregation

EER weak entities depend on their owners for identity. UML expresses this through composite aggregation (filled diamond):

EER Weak Entity:              UML Composite Aggregation:

  BUILDING ════ has ════ ROOM       ┌──────────┐ 1    * ┌────────┐
  (owner)         (weak)            │ Building │◆──────│  Room  │
                                    └──────────┘       └────────┘

The filled diamond (◆) indicates composition—the Room cannot exist without its Building.

2. EER Categories ↔ UML Interfaces/Abstract Classes

EER categories (union types) have no perfect UML equivalent. Options include:

EER Category:                 UML Options:

Person    Company    Bank     Option A: Abstract class
   │         │         │      
   └─────────┼─────────┘         ┌─────────────────┐
            (U)                  │ <<abstract>>    │
             │                   │ AccountHolder   │
      ACCOUNT_HOLDER             └────────▲────────┘
                                     ┌────┴────┐
                                Person  Company

                               Option B: Interface
                                 ┌───────────────┐
                                 │<<interface>>  │
                                 │ IAccountHolder│
                                 └───────▲───────┘
                                    implements

Neither fully captures category semantics (entity belongs to exactly ONE of the parent types). Documentation must clarify.

3. Relationship Attributes ↔ Association Classes

When EER relationships have attributes, UML uses association classes:

EER Relationship with Attributes:

  STUDENT ───────── enrolled_in ───────── COURSE
                         │
                    ┌────┴────┐
                    │ grade   │
                    │ semester│
                    └─────────┘


UML Association Class:

  ┌─────────┐                   ┌────────┐
  │ Student │───────────────────│ Course │
  └─────────┘                   └────────┘
                    │
             ┌──────┴──────┐
             │ Enrollment  │  ← Association Class
             ├─────────────┤
             │ grade       │
             │ semester    │
             └─────────────┘

4. Ternary Relationships

EER ternary (and higher) relationships require special handling in UML:

EER Ternary:                    UML Options:

SUPPLIER ─┐                    Option A: Association class
          │                    Option B: Intermediate class
PROJECT ──┼── supplies         
          │    │               SUPPLIER ─┐
PART ─────┘    │                         ├─→ Supply ←───── PROJECT
           quantity             PART ────┘     │
                                           quantity

Let's examine a complete example modeled in both notations to solidify the mappings.

Domain: University Course Registration

• Students enroll in courses with grades
• Courses belong to departments
• Departments have faculty members
• Some faculty are department chairs
• Graduate students may also be teaching assistants

Both notations are valuable—the choice depends on context, audience, and purpose.

Use EER When:

1. Primary focus is database design

   • You're designing a relational schema
   • The audience includes DBAs and data architects
   • The goal is a physical database implementation

2. Data semantics are paramount

   • Complex participation constraints matter
   • Discriminator-based specialization needs clarity
   • Weak entity relationships need explicit representation

3. Using database-centric tools

   • ERwin, PowerDesigner, MySQL Workbench
   • Database documentation generators
   • Schema migration tools

Use UML When:

1. Modeling complete systems

   • Application architecture, not just data
   • Behavior (sequence diagrams, state machines) matters
   • Multiple diagram types needed

2. Audience is software developers

   • Team uses OO languages (Java, C#, Python)
   • Code generation from models is planned
   • Domain-Driven Design methodology in use

3. Integration with development tools

   • IDE integration (IntelliJ, Visual Studio)
   • Reverse engineering from code
   • Documentation generation (Javadoc links)

Use Both When:

• Large enterprise systems with separate database and application teams
• Projects requiring both database and application documentation
• Organizations with established standards for each domain

When you need to convert between EER and UML (or maintain both), follow systematic translation approaches.

EER → UML Translation Algorithm

For each EER Entity Type E:
    1. Create UML Class C with same name
    2. Copy all simple attributes as UML attributes
    3. For composite attributes: create embedded class or flatten
    4. For multivalued attributes: use Collection<T> type
    5. For derived attributes: prefix with '/' in UML

For each EER Relationship R:
    1. Create UML Association between corresponding classes
    2. Map cardinality: (0,1)→0..1, (1,1)→1, (0,N)→*, (1,N)→1..*
    3. If R has attributes: create Association Class
    4. Add role names if semantically significant

For each EER Specialization:
    1. Create UML Generalization arrows to superclass
    2. Add {disjoint} or {overlapping} constraint
    3. Add {complete} if total, {incomplete} if partial
    4. Note discriminator if attribute-defined

For each EER Weak Entity W:
    1. Create UML class for W
    2. Create Composition (◆) from owner to W
    3. Mark partial key as qualifier if needed

UML → EER Translation Considerations

Translating from UML to EER is often lossy because EER cannot express:

• Methods and behavior
• Access modifiers (public/private)
• Interfaces (behavior contracts)
• Complex type systems (generics, enums as classes)

UML → EER Guidelines:

1. Classes → Entity types (drop methods, visibility)
2. Associations → Relationships (translate multiplicities to cardinalities)
3. Inheritance → Specialization (map constraints if present)
4. Interfaces → Usually omit; may become relationship types
5. Association classes → Relationships with attributes
6. Composition → Weak entity or 1:N with total participation
7. Aggregation → Regular relationship (aggregation is weak in UML)

UML's extensibility mechanism—profiles—allows defining domain-specific notation extensions. The UML Data Modeling Profile adapts UML class diagrams specifically for database design, bringing them closer to EER semantics.

Standard UML Data Modeling Stereotypes

<<table>>       Applied to classes representing database tables
<<column>>      Applied to attributes representing columns
<<PK>>          Primary key attribute
<<FK>>          Foreign key attribute
<<unique>>      Unique constraint
<<index>>       Index definition
<<view>>        Database view
<<schema>>      Database schema container

Example: UML with Data Modeling Profile

┌─────────────────────────────────┐
│        <<table>>                │
│         Employee                │
├─────────────────────────────────┤
│ <<PK>> employee_id: INTEGER     │
│ <<FK>> department_id: INTEGER   │
│ <<column>> name: VARCHAR(100)   │
│ <<column>> salary: DECIMAL(10,2)│
│        <<index>> idx_name       │
└─────────────────────────────────┘

When to Use UML Data Modeling Profile

• Organization is UML-centric and wants unified notation
• Tool ecosystem is UML-based (Enterprise Architect, MagicDraw)
• Need physical database details in models
• Generating DDL from UML models

When to Stick with Traditional EER

• Team expertise is in database design
• Using dedicated database modeling tools
• Need maximum data modeling expressiveness
• Existing documentation is in EER format

Hybrid Approaches

Some organizations use:

• UML for application/domain models (conceptual level)
• EER for database design (logical/physical level)
• Explicit cross-references between models

This separation of concerns can be effective in large organizations with distinct database and development teams.

We have explored the rich relationship between EER and UML, two complementary notations for modeling data and systems. Let's consolidate our understanding.

What's Next

With a thorough understanding of EER's relationship to UML, the final page of this module explores When to Use EER—practical guidelines for deciding when EER is the right tool, when basic ER suffices, and when alternative modeling approaches are more appropriate.