Using UML Class Diagrams for Data Models

Learning outcomes

UML class diagrams were designed for software modeling, not specifically for relational databases, but their classes, attributes, associations, multiplicities, and generalization structures can communicate data models effectively. The danger is assuming an object model and a relational schema are the same thing. They overlap, but their design constraints differ.

Class versus entity versus table

A UML class describes a type of object with attributes and potentially behavior. A conceptual entity type describes a distinguishable domain concept. A relational table represents a relation in a database schema. These concepts can correspond, but not necessarily one-to-one.

A simple UML-style data class

For a data-model review, methods such as save() or calculateAge() are often omitted because they distract from persistence semantics. If the diagram is shared with application developers, behavior can be shown on separate views.

Associations and multiplicities

UML places multiplicities at association ends:

• 0..1 — zero or one;
• 1 — exactly one;
• 0..* or * — zero or many;
• 1..* — one or many.

For WorkshopHub:

Customer "1" -------- "0..*" Asset

Read it as: each Asset is associated with one Customer, while a Customer may be associated with zero or many Assets.

Role names matter in UML too

Recursive and multi-role associations need role names. Example:

The role names explain which side is mentor and which side is mentee. Without them, a self-association line is difficult to interpret.

Association names add domain meaning

UML associations can be named with verbs such as owns, services, or assigned to. This is useful when the same pair of classes participates in different relationships.

For example, Employee and WorkOrder may have separate associations:

• Employee opens WorkOrder;
• Employee approves WorkOrder;
• Employee works on WorkOrder.

Association classes

When an association has its own attributes, UML can use an association class. Technician–WorkOrder has assignment facts:

Technician "*" -------- "*" WorkOrder               |               |       WorkOrderAssignment       -------------------       startedAt       endedAt       role

In the relational schema, WorkOrderAssignment becomes an associative table/entity with foreign keys to Technician and WorkOrder.

Composition and aggregation are not foreign-key cascades

UML includes aggregation and composition notation to express whole-part semantics. Developers sometimes map composition directly to ON DELETE CASCADE. That shortcut is dangerous.

Composition may suggest strong lifecycle ownership, but database deletion behavior must still consider:

• audit retention;
• legal retention;
• soft deletion;
• shared references;
• historical reporting.

Never infer destructive database behavior from one diagram symbol without explicit lifecycle rules.

Generalization and inheritance

UML can express a superclass and subclasses:

        Party       /     \      /       \ Customer   Supplier

This says Customer and Supplier share the semantics of Party. It does not yet say how to store them relationally. Common mappings include:

• single-table inheritance;
• class-table inheritance;
• concrete-table inheritance;
• separate tables with no database-level shared supertype.

Chapter 5 covers mapping supertypes and subtypes to relational schemas.

Disjoint versus overlapping subtypes

Ask whether one Party may be both Customer and Supplier. If yes, subtypes overlap. If not, they are disjoint. Also ask whether every Party must belong to a subtype or whether a plain Party instance is valid.

These are semantic constraints. A UML generalization arrow alone may not communicate all of them unless the diagram includes additional constraints or notes.

Qualifiers, constraints, and notes

UML supports richer annotations, but data diagrams should remain readable. If a constraint is essential, show it near the association or in a linked rule catalogue:

{one active primary assignment per work order}{endedAt >= startedAt}{serialNumber unique within manufacturer}

Do not bury important database invariants in prose that reviewers never see.

Object references versus database relationships

Application code may model a direct object reference:

workOrder.asset

The database implementation may use:

work_order.asset_id -> asset.asset_id

But object-oriented code may also use collections, lazy loading, identity maps, caching, and aggregate boundaries. Those are application concerns. The relational model must preserve keys, integrity, set semantics, and constraints independently.

Do not let ORM annotations become the conceptual model

ORMs can generate database schemas from class definitions, but ORM convenience is not a replacement for data modeling. Problems commonly appear when teams:

• model many-to-many relationships as hidden framework join tables without naming business facts;
• allow nullable foreign keys because object construction is convenient;
• use inheritance mapping defaults without considering query patterns;
• omit unique business keys because object IDs already exist;
• confuse cascade persistence with business lifecycle.

WorkshopHub UML fragment

Customer "1" -------- "0..*" AssetAsset    "1" -------- "0..*" WorkOrderTechnician "1" -------- "0..*" WorkOrderAssignmentWorkOrder  "1" -------- "0..*" WorkOrderAssignmentPart       "1" -------- "0..*" PartUsageWorkOrder  "1" -------- "0..*" PartUsage

This representation communicates multiplicities similarly to Crow's Foot, while fitting naturally into a broader software architecture model.

When UML is a good choice

UML is useful when:

• software architects and developers already use UML;
• data structures must be discussed alongside service/domain models;
• inheritance and object associations are important;
• one shared notation reduces translation overhead between teams.

For DBA-focused physical design, a relational ER notation may still be clearer.

Practice: object model or data model?

Summary and next lesson

UML class diagrams can communicate entities, attributes, multiplicities, association roles, association classes, and inheritance, but object structure is not automatically relational structure. The next lesson focuses on naming and layout conventions that make any notation easier to review and maintain.

References

• Martin Fowler, UML Distilled.
• Object Management Group, UML specification.
• Martin Fowler, Patterns of Enterprise Application Architecture.
• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.