La progettazione di una base di dati (seconda parte)

La progettazione logica realizza a partire da uno schema concettuale uno schema logico, aggiungendo altri dettagli allo schema finale. Prima di effettuare la traduzione dallo schema concettuale a quello logico è necessario compiere un ulteriore passaggio, solitamente detto di ristrutturazione. Ciò è indispensabile poiché non tutti i costrutti usati dal modello ER hanno un equivalente per lo schema logico. Basti pensare al costrutto usato dal modello ER per le generalizzazioni, quest'ultimo, infatti, va ridisegnato mettendo in relazione le entità figlie con l'entità padre. Per i motivi detti sopra suddivideremo la progettazione logica in due fasi: ristrutturazione e traduzione dello schema concettuale.

Prima di analizzare in dettaglio le due fasi dette sopra occorre affrontare un importante discorso ovvero quello sulle prestazioni offerte dallo schema ER. In questa fase, infatti, vanno analizzati alcuni parametri prestazionali come l'occupazione in memoria dei dati e il costo di una operazione (inteso come numero medio di entità e associazioni che il sistema informativo necessita per realizzare una operazione). Per stimare i parametri detti sopra abbiamo bisogno di altre informazioni:

• volume dei dati: inteso sia come numero di entità e relazioni che compongono lo schema che come dimensione (massima) di ogni attributo;
• caratteristiche delle operazioni: richiede la suddivisione delle operazioni per tipo (operazione interattiva, operazione batch) e una stima della frequenza per le operazioni del sistema informativo (anche in relazione ai dati che essa coinvolge);

Le informazione viste sopra sono solitamente riassunte all'interno di tabelle: tavola delle operazioni e tavola dei volumi. Nella tavola delle operazioni si riporta per ogni operazione il tipo e la frequenza prevista o stimata. Nella tavola dei volumi si riporta, invece, il numero medio di partecipazioni delle occorrenze di un'entità con le occorrenze di un'associazione (questo parametro è evidentemente condizionato dalla cardinalità delle associazioni).

Per la fase di ristrutturazione occorre applicare sullo schema concettuale i seguenti passi:

