I modelli di dati sono utilizzati per progettare la struttura degli
archivi di dati permanenti utilizzati dal sistema. Il profilo UML (Unified Modeling Language) per la
progettazione di database fornisce ai progettisti una serie di elementi di modellazione utilizzabili per sviluppare la
progettazione dettagliata delle tabelle nel database e modellare il layout fisico della memoria del database.
Inoltre, il profilo di database UML fornisce costruzioni per modellare l'integrità referenziale (vincoli e trigger),
così come procedure memorizzate utilizzate per gestire l'accesso al database.
I modelli di dati possono essere realizzati a livello di applicazione individuale, di reparto o aziendale. I modelli di
dati di tipo aziendale o di reparto possono essere utilizzati per fornire definizioni standard ad entità di business
chiave (come il cliente e dipendente) che poi saranno utilizzate da tutte le applicazioni all'interno di un'unità di
business o azienda. Questi tipi di modelli di dati possono anche essere utilizzati per definire quale sistema
nell'azienda sarà il "proprietario" dei dati per una specifica entità di business e quali altri sistemi saranno utenti
(sottoscrittori) dei dati.
Questa linea guida descrive gli elementi modello del profilo UML per la modellazione di database utilizzata per
costruire un modello dati di un database relazionale. Poiché esistono numerose pubblicazioni sulle teorie generali
di database, la linea guida non copre quest'area. Per informazioni di background sui modelli dati e modelli
oggetto relazionali, consultare Concetto: Database relazionali e orientamento oggetti.
Nota: le rappresentazioni di modellazione dati contenute in questa linea guida sono basate su UML 1.3. Durante la fase
di realizzazione di questa linea guida, il profilo di modellazione dati UML 1.4 non era ancora disponibile.
Come descritto in [NBG01], vi sono
tre stadi generali nello sviluppo di un modello di dati: concettuale, logico e fisico. Questi stadi di
modellazione dati riflettono i diversi livelli di dettaglio nella progettazione della memoria dati permanenti e dei
meccanismi di recupero dell'applicazione. Le argomentazioni sulla modellazione concettuale dei dati sono fornite in ConcettiModellazione dati concettuale. Un sommario della modellazione dati logica e
fisica è fornito nelle successive due sezioni di questa linea guida.
Modellazione dati logica
Nella modellazione dati logica, il Progettista di database è attento ad identificare le entità chiave e
relazioni che catturano le informazioni critiche necessarie all'applicazione per permanere nel database. Durante
le attività the Analisi caso d'uso, Progettazione
caso d'uso e Progettazione classe, il Progettista database e il Progettista
devono collaborare lavorativamente per garantire che le progettazioni in evoluzione delle classi di analisi e di
progettazione per l'applicazione supporteranno adeguatamente lo sviluppo del database. Durante l'attività Progettazione classe, il progettista database e il progettista devono
identificare la serie di classi nel modello di progettazione che necessiteranno di dati permanenti nel database.
Questa serie di classi permanenti nel modello di progettazione fornisce una vista che, sebbene diversa dal modello dati
logico tradizionale, soddisfa molte delle stesse necessità. Le classi permanenti utilizzate nel modello di
progettazione funzionano allo stesso modo delle entità tradizionali presenti nel modello dati logico.Queste classi di
progettazione riflettono in modo accurato i dati che devono essere permanenti, comprese tutte le colonne dati
(attributi) che devono permanere e le relazioni chiave. Ciò rende queste classi di progettazione un eccellente punto di
partenza per la progettazione fisica del database.
La creazione di un modello dati logico separato è considerata un'opzione. Tuttavia, nel caso migliore effettuerà la
cattura delle stesse informazioni in un formato diverso. Nel caso peggiore non effettuerà la cattura e, pertanto, non
soddisferà le esigenze di business dell'applicazione. In particolare, se il database deve servire una singola
applicazione, la vista dell'applicazione dei dati potrebbe essere il migliore punto di partenza. Il progettista di
database crea le tabelle da questa serie di classi di progettazione permanenti in modo da formare un modello dati
fisico iniziale.
Tuttavia, determinate situazioni esistenti potrebbero richiedere la creazione, da parte del progettista di database, di
una progettazione idealizzata del database indipendente dalla progettazione dell'applicazione. In questo caso, la
progettazione del database logico è rappresentata in un modello dati logico separato come parte del Prodotto di lavoro: Modello dati complessivo. Questo modello di
dati logico descrive le entità logiche chiave e le relative relazioni necessarie per soddisfare i requisiti di sistema
per dati di persistenza congruenti con l'architettura globale dell'applicazione. Il modello dati logico può essere
costruito utilizzando gli elementi di modellazione del profilo UML per la progettazione di database descritta nelle
sezioni successive di questa linea guida. Per progetti che utilizzano questa strategia, una stretta collaborazione
tra i progettisti dell'applicazione e quelli del database è assolutamente necessaria per un corretto sviluppo della
progettazione del database.
Il modello dati logico può essere perfezionato applicando le regole standard di normalizzazione come definito in Concetto: Normalizzazione prima di elaborare gli elementi del modello dati logico per
la creazione della progettazione fisica del database.
La figura riportata di seguito illustra la strategia primaria nell'utilizzare le classi del modello di progettazione
come fonte delle informazioni di progettazione logica del database per la creazione di un modello dati fisico iniziale.
Inoltre, illustra l'approccio alternativo di utilizzare un modello dati logico separato.
Strategie di modellazione dati logica
Modellazione dati fisica
La modellazione dati fisica è lo stadio finale di sviluppo nella progettazione del database. Il modello dati
fisico è composto da progettazioni dettagliate delle tabelle di database e dalle relative relazioni create inizialmente
dalle classi di progettazione permanenti e dalle relative relazioni. I meccanismi che eseguono la trasformazione
delle classi del modello di progettazione in tabelle sono descritti in Linea guida: Database relazionali forward engineering. Il modello dati fisico fa
parte del modello dati; non si tratta di una risorsa separata.
Le tabelle nel modello dati fisico dispongono di colonne ben definite, così come di chiavi e indici. Le tabelle possono
anche avere dei trigger definiti come richiesto per supportare la funzionalità del database e l'integrità referenziale
del sistema. In aggiunta alle tabelle, le procedure memorizzate sono state create, documentate e associate al database
in cui risiederà la procedura memorizzata.
Il diagramma riportato di seguito mostra un esempio di alcuni degli elementi del modello dati fisico. Questo
modello di esempio è una parte del modello dati fisico di un'applicazione di asta in linea fittizia. Descrive quattro
tabelle (Auction, Bid, Item e AuctionCategory), insieme ad una procedura memorizzata (sp_Auction) e la relativa classe
contenitore (AuctionManagement). La figura descrive anche le colonne di ciascuna tabella, i vincoli della chiave
primaria ed esterna e gli indici definiti per le tabelle.
Elementi del modello dati di esempio (fisico)
Il modello dati fisico contiene anche le associazioni delle tabelle alle unità di memoria fisica (tablespace) nel
database. La figura riportata di seguito mostra un esempio di questa associazione. In questo esempio, le
tabelle Auction e OrderStatus sono associate ad un tablespace con nome PRIMARY.Inoltre, il diagramma illustra la
modellazione della realizzazione delle tabelle con il database (denominato PearlCircle in questo esempio).
Elementi del modello di memoria dati di esempio
Nei progetti dove è già presente un database, il progettista di database può eseguire il reverse-engineer del database
esistente per riempire il modello dati fisico. Per maggiori informazioni, consultare Linea guida: Database relazioni di reverse-engineering.
Questa sezione descrive le linee guida di modellazione generale per ogni principale elemento del modello dati basato
sul profilo UML per la modellazione di database. Una breve descrizione di ciascun elemento modello è seguita da
un'illustrazione di esempio dell'elemento modello UML. La sezione Relazioni di questa linea
guida include una descrizione sull'utilizzo degli elementi modello.
I pacchetti UML standard sono utilizzati per raggruppare e organizzare gli elementi del modello dati. Ad esempio,
i pacchetti possono essere definiti per organizzare il modello dati in modelli di dati logici e fisici separati.
Inoltre, è possibile utilizzare i pacchetti per identificare i gruppi di tabelle associati logicamente nel modello dati
che costituiscono le principali "aree di argomento" dati di importanza nel dominio di business dell'applicazione che si
sta sviluppando. La figura riportata di seguito mostra un esempio di due pacchetti di area di argomento (Auction
Management e UserAccount Management) utilizzati per organizzare le viste e tabelle nel modello dati.
Esempio di pacchetti di area di argomento
Nel profilo UML per la modellazione del database, una tabella viene modellata come una classe con uno stereotipo di
<<Tabella>>. Le colonne nella tabella sono modellate come attributi con lo stereotipo di
<<colonna>>. Una o più colonne possono essere assegnate come chiave primaria per le immissioni univoche
della riga nella tabella. Le colonne possono anche essere assegnate come chiavi esterne. Le chiavi primarie ed
esterne hanno dei vincoli associati che sono modellati come operazioni stereotipate di <<Chiave primaria>>
e <<Chiave esterna>> rispettivamente. La figura riportata di seguito illustra la struttura di una
tabella di esempio utilizzata per gestire le informazioni sugli articoli venduti all'asta in un sistema di asta in
linea fittizia .
Esempio di tabella
Le tabelle possono essere associate ad altre tabelle attraverso i seguenti tipi di relazioni:
-
identificazione (aggregazione composita)
-
non identificazione (associazione)
La sezione Relazioni di questa linea guida fornisce degli esempi su come vengono utilizzate
queste relazioni. Le informazioni su come è possibile associare questi tipi di relazioni agli elementi del modello di
progettazione appaiono nella sezione Linea guida: Database relazionali di reverse-engineering.
Un trigger è una funzione procedurale progettata per l'esecuzione come risultato di un'azione sulla tabella in cui è
presente il trigger. L'esecuzione di un trigger viene definita quando una riga nella tabella viene inserita, aggiornata
o eliminata. Inoltre, un trigger viene progettato per essere eseguito prima o dopo l'esecuzione del comando di una
tabella. I trigger sono definiti come delle operazioni in una tabella. Le operazioni sono stereotipate
<<Trigger>>.
Esempio di trigger
Gli indici sono utilizzati come meccanismi che consentono di rendere più veloce l'accesso alle informazioni quando
vengono utilizzate delle specifiche colonne per ricercare la tabella. Un indice è modellato come un'operazione
nella tabella con uno stereotipo di <<indice>>. Gli indici possono essere assegnati come entità unica
e come raggruppati o non raggruppati. Gli indici raggruppati vengono utilizzati per forzare l'ordine delle righe di
dati nella tabella in modo che siano allineate con l'ordine dei valori dell'indice. Un esempio di un'operazione di
indice (IX_auctioncategory) viene mostrato nella figura riportata di seguito.
Esempio di indice
Una vista è una tabella virtuale con nessuna memoria permanente indipendente. Una vista presenta delle caratteristiche
e delle funzionalità di una tabella e accede ai dati nelle colonne da una o più tabelle con cui la vista ha definito
delle relazioni. Le viste sono utilizzate per fornire un accesso più efficace alle informazioni presenti in una o
più tabelle e possono anche essere utilizzate per applicare le regole di business per limitare l'accesso ai dati nelle
tabelle. Nell'esempio riportato di seguito, è stata definita un'operazione AuctionView come "vista" di informazioni
nella tabella Auction mostrata nella sezione di modellazione dati fisica di questa linea guida.
Le viste sono modellate come classi con lo stereotipo di <<vista>>. Gli attributi della classe vista
sono le colonne delle tabelle indicate dalla vista. I tipi di dati delle colonne nella vista sono ereditati dalle
tabelle con una dipendenza definita con la vista.
Esempio di vista
Un dominio è un meccanismo utilizzato per creare i tipi di dati definiti dall'utente applicabili alle colone su più
tabelle. Un dominio è modellato come una classe con lo stereotipo di <<Dominio>>. Nell'esempio
riportato di seguito, è stato definito un dominio per un codice di avviamento postale "zip + 4".
Esempio di dominio
Un contenitore della procedura memorizzata è un raggruppamento di procedure memorizzate all'interno del modello dati.
Un contenitore della procedura memorizzata viene creato come una classe UML con lo stereotipo di <<Contenitore
SP>>. E' possibile creare più contenitori di procedure memorizzate in una progettazione di database. Ciascun
contenitore deve avere almeno una procedura memorizzata.
Una procedura memorizzata è una procedura indipendente che risiede tipicamente nel server del database. Le procedure
memorizzate sono documentate come operazioni che sono raggruppate in classi stereotipate come <<Contenitore
SP>>. Le operazioni sono stereotipate <<SP>>. L'esempio riportato di seguito mostra
un'operazione singola della procedura memorizzata (SP_Auction) in una classe contenitore denominata
AuctionManagement. Durante l'assegnazione delle procedure memorizzate, il progettista di database deve essere a
conoscenza delle convenzioni di denominazione utilizzate dall'RDBMS specifico.
Esempio di contenitore della procedura memorizzata e procedura memorizzata.
Un tablespace rappresenta la quantità di spazio di memoria da assegnare a determinati elementi come tabelle, procedure
memorizzate e indici. I tablespace sono collegati ad uno specifico database attraverso una relazione di dipendenza. Il
numero di tablespace e come le singole tabelle saranno associate ai tablespace dipende dalla complessità del modello
dati. Le tabelle che saranno accedute frequentemente potrebbero richiedere una partizione in più tablespace. Le
tabelle che non contengono quantità elevate di dati acceduti frequentemente possono essere raggruppate in un'unica
tablespace.
Viene definito un contenitore tablespace per ogni tablespace. Il contenitore tablespace è l'unità di memoria fisica per
il tablespace. Sebbene più contenitori di tablespace possano esistere per un unico tablespace, si consiglia di
assegnare un contenitore tablespace soltanto a un unico tablespace. I contenitori tablespace sono definiti come
attributi per il tablespace; non sono modellati in modo esplicito.
Esempio di tablespace
Uno schema documenta l'organizzazione o la struttura del database. Uno schema è rappresentato come un pacchetto
stereotipato <<Schema>>. Quando uno schema viene definito come un pacchetto, le tabelle che compongono quel
pacchetto devono essere contenute all'interno dello schema. Una dipendenza tra il database e lo schema viene creata per
documentarne la relazione.
Esempio di schema
Il database è una raccolta di dati organizzato in modo che è possibile accedere e gestire le informazioni in esso
contenute. La gestione e l'accesso delle informazioni nel database vengono eseguite mediante l'uso di un sistema
di gestione del database (DBMS) commerciale. Un database è rappresentato nel modello dati come un componente
stereotipato <<Database>>.
Esempio di database
Il profilo UML per la modellazione del database definisce le relazioni valide tra i principali elementi del modello
dati. Le seguenti sezioni forniscono degli esempi di diversi tipi di relazioni.
Non-Identifying
Una relazione di non identificazione è una relazione presente tra due tabelle che esistono in modo indipendente
all'interno del database. Tale tipo di relazione è documentato utilizzando un'associazione tra le tabelle.
L'associazione è stereotipata come <<non identificazione>>. L'esempio riportato di seguito illustra
una relazione di non identificazione tra la tabella Item e la tabella AuctionCategory.
Esempio di relazione di non identificazione
Identificazione
Una relazione di identificazione è una relazione tra due tabelle in cui la tabella secondaria deve coesistere con la
tabella principale. Una relazione di identificazione è documentata utilizzando un'aggregazione composita tra due
tabelle. L'aggregazione composita è stereotipata come <<Identificazione>>. La figura mostrata di seguito è
un esempio di una relazione di identificazione. Questo esempio mostra che le istanze di una tabella secondaria
(CreditCard) devono avere una voce associata nella tabella principale (UserAccount).
Esempio di relazione di identificazione
Sia per l'aggregazione composita che di associazione, è necessario definire la molteplicità per documentare il numero
di righe nella relazione. Nell'esempio riportato sopra, per ciascuna riga nella tabella UserAccount, è possibile avere
0 o più righe CreditCard nella tabella CreditCard. Per ciascuna riga nella tabella CreditCard, esiste esattamente una
riga nella tabella UserAccount. Molteplicità è anche conosciuta come cardinalità.
Viste del database
Quando si definisce la relazione di una vista del database con una tabella, viene utilizzata una relazione di
dipendenza estratta dalla vista della tabella. Lo stereotipo della dipendenza è <<Deriva>>. Tipicamente, la
dipendenza della vista ha un nome e tale nome è lo stesso del nome della tabella che è definito nella relazione di
dipendenza con la vista del database.
Esempio della relazione di dipendenza della vista e della tabella
Tablespace
Una relazione di dipendenza viene utilizzata per collegare un tablespace con uno specifico database. Come mostrato
nella figura riportata di seguito, la relazione viene tracciata per mostrare la dipendenza del database sul
tablespace. E' possibile associare più tablespace ad un singolo tablespace nel modello.
Esempio della relazione di dipendenza del tablespace e del database
Una relazione di dipendenza viene utilizzata per documentare le relazioni tra i tablespace e le tabelle all'interno di
un tablespace. E' possibile associare una o più tabelle ad un singolo tablespace e una singola tabella a più
tablespace. L'esempio mostrato di seguito mostra che la tabella Auction è assegnata ad un singolo tablespace denominato
PRIMARY.
Esempio della relazione di dipendenza della tabella e del tablespace
Realizzazioni
Le realizzazioni vengono utilizzate per stabilire la relazione tra un database e le tabelle che sono presenti in
essa. Una tabella può essere realizzata da più database nel modello dati.
Esempio della relazione di realizzazione della tabella e del database
Procedure memorizzate
Una relazione di dipendenza viene utilizzata per documentare la relazione tra il contenitore della procedura
memorizzata e le tabelle in cui operano le procedure memorizzate all'interno dei contenitori. L'esempio di seguito
descrive questo tipo di relazione mostrando che la procedura memorizzata SP_Auction sarà utilizzata per accedere
informazioni nella tabella Auction.
Esempio della relazione di dipendenza della tabella e del contenitore della procedura memorizzata
Nella fase di inizio, le attività di modellazione dati iniziale possono essere eseguite
insieme allo sviluppo di tutti i prototipi Proof-of-Concept (POC) come parte delle attività "Esecuzione dell'attività
di sintesi strutturale". Nei progetti dove è già presente un database, il progettista di database può eseguire il
reverse-engineer del database esistente per sviluppare un modello dati fisico iniziale basato sulla struttura del
database esistente. Per maggiori informazioni, consultare Linea guida: Database relazioni di reverse-engineering. Gli elementi del modello dati
fisico possono essere trasformati negli elementi del modello di progettazione per supportare tutte le attività di
creazione prototipi Proof-of-Concept (POC).
Lo scopo della fase di elaborazione è di eliminare i rischi tecnici e di realizzare un'architettura
stabile (confrontata con la linea di base)per il sistema. Nei sistemi a larga scala, le scarse prestazioni dovute a un
modello dati progettato in modo errato determinano una problematica strutturale fondamentale. Di conseguenza, sia la
modellazione dei dati che lo sviluppo di un prototipo strutturale che consentono di valutare le prestazioni del
database sono fondamentali per raggiungere un'architettura stabile. Mentre i casi d'uso significativi secono
l'architettura sono descritti in dettaglio e analizzati in ciascuna interazione, gli elementi del modello dati sono
definiti in base allo sviluppo delle progettazioni della classe permanente dai casi d'uso. Quando le progettazioni
della classe raggiungono una stabilità, il progettista di database può periodicamente trasformare tali progettazioni in
tabelle nel modello dati e definire gli opportuni elementi del modello di memoria dati.
Alla fine della fase di elaborazione, le principali strutture di database (tabelle, indici e colonne chiave primarie ed
esterne) devono essere configurate per supportare l'esecuzione degli scenari significativi definiti secondo
l'architettura per l'applicazione. Inoltre, è necessario caricare i volumi di dati rappresentativi nel database per
supportare la verifica delle prestazioni strutturali. In base ai risultati di verifica delle prestazioni, potrebbe
essere necessario correggere il modello dati utilizzando le tecniche di ottimizzazione, includendo ma non limitandosi
alla denormalizzazione, all'ottimizzazione degli attributi di memoria fisici o alla distribuzione e indicizzazione.
La principale ristrutturazione del modello dati non deve verificarsi durante la fase di
costruzione. E' possibile definire tabelle ed elementi di memoria dati aggiuntivi durante le iterazioni della fase
di costruzione basate sulla progettazione dettagliata della serie di casi d'uso e sulle richieste di modifica approvate
e quindi assegnate all'iterazione. Un'attenzione primaria alla progettazione di database durante la fase di costruzione
è il monitoraggio continuo delle prestazioni del database e l'ottimizzazione della progettazione richiesta mediante la
de-normalizzazione, la definizione degli indici, la creazione delle viste di database e le altre tecniche di
ottimizzazione.
Il modello dati fisico è la risorsa di progettazione che il progettista di database conserva durante la fase di
costruzione. Può essere gestito mediante aggiornamenti immediati nel modello o come risultato di un tool che legge gli
aggiornamenti che sono stati fatti direttamente nel database.
Il modello dati, come il modello di progettazione, è conservato durante la fase di transizione
in risposta alle richieste di modifica approvate. Il progettista di database deve tenere sincronizzato il modello dati
con il database mentre l'applicazione esegue il test di accettazione finale e viene distribuita alla produzione.
Se un team di sviluppo utilizza i tool di modellazione visiva moderni che hanno la capacità di convertire le classi in
tabelle (e viceversa) e/o di eseguire il reverse e forward engineer dei database, il team necessita di stabilire le
linee guida per gestire i processi di trasformazione e di progettazione. Le linee guida sono principalmente
richieste per grossi progetti in cui un team lavora in parallelo sulla progettazione del database e
dell'applicazione. Il team di sviluppo deve definire i punti nello sviluppo dell'applicazione (ciclo di
build/release) in cui sarà opportuno eseguire le trasformazioni da classe a tabella e il forward-engineer del
database. Una volta creato il database esistente, il team di sviluppo deve definire le linee guida del team per
gestire la sincronizzazione del modello dati e del database mentre la progettazione e il codice del sistema vengono
sviluppati all'interno del progetto.
|