UML: Class & Object Diagrams

From Class Diagram to Database & Code

18 min Lesson 9 of 10

From Class Diagram to Database & Code

A class diagram is not just documentation — it is a blueprint. Once your domain model is stable, you can mechanically translate it into two deliverables that developers care about most: a relational database schema and source-code class skeletons. Understanding this translation is one of the most practical skills a systems analyst can master, because it bridges the gap between analysis and implementation.

Why the Mapping Matters

Developers frequently receive a class diagram from analysts and must produce working code and a database from it. When the translation rules are applied consistently, the result is a schema whose tables mirror the domain, foreign keys that match associations, and class files whose fields and methods follow directly from the model. Errors in the mapping — such as ignoring multiplicity or missing an association class — are expensive to fix once data starts accumulating.

Rule 1 — Each Class Becomes a Table

Every concrete class in the diagram maps to a table. The class name becomes the table name (usually plural in practice). Each attribute becomes a column, and the UML type maps to a database type:

String → VARCHAR
Integer → INT
Boolean → TINYINT(1) or BOOLEAN
Date / DateTime → DATE / DATETIME
Decimal → DECIMAL(p,s)

Every table also gets a surrogate primary key (id) unless the model specifies a natural key. In code, the class becomes a file with private fields and getter/setter methods (or public properties depending on the language).

Rule 2 — Associations Become Foreign Keys

The multiplicity of an association determines exactly how the foreign key is placed:

One-to-Many (1 → 0..*) — the foreign key lives on the many side. For example, an Order belongs to one Customer: the orders table gets a customer_id column.
One-to-One (1 → 0..1) — the foreign key lives in the weaker/optional side. A Patient has one optional MedicalRecord: the medical_records table gets a patient_id (unique).
Many-to-Many (* → *) — a junction table is required. It has two foreign keys — one to each side — and its own primary key (or a composite one).

In code, a one-to-many association becomes a collection field on the one side (e.g., List<Order> orders) and a reference field on the many side (e.g., Customer customer).

Rule 3 — Aggregation and Composition

Aggregation maps the same way as a regular association — a foreign key on the part side (or a junction table for many-to-many). The distinction is semantic, not structural, in the database. In code, the "whole" class holds a reference or collection to the "part".

Composition signals a stronger ownership: the part cannot exist without the whole. In the database, add ON DELETE CASCADE to the foreign key so that deleting the whole automatically removes its parts. In code, the whole is responsible for creating and destroying its parts.

Rule 4 — Inheritance Strategies

Inheritance has three common mapping strategies in relational databases:

Single Table Inheritance (STI) — one table for the entire hierarchy with a type discriminator column. Simple but wastes space with NULLs for subclass-specific columns.
Class Table Inheritance (CTI) — one table per class in the hierarchy; the subclass table's primary key is also a foreign key to the parent table. Normalized but requires JOINs.
Concrete Table Inheritance — one table per leaf class, with all parent attributes duplicated. Fast reads but data duplication.

In code, the class hierarchy maps directly: the parent class (or abstract class) is the base; subclasses extend it and inherit attributes and methods.

An online store class diagram (left) mapped to relational database tables (right). The many-to-many Order–Product association becomes the order_items junction table.

Rule 5 — Association Classes Become Junction Tables

When a many-to-many relationship carries its own attributes (an association class), those attributes become columns in the junction table. In the diagram above, OrderItem holds quantity and unitPrice: these become columns in the order_items table alongside the two foreign keys.

Rule 6 — Abstract Classes and Interfaces

Abstract classes do not get their own table when using Concrete Table Inheritance, but do get one in Class Table Inheritance. Interfaces have no database mapping — they are a code-only concept. In code, abstract classes become abstract class declarations; interfaces become interface declarations with method signatures and no implementation bodies.

The Payment class hierarchy mapped using Class Table Inheritance (CTI): one table per class, with the subclass table's primary key doubling as a foreign key to the parent payments table.

Code Skeleton Example

Translating to code is equally mechanical. Consider the Order class from the online store. A typical object-oriented skeleton looks like this:

// Java-style skeleton derived from the class diagram
public class Order {
    private int id;
    private Customer customer;        // association → reference field
    private List<OrderItem> items;    // composition → collection
    private LocalDateTime date;
    private BigDecimal total;
    private String status;

    public Order(Customer customer) {
        this.customer = customer;
        this.items = new ArrayList<>();
        this.date = LocalDateTime.now();
        this.status = "PENDING";
    }

    public void confirm() { this.status = "CONFIRMED"; }
    public void cancel()  { this.status = "CANCELLED"; }
    public BigDecimal getTotal() { return this.total; }
}

Notice how each UML attribute becomes a private field, each association becomes a reference or collection, and each UML operation becomes a method. The constructor enforces the mandatory association (an Order must have a Customer).

Analyst Tip — Stop at the Boundary. Your job as a systems analyst is to produce a correct, complete class diagram. Developers own the code-generation step. However, knowing the translation rules helps you catch errors early: if you cannot map your diagram to tables cleanly, the model itself may have a flaw — a missing multiplicity, a misplaced association, or an unnecessary class.

Naming Conventions Matter. Use PascalCase for class names and camelCase for attributes and operations in UML. When generating tables, convert to snake_case (e.g., OrderItem → order_items). Consistent naming avoids confusion between the model and the implementation.

Do Not Flatten Composition into Attributes. A common mistake is to represent a composed part (like an Address inside a Customer) as a bag of string attributes on the parent class. This breaks normalization and hides the structure. Model it as a separate class, then decide in the database whether to give it its own table or embed it as columns (an acceptable trade-off for simple value objects, but make it a conscious choice).

Checklist: Class Diagram to Database

Every concrete class → one table.
Every attribute → one column (with the correct SQL type).
One-to-many association → FK on the many-side table.
Many-to-many association (with or without association class) → junction table with two FKs.
Composition → add ON DELETE CASCADE to the FK.
Inheritance → choose STI, CTI, or Concrete Table and apply consistently.
Abstract classes → table only in CTI (holds shared columns).
Interfaces → no table, no columns — code only.

With these rules in hand, you can hand a developer a class diagram and a mapping decision sheet, and they will be able to build a correct database and code structure without guessing. That precision is the hallmark of a professional systems analyst.