Operazione: Progettazione di database
Questa attività descrive in che modo progettare un database al fine di implementare la persistenza all'interno di un'applicazione.
Discipline: Analisi e progettazione
Scopo
  • Per essere certi che i dati persistenti siano archiviati uniformemente ed efficacemente.
  • Per definire la funzionalità che deve essere implementata nel database.
Relazioni
Descrizione principale

Le operazioni riportate in questa attività prevedono che la progettazione dei dati persistenti dell'applicazione sarà implementata utilizzando un sistema RDBMS (cioè un sistema di gestione del database relazionale). Si suppone che l'utente abbia dimestichezza con i concetti di database, includendo la normalizzazione e la denormalizzazione, oltre che con la terminologia di database descritta nei riferimenti come [DAT99]. 

Le operazioni riportate in questa attività fanno riferimento anche al profilo UML (Unified Modeling Language) per il modellamento del database, descritto in [NBG01]. In aggiunta, [NBG01] contiene una descrizione generale del processo per il modellamento e la progettazione dei database relazionali utilizzando UML.  Per informazioni background sulla relazione tra i modelli oggetto ed i modelli di dati relazionali, consultare Concetto: Database relazionali e orientamento oggetti.

Passi
Sviluppo del modello di dati logici (facoltativo)
Scopo Definire un modello della progettazione logica del database.

Lo scopo del modello dati logico è di fornire una vista idealizzata delle entità di dati logici chiave e delle relative relazioni indipendenti da una qualsiasi implementazione specifica di database o software. Si tratta del terzo formato normale (consultare Concetto: Normalizzazione), che è un modello di modellazione dati che minimizza la ridondanza e garantisce le dipendenze. Un modello di questo tipo verifica come apparirà il database durante la cattura dei dati, piuttosto che con le applicazioni che utilizzano i dati e le relative prestazioni. Si noti che un modello dati logico è considerato parte del Prodotto di lavoro: Modello dati e non un prodotto di lavoro RUP separato. Tuttavia, è spesso importante definire i singoli modelli dati logici per:

  • progetti in cui le realizzazioni di database e di applicazioni vengono sviluppate da team diversi.
  • progetti in cui esistono più applicazioni che condivideranno un database comune.

Se si sta creando un modello dati logico, è possibile iniziare da zero utilizzando gli elementi del modello esaminati in Linea guida per il prodotto di lavoro: Modello dati oppure è possibile iniziare con le entità per ciascuna classe permanente nel Modello di analisi o Modello di progettazione.

Si può decidere di non creare un modello dati logico separato, specialmente se si sta progettando un database che serve una singola applicazione. In questo caso, il Progettista di database sviluppa il modello dati fisico basato sulla serie di classi permanenti e sulle relative associazioni nel modello di progettazione.

In entrambi gli approcci, è importante che vi sia collaborazione tra il Progettista di database e il Progettista durante tutto il processo di analisi e di progettazione al fine di identificare quali classi nel Prodotto di lavoro: Modello di progettazione hanno bisogno di archiviare le informazioni in un database. Come descritto nella fase intitolata, "Identificazione delle classi permanenti dell'Compito: Progettazione della classe," il progettista di database collabora con il progettista per identificare quali classi di progettazione nel modello di progettazione sono considerate permanenti e potenziali candidate per diventare tabelle nel database.

Sviluppo della progettazione fisica di un database
Scopo Definire la progettazione fisica dettagliata del database.

La progettazione fisica del database include gli elementi modello (come le tabelle, viste e procedure memorizzate) che rappresentano la struttura fisica dettagliata del database e degli elementi modello (come gli schema ed i tablespace) che rappresentano la progettazione della memoria dati sottostante del database.  Collettivamente, questi elementi del modello contengono il modello dati fisico del database.  Tale modello dati fisico è contenuto nel Prodotto di lavoro: Modello dati e non è un prodotto di lavoro del modello separato.

Le operazioni dettagliate per lo sviluppo della progettazione fisica del database sono riportate di seguito:

Definire i domini

Scopo Per tracciare i tipi definiti dall'utente e riutilizzabili. 

I domini possono essere utilizzati dal progettista di database per applicare gli standard tipo in tutta la progettazione del database. I domini sono tipi di dati definiti dall'utente che possono essere applicati ad una colonna in una tabella.  I domini hanno le proprietà di una colonna senza il nome. 

