Passi chiave di progettazione del database

2.1. Design concettuale

La progettazione del database si svolge in tre fasi:

1. design concettuale;
2. progettazione logica;
3. progettazione fisica.

Lo scopo della fase di progettazione concettuale è creare un modello di dati concettuale basato sulle idee degli utenti sull'area tematica. Per ottenerlo, vengono eseguite una serie di procedure sequenziali. Un esempio di uno schema di entità (concettuale):

1. Definizione delle entità e loro documentazione. Per identificare le entità, vengono definiti oggetti che esistono indipendentemente dagli altri. Tali oggetti sono entità. A ogni entità viene assegnato un nome significativo che gli utenti possono comprendere. I nomi e le descrizioni delle entità vengono inseriti nel dizionario dei dati. Se possibile, viene impostato il numero previsto di istanze di ciascuna entità.

2. Determinazione dei rapporti tra enti e loro documentazione. Vengono definite solo le relazioni tra entità necessarie per soddisfare i requisiti di progettazione del database. Il tipo di ciascuno è impostato. Viene rivelata la classe di appartenenza delle entità. Ai collegamenti vengono assegnati nomi significativi espressi da verbi. Nel dizionario dei dati viene inserita una descrizione dettagliata di ogni connessione, indicandone la tipologia e la classe di appartenenza delle entità che partecipano alla connessione.

3. Creazione di un modello ER dell'area disciplinare. I diagrammi ER vengono utilizzati per rappresentare entità e relazioni tra di esse. Sulla base di essi, viene creata un'unica immagine visiva dell'area tematica modellata: il modello ER dell'area tematica.

4. Definizione degli attributi e loro documentazione. Vengono rivelati tutti gli attributi che descrivono le entità del modello ER creato. A ogni attributo viene assegnato un nome significativo che gli utenti possono comprendere. Le seguenti informazioni sono memorizzate nel dizionario dei dati per ciascun attributo:

• nome e descrizione dell'attributo;
• tipo e dimensione dei valori;
• il valore predefinito per l'attributo (se presente);
• se l'attributo può avere valori NULL;
• se l'attributo è composto e, in caso affermativo, di quali attributi semplici è costituito. Ad esempio, l'attributo "Nome completo del cliente" può essere costituito da attributi semplici "Cognome", "Nome", "Patronimico" oppure può essere semplice, contenente singoli valori, come "Sidorsky Evgeniy Mikhailovich". Se l'utente non ha bisogno di accedere ai singoli elementi del "Nome", l'attributo viene presentato come semplice;
• se l'attributo viene calcolato e, in tal caso, come vengono calcolati i suoi valori.

5. Definizione dei valori degli attributi e loro documentazione. Per ogni attributo di un'entità che partecipa al modello ER, viene determinato un insieme di valori validi e ad esso viene assegnato un nome. Ad esempio, l'attributo "Tipo di conto" può avere solo i valori "deposito", "corrente", "su richiesta", "conto carta". Le voci del dizionario dati relative agli attributi vengono aggiornate con i nomi delle serie di valori degli attributi.

6. Definizione delle chiavi primarie degli enti e loro documentazione. Questo passaggio è guidato dalla definizione di una chiave primaria - come attributo o insieme di attributi di un'entità che consente l'identificazione univoca delle sue istanze. Le informazioni sulla chiave primaria vengono inserite nel dizionario dei dati.

7. Discussione del modello dati concettuale con gli utenti finali. Il modello di dati concettuale è rappresentato da un modello ER con documentazione di accompagnamento contenente una descrizione del modello di dati sviluppato. Se vengono rilevate incoerenze di dominio, vengono apportate modifiche al modello fino a quando gli utenti non confermano che il modello da loro proposto riflette adeguatamente le loro opinioni personali.

2.2 Progettazione logica

Lo scopo della fase di progettazione logica è trasformare il modello concettuale basato sul modello di dati selezionato in un modello logico indipendente dalle caratteristiche del DBMS utilizzato successivamente per l'implementazione fisica del database. Per ottenerlo, vengono eseguite le seguenti procedure.

Un esempio di uno schema di database logico.

1. Scelta di un modello di dati. Molto spesso, viene scelto un modello di dati relazionali per la chiarezza della presentazione tabulare dei dati e la comodità di lavorare con essi.

2. Definire un insieme di tabelle basate sul modello ER e documentarle. Viene creata una tabella per ogni entità del modello ER. Il nome dell'entità è il nome della tabella. Le relazioni tra le tabelle vengono stabilite attraverso il meccanismo delle chiavi primarie e delle chiavi esterne. Vengono documentate le strutture delle tabelle e le relazioni stabilite tra di esse.

3. Normalizzazione delle tabelle. Per eseguire correttamente la normalizzazione, il progettista deve comprendere a fondo la semantica e i modelli di utilizzo dei dati. In questa fase controlla la correttezza della struttura delle tabelle create nella fase precedente applicando ad esse la procedura di normalizzazione. Consiste nel portare ciascuna delle tabelle almeno al 3° NF. Come risultato della normalizzazione, si ottiene un design del database molto flessibile, che facilita la creazione delle estensioni necessarie.

4. Verifica del modello di dati logici per la possibilità di eseguire tutte le transazioni fornite dagli utenti. Una transazione è un insieme di azioni eseguite da un singolo utente o programma applicativo per modificare il contenuto di un database. Quindi, un esempio di transazione nel progetto BANK può essere il trasferimento del diritto di gestire i conti di un determinato cliente a un altro cliente. In questo caso, sarà necessario apportare diverse modifiche al database contemporaneamente. Se un computer si arresta in modo anomalo durante una transazione, il database si troverà in uno stato incoerente perché alcune modifiche sono già state apportate e altre no. Pertanto, tutte le modifiche parziali devono essere annullate per riportare il database allo stato coerente precedente.

L'elenco delle transazioni è determinato dalle azioni degli utenti nell'area tematica. Utilizzando il modello ER, il dizionario dei dati e le relazioni stabilite tra chiavi primarie ed esterne, si tenta di eseguire manualmente tutte le operazioni di accesso ai dati necessarie. Se una qualsiasi operazione manuale fallisce, il modello di dati logici compilato è inadeguato e contiene errori che devono essere eliminati. Forse sono correlati a una lacuna nel modello di un'entità, relazione o attributo.

5. Determinazione dei requisiti di supporto all'integrità dei dati e relativa documentazione. Questi requisiti sono restrizioni messe in atto per impedire l'immissione di dati in conflitto nel database. In questa fase, i problemi di integrità dei dati vengono trattati senza tener conto di aspetti specifici della sua implementazione. Dovrebbero essere considerati i seguenti tipi di restrizioni:

• dati richiesti. Scoprire se ci sono attributi che non possono avere valori NULL;
• restrizioni sui valori degli attributi. Sono definiti valori validi per gli attributi;
• integrità dell'entità. Si ottiene se la chiave primaria dell'entità non contiene valori NULL;
• integrità referenziale. Resta inteso che il valore della chiave esterna deve essere presente nella chiave primaria di una delle righe della tabella per la controllante;
• restrizioni imposte dalle regole aziendali. Ad esempio, nel caso del progetto BANCA, potrebbe essere adottata una norma che vieti al cliente di gestire, diciamo, più di tre conti.

Le informazioni su tutti i vincoli di integrità dei dati stabiliti vengono inserite nel dizionario dei dati.

6. Creazione della versione finale del modello logico dei dati e discussione con gli utenti. Questo passaggio prepara la versione finale del modello ER, che rappresenta il modello dati logico. Il modello stesso e la documentazione aggiornata, incluso il dizionario dei dati e lo schema di collegamento della tabella relazionale, vengono presentati per la revisione e l'analisi da parte degli utenti, che devono garantire che rappresenti accuratamente l'area tematica.

2.3. Progettazione fisica

Lo scopo della fase di progettazione fisica è descrivere un'implementazione specifica di un database situato nella memoria esterna di un computer. Questa è una descrizione della struttura di archiviazione dei dati e dei metodi efficienti di accesso ai dati del database. Nella progettazione logica, rispondono alla domanda - cosa deve essere fatto, e nella progettazione fisica - viene scelto un modo per farlo. Le procedure di progettazione fisica sono le seguenti.

1. Progettazione delle tabelle del database utilizzando il DBMS selezionato. Viene selezionato un DBMS relazionale da utilizzare per creare un database ospitato sul supporto della macchina. La sua funzionalità per la progettazione di tavoli è studiata a fondo. Quindi viene eseguita la progettazione delle tabelle e lo schema della loro connessione nell'ambiente DBMS. Il progetto di database preparato è descritto nella documentazione di accompagnamento.

2. Implementazione delle regole aziendali nell'ambiente del DBMS selezionato. L'aggiornamento delle informazioni nelle tabelle può essere limitato dalle regole aziendali. Il modo in cui vengono implementati dipende dal DBMS scelto. Alcuni sistemi per implementare i requisiti dell'area disciplinare offrono più funzionalità, altri meno. In alcuni sistemi non è previsto alcun supporto per l'implementazione delle regole aziendali. In questo caso, le applicazioni vengono sviluppate per implementare i loro limiti.

Tutte le decisioni prese in relazione all'implementazione delle regole aziendali del dominio sono descritte in dettaglio nella documentazione di accompagnamento.

3. Progettare l'organizzazione fisica del database. Questo passaggio seleziona la migliore organizzazione di file per le tabelle. Vengono identificate le transazioni che verranno eseguite nel database in fase di progettazione, evidenziando le più importanti. Viene analizzato il throughput delle transazioni, il numero di transazioni che possono essere elaborate in un determinato intervallo di tempo, e il tempo di risposta, il periodo di tempo necessario per completare una transazione. Si sforzano di aumentare il throughput delle transazioni e ridurre i tempi di risposta.

Sulla base di questi indicatori, vengono prese decisioni per ottimizzare le prestazioni del database definendo indici nelle tabelle che velocizzano la selezione dei dati dal database o riducendo i requisiti per il livello di normalizzazione della tabella. Viene stimato lo spazio su disco necessario per ospitare il database creato. Sforzati di minimizzarlo.

Le decisioni prese sulle questioni di cui sopra sono documentate.

4. Sviluppo di una strategia di protezione del database. Il database è una preziosa risorsa aziendale e molta attenzione viene posta alla sua protezione. Per fare ciò, i progettisti devono avere una comprensione completa e chiara di tutte le protezioni fornite dal DBMS selezionato.

5. Organizzazione del monitoraggio del funzionamento della banca dati e del suo adeguamento. Successivamente alla realizzazione del progetto fisico della banca dati, viene organizzato un monitoraggio continuo del suo funzionamento. Le informazioni risultanti sul livello di prestazioni del database vengono utilizzate per ottimizzarlo. Per questo, sono coinvolti anche i mezzi del DBMS selezionato.

Le decisioni di apportare modifiche a un database funzionante dovrebbero essere considerate e ponderate attentamente.