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:
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:
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.
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:
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.
L'aggregazione viene anche modellata utilizzando le relazioni di chiavi esterne.
Esempio:
Si presupponga che esiste la seguente associazione tra 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.
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.
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.
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.
|