Creazione degli elementi di progettazione del database fisico iniziale

Scopo Creare le relazioni e le tabelle di database iniziali.

Il progettista di database modella gli elementi del modello dati fisico utilizzando le tabelle e le colonne nelle tabelle, come descritto nella sezione Linee guida per il prodotto di lavoro: Modello dati

Se è stato creato un modello dati logico, le relative entità logiche possono quindi essere utilizzate come base per una serie iniziale di tabelle.

In alternativa, il progettista di database può saltare l'avvio del modello dati fisico utilizzando le classi permanenti nel modello di progettazione come punto di partenza per le tabelle nel modello dati fisico.  Il progettista di database esegue la modellazione delle classi permanenti e dei relativi attributi come tabelle e colonne rispettivamente.  Il progettista di database deve inoltre definire le relazioni tra le tabelle, basate sulle associazioni tra le classi permanenti nel modello di progettazione.  Una descrizione su come gli elementi e le relazioni del modello di progettazione vengono associati agli elementi e alle relazioni del modello dati è fornita nella sezioneLinee guida per il prodotto di lavoro: Database relazionali forward engineering.

Se si inizia il modello dalle classi persistenti anziché da un modello di dati logici normalizzato, sarà generalmente necessario applicare una determinata normalizzazione per poter eliminare le ridondanze di dati e le dipendenze di campi senza chiavi. Consultare Concetto: Normalizzazione per maggiori informazioni sulla normalizzazione del database.

Definizione delle tabelle di riferimento

Scopo Per definire le tabelle di riferimento standard utilizzate in tutto il progetto.

Esistono spesso delle tabelle per la ricerca standard, tabelle di convalida o tabelle di riferimento utilizzate in tutto il progetto. Poiché i dati presenti in queste tabelle tendono ad essere frequentemente acceduti ma raramente modificati, tali dati meritano una considerazione speciale. Nel modello di progettazione queste tabelle possono contenere dei codici di prodotto standard, prefissi nazionali o provinciali, codici di avviamento postali, codici tasse, dati di convalida dei prefissi di teleselezione o altre informazioni accedute di frequente. Nei sistemi finanziari, queste tabelle possono contenere elenchi dei codici di condotta, classificazioni dei livelli assicurativi o tassi di conversione. Effettuare una ricerca nel modello di progettazione per le classi che sono principalmente di sola lettura e che forniscono delle informazioni di conferma per un elevato numero di clienti.

Se la tabella di riferimento è piccola, non provare a indicizzarla, poiché l'indicizzazione potrebbe effettivamente aggiungere un ulteriore sovraccarico alle tabelle piccole. Una piccola tabella a cui si accede frequentemente tende anche a restare in memoria, dato che gli algoritmi della memoria cache spesso conservano le tabelle accedute con frequenza nella cache dei dati.

Se possibile, accertarsi che la cache del database sia sufficientemente grande per conservare tutte le tabelle di riferimento in memoria, compreso il normale "spazio operativo" per le query e transazioni. Molto spesso il segreto per aumentare le prestazioni del database è di ridurre l'I/O del disco.

Una volta definite le strutture delle tabelle di riferimento, stabilire una strategia per riempire le tabelle di riferimento. Poiché l'accesso a queste tabelle avviene nella fase iniziale del progetto, la determinazione dei valori di riferimento e il caricamento delle tabelle devono spesso verificarsi relativamente presto durante il runtime dell'applicazione. Sebbene il progettista di database non sia responsabile per l'ottenimento dei dati, è responsabile delle modalità di aggiornamento delle tabelle di riferimento.

Creazione della chiave primaria e dei vincoli univoci

Scopo Per definire una o più colonne che identificano in modo univoco una riga nella tabella.
Per definire i vincoli sulle colonne che garantiscono la univocità dei dati o della raccolta di dati.

Una chiave primaria è rappresentata da una o più colonne che identificano in modo univoco le righe in una tabella. Una tabella dispone di una singola chiave primaria. E' spesso presente una chiave "naturale" che può essere utilizzata per identificare in modo univoco una riga di dati (ad esempio, il codice postale in una tabella di riferimento). La chiave primaria non deve contenere dati che potrebbero cambiare con l'ambiente di business. Se la chiave "naturale" è un valore che può cambiare (ad esempio il nome di una persona), è consigliabile che il progettista di database crei una singola colonna non significativa e senza immissione utente durante la creazione di una chiave primaria. In questo modo viene creata una struttura dati con una maggiore adattabilità alle modifiche nella struttura, regole o ambiente di business.

L'utilizzo di una colonna non significativa e senza immissione utente come chiave primaria è un concetto essenziale nella progettazione di un magazzino dati. I sistemi di transazione scelgono spesso una chiave primaria "naturale" che potrebbe essere subordinata ad una minima modifica in una colonna non significativa e senza immissione utente.

Un vincolo univoco specifica che i dati nella colonna o la raccolta di colonne è univoca per riga. Se il vincolo univoco si trova in una colonna, i dati in una specifica riga della colonna specificata devono essere univoci rispetto ai dati in una diversa riga della stessa colonna. 

Quando viene definito un vincolo univoco per un gruppo di colonne, l'univocità si basa sull'intera raccolta dei dati nelle colonne che compongono quel vincolo univoco. I dati presenti in una specifica riga di una specifica colonna non devono essere univoci rispetto ai dati presenti in una diversa riga della stessa colonna. Il progettista di database utilizza il vincolo univoco per garantire l'univocità dei dati di business.

Definizione delle regole di applicazione dell'integrità referenziale e dei dati

Scopo Per garantire l'integrità del database.

Le regole di integrità dei dati, note anche come vincoli, assicurano che i valori dei dati siano all'interno degli intervalli definiti. Laddove è possibile identificare questi intervalli, il database può applicarli. Tuttavia, non si vuole intendere che la convalida dei dati non deve essere effettuata nell'applicazione, ma soltanto che il database può servire come "validator dell'ultimo ricorso" nel caso l'applicazione non funzioni correttamente. Laddove sono presenti le regole di convalida dei dati, i vincoli del database devono essere progettati per applicarle.

Una chiave esterna è rappresentata da una o più colonne in una tabella che viene associata alla chiave primaria in un'altra tabella. Una tabella può avere molte chiavi esterne e ciascuna chiave esterna è un'associazione a una diversa tabella. Questa associazione o relazione tra le tabelle viene spesso indicata come una relazione principale-secondaria. La tabella secondaria contiene la chiave esterna, che viene associata alla chiave primaria nella tabella principale. 

La definizione dei vincoli della chiave esterna viene anche frequentemente utilizzata dal programma di ottimizzazione del query per migliorarne le prestazioni.  In molti casi, le regole di applicazione delle chiavi esterne utilizzano le tabelle di riferimento.

Denormalizzazione della progettazione di database per il miglioramento delle prestazioni

Scopo Per migliorare le strutture dati del database in relazione alle prestazioni.

Nel caso di un modello dati relazionale, la mappatura iniziale produce generalmente una semplice associazione "classe a tabella". Se è necessario richiamare contemporaneamente gli oggetti da classi diversi, il sistema RDBMS utilizza un'operazione definita "unione tabella" per richiamare le righe associate agli oggetti di interesse. Per dati acceduti con frequenza, le operazioni di unione possono determinare elaborazioni dispendiose. Per eliminare il costo dell'operazione di unione, viene spesso utilizzata una tecnica relazionale standard definita "denormalizzazione".

La denormalizzazione unisce le colonne provenienti da due o più tabelle diverse nella stessa tabella, pre-unendo efficacemente le informazioni. La denormalizzazione rispecchia un compromesso tra le operazioni di aggiornamento più dispendiose in favore delle operazioni di richiamo meno dispendiose. Inoltre, questa tecnica riduce le prestazioni del sistema in query che sono solo interessate agli attributi di uno degli oggetti che sono completamente uniti nella tabella denormalizzata, dal momento che gli attributi sono normalmente richiamati in ogni query. Nei casi in cui l'applicazione desidera normalmente tutti gli attributi, si può avere un significativo miglioramento delle prestazioni.

Il processo di denormalizzazione di più di due tabelle è raro e aumenta il costo degll'inserimento e degli aggiornamenti così come il costo delle query non unite. Limitare la denormalizzazione a due tabelle è un buon criterio a meno che non vengano prodotte delle prove forti e convincenti riguardanti i vantaggi.

La denormalizzazione può essere dedotta dalle classi di progettazione nei casi in cui le classi sono nidificate. Le classi nidificate possono essere associate a una tabella denormalizzata.

Alcuni database di oggetti adottano un concetto simile alla denormalizzazione, in cui gli oggetti correlati sono raggruppati sul disco e richiamati in operazioni singole. Il concetto di utilizzo è analogo: ridurre il tempo di richiamo dell'oggetto diminuendo il lavoro che il sistema deve eseguire per richiamare gli oggetti correlati dal database.

In alcuni casi, l'ottimizzazione del modello dati può smascherare i problemi nel modello di progettazione, inclusi i colli di bottiglia nelle prestazioni, una carente modellazione o le progettazioni incomplete. In questo caso, discutere i problemi con il progettista della classe, attivando le richieste di modifica.

Ottimizzazione dell'accesso ai dati

Scopo Per consentire un accesso dati efficace utilizzando l'indicizzazione.
Per consentire un accesso dati efficace utilizzando le viste del database.

Una volta progettata la struttura della tabella, è necessario stabilire i tipi di query che saranno eseguiti rispetto ai dati. L'indicizzazione è utilizzata dal database per velocizzare l'accesso. L'operazione di indicizzazione è più efficace quando i valori dei dati nella colonna da indicizzare sono relativamente diversi.

Considerare i seguenti principi di indicizzazione:

  • La colonna della chiave primaria della tabella deve essere sempre indicizzata. Le colonne della chiave primaria sono utilizzate frequentemente come chiavi di ricerca e per operazioni di unione.
  • Le tabelle inferiori alle 100 righe di dimensione con solo alcune colonne presentano un minore beneficio dall'indicizzazione. Alcune tabelle generalmente si adattano facilmente alla cache del database.
  • Gli indici devono essere definiti anche per le query eseguite frequentemente oppure per le query che devono richiamare i dati rapidamente (di solito, una qualsiasi ricerca effettuata mentre una persona è in attesa). E' possibile definire un indice per ciascuna serie di attributi che sono utilizzati insieme come criterio di ricerca. Ad esempio, se il sistema deve individuare tutti gli ordini in cui un particolare prodotto è ordinato, è necessario un indice nella tabella Elemento riga della colonna del numero prodotto.
  • Gli indici vanno generalmente definiti solo nelle colonne utilizzate come identificatori e non sui valori numerici, come il saldo del conto o sulle informazioni testuali come i commenti dell'ordine. I valori identificatori della colonna tendono ad essere assegnati quando viene creato l'oggetto e restano invariati per tutto il ciclo vitale dell'oggetto.
  • L'indicizzazione di numeri semplici (tipi di dati numerici e interi) è molto più agevole e veloce rispetto agli indici eseguiti sulle stringhe. Dato il volume di dati più grande elaborato su una query o un comando di unione (join) esteso, i salvataggi di piccole entità si sommeranno rapidamente.  Gli indici sulle colonne numeriche tendono ad occupare significativamente meno spazio rispetto agli indici eseguiti sui caratteri.

D'altro canto, l'utilizzo di indici non è indipendente; quanti più indici sono presenti in una tabella, maggiore è il tempo di elaborazione degli inserimenti e aggiornamenti. Quando si pianifica l'uso degli indici, tenere presente le seguenti precauzioni:

  • Non eseguire l'indicizzazione soltanto per rendere più rapido una query eseguita raramente, a meno che la query non sia richiesta in un punto critico, rendendo essenziale la massima velocità.
  • In alcuni sistemi, le prestazioni dell'aggiornamento e dell'inserimento sono più importanti di quelle della query. Un esempio comune si trova nelle applicazioni di acquisizione dei dati aziendali in cui i dati sulla qualità sono catturati in tempo reale. In questi sistemi vengono eseguite soltanto le query in linea saltuarie e la maggior parte dei dati viene analizzata in modo periodico mediante applicazioni di notifica in batch che eseguono analisi statistici sui dati. Per i sistemi di acquisizione dei dati, rimuovere tutti gli indici per ottenere la massima velocità di elaborazione. Se gli indici sono richiesti, essi possono essere ricreati appena prima dell'esecuzione della notifica di prospetti in batch e delle applicazioni di analisi, quindi eliminati quando vengono completate la notifica del prospetto e l'analisi.
  • Tenere sempre presente che gli indici hanno costi nascosti. Ad esempio, richiedono del tempo per essere aggiornati (una tassa pagata per ogni inserimento, aggiornamento o eliminazione) e occupano spazio su disco. Accertarsi che il loro utilizzo porti valore.

Molti database offrono una scelta di tipi di indice. I più comuni includono:

  • Indici B-treeI tipi più frequentemente utilizzati si basano sulle strutture dati d'indice b-tree bilanciate. Sono molto utili quando i valori chiave dell'indice sono casualmente distribuiti e tendono ad avere un'ampia variabilità. Tendono ad avere scarse prestazioni tuttavia quando i dati da indicizzare sono già in ordine sequenziale.
  • Indici di tipo hashMeno frequenti, i valori chiave dell'indice sono di tipo hash. Offrono migliori prestazioni quando l'intervallo dei valori chiave dell'indice è noto, relativamente senza modifiche e univoco. Questa tecnica si affida all'uso del valore chiave per calcolare l'indirizzo dei dati di interesse. Poiché il concetto della prevedibilità è importane, gli indici hash tendono ad essere utili solo per tabelle di ricerca di medie dimensioni che vengono modificate raramente.

La scelta di una strategia di indicizzazione e di tempificazione della creazione dell'indice possono avere un enorme impatto sulle prestazioni. Il caricamento di elevate quantità di dati deve essere eseguito senza gli indici (ciò può essere ottenuto rilasciando l'indice, caricando i dati e quindi ricreando l'indice). Il motivo è che la struttura dell'indice viene nuovamente bilanciata mentre si aggiunge ogni riga. Poiché le successive righe modificheranno la struttura ottimale dell'indice, il lavoro eseguito per bilanciare nuovamente l'indice mentre ogni riga viene inserita è ampiamente perduto. E' più rapido ed efficiente caricare i dati senza gli indici, quindi ricreare l'indice quando è terminato il caricamento dei dati. Alcuni database forniscono dei programmi di caricamento dati estesi in modo automatico.

Un'altra strategia per ottimizzare le prestazioni di accesso al database è l'utilizzo delle viste. Le viste di database sono tabelle virtuali che non dispongono di una propria memoria indipendente. Per il programma di chiamata (o utente), tuttavia, una vista si comporta come una tabella. Una vista supporta il recupero dei dati e può essere utilizzata per aggiornare i dati (a seconda della struttura e del vendor del database). La vista contiene dati da una o più tabelle accessibili tramite una singola istruzione di selezione (select). L'aumento delle prestazioni si ottiene durante la selezione dei dati, specialmente nelle tabelle di cui si esegue frequentemente il query. I dati vengono richiamati da una singola ubicazione - la vista - piuttosto che ricercando le tabelle multiple o estese che sono presenti nel database.

Le viste giocano anche un ruolo importante nella protezione del database. Una vista contenente parti di una tabella può limitare l'accesso a dati sensibili contenuti nella tabella base.

Definizione delle caratteristiche di memoria

Scopo Per definire l'assegnazione dello spazio e l'organizzazione della pagina su disco del database.

Un progettista di database utilizza i tablespace per rappresentare la quantità di spazio di memoria che viene assegnata alle tabelle, agli indici, alle procedure memorizzate e così via. Uno o più tablespace sono associati a un database. Il progettista di database deve analizzare le tabelle nel modello dati per determinare il modo in cui occorre distribuirle insieme agli altri elementi del database di supporto, in tutto lo spazio di memoria del database.

Nel determinare le strutture tablespace per il database, tenere presente che i database non eseguono operazioni I/O sulle righe, sui record oppure sulle intere tabelle. Invece, i database eseguono operazioni di I/O sui blocchi del disco. Il motivo è semplice: le operazioni I/O sul blocco sono generalmente ottimizzate nel software e nell'hardware del sistema. Come risultato, l'organizzazione fisica delle tabelle e degli indici nel database può avere un impatto notevole sulle prestazioni del sistema.

Quando si pianificano l'assegnazione dello spazio e l'organizzazione della pagina su disco del database, tenere presente i seguenti fattori:

  • la densità delle informazioni nelle pagine del disco
  • l'ubicazione delle pagine sul disco o su più dischi
  • la quantità di spazio sul disco da assegnare alla tabella

Questi fattori vengono discussi nelle sezioni che seguono.

Densità pagina sul disco

La densità delle pagine sul disco dipende dalla misura con cui sono previste modifiche ai dati nel tempo. Fondamentalmente, una pagina con densità inferiore è maggiormente in grado di accettare modifiche di valori oppure l'aggiunta di dati nel tempo, mentre una pagina di dati completa fornisce una migliore prestazione in lettura, poiché vengono richiamati più dati per lettura blocco.

Per rendere più semplice la gestione del disco, il progettista di database può raggruppare le tabelle nella misura in cui tendono a modificare. I seguenti tre gruppi costituiscono un buon inizio per questo tipo di organizzazione:

  • tabelle altamente dinamiche
  • tabelle alquanto dinamiche
  • tabelle maggiormente statiche

Le tabelle altamente dinamiche devono essere associate alle pagine su disco che hanno un'enorme quantità di spazio libero (probabilmente 30%); le tabelle alquanto dinamiche devono essere associate alle pagine su disco che hanno meno spazio libero (probabilmente 15%); e la tabella più statica deve essere associata alle pagine su disco che hanno veramente poco spazio libero (probabilmente 5%). Gli indici per le tabelle devono essere associati in modo analogo.

Ubicazione pagina sul disco

Dopo l'associazione dei gruppi di tabelle, il progettista di database deve stabilire l'ubicazione in cui collocare le pagine sul disco. L'obiettivo è di bilanciare il carico di lavoro su un numero di svariate unità e testine al fine di ridurre o eliminare i colli di bottiglia. Considerare le seguenti linee guida:

  • Mai collocare i dati sullo stesso disco del sistema operativo, dei relativi file temporanei o delle unità di swap. Queste unità sono abbastanza impegnate senza dover aggiungere ulteriore carico di lavoro.
  • Collocare i dati acceduti simultaneamente su diverse unità in modo da bilanciare il carico di lavoro. Alcuni sistemi supportano i canali I/O paralleli. In tal caso, collocare i dati su canali diversi.
  • Collocare gli indici su un'unità diversa dai dati di cui crea l'indice per poter distribuire il carico di lavoro.
  • Fare riferimento alla documentazione del fornitore del database per le linee guida.
  • Il tipo di memoria utilizzata (ad esempio RAID-5, RAID-10, SAN, NAS e canale collegato) influisce sulle prestazioni del database. Utilizzare le indicazioni sulle prestazioni fornite dal fornitore di memoria.

L'I/O del database è generalmente il fattore limitante nelle prestazioni del database. Il bilanciamento I/O è un processo iterativo e sperimentale. Mediante creazione dei prototipi per le prestazioni di accesso al database durante la fase di elaborazione, insieme all'appropriata strumentazione per il controllo dell'I/O fisico e logico, è possibile rilevare in anticipo i problemi di prestazioni mentre vi è ancora tempo per modificare la progettazione del database.

Allocazione di spazio su disco

Utilizzando le caratteristiche del meccanismo di progettazione della persistenza, valutare il numero di oggetti che deve essere memorizzato. La quantità di spazio su disco richiesta per memorizzare gli oggetti varia da RDBMS a RDBMS. Quando si calcola lo spazio su disco, accertarsi di stimare la crescita dovuta alle aggiunte di dati.  Per stimare lo spazio su disco per un database, è necessario prima stimare lo spazio su disco richiesto per ciascuna tabella e poi calcolare i requisiti di spazio per tutte le tabelle.  Consultare il manuale dell'amministratore di database per il prodotto RDBMS specifico al fine di determinare la formula esatta di stima della dimensione.  Di seguito sono riportate alcune procedure generali di stima dei requisiti di spazio per una tabella:

  • Calcolare la dimensione media della riga.  Questo calcolo deve includere tutte le informazioni di controllo a livello di record, oltre a tutte le informazioni di controllo richieste per le colonne con lunghezza variabile.
  • Calcolare il numero di righe che si adattano ad una pagina o un blocco di I/O. Poiché la maggior parte dei database memorizza soltanto record completi su una pagina o un blocco di I/O, occorre che vi sia un numero intero di righe che dovranno adattarsi ad una pagina o un blocco di I/O.
  • Calcolare il numero di pagine o blocchi di I/O richiesto per memorizzare il numero stimato di record nel database.  Il numero stimato di record deve includere tutti i fattori di caricamento.
  • Moltiplicare il numero di pagine o blocchi di I/O richiesto per la dimensione della pagina o del blocco I/O.
  • Aggiungere eventuali eccessi per gli indici aggiuntivi.
  • Aggiungere un qualsiasi eccesso prefissato per la tabella.

Una volta che i requisiti dello spazio tabella sono stati definiti:

  • Calcolare la somma dello spazio richiesto dalle tabelle.
  • Aggiungere tutte le quantità fisse di spazio richieste per la gestione del database.
  • Aggiungere lo spazio disco richiesto per la registrazione della transazione e la traccia di controllo. 

In un ambiente aggiornato frequentemente, i requisiti di retenzione per la traccia di controllo richiedono quantità significative di memoria. La documentazione per i principali sistemi di gestione dei database commerciali fornisce solitamente istruzioni dettagliate di dimensionamento. Accertarsi di consultare queste istruzioni quando si calcolano le stime dei requisiti di spazio su disco del database.

Progettazione delle procedure memorizzate per la distribuzione del comportamento delle classi al database

Scopo Per stabilire se le procedure memorizzate o i trigger devono essere utilizzati per implementare le operazioni sulla classe di accesso dei dati.

Gran parte dei database supporta un funzione di procedura memorizzata. Una procedura memorizzata è un codice eseguibile avviato all'interno dello spazio dei processi di un sistema di gestione del database. Consente di eseguire le azioni associate al database sul server senza dover trasferire i dati su una rete. L'utilizzo giudizioso delle procedure memorizzate può migliorare le prestazioni del sistema.

Le procedure memorizzate sono normalmente di due tipi: procedure effettive o trigger. Le procedure sono eseguite esplicitamente da un'applicazione, generalmente hanno dei parametri e forniscono un valore di ritorno specifico. I trigger, d'altro canto, sono richiamati implicitamente quando si verificano degli eventi del database (ad esempio, inserire una riga, aggiornarla o eliminarla), non hanno parametri oltre che la riga modificata (poiché sono richiamati implicitamente) e non forniscono un valore di ritorno specifico.

Nei sistemi di database che mancano di vincoli, i triggers sono spesso utilizzati per applicare l'integrità referenziale e dei dati. Altrimenti, essi tendono ad essere utilizzati quando un evento deve attivare (o causare) un altro evento. I trigger sono spesso utilizzati anche per motivi di sicurezza mediante controllo dell'evento di attivazione.

E' necessario controllare le classi nel modello di progettazione per rilevare se hanno delle operazioni che vanno implementate utilizzando la funzione procedura memorizzata o trigger. I candidati comprendono:

  • tutte le operazioni che si occupano principalmente dei dati permanenti (creazione, aggiornamento, richiamo o cancellazione).
  • tutte le operazioni in cui un query è occupato in un calcolo (come il calcolo della quantità media e del valore di un prodotto nell'inventario).
  • le operazioni che devono accedere al database per poter convalidare i dati.

Da tenere presente che il miglioramento delle prestazioni del database significa di solito ridurre l'I/O. Pertanto, se l'esecuzione di un calcolo sul server DBMS ridurrà la quantità di dati trasferita sulla rete, il calcolo dovrebbe probabilmente essere eseguito sul server.

Collaborare con il progettista della classe di progettazione per discutere in che modo è possibile utilizzare il database per migliorare le prestazioni. Il progettista aggiornerà il metodo di operazione per indicare se una o più procedure memorizzate possono essere utilizzate per implementare l'operazione.

Revisione dei risultati
Scopo Per garantire la qualità ed integrità del Modello dati.

Durante tutta questa attività è necessario considerare continuamente l'elenco di controllo: Modello dati per valutare la totalità e qualità dell'impegno lavorativo.  Inoltre, il progettista di database deve regolarmente revisionare la struttura implementata del database per garntire che il modello dati sia coerente con tutte le modifiche che sono state apportate direttamente nel database.  Se il progetto sta utilizzando i tool di modellazione dati che supportano la sincronizzazione del modello dati con la struttura fisica del database, il progettista di database deve periodicamente controllare lo stato del modello dati con il database e apportare le rettifiche necessarie. 

I difetti rilevati che non saranno corretti in questa fase devono essere documentati nelle richieste di modifica ed alla fine assegnati ad una persona che possiede e gestisce la risoluzione.

Ulteriori informazioni