Linea guida: Modellamento di dati
Il Modello di dati cattura il progetto degli archivi di dati permanenti utilizzati dal sistema. Questa linea guida introduce la Modellazione di dati ed il suoi utilizzo in RUP.
Relazioni
Descrizione principale

Panoramica

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.

Stadi di modellazione dati

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.  

Diagramma descritto nel testo di accompagnamento.

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. 

Diagramma descritto nel testo di accompagnamento.

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).

Diagramma descritto nel testo di accompagnamento.

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.

Elementi del modello dati

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.

Pacchetto

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.

Diagramma descritto nel testo di accompagnamento.

Esempio di pacchetti di area di argomento

Tabella

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 . 

Diagramma descritto nel testo di accompagnamento.

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.

Trigger

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>>. 

Diagramma descritto nel testo di accompagnamento.

Esempio di trigger

Indice

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.

Diagramma descritto nel testo di accompagnamento.

Esempio di indice

Vista

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.

 Diagramma descritto nel testo di accompagnamento.

Esempio di vista

Dominio

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". 

Diagramma descritto nel testo di accompagnamento.

Esempio di dominio

Contenitore della procedura memorizzata

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.

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. 

Diagramma descritto nel testo di accompagnamento.

Esempio di contenitore della procedura memorizzata e procedura memorizzata.

Tablespace

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.

Diagramma descritto nel testo di accompagnamento.

Esempio di tablespace

Schema Inizio pagina

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. 

Diagramma descritto nel testo di accompagnamento.

Esempio di schema

Database Inizio pagina

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>>.

Diagramma descritto nel testo di accompagnamento.

Esempio di database

Relaziones Inizio pagina

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.

Diagramma descritto nel testo di accompagnamento.

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).

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

Esempio della relazione di dipendenza della tabella e del contenitore della procedura memorizzata

Evoluzione del modello dati

Fase di inizio

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).

Fase di elaborazione

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.

Fase di costruzione

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.

Fase di transizione

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.

Considerazioni sul roundtrip engineering

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.