Linea guida: Forward engineering di database relazionali
Questa guida descrive i metodi per associare le classi di progettazione permanenti nel modello di progettazione alle tabelle del modello di dati.
Relazioni
Descrizione principale

Introduzione

Questa linea guida descrive i metodi per associare le classi di progettazione permanenti nel modello di progettazione alle tabelle nel modello dati

Trasformazione di elementi di modelli di progettazione in elementi di modelli dati

Le classi permanenti, provenienti dal modello di progettazione, possono essere trasformate in tabelle nel modello dati.  La tabella qui di seguito illustra un riepilogo della mappatura generale tra elementi di un modello di progettazione e quelli di un modello dati.

Elemento del modello di progettazione

Elemento del modello dati corrispondente

Classe Tabella
Attributo Colonna

Associazione

Relazione non identificativa

Classe di associazione

Tabella di intersezione

Aggregazione composita

Relazione identificativa

Associazione molti a molti

Tabella di intersezione

Molteplicità

Cardinalità

Associazione qualificata

Tabella di intersezione

Generalizzazione (ereditarietà) Tabella separata

Mappatura di classi persistenti in tabelle

Le classi permanenti nel modello di progettazione rappresentano le informazioni che il sistema deve memorizzare. Concettualmente, queste classi possono assomigliare ad una progettazione relazionale. Ad esempio, è possibile riflettere le classi, presenti nel modello di progettazione, in qualche modo come entità dello schema relazionale. Appena il progetto passa dall'elaborazione alla costruzione, tuttavia, gli obiettivi del modello di progettazione e del modello dati relazionale differiscono. Tale divergenza viene causata perché l'obiettivo dello sviluppo del database relazionale è di normalizzare i dati, mentre l'obiettivo del modello di progettazione è di incapsulare un comportamento sempre più complesso. La divergenza di questi due prospettive, dati e comportamento, porta alla necessità di una mappatura tra elementi correlati nei due modelli.

Nel database relazionale nel terzo modulo normale, ciascuna riga nelle tabelle, ciascuna "tupla", viene vista come un oggetto. Una colonna di una tabella equivale ad un attributo permanente di una classe. Si noti che una classe permanente può possedere attributi transitori. Pertanto, nel semplice caso in cui non vi siano associazioni ad altre classi, la mappatura tra le due realtà è facile. Il tipo di dati dell'attributo corrisponde ad uno dei tipi di dati consentito per le colonne.

Esempio

La seguente classe Cliente:

Classe Cliente

quando viene creato un modello in RDBMS verrà tradotta in una tabella chiamata Cliente, con le colonne ID_cliente, Nome e Indirizzo.

È possibile visualizzare un'istanza di questa tabella come:

Diagramma che illustra una parte della nuova tabella del oggetto cliente

Attributi permanenti e chiavi

Per ciascun attributo persistente, le domande devono essere fatte per dedurre informazioni aggiuntive da utilizzare per modellare in modo appropriato l'oggetto persistente nel modello dati relazionale. Per esempio:

  • Questo attributo permanente può servire come chiave o parte di una chiave? Esempio: l'"attributo X, insieme con l'attributo Z, identifica in modo univoco l'oggetto". Nella tabella Cliente, l'ID_cliente rappresenta una chiave primaria.
  • Quali sono i valori minimi e massimi per l'attributo?
  • Sarà possibile effettuare una ricerca utilizzando questo attributo come una chiave? Potrebbe, ad esempio, essere parte di un filtro in un'istruzione di selezione quale "Comunemente si effettua la ricerca di tutte le istanze dove Y > 1000."
  • L'attributo possiede una descrizione del tipo "l'attributo X rappresenta il numero di ritrasmissioni per 100000 caratteri trasmessi"?
  • L'attributo possiede valori numerici possibili e conversioni desiderate tra valori numerici differenti?
  • Chi è autorizzato ad aggiornare l'attributo? Esempio: "T può essere modificato solo da persone che sono nella classe di autorizzazione nn."
  • Chi è autorizzato ad leggere l'attributo? Esempi: "P può essere letto da persone nelle classi di autorità yy e zz" oppure ""P è compreso nelle viste Vi e Vj."
  • Esistono informazioni adeguate sui volumi e le frequenze? Esempi: "Esistono fino a 50 000 ricorrenze di A" oppure "In media vengono modificate 2000 A al giorno".
  • L'attributo è univoco? Esempio: solo una persona possiede lo stesso numero di patente.

Mappatura di associazioni tra oggetti persistenti al modello dati

Associazioni tra due oggetti persistenti vengono realizzate come chiavi esterne agli oggetti associati. Una chiave esterna è una colonna di una tabella che contiene il valore di chiave primari dell'oggetto associato.

Esempio:

Si presuma che esista la seguente associazione tra Ordine e Cliente:

