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: