Modellare un Database con UML: un ponte tra oggetti e tabelle

Introduzione

UML (Unified Modeling Language) è diventato uno standard per la modellazione di applicazioni scritte con linguaggi orientati agli oggetti. In un precedente articolo abbiamo esplorato le sue potenzialità in ambito software. Ma UML può essere utilizzato anche per modellare la struttura di un database, offrendo un vantaggio significativo: la possibilità di passare direttamente da un’analisi object-oriented alla progettazione delle tabelle, senza dover cambiare formalismo.

UML vs E-R: due linguaggi, un obiettivo

Tradizionalmente, per la modellazione dei database si utilizzano i diagrammi E-R (Entità-Relazione), di cui abbiamo parlato in un altro articolo. Tuttavia, i Class Diagram di UML possono rappresentare in modo equivalente la struttura di un database relazionale, con il vantaggio di mantenere coerenza tra analisi e progettazione.

Class Diagram: la chiave per modellare i dati

In UML esistono molti tipi di diagrammi, ma per descrivere la struttura di un database ci si concentra sui Class Diagram. Ogni classe viene rappresentata da un rettangolo suddiviso in tre sezioni:

1. Nome della classe (es. Cliente)
2. Attributi (es. Nome, Cognome, Email)
3. Operazioni (es. calcolaSconto) – non rilevanti per la struttura del database

Relazioni tra classi

• Ereditarietà: freccia con punta bianca dalla classe derivata alla base
• Aggregazione: linea con rombo vuoto (riferimento opzionale)
• Composizione: linea con rombo pieno (relazione di appartenenza forte)
• Cardinalità: indicata agli estremi della linea (es. 1:N)

Dal diagramma UML al database relazionale

Per convertire un Class Diagram in uno schema relazionale si seguono alcune regole:

1. Creare una tabella per ogni classe
2. Creare un campo per ogni attributo
3. Definire la chiave primaria
4. Gestire le relazioni:
   • 1:1 → possibile fusione delle tabelle
   • 1:N → chiave esterna + vincolo di integrità referenziale
   • N:N → tabella ponte con due chiavi esterne

Esempio pratico: Gestionale Clienti e Fatture

Classi coinvolte

• Cliente: IDCliente, Nome, Cognome, Email
• Fattura: IDFattura, Data, IDCliente
• Prodotto: IDProdotto, Nome, PrezzoUnitario
• DettaglioFattura: IDDettaglio, IDFattura, IDProdotto, Quantità, Sconto

Relazioni

• Cliente 1:N Fattura
• Fattura 1:N DettaglioFattura
• Prodotto 1:N DettaglioFattura

SQL generato

CREATE TABLE Cliente (
  IDCliente INT PRIMARY KEY,
  Nome VARCHAR(100),
  Cognome VARCHAR(100),
  Email VARCHAR(255)
);

CREATE TABLE Fattura (
  IDFattura INT PRIMARY KEY,
  Data DATE,
  IDCliente INT,
  FOREIGN KEY (IDCliente) REFERENCES Cliente(IDCliente)
);

CREATE TABLE Prodotto (
  IDProdotto INT PRIMARY KEY,
  Nome VARCHAR(100),
  PrezzoUnitario DECIMAL(10,2)
);

CREATE TABLE DettaglioFattura (
  IDDettaglio INT PRIMARY KEY,
  IDFattura INT,
  IDProdotto INT,
  Quantità INT,
  Sconto DECIMAL(5,2),
  FOREIGN KEY (IDFattura) REFERENCES Fattura(IDFattura),
  FOREIGN KEY (IDProdotto) REFERENCES Prodotto(IDProdotto)
);

Stored Procedure e logica applicativa

UML consente anche di modellare il comportamento delle classi. Questa logica può essere trasferita nel database tramite stored procedure, ad esempio per:

• Calcolare lo sconto su una fattura
• Promuovere un impiegato
• Applicare regole di business direttamente nel DBMS

Le stored procedure offrono vantaggi in termini di sicurezza, performance e centralizzazione della logica.

Conclusione

I Class Diagram UML rappresentano una valida alternativa ai diagrammi E-R per la modellazione dei database relazionali. Consentono di:

• Uniformare l’analisi e la progettazione
• Automatizzare la generazione di script SQL
• Integrare logica applicativa e struttura dati

Per chi sviluppa software gestionali, questo approccio semplifica la transizione da oggetti a tabelle, mantenendo coerenza, chiarezza e potenziale evolutivo.