Il diagramma UML che illustra l'associazione tra Ordine e Cliente.

Quando ciò viene associato nelle tabelle relazionali, il risultato è una tabella Ordine ed una Cliente. La tabella Ordine contiene colonne per gli attributi elencati, oltre ad una colonna aggiuntiva, chiamata ID_cliente, che contiene i riferimenti di chiavi esterne alla chiave primaria della riga associata nella tabella Cliente. Per un dato Ordine, la colonna ID_cliente contiene l'identificativo del Cliente al quale viene associato l'ordine. Le chiavi esterne consentono a RDBMS di unificare le informazioni correlate.

Mappatura tra associazioni di aggregazione nel modello dati

L'aggregazione viene anche modellata utilizzando le relazioni di chiavi esterne.

Esempio:

Si presupponga che esiste la seguente associazione tra Ordine ed Articolo linea

Classi Ordine ed Articolo linea

Quando ciò viene associato nelle tabelle relazionali, il risultato è una tabella Ordine ed una Articolo_linea. La tabella Ordine contiene colonne per gli attributi elencati, oltre ad una colonna aggiuntiva, chiamata ID_ordine, che contiene un riferimento di chiavi esterne alla riga associata nella tabella Ordine. Per un'Articolo linea dato, la colonna ID_ordine contiene l'ID_ordine dell'ordine al quale è associato l'articolo della linea. Le chiavi esterne consentono a RDBMS di ottimizzare le operazioni di unione.

Inoltre, è importante implementare un vincolo di eliminazione a cascata che fornisce integrità referenziale nel modello dati. Una volta che viene realizzato, ogni qualvolta viene eliminato l'ordine, vengono anche eliminati tutti relativi articoli di linea.

Modellazione delle relazioni di generalizzazione nel modello dati

Il modello dati relazionale standard non supporta ereditarietà di modellazione in modo diretto. È possibile utilizzare una certa quantità di strategie per modellare l'ereditarietà. Qui di seguito ne viene fornito un riepilogo:

  • Utilizzare tabelle separate per rappresentare la superclasse e la sottoclasse. La tabella di sottoclasse deve includere un riferimento di chiave esterna alla tabella di superclasse. Per creare un'istanza di un oggetto di sottoclasse, si devono unire le due tabelle. Tale approccio è semplice da un punto di vista concettuale, ma spesso offre ridotte prestazioni a causa del lavoro eccessivo.
  • Duplicare tutti gli attributi e le associazioni ereditate come colonne separate nella tabella di sottoclasse. Questa è una cosa simile alla denormalizzazione nel modello dati relazionale standard.

Modellazione di associazioni molti a molti nel modello dati

Una tecnica standard nella modellazione relazionale è rappresentata dall'utilizzo di un'entità di intersezione per rappresentare le associazioni molti a molti. Lo stesso approccio può essere applicato in questo caso; una tabella di intersezione viene utilizzata per rappresentare l'associazione.

Esempio:

Se i fornitori possono fornire molti Prodotti, e un Prodotto può essere fornito da molti Fornitori, la soluzione è quella di creare una tabella Fornitore/Prodotto. Questa tabella dovrebbe contenere solo chiavi primarie delle tabelle Fornitore e Prodotto e servire a collegare i Fornitori ai Prodotti correlati. Il modello oggetto non ha un qualcosa di analogo per questa tabella; viene utilizzata solamente per rappresentare le associazioni nel modello dati relazionale.

Ridefinizione del modello dati

Una volta trasformate le classi di progettazione in tabelle e le relazioni appropriare in modello dati, il modello viene perfezionato per implementare l'integrità referenziale e ottimizzare l'accesso dati attraverso le viste e le procedure memorizzate. Per ulteriori informazioni, consultare la linea guida: Modello dati.

Forward engineering del modello dati

La maggior parte dei tool delle applicazioni supportano la generazione di script DDL (Data Definition Language) dai modello dati e/o la generazione del database dal modello dati.  Il forward engineering del database deve essere pianificato come parte dello sviluppo di applicazioni complessivo e di compiti di integrazione.   La sincronizzazione e la frequenza per il forward engineering del database dal modello dati dipende dalla situazione specifica del progetto.  Per nuovi progetti di sviluppo dell'applicazione, che stanno creando un nuovo database, potrebbe essere necessario il forward engineering iniziale come parte del lavoro di implementazione di una versione strutturale stabile al termine della fase di elaborazione.  In altri casi, il forward engineering iniziale deve essere effettuato nelle prime iterazioni della fase di costruzione.  

I tipi di elementi nel modello dati, di cui può essere effettuato il forward engineering, variano a seconda dei tool di progettazione specifici e del RDBMS utilizzati sul progetto.  In generale, si può effettuare il forward engineering nel database dei maggiori elementi strutturali del modello dati, comprese tabelle, viste, procedure memorizzate, trigger e indici.