• analisi delle ridondanza: per ridondanza si intende la presenza di un dato all'interno dello schema che può essere ricavato da altri dati dello schema. Occorre analizzare gli attributi di ogni entità e stabilire se questi siano fra loro dipendenti, eliminando quindi quelli derivabili. La scelta dell'attributo da eliminare va fatto considerando le operazioni sui dati. Per scongiurare la ridondanza degli attributi vanno analizzati anche gli attributi delle entità in relazione. All'interno di uno schema possono essere presenti anche ridondanze di associazioni, l'analisi va sempre condotta considerando le tavole dette prime;
• eliminazione delle generalizzazioni: occorre tradurre le generalizzazione effettuando a seconda dei casi l'accorpamento delle entità che vi partecipano. Le entità figlie possono essere accorpate nell'entità padre, in tal caso l'entità padre prenderà gli attributi delle entità figlie (utile quando la distinzione fra le entità figlie e padre e degli attributi non incide sul costo delle operazioni). Altra possibilità è quella di accorpare l'entità padre nelle entità figlie, in tal caso le entità figlie prenderanno gli attributi dell'entità padre e parteciperanno alle relazioni dell'entità padre (questa soluzione è possibile solo se la generalizzazione è totale, altrimenti le occorrenze dell'entità padre non sarebbero rappresentate nelle occorrenze delle entità figlie). L'ultima possibilità per eliminare le generalizzazioni prevede la sostituzione del costrutto con associazioni fra entità padre e entità figlie (da usare quando la generalizzazione non è totale e conviene tenere nello schema, a causa di alcune operazioni, tutte le entità);
• partizionamento e/o accorpamento di entità e/o associazioni: il partizionamento di una entità è utile quando la stessa contiene troppi attributi e le operazioni accedono, solitamente, a un sottoinsieme di tali attributi (decomposizione verticale). Anche l'eliminazione di un attributo multi-valore avviene attraverso il partizionamento dell'entità. L'attributo multi-valore viene messo in una nuova entità che va quindi messa in relazione con l'entità di partenza. Se le operazioni del sistema informativo insistono su insieme di attributi appartenenti a due o più entità si può pensare a un'accorpamento degli stessi all'interno di un'unica entità;
• scelta degli identificatori primari: ha lo scopo di stabilire le chiavi primarie per le entità dello schema. Meglio scegliere un identificatore costituito da pochi attributi, possibilmente interno all'entità;

(generalizzazione)

(soluzione 1)

(soluzione 2)

(soluzione 3)

Lo schema concettuale ristrutturato ci permette di avviare, finalmente, la traduzione verso uno schema logico equivalente. Le regole per la traduzione prevedono che per ogni entità dello schema ci sia una relazione (in questo contesto bisogno si intende per relazione la rappresentazione tabellare dei dati, organizzati dunque su righe e colonne) avente lo stesso nome, gli stessi attributi dell'entità e come chiave primaria il suo identificatore. Anche le associazioni vengono tradotte in relazioni, gli attributi e il nome della relazione saranno gli attributi e il nome dell'associazione, la chiave primaria sarà composta dagli identificatori delle entità che partecipano all'associazione.

In base alla cardinalità delle entità partecipanti a una relazione è possibile avere uno dei seguenti casi di traduzione: molti a molti, uno a molti, uno a uno. Nella traduzione molti a molti ogni entità e ogni associazione viene tradotta in una relazione. L'informazione rappresentata dal seguente schema concettuale:

può essere rappresentate dal seguente modello:

studente(matricola, nome, cognome)

esame(nome,crediti)

sessione(studente, esame, voto, data)

con i vincoli di integrità referenziale fra gli attributi studente ed esame della relazione sessione e gli attributi matricola e nome. Nella traduzione uno a molti occorre prestare attenzione alla cardinalità delle occorrenze. Se la cardinalità minima di una occorrenza è 0 possono esserci più traduzioni (la scelta ricadrà su quella che garantisce le prestazioni migliori), in tal caso la traduzione è come il caso già analizzato sopra (ci sarà, pertanto, una relazione per ogni entità o associazione). Se la partecipazione di un'entità all'associazione è obbligatoria la traduzione tenderà ad accorpare in essa anche gli attributi dell'associazione. L'informazione rappresentata dal seguente schema concettuale:

può essere rappresentata dal seguente modello:

impiegato(cf, nome, cognome, settore, data)

settore(nome, città)

con il vincolo di integrità referenziale fra l'attributo settore della relazione impiegato e l'attributo nome della relazione settore. Nella traduzione uno a uno possiamo avere due casi, anche in questo caso occorre analizzare la cardinalità minima delle singole partecipazione. Possiamo avere una partecipazione obbligatoria oppure opzionale. Per la partecipazione obbligatoria sono possibili più traduzioni del modello poiché gli attributi dell'associazione possono essere accorpati in una qualunque delle relazioni. L'informazione rappresentata dal seguente schema concettuale:

può essere rappresentata dal seguente modello:

utente(login, nome, cognome, upgrade, stats)

upgrade(codice, nome, descrizione)

oppure dal modello:

utente(login, nome. cognome)

upgrade(codice, nome, descrizione, utente, data)

Per la partecipazione opzionale va invece escluso uno dei possibili modelli (essendo la cardinalità minima di una partecipazione pari a 0). L'informazione rappresentata dal seguente schema concettuale:

può essere rappresentata dal seguente modello:

utente(login, nome, cognome)

upgrade(codice, nome, descrizione, utente, data)

In seguito analizzeremo un esempio completo di progettazione di una base di dati, dal modello concettuale al quello fisico.

La progettazione di una base di dati (prima parte)

Le applicazioni molto spesso interagiscono con i dati, manipolando l'informazione. L'informazione è l'elemento centrale di un programma e la sua progettazione deve precedere quella dell'intero sistema informativo che vi accede. Per questo motivo la progettazione di una base di dati, coerente con la realtà di riferimento descritta nelle specifiche del software, è indispensabile per la progettazione degli altri componenti. L'esistenza di modelli di riferimento per la progettazione di una base di dati ne dimostra l'importanza. Per la progettazione dei dati possiamo fare riferimento ad una consolidata metodologia che prevede le seguenti fasi:

• progettazione concettuale;
• progettazione logica;
• progettazione fisica;

Ognuna di queste fasi, rispecchiando i requisiti della base di dati, realizza il modello finale per i dati del sistema informativo.

La progettazione concettuale rappresenta il livello di astrazione più alto ed ha come scopo la rappresentazione dei requisiti della base di dati, il prodotto finale di questa fase è chiamato schema concettuale. In questa fase il progettista non deve mai considerare gli aspetti implementativi della base di dati e l'efficienza dello schema concettuale ottenuto (tutte le osservazioni e le modifiche del modello avvengono nei successivi livelli di astrazione). Lo schema concettuale è un'alternativa alla scrittura dei requisiti funzionali della base di dati. La sua semplicità, infatti, ne permette l'uso anche all'interno della documentazione del sistema informativo.

La progettazione logica prevede la traduzione dello schema concettuale (ottenuto nella fase precedente) in schema logico. In questo livello di astrazione, per ottimizzare lo schema logico vengono considerati i vincoli e le operazioni sui dati che il sistema informativo dovrà compiere sugli stessi. Il modello logico più usato in questa fase della progettazione è il modello relazionale, che si basa sull'algebra relazionale e sul concetto di relazione. Tale modello, come vedremo in seguito, prima di essere tradotto in schema logico necessita di un ulteriore processo di ristrutturazione!

La progettazione fisica genera a partire dallo schema logico uno schema fisico, ottenuto considerando adesso le specifiche sui dati, il database scelto e le ottimizzazioni sullo stesso per migliorare le operazioni che il sistema informativo eseguirà in futuro (questo potrebbe significare anche la modifica dello schema logico).

Il modello Entità-Relazione (entity-relationship) è un modello concettuale per l'astrazione dei dati di un sistema informativo. Viene di solito abbreviato con la sigla E-R, la cui vera traduzione è Entità-Associazione. Questo modello offre al progettista una serie di utili costrutti grafici che, miscelati tra loro, permettono di generare un modello concettuale dei dati. Questi i principali costrutti:

Entità

L'entità modella un insieme omogeneo di dati, rappresenta una classe di oggetti che ha motivo di esistere all'interno del modello poiché è indispensabile per modellare una porzione della realtà di riferimento. Va comunque detto che un entità è anche indipendente ed autonoma ai fini dell'applicazioni, può cioè fornire informazioni anche senza interagire con altri componenti del modello. Il costrutto grafico usato per l'entità prevede un rettangolo che racchiude il nome (univoco all'interno dello schema) dell'entità. Alcuni esempi di entità, validi all'interno di realtà di riferimento assegnate, potrebbero essere le entità: impiegato, studente, città, per modellare l'occorrenza di tali oggetti nel sistema informativo.

Relazione

Una relazione rappresenta il legame logico esistente fra due o più entità della base di dati. Una relazione fra due entità è detta binaria, altrimenti è n-aria (fra n entità). Esistono anche relazioni ricorsive! Il costrutto grafico usato per la relazione prevede un rombo che racchiude il nome (univoco all'interno dello schema) della relazione alla quale afferiscono le entità che vi prendono parte. E' preferibile scegliere come nome di una relazione un sostantivo piuttosto che un verbo, in maniera tale da non far intendere il verso della relazione.

E' opportuno osservare che l'insieme delle occorrenze di una relazione corrisponde al prodotto cartesiano delle occorrenze delle entità che vi prendono parte. Pertanto, fra le occorrenze di una relazione del modello E-R non possono esserci, come vedremo meglio in seguito, duplicati! Questa osservazione ha un impatto molto importante sul modello poiché non permette di rappresentare alcuni eventi. Ad esempio, la relazione binaria esame collega logicamente le entità studente e corso:

Poiché le occorrenze di una relazione sono univoche, in questo modello non è possibile rappresentare i vari tentativi che uno studente compie per superare l'esame di un corso. Se vogliamo rappresentare questi eventi all'interno della base di dati dobbiamo allora modificare il modello in questo modo (usando una relazione n-aria):

Attributi

Gli attributi descrivono le proprietà delle entità o delle relazioni che sono utili ai fini dell'applicazione. Ad esempio, per l'entità studente potrebbero interessare gli attributi: matricola, nome, cognome e data di nascita. Per la relazione esame, invece, potrebbero interessare gli attributi relativi al voto conseguito e alla data dell'esame. L'attributo, quindi, specifica per ogni occorrenza di una entità o relazione i valori che tale occorrenza può assumere (il dominio). Tutti gli oggetti della stessa entità o relazione hanno gli stessi attributi.

Il costrutto grafico usato per la rappresentazione degli attributi prevede un piccolo cerchio vuoto, collegato all'entità o alla relazione mediante una linea, caratterizzato nelle immediate vicinanze da un nome (univoco all'interno dello schema) che identifica la proprietà dell'occorrenza. In alcuni casi gli attributi possono essere raggruppati per formare attributi di tipo composto, come avviene in questo esempio:

Cardinalità delle relazioni e degli attributi

Specificano, per le relazioni, il numero minimo e massimo di occorrenze per le entità che partecipano all'associazione. Per la cardinalità minima i possibili valori possono essere 0 o 1. Se la cardinalità minima per un'occorrenza è 0 la partecipazione alla relazione è detta opzionale. Se 1, invece, è detta obbligatoria. Per la cardinalità massima i possibili valori possono essere 1 o N (molti, più di uno). Se la cardinalità massima e quella minima è 1 si dice che la relazione realizza una funzione, associa cioè a un'occorrenza di un'entità una sola occorrenza delle altre entità della relazione. Le relazioni binarie (fra due entità) vengono talvolta ricordate considerando le cardinalità massime delle entità partecipanti, questi i possibili casi:

• relazione uno a uno;
• relazione uno a molti;
• relazione molti a molti;

Seguono alcuni esempi:

Nella relazione uno a uno: un impiegato può avere al massimo un solo telefono aziendale (la cardinalità minima, in questo caso pari a 0, indica che un impiegato può anche non avere un telefono aziendale). Dall'altro lato della relazione: un telefono aziendale può essere assegnato a un solo impiegato.

Nella relazione uno a molti: un impiegato risiede in una sola città (occorrenza obbligatoria per il modello di dati analizzato). Dall'altro lato della relazione: una città può avere N impiegati ivi residenti (data la cardinalità minima della relazione, una città potrebbe anche non aver nessun impiegato!).

Nella relazione molti a molti: un impiegato può ricevere N incarichi di progetto (data la cardinalità minima della relazione possiamo anche dire che ne riceve almeno uno). Dall'altro lato della relazione: un progetto può essere assegnato ad N impiegati (oppure, vista la cardinalità minima, non è ancora stato assegnato).

Anche un attributo può avere una cardinalità minima e massima. L'attributo ha una cardinalità minima che può valere 0 (attributo opzionale) oppure 1 (attributo obbligatorio). Se la cardinalità massima di un attributo è pari ad N l'attributo è allora detto multi-valore. Se l'attributo ha cardinalità (1,1) la notazione viene omessa dallo schermo (per non appesantirne il disegno).

Identificatori delle entità

Ogni occorrenza di una entità deve essere sempre distinguibile dalle altre, per questo motivo il modello E-R offre un ulteriore costrutto per l'identificazione. L'identificatore di un occorrenza è in molti casi una proprietà dell'entità. Per segnare tale proprietà come identificatore dell'occorrenza occorre annerire il cerchio della proprietà che afferisce all'entità analizzata, come in questo esempio:

In alcune realtà di riferimento il modello dei dati potrebbe suggerire come identificatore un insieme di più attributi, il formalismo grafico da usare in questo caso è il seguente:

In altri contesti, infine, gli attributi interni non sono sufficienti a identificare univocamente un'occorrenza. In tal caso si userà come identificatore un insieme di attributi interni e un insieme di attributi di entità esterne (attributo esterno). In questo esempio:

l'identificatore è composto dall'attributo matricola della entità studente e dall'attributo nome dell'entità università. Ciò potrebbe essere sufficientemente reale se si pensa ad esempio che due studenti iscritti a due università differenti possano poi avere lo stesso numero di matricole! In questo modello l'uso dell'attributo esterno è dunque indispensabile!

Generalizzazioni

Attraverso questo costrutto possiamo distinguere due o più entità che differiscono fra loro per la presenza o l'assenza di uno o più attributi. In altre parole con questo costrutto possiamo generalizzare un entità padre in una o più entità figlie. Le entità figlie ereditano gli attributi dell'entità padre, oltre ad avere i propri attributi. Ad esempio, l'entità uomo o donna potrebbe essere una generalizzazione dell'entità persona. Ogni occorrenza dell'entità figlia è anche una occorrenza dell'entità figlia. Le generalizzazioni vengono rappresentate graficamente da una freccia che che unisce le entità figlie all'entità padre, la freccia punta all'entità padre. Se la freccia è piena la generalizzazione si dice totale: ogni occorrenza della classe padre è una occorrenza di almeno una delle entità figlie, in caso contrario la generalizzazione è detta parziale. Se la freccia non è piena la generalizzazione si dice esclusiva: ogni occorrenza della classe padre è al più una occorrenza di una delle entità figlie, in caso contrario è detta sovrapposta.

Adesso siamo in grado di comprendere il seguente modello concettuale: