Metodologia di Progettazione database relazionali

Informatica e Telecomunicazioni S.p.A.
Metodologia
di
Progettazione database relazionali
I&T Informatica e Telecomunicazioni S.p.A
Via dei Castelli Romani, 9
00040 Pomezia (Roma) – Italy
Tel. +39-6-911611
Fax +39-6-91601162
http://www.iet.it
Marketing Operativo e Innovazione
Hi Tech - Knowledge Technology
Relatore: Nino RUSSO
[email protected]
Febbraio 1999
Metodologia di progettazione database relazionali
Indice
1
Introduzione alla progettazione
1.1 Ciclo di vita dei sistemi informativi
1.2 Metodologia e fasi di progettazione
1.2.1
Progetto concettuale del database
1.2.1.1 Livello vista
1.2.1.2 Schemi ed Istanze
1.2.2
Progetto logico del database
1.2.3
Progetto fisico del database
1.2.4
Indipendenza dei dati
1.3 Prodotti delle varie fasi della progettazione
2
Progettazione concettuale
2.1 Raccolta e analisi dei requisiti
2.2 Modello Entità-Relazione
2.3 Criteri generali di rappresentazione
2.4 Documentazione dei diagrammi Entità-Relazione
2.5 Utilità dei diagrammi Entità-Relazione
2.6 Strategie di progetto
2.6.1
Strategia top-down
2.6.2
Strategia bottom-up
2.6.3
Strategia inside-out
2.6.4
Stategia mista
2.7 Qualità di uno schema concettuale
2.8 Metodologia generale
3
Progettazione logica
3.1 Analisi delle prestazioni su schemi E-R
3.2 Ristrutturazione di schemi E-R
3.3 Modello dati logico
3.4 Modello dati relazionale
3.5 Traduzione verso il modello relazionale
3.6 Vincoli di integrità
3.6.1
Vincoli di chiave
3.6.2
Vincoli di integrità referenziale
3.7 Algebra relazionale
3.7.1
Operatori di base
3.7.2
Operatori derivati
3.8 Normalizzazione dei dati
3.8.1
Ridondanza e anomalie
3.8.2
Dipendenze
3.8.3
Scomposizioni
3.8.4
Prima forma normale
3.8.5
Seconda forma normale
3.8.6
Terza forma normale
3.8.7
Linee guida sulla normalizzazione
3.9 Implementazione dello schema logico
4
Progettazione fisica
I&T Informatica e Telecomunicazioni SpA
3
3
4
5
5
6
6
7
7
7
10
10
12
14
14
15
16
16
17
18
18
18
19
22
23
24
25
26
26
27
27
27
28
28
29
30
30
31
31
32
33
33
33
35
36
2
Metodologia di progettazione database relazionali
1
Introduzione alla progettazione
Progettare una base di dati (o banca dati o database) significa definire struttura, caratteristiche e
contenuto: si tratta di un processo nel quale bisogna prendere molte decisioni strategiche e l’uso di
opportune metodologie è fondamentale per la realizzazione di un prodotto di alta qualità.
La metodologia cui fa riferimento la I&T è articolata in tre fasi: la progettazione concettuale, la
progettazione logica e la progettazione fisica.
1.1
Ciclo di vita dei sistemi informativi
La progettazione di una base di dati costituisce solo una componente del processo di sviluppo,
all’interno di una organizzazione, di un sistema informativo complesso e va quindi inquadrata in un
contesto più ampio, quello del ciclo di vita dei sistemi informativi.
Come illustrato in figura 1.1, il ciclo di vita di un sistema informativo comprende, generalmente, le
seguenti attività.
Studio di
fattibilità
Raccolta e analisi
dei requisiti
Progettazione
Implementazione
Validazione e
collaudo
Funzionamento
Fig. 1.1 Ciclo di vita di un sistema informativo
• Studio di fattibilità. Serve a definire, in maniera per quanto possibile precisa, i costi delle varie
alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del sistema.
• Raccolta e analisi dei requisiti. Consiste nella individuazione e nello studio delle proprietà e
delle funzionalità che il sistema informativo dovrà avere. Questa fase richiede una interazione
con gli utenti del sistema e produce una descrizione completa, ma generalmente informale, dei
dati coinvolti (anche in termini di previsione sulla loro frequenza). Vengono inoltre stabiliti i
requisiti software e hardware del sistema informativo.
I&T Informatica e Telecomunicazioni SpA
3
Metodologia di progettazione database relazionali
• Progettazione. Si divide generalmente in progettazione dei dati e progettazione delle
applicazioni. Nella prima si individua la struttura e l’organizzazione che i dati dovranno avere,
nell’altra si definiscono le caratteristiche dei programmi applicativi. Le due attività sono
complementari e possono procedere in parallelo o in cascata. Le descrizioni dei dati e dei
programmi prodotte in questa fase sono formali e fanno riferimento a specifici modelli.
• Implementazione. Consiste nella realizzazione del sistema informativo secondo la struttura e le
caratteristiche definite nella fase di progettazione. Viene costruita e popolata la base di dati e
viene sviluppato il codice dei programmi.
• Validazione e collaudo. Serve a verificare il corretto funzionamento e la qualità del sistema
informativo. La sperimentazione deve prevedere, per quanto possibile, tutte le condizioni
operative.
• Funzionamento. In questa fase il sistema informativo diventa operativo e richiede, a meno di
malfunzionamenti o revisioni delle funzionalità del sistema, solo operazioni di gestione e
manutenzione.
Va detto che accanto alle attività citate, viene oggi spesso effettuata anche un’attività di
prototipizzazione, che consiste nell’uso di specifici strumenti software per la realizzazione rapida di
una versione semplificata del sistema informativo, con la quale sperimentare le sue funzionalità. La
verifica del prototipo può portare a una modifica dei requisiti e una eventuale revisione del progetto.
Le basi di dati costituiscono in effetti solo una delle componenti di un sistema informativo che
tipicamente include anche programmi applicativi, le interfacce con l’utente e altri programmi di
servizio. Comunque, il ruolo centrale che i dati hanno in un sistema informativo giustifica uno
studio autonomo relativo alla progettazione delle basi di dati e che si individua nella terza fase del
ciclo di vita riportato in figura 1.1. Con questo approccio, in linea di principio, viene prima
progettata la base di dati e, successivamente, le applicazioni che la utilizzano.
1.2
Metodologia e fasi di progettazione
Una metodologia di progettazione è una combinazione di una serie di passi e di proprietà che
permettono di ottenere prodotti di alta qualità. In buona sostanza, una metodologia di progettazione
consiste in:
• una decomposizione in passi successivi indipendenti dell’intera attività di progetto,
• una serie di strategie da seguire nei vari passi e alcuni criteri per la scelta in caso di alternative,
• alcuni modelli di riferimento per descrivere i dati di ingresso e uscita delle varie fasi.
Le proprietà che una metodologia deve garantire sono principalmente:
• la generalità rispetto alle applicazioni e ai sistemi in gioco (e quindi la possibilità di utilizzo
indipendente dal problema allo studio e dagli strumenti a disposizione),
• la qualità del prodotto in termini di correttezza, completezza ed efficienza rispetto alle risorse
impiegate,
• la faciltà d’uso sia delle strategie che dei modelli di riferimento.
Nel corso degli anni, nell’ambito delle basi di dati, si è consolidata una metodologia di progetto
articolate in tre fasi principali da effettuare in cascata. Essa si fonda su un principio molto semplice
I&T Informatica e Telecomunicazioni SpA
4
Metodologia di progettazione database relazionali
ma efficace: quello di separare in maniera netta le decisioni relative a “cosa” rappresentare in una
base dati (prima fase), da quelle relative a “come” farlo (fasi successive).
Ogni fase si riferisce a un livello di astrazione nella rappresentazione dei dati e delle relazioni tra
essi, e ha lo scopo di separare le attività di risoluzione dei problemi e di garantire la possibilità di
modificare delle soluzioni adottate ai livelli inferiori senza dover riprogettare quanto definito nei
livelli superiori.
A ciascuna fase di progettazione corrispondono diversi modelli per la rappresentazione dei dati,
ovvero tecniche per la rappresentazione degli aspetti rilevanti della realtà da modellare, definite da
strumenti e vincoli specifici. La rappresentazione generata seguendo le regole del modello viene
definita schema (vedi fig. 1.2).
realtà di interesse
modello (regole di rappresentazione)
schema
Fig. 1.2 Realtà/modello/schema
Le fasi riconosciute fondamentali nella progettazione di un database sono le seguenti: progetto
concettuale, progetto logico e progetto fisico (vedi figura 1.3).
1.2.1 Progetto concettuale del database
Obiettivo della fase di progettazione concettuale è la rappresentazione completa (formale) della
realtà di interesse (informale) ai fini informativi, in maniera indipendente da qualsiasi specifico
DBMS (Database Management System) e quindi senza tenere conto degli aspetti implementativi.
Tale rappresentazione, detta schema concettuale (che fa riferimento a un modello concettuale dei
dati), è la rappresentazione più astratta, ovvero più vicina alla logica umana, nella definizione di
dati e relazioni.
I modelli dei dati usati nella progettazione concettuale vengono definiti modelli semantici. Nel
corso degli anni sono stati definiti diversi modelli dei dati ad iniziare da quelli reticolari e
gerarchici seguiti da quello entità-relazione e infine quelli orientati agli oggetti e alla logica.
1.2.1.1 Livello vista
Una vista, sottoschema, o subschema, è una parte del database concettuale o un’astrazione di parte
del database concettuale. In un certo senso, la costruzione delle viste è l’inverso del processo di
integrazione di un database: per ogni collezione dei dati che hanno contribuito alla costruzione del
database concettuale globale, possiamo costruire una vista che contenga proprio quei dati. Le viste
sono importanti anche per far valere la sicurezza in un sistema di database, permettendo solo agli
utenti che ne hanno l’autorizzazione di osservare i sottoinsiemi dei dati.
Spesso una vista è proprio come un piccolo database concettuale ed ha lo stesso livello di
astrazione. Però, in un certo senso, una vista può essere “più astratta” di un data base concettuale, in
quanto i dati in essa coinvolti possono essere costruiti a partire dal database concettuale, senza però
essere effettivamente presenti in quel database.
I&T Informatica e Telecomunicazioni SpA
5
Metodologia di progettazione database relazionali
Requisiti
della base di
dati
Progettazione di
base di dati
Progetto concettuale
Modello concettuale
Schema concettuale
Progetto logico
Modello logico
Schema logico
Progetto fisico
Modello fisico
Schema fisico
Prodotti della progettazione
Fig. 1.3 Fasi della progettazione di una base di dati
1.2.1.2 Schemi ed Istanze
Quando si progetta un database si è interessati al suo schema, quando invece si usa si è interessati ai
dati effettivamente presenti in esso. Si noti che i dati nel database cambiano frequentemente, mentre
gli schemi rimangono gli stessi per lungo tempo.
Il contenuto corrente del database si chiama istanza del database (o estensione del database o stato
del database).
Come visto, il termine schema è usato nelle varie fasi della progettazione di un database, così
avremo schema concettuale per riferirsi al livello di progettazione concettuale del database, schema
logico per il progetto logico, schema fisico per il progetto fisico e semplicemente sottoschema per il
livello delle viste.
1.2.2 Progetto logico del database
La fase di progettazione logica del database ha lo scopo di tradurre lo schema concettuale espresso
mediante un modello semantico in una rappresentazione mediate un modello logico dei dati. La
rappresentazione che si ottiene viene definita schema logico del database.
I&T Informatica e Telecomunicazioni SpA
6
Metodologia di progettazione database relazionali
A differenza dello schema concettuale, lo schema logico dipende strettamente dalla categoria di
DBMS utilizzato e in particolare del suo modello logico dei dati. Un modello logico dei dati è
quindi la tecnica di organizzazione e di accesso ai dati utilizzata da specifiche categorie di DBMS.
In particolare, in riferimento al modello logico dei dati su cui si basano, vengono distinti DBMS
gerarchici, reticolari, relazionali, ad oggetti e basati sulla logica.
Un ulteriore compito della progettazione logica è quello di dichiarare le viste, tramite il DDL (Data
Definition Language) o gli specifici linguaggi di definizione dei dati del sottoschema.
Successivamente per presentare interrogazioni ed operazioni su tali viste, può essere previsto un
linguaggio di manipolazione del sottoschema altrimenti viene usato il DML (Data Manipulation
Language) generico.
1.2.3 Progetto fisico del database
Nel progetto fisico viene stabilito come le strutture a livello logico debbano essere organizzate negli
archivi e nelle strutture del file system: esso dipende quindi non solo dal tipo di DBMS utilizzato,
ma anche dal sistema operativo e in ultima istanza dalla piattaforma hardware del sistema che ospita
il DBMS.
È pertanto il livello di progettazione in cui si può far uso del minor livello di astrazione, dovendo
rispettare i vincoli tecnici imposti dal sistema ospite.
1.2.4 Indipendenza dei dati
La catena di astrazione della figura 1.3, dal database concettuale, a quello logico e a quello fisico,
fornisce due livelli di “indipendenza dei dati”. È ovvio che in un database ben progettato, lo schema
fisico possa essere modificato senza alterare quello logico e senza richiedere una ridefinizione dei
sottoschemi. Questa indipendenza è nota come indipendenza fisica dei dati. Ciò implica che le
modifiche all’organizzazione del database fisico possono alterare l’efficienza dei programmi
applicativi, ma non sarà mai chiesto di riscrivere tali programmi solo perché lo schema fisico ha
modificato l’implementazione dello schema logico.
Anche la relazione tra vista e il database concettuale, fornisce un tipo di indipendenza chiamata
indipendenza logica dei dati. L’uso del database può rendere necessario modificare lo schema
concettuale, per esempio aggiungendo informazioni su diversi tipi di entità o altre informazioni su
entità già esistenti. Lo schema concettuale può subire molte modifiche, senza coinvolgere i
sottoschemi esistenti, mentre altri tipi di variazione allo schema concettuale possono essere fatte
solo ridefinendo la corrispondenza tra sottoschema e schema concettuale. Ancora una volta non
sono necessari variazioni ai programmi applicativi. L’unico tipo di variazione dello schema
concettuale che non si riflette in una semplice ridefinizione della corrispondenza col sottoschema, si
verifica quando vengono cancellate alcune informazioni del sottoschema. Naturalmente tali
variazioni richiederanno la riscrittura o l’eliminazione di alcuni programmi applicativi.
1.3
Prodotti delle varie fasi della progettazione
I requisiti delle base di dati vengono utilizzati in maniera differente nelle varie fasi della
progettazione. Nella progettazione concettuale si fa uso soprattutto delle specifiche sui dati mentre
le specifiche sulle operazioni servono solo a verificare che lo schema concettuale sia completo,
contenga cioè le informazioni necessarie per eseguire tutte le operazioni previste. Nella
progettazione logica si fa invece riferimento allo schema concettuale per quanto riguarda i dati (cioè
I&T Informatica e Telecomunicazioni SpA
7
Metodologia di progettazione database relazionali
non si fa più uso diretto delle specifiche sui dati), mentre le specifiche sulle operazioni si utilizzano,
insieme alle previsioni sul carico applicativo, per ottenere uno schema logico che renda tali
operazioni eseguibili in maniera efficiente. In questa fase bisogna anche conoscere il modello logico
adottato ma non è ancora necessario conoscere il particolare DBMS scelto (solo la categoria a cui
appartiene). Infine, nella progettazione fisica si fa uso dello schema logico e delle specifiche sulle
operazioni per ottimizzare le prestazioni del sistema. In questa fase bisogna anche tener conto delle
caratteristiche del particolare sistema di gestione di base di dati utilizzato.
Il risultato della progettazione di una base dati non è solo lo schema fisico, ma è costituito anche
dallo schema concettuale e dallo schema logico. Lo schema concettuale fornisce infatti una
rappresentazione della di base di dati ad alto livello, che può essere molto utile a scopo
documentativo, mentre lo schema logico fornisce una descrizione concreta del contenuto della base
di dati che, prescindendo dagli aspetti implementativi, può essere utile come riferimento per le
operazioni di interrogazione e aggiornamento.
Nella figura 1.4 vengono mostrati i prodotti delle varie fasi nel caso della progettazione di una base
di dati relazionale, basata sull’uso del più diffuso modello concettuale dei dati, il modello EntitàRelazione. A partire da requisiti rappresentati da documenti e moduli di vario genere, acquisiti
anche attraverso l’interazione con l’utente, viene costruito uno schema Entità-Relazione
(rappresentato da un diagramma) che descrive a livello concettuale la base di dati. Questa
rappresentazione viene poi tradotta in uno schema relazionale, costituito da una collezione di
tabelle. Infine, i dati vengono descritti da un punto di vista fisico (tipo e dimensione dei campi) e
vengono specificate strutture ausiliarie per l’accesso efficiente ai dati.
Nel seguito del documento saranno affrontati in maniera dettagliata i vari passi della progettazione
di base di dati secondo la decomposizione di figura 1.3 e con riferimento ai modelli usati nella
figura 1.4.
I&T Informatica e Telecomunicazioni SpA
8
Metodologia di progettazione database relazionali
Realtà
Progettazione concettuale
Schema
Entità-Relazione
Progettazione logica
Schema
Relazionale
Progettazione fisica
Strutture
fisiche
d’accesso
Fig. 1.4 Prodotti delle varie fasi del progetto di una base dati relazionale con il modello Entità-Relazione
I&T Informatica e Telecomunicazioni SpA
9
Metodologia di progettazione database relazionali
2
Progettazione concettuale
La progettazione concettuale è la prima fase che viene eseguita nella costruzione di una base di dati,
e in essa si produce, uno schema concettuale che rappresenta la realtà di interesse.
Anche nel caso di applicazioni non particolarmente complesse, lo schema che si ottiene può
contenere molti concetti correlati in una maniera piuttosto complicata. Ne consegue che la
costruzione dello schema finale è, necessariamente, un processo graduale: il nostro schema
concettuale viene progressivamente raffinato e arricchito attraverso una serie di trasformazioni ed
eventuali correzioni. Di seguito verranno descritte le strategie che è possibile seguire in questo
processo di sviluppo graduale di uno schema concettuale e il più diffuso modello che permette di
realizzare il suddetto schema, il modello Entità-Relazione.
Prima di iniziare a parlare di queste strategie, vale però la pena spendere qualche parola sull’attività
che precede la progettazione vera e propria: la raccolta e l’analisi dei requisiti. Questa fase, infatti,
non è completamente separata da quella della progettazione, ma procede, in molti casi,
parallelamente ad essa. Possiamo, infatti, iniziare a definire uno schema Entità-Relazione quando
non abbiamo ancora terminato di raccogliere e analizzare tutti i requisiti, per poi arricchirlo
progressivamente man mano che le informazioni in nostro possesso aumentano.
2.1
Raccolta e analisi dei requisiti
Va detto innanzitutto che il reperimento e l’analisi dei requisiti di una applicazione sono attività
difficilmente standardizzabili perché dipendono molto dall’applicazione con cui si a che fare.
Vogliamo però parlare di alcune regole pratiche che è conveniente seguire in questa fase di sviluppo
di una base di dati.
Per raccolta dei requisiti si intende la completa individuazione dei problemi che il sistema da
realizzare deve risolvere e le caratteristiche che tale sistema dovrà avere. Per caratteristiche del
sistema si intendono sia gli aspetti statici (i dati) che gli aspetti dinamici (le operazioni sui dati). I
requisiti vengono inizialmente raccolti in specifiche espresse in linguaggio naturale e, per questo
motivo, spesso ambigue e disorganizzate. L’analisi dei requisiti consiste nel chiarimento e
nell’organizzazione delle specifiche dei requisiti. Si tratta ovviamente di attività fortemente
interconnesse: l’attività di analisi inizia con i primi requisiti ottenuti per poi procedere di pari passo
con attività di raccolta.
I requisiti di una applicazione provengono, nella maggior parte dei casi, da fonti diverse. Le
principali fonti di informazione sono, in genere, le seguenti.
• Gli utenti dell’applicazione. In questo caso le informazioni si acquisiscono mediante opportune
interviste, anche ripetute, oppure attraverso una documentazione scritta che gli utenti possono
aver predisposto appositamente per questo scopo.
• Tutta la documentazione esistente che ha qualche attinenza con il problema allo studio: moduli,
regolamenti interni, procedure aziendali e normative. È richiesta, in questo caso, un’attività di
raccolta e selezione che viene assistita dagli utenti, ma è a carico del progettista.
• Eventuali realizzazioni esistenti, ovvero applicazioni che si devono rimpiazzare o che devono
interagire in qualche maniera con il sistema da realizzare. La conoscenza delle caratteristiche di
questi pacchetti software (tracciati record, maschere, algoritmi, documentazione associata) può
fornirci importanti informazioni anche in relazione ai problemi esistenti che è necessario
risolvere.
I&T Informatica e Telecomunicazioni SpA
10
Metodologia di progettazione database relazionali
Risulta chiaro che, nella fase di acquisizione delle specifiche, gioca un importante ruolo
l’interazione con gli utenti del sistema informativo. Durante questa interazione, avviene spesso che
gli utenti diversi forniscono informazioni diverse, spesso complementari ma qualche volta
contraddittorie. Gli utenti a livello più alto possiedono in genere una visione più ampia, ma meno
dettagliata. Possono però indirizzare verso gli esperti dei singoli sottoproblemi.
Come criterio generale da seguire possiamo dire che, nel corso delle interviste, è opportuno
effettuare con l’utente verifiche di comprensione e consistenza sulle informazioni che si stanno
raccogliendo. Questo può essere fatto attraverso esempi (generali e relativi a casi simili) oppure
richiedendo definizioni e classificazioni precise. È inoltre molto importante in questa fase cercare di
individuare gli aspetti essenziali rispetto a quelli marginali e procedere per raffinamenti successivi.
Partendo quindi dai principali aspetti del problema allo studio, dei quali si ha inizialmente una
conoscenza solo parziale, si procede cercando di acquisire via via maggiori dettagli.
Come abbiamo già accennato, la specifica dei requisiti raccolti avviene spesso, almeno in prima
battuta, facendo uso di descrizioni in linguaggio naturale. Sappiamo bene però che il linguaggio
naturale è fonte di ambiguità e fraintendimenti. È molto importante quindi effettuare una profonda
analisi del testo che descrive le specifiche per filtrare le eventuali inesattezze e i termini ambigui
presenti.
Alcune regole generali per ottenere una specifica dei requisiti più precisa e senza ambiguità sono le
seguenti:
• Scegliere il corretto livello di astrazione. È bene evitare l’utilizzo di termini troppo generici o
troppo specifici che rendono poco chiaro un concetto.
• Standardizzare la struttura delle frasi. Nella specifica dei requisiti è preferibile utilizzare
sempre lo stesso stile sintattico. Ad esempio, “per <dato> rappresentiamo <proprietà>” per la
descrizione dei dati e “se <condizione> allora <azione1> altrimenti <azione2> per descrivere le
azioni.
• Evitare frasi contorte. Le definizioni devono essere semplici e chiare.
• Individuare sinonimi/omonimi e unificare i termini. I sinonimi indicano termini diversi con
lo stesso significato; gli omonimi indicano termini uguali con diversi significati. Queste
situazioni possono generare ambiguità e vanno chiarite: nel caso di sinonimi, unificando i
termini, nel caso di omonimi, utilizzando termini diversi o specificandoli meglio.
• Rendere esplicito il riferimento tra termini. Può succedere che l’assenza di un contesto di
riferimento renda alcuni concetti ambigui: in questi casi bisogna esplicitare il riferimento tra
termini.
• Costruzione di un glossario dei termini. È molto utile, per la comprensione e precisazione dei
termini usati, definire un glossario che, per ogni termine, contenga: una breve descrizione,
possibili sinonimi e altri termini contenuti nel glossario con i quali esiste un legame logico.
Dopo aver individuato le varie ambiguità e le imprecisioni, esse vanno eliminate sostituendo i
termini non corretti con i termini più adeguati. In caso di dubbio, è necessario intervistare
nuovamente colui che ha fornito il dato o consultare la documentazione relativa. A questo punto si
possono riscrivere le specifiche apportando le modifiche proposte.
Naturalmente, accanto alle specifiche sui dati, vanno raccolte le specifiche sulle operazioni
(inserimenti, consultazioni, aggiornamenti, stampe, ecc.) da effettuare su questi dati. Bisogna
cercare di utilizzare la medesima terminologia usata per i dati (possiamo per questo fare riferimento
al glossario dei termini) e informarci anche sulla frequenza con la quale le varie operazioni vengono
eseguite. Come vedremo, la conoscenza di questa informazione sarà determinante nella fase di
progettazione logica.
I&T Informatica e Telecomunicazioni SpA
11
Metodologia di progettazione database relazionali
Dopo questa strutturazione dei requisiti, siamo pronti ad avviare la prima fase della progettazione
che consiste nella costruzione di uno schema concettuale in grado di descrivere in maniera adeguata
le specifiche dei dati raccolte. A tal fine noi usiamo il modello Entità-Relazione.
2.2
Modello Entità-Relazione
Lo scopo del modello Entity-Relationship (Entità-Relazione E-R) è quello di permettere la
descrizione dello schema concettuale di una situazione reale senza preoccuparsi dell’efficienza o
della progettazione del database fisico, che ci si aspetta invece nella maggior parte dei modelli
fisici. Di solito si pensa che lo schema entità-relazione così costruito sia poi tradotto in uno schema
logico di un modello logico dei dati, ad esempio quello relazionale, che al momento è il più diffuso.
Di seguito sono descritti i costrutti che il modello mette a disposizione per esprimere la realtà di
interesse in maniera formale e facile da comprendere, e che prescinde dai criteri di organizzazione
dei dati negli elaboratori.
Entità
Il modello entità-relazione, prevede come prima attività della progettazione concettuale, la
individuazione delle entità.
Una entità è qualcosa che esiste ed è distinguibile: possiamo cioè riconoscere un’entità tra le altre.
Ad esempio ogni persona è un’entità, così come ogni automobile.
Set di entità
Un gruppo composto da entità tutte “simili” forma un set di entità. Il termine “entità simili” non è
definito in modo preciso e si possono stabilire infinite proprietà diverse con cui definire set di
entità.
Nella progettazione del modello concettuale di un database, la scelta dei set di entità, è una
operazione fondamentale così come è importante individuare tutte le proprietà caratteristiche di un
set di entità che vengono descritte mediante gli attributi. Dalla “somiglianza”, quindi, nasce la
necessità dell’individuazione di un insieme di caratteristiche comuni a tutti gli elementi del set di
entità.
Il set di entità è un concetto a livello di schema, mentre il corrispondente concetto a livello di
istanza è il relativo sottoinsieme corrente di tutti gli elementi del dato set di entità nel database.
Lo schema entità-relazione ha una rappresentazione grafica che permette di avere immediatamente
la visione globale dello schema concettuale del database. La rappresentazione grafica che si ottiene,
a volte, invece di schema, viene chiamata diagramma entità-relazione (Entity-Relationship
Diagram – ERD). In questa rappresentazione grafica si usa una convenzione per rappresentare i vari
oggetti. I set di entità vengono rappresentate con dei rettangoli con il nome del set di entità
all’interno.
Attributi e chiavi
Come già detto, i set di entità possiedono delle proprietà, chiamate attributi, le quali associano ad
ogni entità del set un valore appartenente al dominio dei possibili valori per quell’attributo. Di solito
il dominio sarà un insieme di interi, numeri reali, stringhe di caratteri, valori booleani ma anche
immagini, audio e video come nei più recenti database multimediali.
La scelta degli attributi caratteristici per i set di entità è un punto abbastanza critico nell’ideare lo
schema concettuale di un database. Tra tutti gli attributi di un particolare set di entità ne va scelto
uno o un insieme, i cui valori identificano in modo univoco ogni entità del set. Questo attributo o
insieme di attributi è chiamato chiave per quel dato set. In linea di principio ogni set di entità
possiede una chiave soddisfacendo la richiesta che ogni entità sia distinguibile da ogni altra. Ma se
I&T Informatica e Telecomunicazioni SpA
12
Metodologia di progettazione database relazionali
per un set di entità scegliamo un insieme di attributi tra i quali non si possa individuare una chiave,
non saremo in grado di distinguere una entità dall’altra. Però è possibile fornire un codice
identificativo arbitrario da usare come chiave.
La rappresentazione grafica degli attributi è un’ellisse con il nome dell’attributo scritto all’interno e
si collega con il rispettivo set di entità con dei segmenti (non orientati). Agli attributi che fanno
parte della chiave per il rispettivo set, viene aggiunta una sottolineatura al nome. Nel caso speciale
di set di entità con un singolo attributo, a volte si identifica il set con l’attributo stesso, chiamando il
set col il nome dell’attributo. In tal caso, invece che con un rettangolo, il set di entità è
rappresentato con un’ellisse collegata a qualunque relazione con cui sia coinvolto il set di entità.
Relazioni
Le dipendenze o associazioni di interesse informativo tra i dati da rappresentare vengono espresse
nel modello entity-relationship mediante relazioni tra le corrispondenti entità. Le relazioni dello
stesso tipo compongono l’insieme di relazioni (relation set) tra i due insiemi di entità.
Per ottenere un modello adeguato del mondo reale, spesso è necessario classificare le relazioni a
seconda del numero di entità associabili tra un set di entità e l’altro.
Relazioni uno-a-uno
La relazione più semplice, e più rara, fra le relazioni che collegano due set è quella uno-a-uno, cioè
che ogni entità di un set è legata con al più un elemento dell’altro set.
Le relazioni vengono rappresentate graficamente con dei rombi e vengono collegati ai propri set di
entità con dei segmenti orientati o non a seconda del tipo di relazione. Nel caso di relazione uno-auno il segmento è orientato in entrambi i versi. Un’alternativa all’utilizzo dei segmenti orientati è
quella di mettere sui segmenti che collegano la relazione ai set dei numeri che indicano la
cardinalità della relazione.
Un esempio di relazione 1:1 è la relazione tra nazioni e capitali. Ogni nazione ha un’unica capitale,
ad una capitale corrisponde un’unica nazione.
Relazione uno-a-molti
Due set E1 ed E2 sono in relazione uno-a-molti da E1 ad E2 se una entità nel set E1 è associata con
zero o più entità nel set E2, ma ogni entità in E2 è associata con al più una entità in E1.
Un esempio di relazione 1:N è la relazione tra madri e figli. Una madre può avere più figli, mentre
ad un figlio corrisponde un’unica madre.
La rappresentazione grafica della relazione 1:N è un rombo con segmenti che uniscono i set di
entità coinvolti e orientati soltanto nella direzione del set di entità con cardinalità uno.
Relazione molti-a-molti
Due set E1 ed E2 sono in relazione molti-a-molti se ad ogni elemento di E1 possono corrispondere
più elementi di E2 e viceversa.
Sulle relazioni molti-a-molti è da notare il fatto che non esistono efficienti strutture dati per la loro
implementazione, spesso è richiesto di scomporre tali relazioni con varie relazioni molti-a-uno.
Un esempio di relazione N:M è la relazione tra corsi e studenti. Un corso è seguito da più studenti, e
lo stesso studente segue più corsi.
La rappresentazione grafica della relazione N:M è un rombo con segmenti non orientati che
uniscono i set di entità coinvolti.
Gerarchia ISA
Un tipo particolare di relazione è quella chiamata ISA o sottotipo/supertipo. Diciamo che A isa B,
cioè “A è un B” (A è il sottotipo e B è il supertipo), se il set di entità B è una generalizzazione di
entità del set A, o in modo equivalente se A è un tipo particolare (specializzazione) di B. Lo scopo
I&T Informatica e Telecomunicazioni SpA
13
Metodologia di progettazione database relazionali
principale per dichiarare le relazioni isa tra i set di entità A e B è che in tal modo A eredita gli
attributi di B, ma avrà anche attributi che non avrebbero necessariamente significato per gli
elementi di B che non siano anche elementi di A.
La rappresentazione grafica della gerarchia isa è un rombo con etichetta isa con segmenti orientati
nella direzione del set supertipo.
Un esempio di relazione isa è quello di una società che può avere un set di entità Dipendenti con
attributi Matricola, Nome e Stipendio. Se la società fosse una squadra di calcio, alcuni dei
dipendenti, i Giocatori, avrebbero altri importanti attributi come Ruolo (portiere, difensore,
attaccante), che non riguarderebbero gli altri dipendenti. Il modo migliore per progettare questo
schema, è quello di avere un altro set di entità, Giocatori, legato con la relazione isa al set
Dipendenti. Gli attributi (anche le chiavi) che appartengono a Dipendenti (Matricola, Nome,
Stipendio), verrebbero ereditati da Giocatori, ma solo Giocatori avrebbe un attributo come Ruolo.
Attributi delle relazioni
Il modello entità-relazione prevede che anche gli insiemi delle relazioni abbiano degli attributi che
ne specificano le caratteristiche. Tali attributi vengono rappresentati graficamente con una ellisse,
cioè come per gli attributi di un set di entità, con un segmento orientato nel verso che va dal rombo
all’ellisse.
2.3
Criteri generali di rappresentazione
Prima di affrontare le metodologie di progetto, è conveniente stabilire alcune criteri generali per
tradurre una specifica informale in un costrutto del modello Entità-Relazione. Va precisato che
spesso non esiste una rappresentazione univoca di un insieme di specifiche, perché la stessa realtà
può essere rappresentata in modi differenti e non comparabili. Comunque, quando ci si trova
davanti a diverse possibilità, è utile avere delle indicazioni sulle scelte più opportune. Nel caso della
progettazione concettuale conviene, in buona sostanza, seguire le “regole concettuali” del modello
E-R.
• Se un concetto ha proprietà significative e/o descrive classi di oggetti con esistenza autonoma, è
opportuno rappresentarlo con una entità.
• Se un concetto ha una struttura semplice e non possiede proprietà rilevanti associate, è
opportuno rappresentarlo con un attributo di un altro concetto a cui si riferisce.
• Se sono state individuate due (o più) entità e nei requisiti compare un concetto che le associa,
questo concetto può essere rappresentato da una relazione.
• Se uno o più concetti risultano essere casi particolari di un altro, è opportuno rappresentarli
facendo uso di una generalizzazione.
I criteri visti hanno validità generale, sono cioè indipendenti dalla strategia di progettazione scelta.
Come vedremo in seguito, in ogni strategia esiste prima o poi un momento in cui va presa la
decisione sul costrutto da scegliere per rappresentare un certa specifica.
2.4
Documentazione dei diagrammi Entità-Relazione
Gli schemi Entità-Relazione ben congeniati sono in genere autoesplicativi e quindi facilmente
comprensibili. È buona norma però corredare uno schema con una documentazione di supporto, che
I&T Informatica e Telecomunicazioni SpA
14
Metodologia di progettazione database relazionali
possa servire a facilitare l’interpretazione dello schema stesso e a descrivere proprietà dei dati
rappresentati che non possono essere espressi direttamente dai costrutti del modello.
I concetti rappresentati in uno schema possono essere documentati facendo uso di uno dizionario
dei dati. Esso è composto da due tabelle: la prima descrive le entità dello schema (dizionario dei
dati delle entità) con il nome, una descrizione informale, l’elenco degli attributi e gli identificatori,
l’altra descrive le relazioni (dizionario dei dati delle relazioni) con il nome, una descrizione
informale, le entità coinvolte, la cardinalità e gli attributi.
L’uso del dizionario dei dati è particolarmente importante nei casi in cui lo schema è complesso
(molti concetti collegati in maniera complicata) e risulta pesante aggiungere allo schema tutti gli
attributi di entità e relazioni.
Inoltre, esiste un altro aspetto molto importante di uno schema E-R che va documentato: la presenza
di vincoli di integrità sui dati che non possono essere rappresentati con i costrutti del modello. Ad
esempio un vincolo non esprimibile direttamente potrebbe essere il fatto che un impiegato non può
avere uno stipendio maggiore del direttore del dipartimento al quale afferisce. In questi casi, la cosa
migliore è di aggiungere allo schema delle annotazioni (una tabella dei vincoli di integrità sui dati)
che completano la descrizione delle proprietà associate ai concetti presenti nello schema e non
esprimibili altrimenti.
2.5
Utilità dei diagrammi Entità-Relazione
Perché dovremmo essere interessati al modello dati di un sistema? In primo luogo perché le
strutture di dati e le relazioni possono essere così complesse che vogliamo evidenziarle ed
esaminarle indipendentemente dall’elaborazione che avrà luogo. In effetti, ciò è particolarmente
vero quando il modello del sistema viene mostrato agli utenti esecutivi di livello superiore in
un’organizzazione (ad esempio, i vicepresidenti o direttori di reparto). Tali utenti sono spesso
interessati ai dati: quali dati servono per condurre gli affari? In che modo i dati sono correlati ad
altri dati? Chi possiede i dati? A chi è consentito l’accesso ai dati?
La risposta ad alcune di queste domande – ad esempio, l’accesso ai dati e l’identificazione dei
proprietari – è fornita dai DA (Data Administrator). Ogni volta che si inizia a costruire un nuovo
sistema informativo, si ha bisogno di parlare con queste persone in modo da poter coordinare le
proprie informazioni sul sistema col loro modello di informazioni globale a livello aziendale.
• Il diagramma entità-relazione è un utile strumento per svolgere la conversazione col gruppo dei
DA.
Si dovrà altresì conversare con il gruppo dei DBA (Data Base Administrator), situato solitamente
nel reparto di elaborazione dati (mentre i DA non vi appartengono necessariamente), il cui compito
è quello di garantire che i database computerizzati siano organizzati, gestiti e controllati
efficacemente. Quindi essi costituiscono spesso la squadra di implementazione che ha la
responsabilità di prendere un modello essenziale (cioè, un modello indipendente dalla tecnologia
specifica) e convertirlo in un progetto di database fisico efficace ed efficiente per Oracle, Informix,
DB2 o qualche altro sistema di gestione di database.
• Il diagramma di entità-relazione è un efficace strumento di modellamento per comunicare col
gruppo di DBA.
In base alle informazioni presentate dal diagramma E-R, il gruppo di amministrazione del database
può iniziare a determinare i tipi di chiave o di indici o di puntatori che servono per accedere
efficientemente ai record del database.
I&T Informatica e Telecomunicazioni SpA
15
Metodologia di progettazione database relazionali
Quindi il modello dei dati fornisce, oltre alla rappresentazione dei dati del sistema che si vuole
gestire, un utile strumento di conversazione con gli altri gruppi di lavoro che interagiscono in un
progetto.
In realtà fornendo rappresentazioni facili da comprendere dei dati coinvolti da un’applicazione, gli
schemi E-R possono essere utilizzati anche indipendentemente dallo scopo finale di realizzare
un’applicazione.
Esistono diversi esempi di possibile uso degli schemi concettuali che prescindono dall’attività di
progettazione:
• gli schemi E-R possono essere per esempio utilizzati a scopo documentativo, perché sono
facilmente comprensibili anche da non specialisti di base di dati;
• possono essere utilizzati per descrivere e analizzare un sistema informatico già esistente e, nel
caso di sistema costituito da diversi sottoinsiemi, c’è il vantaggio di poter rappresentare le varie
componenti con un linguaggio astratto e quindi unificante;
• possono essere infine utilizzati per comprendere, in caso di modifica dei requisiti di una
applicazione, su quali porzioni di sistema si deve operare e in cosa consistono le modifiche da
effettuare.
2.6
Strategie di progetto
Lo sviluppo di uno schema concettuale a partire dalle sue specifiche può essere considerato a tutti
gli effetti un processo di ingegnerizzazione e, come tale, risultano ad esso applicabili le comuni
strategie di progetto utilizzate anche in altre discipline. Vediamo quali sono queste strategie con
specifico riferimento alla modellazione di una base di dati.
2.6.1 Strategia top-down
In questa strategia, lo schema concettuale viene prodotto mediante una serie di raffinamenti
successivi a partire da uno schema iniziale che descrive tutte le specifiche con pochi concetti molto
astratti. Lo schema viene poi via via raffinato mediante opportune trasformazioni che aumentano il
dettaglio dei vari concetti presenti. Si procede definendo vari piani di raffinamento del processo:
ognuno di questi piani contiene uno schema che descrive le medesime informazioni a un diverso
livello di dettaglio. Con questa strategia quindi, tutti gli aspetti presenti nello schema finale sono
presenti, in linea di principio, a ogni livello di raffinamento.
Nel passaggio da un livello di raffinamento ad un altro, lo schema viene modificato facendo uso di
alcune trasformazioni elementari che vengono denominate primitive di trasformazione top-down.
Queste primitive operano su un singolo concetto dello schema e lo trasformano in una struttura più
complessa in grado di descrivere il concetto di partenza con maggiore dettaglio. Di seguito sono
elencate queste primitive.
• Trasformazione da entità a relazione tra entità. Si applica quando si comprende che una
entità descrive due concetti diversi legati logicamente tra di loro.
• Trasformazione da entità a generalizzazione. Si applica quando si comprende che una entità è
composta da sotto-entità distinte.
• Trasformazione da relazione a insieme di relazioni. Si applica quando si comprende che una
relazione descrive in realtà due relazioni diverse tra le medesime entità.
I&T Informatica e Telecomunicazioni SpA
16
Metodologia di progettazione database relazionali
• Trasformazione da relazione a entità con relazioni. Si applica quando si comprende che una
relazione descrive un concetto con esistenza autonoma ai fini dell’applicazione.
• Introduzione di attributi su entità. Si applica per aggiungere proprietà (attributi) a entità.
• Introduzione di attributi su relazioni. Si applica per aggiungere attributi a relazioni.
Il vantaggio della strategia top-down è che il progettista può descrivere inizialmente tutte le
specifiche dei dati trascurandone i dettagli, per poi entrare nel merito di un concetto alla volta (si
osservi che le primitive di trasformazione agiscono su singoli concetti). Questo però è possibile solo
quando si possiede, sin dall’inizio, una visione globale e astratta di tutte le componenti del sistema,
ma ciò è estremamente difficile quando si ha a che fare con applicazioni di una certa complessità.
2.6.2 Strategia bottom-up
In questa strategia, le specifiche iniziali sono suddivise in componenti via via sempre più piccole,
fino a quando queste componenti descrivono un frammento elementare della realtà di interesse. A
questo punto, le varie componenti vengono rappresentate da semplici schemi concettuali che
possono consistere anche di un singolo concetto. I vari schemi così ottenuti vengono poi fusi fino a
giungere, attraverso una completa integrazione di tutte le componenti, allo schema concettuale
finale. Questo procedimento consiste, quindi, di una fase di decomposizione delle specifiche, di una
successiva fase di rappresentazione delle componenti di base e di una fase finale di integrazione
degli schemi elementari. A differenza della strategia top-down, con questa strategia i vari concetti
presenti nello schema finale vengono via via introdotti durante le varie fasi.
Anche in questo caso, lo schema finale si ottiene attraverso alcune trasformazioni elementari che
vengono denominate primitive di trasformazione bottom-up. Queste primitive introducono nello
schema nuovi concetti non presenti precedentemente e in grado di descrivere aspetti della realtà di
interesse che non erano ancora stati rappresentati. Vediamo queste primitive.
• Generazione di entità. Si applica quando si individua nelle specifiche una classe di oggetti con
proprietà comuni.
• Generazione relazione. Si applica quando si individua nelle specifiche un legame logico tra
due entità.
• Generazione di una generalizzazione. Si applica quando si individua nelle specifiche un
legame tra diverse entità riconducibili a una generalizzazione.
• Aggregazione di attributi su entità. Si applica quando, a partire da una serie di attributi, si
individua una entità che può essere vista come aggregazione di tali attributi.
• Aggregazione di attributi su relazione. Si applica in maniera simile alla trasformazione
precedente, quando si individua una relazione che può essere vista come aggregazione di alcuni
attributi.
Il vantaggio della strategia bottom-up è che si adatta ad una decomposizione del problema in
componenti più semplici, facilmente individuabili, il cui progetto può essere affrontato anche da
progettisti diversi. È quindi un tipo di strategia che si presta bene a lavori svolti in collaborazione o
suddivisi all’interno di un gruppo. Lo svantaggio di questa strategia è invece il fatto che richiede
delle operazioni di integrazione di schemi concettuali diversi che, nel caso di schemi complessi,
presentano quasi sempre grosse difficoltà.
I&T Informatica e Telecomunicazioni SpA
17
Metodologia di progettazione database relazionali
2.6.3 Strategia inside-out
Questa strategia può essere vista come un caso particolare della strategia bottom-up. Si individuano
inizialmente solo alcuni concetti importanti e poi si procede, a partire da questi, a “macchia d’olio”.
Si rappresentano cioè prima i concetti concettualmente più vicini ai concetti iniziali, per poi
muoversi verso quelli più lontani attraverso una “navigazione” tra le specifiche.
Questa strategia ha il vantaggio di non richiede passi di integrazione. D’altro canto è necessario, di
volta in volta, esaminare tutte le specifiche per individuare concetti non ancora rappresentati e
descrive i nuovi concetti nel dettaglio. Non è quindi possibile procedere per livelli di astrazione
come avviene nella strategia top-down.
2.6.4 Stategia mista
La strategia mista cerca di combinare i vantaggi della strategia top-down con quelli della strategia
bottom-up. Il progettista suddivide i requisiti in componenti separate, come nella strategia bottomup, ma allo stesso tempo definisce uno schema scheletro contenente, a livello astratto, i concetti
principali dell’applicazione. Questo schema scheletro fornisce una visione unitaria, sia pure astratta,
dell’intero progetto e favorisce le fasi di integrazione degli schemi sviluppati separatamente.
Definito lo schema scheletro possiamo procedere considerando, anche separatamente, i concetti
principali e proseguire per raffinamenti successivi (procedendo quindi in maniera top-down) oppure
estendere il (sotto)schema con concetti non ancora rappresentati (procedendo quindi in maniera
bottom-up).
La strategia mista è probabilmente la più flessibile tra le strategie viste perché si adatta bene a
esigenze contrapposte: quella di suddividere un problema complesso in sottoproblemi e quella di
procedere per raffinamenti successivi. In effetti, questa strategia ingloba anche la strategia insideout che, che come abbiamo detto, è solo un caso particolare della strategia bottom-up. È infatti
abbastanza naturale, durante uno sviluppo bottom-up di una sottocomponente di un progetto,
procedere a macchia d’olio per rappresentare le specifiche della nostra base di dati non ancora
rappresentate.
C’è anche da dire che, in quasi tutti i casi pratici di una certa complessità, la strategia mista è
l’unica che si può effettivamente adottare perché, come abbiamo detto precedentemente, è spesso
necessario cominciare la progettazione quando non sono ancora disponibili tutti i dati e, dei dati
noti, abbiamo spesso delle conoscenze a livello di dettaglio non omogenei.
2.7
Qualità di uno schema concettuale
Nella costruzione di uno schema concettuale vanno comunque garantite alcune proprietà generali
che uno schema concettuale di buona qualità deve possedere. Analizziamo le qualità più importanti
e vediamo come è possibile verificare, durante la progettazione, queste qualità.
Correttezza
Uno schema concettuale è corretto quando utilizza propriamente i costrutti messi a disposizione dal
modello concettuale di riferimento. Come avviene nei linguaggi programmativi, gli errori possono
essere sintattici o semantici. I primi riguardano un uso non ammesso di costrutti come, per esempio,
una generalizzazione tra relazioni invece che tra entità. I secondi riguardano invece un uso di
costrutti che non rispettano la loro definizione. Per esempio, l’uso di una relazione per descrivere il
fatto che un’entità è specializzazione di un’altra. La correttezza di uno schema si può verificare per
ispezione, confrontando i concetti presenti nello schema in via di costruzione con le specifiche e
con le definizioni dei costrutti del modello concettuale usato.
I&T Informatica e Telecomunicazioni SpA
18
Metodologia di progettazione database relazionali
Completezza
Uno schema concettuale è completo quando rappresenta tutti i dati di interesse e quando tutte le
operazioni possono essere eseguite a partire dai concetti descritti nello schema. La completezza di
uno schema si può verificare controllando che tutte le specifiche sui dati siano rappresentate da
qualche concetto presente nello schema che stiamo costruendo, e che tutti i concetti coinvolti in una
operazione presente nelle specifiche siano raggiungibili “navigando” attraverso lo schema.
Leggibilità
Uno schema concettuale è leggibile quando rappresenta i requisiti in maniera naturale e facilmente
comprensibili. Per garantire questa proprietà è necessario rendere lo schema autoesplicativo, per
esempio, mediante una scelta opportuna dei nomi da dare ai concetti. La leggibilità dipende anche
da criteri puramente estetici: la comprensione di uno schema è per esempio facilitata se tracciamo il
relativo diagramma su una griglia nella quale i vari costrutti hanno le stesse dimensioni. Alcuni
suggerimenti per rendere lo schema più leggibile sono i seguenti:
• disporre i costrutti in una griglia scegliendo come elementi centrali quelli con più legami
(relazioni) con gli altri;
• tracciare solo linee perpendicolari e cercare di minimizzare le intersezioni (si noti che le
intersezioni si possono evitare se lo schema è un grafo planare);
• disporre le entità che sono padri di generalizzazioni sopra le relative entità figlie.
La leggibilità di uno schema si può verificare facendo delle prove di comprensione con gli utenti.
Minimalità
Uno schema è minimale quando tutte le specifiche sui dati sono rappresentate una sola volta nello
schema. Uno schema quindi non è minimale quando esistono delle ridondanze, ovvero concetti che
possono essere derivati da altri. Una fonte di ridondanza tipica in uno schema E-R è la presenza di
cicli dovuta alla presenza di relazioni e/o generalizzazioni. A differenza delle altre proprietà
comunque, non sempre una ridondanza è indesiderata, ma può nascere da precise scelte progettuali.
In ogni caso però, queste situazioni vanno documentate. La minimalità di uno schema si può
verificare per ispezione, controllando se esistono concetti che possono essere eliminati dallo schema
che stiamo costruendo senza inficiare la sua completezza. Per quanto detto, si deve prestare
particolare attenzione ai cicli presenti nello schema.
Nel prossimo paragrafo illustreremo come la verifica delle qualità di uno schema concettuale
appena viste, possa essere inglobata in una metodologia di progettazione generale.
2.8
Metodologia generale
In quest’ultimo paragrafo vogliamo cercare di tirare le somme su quanto detto relativamente alla
progettazione concettuale di base di dati. Per quel che riguarda le strategie di progetto viste, va
precisato che, in pratica, non accade quasi mai che un progetto proceda sempre in maniera topdown o bottom-up. Indipendentemente dalla strategia scelta, nelle situazioni reali capita infatti di
modificare lo schema in via di costruzione sia con trasformazioni che raffinano un concetto presente
(e quindi tipicamente top-down) sia con trasformazioni che aggiungono un concetto non presente (e
quindi tipicamente bottom-up). Presentiamo quindi una metodologia per la progettazione
concettuale con il modello E-R con riferimento alla strategia mista che, come abbiamo detto, fa uso
delle tecniche su cui si basano le altre e le comprende come caso particolare. La metodologia è
composta dai passi seguenti.
I&T Informatica e Telecomunicazioni SpA
19
Metodologia di progettazione database relazionali
1) Analisi dei requisiti
a) Costruzione di un glossario dei termini;
b) Analizzare i requisiti ed eliminare le ambiguità presenti;
c) Raggruppare i requisiti in insiemi omogenei;
2) Passo base
a) Individuare i concetti più rilevanti e rappresentarli in uno schema scheletro;
3) Passo di decomposizione (da effettuare se opportuno o necessario)
a) Effettuare una decomposizione dei requisiti con riferimento ai concetti presenti nello
schema scheletro;
4) Passo iterativo: da ripetere, per tutti i sotto-schemi (se presenti), finché ogni specifica è stata
rappresentata.
a) Raffinare i concetti presenti sulla base delle loro specifiche;
b) Aggiungere nuovi concetti allo schema per descrivere specifiche non ancora
descritte;
5) Passo di integrazione (da effettuare se sono presenti diversi sotto-schemi)
a) Integrare i vari sottoschemi in uno schema generale facendo riferimento allo schema
scheletro;
6) Analisi di qualità
a) Verificare la correttezza dello schema ed eventualmente ristrutturare lo schema;
b) Verificare la completezza dello schema ed eventualmente ristrutturare lo schema;
c) Verificare la minimalità, documentare le ridondanze ed eventualmente ristrutturare lo
schema;
d) Verificare la leggibilità dello schema ed eventualmente ristrutturare lo schema.
Si osservi che se il passo 3) e il passo 5) non vengono effettuati e nel passo 4) si procede solo
mediante raffinamenti (azione a)), abbiamo una strategia top-down pura. Viceversa se il passo base
non viene effettuato e nel passo 5) vengono solo aggiunti nuovi concetti, ci stiamo muovendo
secondo la strategia bottom-up pura. Infine, nelle trasformazioni bottom-up, si può procedere a
“macchia d’olio”, cioè secondo la strategia inside-out. Si noti inoltre che nell’ultimo passo c’è una
verifica finale della completezza, sebbene la verifica di tale proprietà viene fatta anche a ogni
esecuzione del passo iterativo.
Concludiamo questa presentazione con una breve riflessione sulla fase finale della metodologia
presentata, quello dell’analisi della qualità del progetto. Questo ultimo passo costituisce in effetti un
importante momento di verifica del risultato dell’intera attività di progettazione, nel quale è spesso
necessario dover effettuare delle ristrutturazioni per rimediare a “errori” fatti nelle fasi precedenti.
Bisogna porre, in questa fase, particolare attenzione a concetti dello schema aventi proprietà
particolari: per esempio, entità senza attributi, insiemi di concetti che formano cicli, gerarchie di
generalizzazione troppo complesse o porzioni dello schema particolarmente contorte. Come
accennato in precedenza, non è detto che questa analisi porti necessariamente a delle
ristrutturazioni, ma solo a una riorganizzazione dello schema che ne aumenta la leggibilità. È
I&T Informatica e Telecomunicazioni SpA
20
Metodologia di progettazione database relazionali
comunque molto importante garantire che alla fine, tutte le caratteristiche dello schema concettuale
prodotto, corrispondono a ben ponderate scelte progettuali.
I&T Informatica e Telecomunicazioni SpA
21
Metodologia di progettazione database relazionali
3
Progettazione logica
L’obiettivo della progettazione logica è quello di costruire uno schema logico in grado di
descrivere, in maniera corretta ed efficace, tutte le informazioni contenute nello schema EntitàRelazione prodotto nella fase di progettazione concettuale. Diciamo subito che non si tratta di una
semplice traduzione da un modello ad un altro perché, prima di passare allo schema logico, lo
schema Entità-Relazione va strutturato per soddisfare due esigenze: quello di “semplificare” la
traduzione e quella di “ottimizzare” il progetto. La semplificazione dello schema si rende necessaria
perché non tutti i costrutti del modello Entità-Relazione hanno una traduzione naturale nei modelli
logici. Per esempio, mentre un’entità può essere facilmente rappresentata da una relazione nel
modello relazionale (avente gli stessi attributi dell’entità), per le generalizzazioni esistono varie
alternative. Inoltre, mentre la progettazione concettuale ha come obiettivo la rappresentazione
accurata e naturale dei dati di interesse dal punto di vista del significato che hanno
nell’applicazione, la progettazione logica costituisce la base per l’effettiva realizzazione
dell’applicazione e deve tener conto, per quanto possibile, delle sue prestazioni: questa necessità
può portare a una ristrutturazione dello schema concettuale che renda più efficiente l’esecuzione
delle operazioni previste. Pertanto, è necessario prevedere sia un’attività di riorganizzazione, sia
un’attività di traduzione (dal modello concettuale a quello logico). Poiché la riorganizzazione può
essere in buona misura discussa indipendentemente dal modello logico, è utile di solito articolare la
progettazione logica in due fasi, come schematizzato in figura 3.1.
Schema
E-R
Carico
applicativo
Modello
logico
Progettazione logica
Ristrutturazione
dello schema E-R
Schema E-R ristrutturato
Traduzione verso
un modello logico
Schema logico
Vincoli
d’integrità
Schema
logico
Documentazione
di supporto
Fig. 3.1 Progettazione logica di base di dati
• Ristrutturazione dello schema Entità-Relazione: è una fase indipendente dal modello logico
scelto e si basa su criteri di ottimizzazione dello schema e di semplificazione della fase
successiva;
I&T Informatica e Telecomunicazioni SpA
22
Metodologia di progettazione database relazionali
• Traduzione verso il modello logico: fa riferimento ad uno specifico modello logico (nel nostro
caso il modello relazionale) e può includere una ulteriore ottimizzazione che si basa sulle
caratteristiche del modello logico stesso.
I dati di ingresso della prima fase sono lo schema concettuale prodotto nella fase precedente e il
carico applicativo previsto, in termini di dimensione dei dati e caratteristiche delle operazioni. In
risultato che si ottiene è uno schema E-R ristrutturato, che non è più uno schema concettuale nel
senso stretto del termine, in quanto costituisce una rappresentazione dei dati che tiene conto degli
aspetti realizzativi. Questo schema e il modello logico scelto costituiscono i dati di ingresso della
seconda fase, che produce lo schema logico della nostra base di dati. In questa seconda fase è
possibile effettuare verifiche della qualità dello schema (la normalizzazione) ed eventuali ulteriori
ottimizzazioni mediante tecniche basate sulle caratteristiche del modello logico.
Come premessa alla prima fase della progettazione logica parleremo degli strumenti e delle tecniche
che si possono usare per analizzare le prestazioni di una base di dati facendo riferimento al suo
schema concettuale.
3.1
Analisi delle prestazioni su schemi E-R
Uno schema E-R può essere modificato per ottimizzare gli indici di prestazione del progetto.
Parliamo di indici di prestazione e non di prestazioni perché, in realtà, le prestazioni di una base di
dati non sono valutabili in maniera precisa in sede di progettazione logica, in quanto dipendenti
anche da parametri fisici, dal sistema di gestione di basi di dati che verrà utilizzato e da altri fattori
difficilmente prevedibili in questa fase. È comunque possibile, facendo uso di alcune
schematizzazioni, effettuare studi di massima dei due parametri che generalmente regolano le
prestazioni dei sistemi software:
• costo di una operazione: viene valutato in termini di numero di occorrenze di entità e
associazioni (relazione del modello E-R) che mediamente vanno visitate per rispondere a una
operazione sulla base dei dati;
• occupazione di memoria: viene valutato in termini dello spazio di memoria (misurato in genere
in byte) necessario per memorizzare i dati descritti dallo schema.
Per studiare questi parametri abbiamo bisogno di conoscere, oltre allo schema, le seguenti
informazioni.
•
Volume dei dati. Ovvero:
♦
♦
•
numero (medio) di occorrenze di ogni entità e associazione dello schema,
dimensione di ciascun attributo (di entità o associazione)
Caratteristiche delle operazioni. Ovvero:
♦
♦
♦
tipo dell’operazione (interattiva o batch),
frequenza (numero medio di esecuzioni in un certo intervallo di tempo),
dati coinvolti (entità e/o associazioni).
Il volume dei dati e le caratteristiche generali delle operazioni possono essere descritti facendo uso
di tabelle, dette tavole dei volumi, che riportano tutti i concetti dello schema (entità e associazioni)
con il volume previsto a regime. Mentre una tavola delle operazioni riporta, per ogni operazione, la
frequenza prevista e un simbolo che indica se l’operazione è interattiva o batch. Da notare che nella
I&T Informatica e Telecomunicazioni SpA
23
Metodologia di progettazione database relazionali
tavola dei volumi, il numero delle occorrenze delle associazioni uno a molti (e uno a uno) dipende
dal volume dell’entità che partecipa all’associazione con cardinalità massima pari a uno. Nel caso
invece di relazioni molti a molti, il volume delle associazioni dipende dal numero medio di
partecipazioni delle entità coinvolte.
Per ogni operazione, possiamo inoltre descrivere graficamente i dati coinvolti con uno schema di
operazione che consiste nel frammento dello schema E-R interessato dall’operazione, sul quale
viene assegnato il “cammino logico” (con delle frecce) da percorrere per accedere alle informazioni
di interesse.
Avendo a disposizione queste informazioni, è possibile fare una stima del costo di un’operazione
sulla base di dati contando il numero di accessi alle occorrenze di entità e relazioni necessario per
eseguire l’operazione. Tutto questo può essere riassunto in una tavola degli accessi che riporta il
concetto, il costrutto (entità o relazione), il numero degli accessi e il tipo dell’operazione (lettura,
scrittura). La specificazione del tipo dell’operazione è importante in quanto le operazioni di scrittura
sono più onerose di quelle di lettura e devono essere eseguite in modo esclusive e possono
richiedere l’aggiornamento di indici (strutture ausiliarie per l’accesso efficiente ai dati).
Questi strumenti di analisi possono essere utilizzati per prendere decisioni durante la
ristrutturazione di schemi E-R mediante la costruzione degli indici di prestazione.
3.2
Ristrutturazione di schemi E-R
La fase di ristrutturazione di uno schema E-R si può suddividere in una serie di passi da effettuare
in sequenza come mostrato in figura 3.2.
Schema
E-R
Carico
applicativo
Ristrutturazione dello
schema E-R
Analisi delle ridondanze
Eliminazione delle
generalizzazioni
Partizionamento /
Accorpamento di entità
e associazioni
Scelta degli
identificatori principali
Schema E-R ristrutturato
Fig. 3.2 Fasi di ristrutturazione della progettazione logica di base di dati
I&T Informatica e Telecomunicazioni SpA
24
Metodologia di progettazione database relazionali
• Analisi delle ridondanze. Si decide se eliminare o mantenere eventuali ridondanze presenti
nello schema. La ridondanza corrisponde alla presenza di un dato che può essere derivato da
altri dati. La decisione di mantenere o eliminare una ridondanza va presa confrontando il costo
di esecuzione delle operazioni che coinvolgono il dato ridondante e la relativa occupazione di
memoria, nei casi di presenza e assenza di ridondanza. A tale scopo vengono calcolati gli indici
di prestazione usando gli strumenti di valutazione visti in precedenza nei due casi, assenza e
presenza di ridondanza, e si decide sulla base dei valori che si ottengono.
• Eliminazione delle generalizzazioni. Tutte le generalizzazioni presenti nello schema vengono
analizzati e sostituite con altri costrutti supportati dal modello logico. Sostanzialmente esistono
tre tecniche di eliminazione delle gerarchie ISA:
♦
♦
♦
Accorpamento delle figlie della generalizzazione nel padre;
Accorpamento del padre della generalizzazione nelle figlie;
Sostituzione della generalizzazione con relazioni 1:1.
• Partizionamento/accorpamento di entità e associazioni. Si decide se è opportuno partizionare
concetti dello schema (entità e/o associazioni) in più concetti o, viceversa, accorpare concetti
separati in un unico concetto. Queste modifiche sono rivolte a garantire una maggiore efficienza
delle operazioni in base al seguente principio: gli accessi si riducono separando attributi di uno
stesso concetto che vengono acceduti da operazioni diverse e raggruppando attributi di concetti
diversi che vengono acceduti dalle medesime operazioni.
• Scelta degli identificatori primari. Si seleziona un identificatore per quelle entità che ne hanno
più di uno. Nei casi in cui esistono entità per le quali sono stati specificati più identificatori,
bisogna decidere quali di questi identificatori verrà utilizzato come chiave principale. I criteri di
decisione per questa scelta sono i seguenti:
♦
♦
♦
♦
Gli identificatori con valori nulli non possono essere principali (non garantiscono
l’accesso a tutte le occorrenze dell’entità corrispondente);
Un identificatore semplice (cioè composto da uno o da pochi attributi) è da preferire a
indentificatori complessi (le operazioni sono più efficienti e si hanno indici di dimensioni
ridotte);
Per gli stessi motivi del punto precedente un identificatore interno con pochi attributi è
preferibile ad un identificatore esterno che coinvolge diverse entità.
Un identificatore che viene utilizzato da molte operazioni per accedere alle occorrenze di
una entità è da preferire rispetto agli altri.
È comunque buona norma tenere traccia, in qualche maniera, degli identificatori non
selezionati come primari in questa fase e che vengono utilizzati da qualche operazione per
accedere ai dati. Per questi identificatori è, infatti, possibile definire, in fase di progettazione
fisica, strutture per l’accesso efficiente ai dati (indici).
3.3
Modello dati logico
Un modello dati a livello logico di progettazione è definito come un formalismo matematico
composto da due parti:
• una notazione per descrivere i dati,
• un insieme di operazioni per manipolare i dati.
I&T Informatica e Telecomunicazioni SpA
25
Metodologia di progettazione database relazionali
Un modello matematico dei dati consente l’utilizzo di linguaggi e metodologie formali per l’accesso
ai dati. In particolare le due metodologie su cui si basano i linguaggi di accesso ai dati di un
database relazionale sono l’algebra relazionale e il calcolo relazionale. In seguito verrà introdotta
la prima metodologia, in quanto costituisce la base del linguaggio SQL (Structured Query
Language), ormai affermato come standard nell’accesso ai database relazionali.
3.4
Modello dati relazionale
La rappresentazione dei dati nel modello logico relazionale è basata su un unico concetto
fondamentale, ovvero la relazione: questa va intesa in termini algebrici, e non va confusa con le
relazioni tra i dati del modello concettuale.
Il concetto di relazione algebrica è quello secondo la teoria degli insiemi, cioè un sottoinsieme del
prodotto cartesiano di una lista di domini. Non vogliamo qui entrare nei dettagli matematici e ci
limitiamo a dire che le relazioni possono essere rappresentate graficamente sotto forma tabellare.
Nella tabella che rappresenta la relazione algebrica, ogni riga è una tupla (o record) e a ogni
colonna corrisponde una componente (o campo). Alle colonne si danno spesso dei nomi e sono gli
attributi.
L’insieme dei nomi di attributi (delle colonne) di una relazione si chiama schema di relazione. Se
denotiamo con REL una relazione e il suo schema di relazione ha gli attributi A1, A2, … , Ak si scrive
spesso lo schema di relazione come:
REL(A1, A2, … , Ak)
L’insieme degli schemi di relazione usati per rappresentare informazioni viene chiamato schema di
database (relazionale), e i valori correnti delle corrispondenti relazioni formano un’istanza del
database o semplicemente il database (relazionale).
Nella definizione di relazione come insieme seguono due osservazioni fondamentali:
• in una tabella non possono esistere due righe uguali
• l’ordine tra le righe di una tabella non è significativo.
Da tali osservazioni deriva che è possibile, e necessario, individuare in ciascuna tabella un insieme
di attributi (colonne) in base alle quali identificare le singole righe, che rappresentano quindi una
chiave di accesso univoca alle informazioni contenute nella tabella stessa. Questo insieme di
colonne, definito in fase di ristrutturazione dello schema E-R, è detto chiave primaria (Primary
Key - PK) della tabella.
3.5
Traduzione verso il modello relazionale
Per la creazione di uno schema logico relazionale è necessario, partendo da uno schema concettuale
definito in precedenza, in base al modello entità-relazione, applicare le seguenti regole.
1) Le entità dello schema concettuale diventano tabelle nello schema logico.
2) Le relazioni tra entità dello schema concettuale, vengono rappresentate nello schema logico,
facendo uso delle cosiddette chiavi esterne. Una chiave esterna (Foreign Key - FK) di una
tabella è un insieme di attributi che corrispondono a quelli che costituiscono la chiave primaria
di un’altra tabella, e stabiliscono quindi, un riferimento tra le righe delle due tabelle (vincoli di
integrità referenziale).
In particolare per rappresentare una relazione tra le tabelle T1 e T2 bisogna distinguere tra le
relazioni 1:1, 1:N, N:N.
I&T Informatica e Telecomunicazioni SpA
26
Metodologia di progettazione database relazionali
2.1)
2.2)
2.3)
Relazione 1:1
Agli attributi di T1 vanno aggiunti, come chiave esterna, gli attributi che costituiscono
la chiave primaria di T2, o alternativamente a T2 vanno aggiunti, come chiave esterna,
gli attributi che costituiscono la chiave primaria di T1. Le due soluzioni sono del tutto
equivalenti.
Relazione 1:N
Supponiamo che la relazione sia 1:N tra T1-T2. Agli attributi di T2 vanno aggiunti,
come chiave esterna, gli attributi che costituiscono la chiave primaria di T1 (ma non il
viceversa!).
Relazione N:N
In questo caso va definita una nuova tabella T3, che contiene, come chiavi esterne, le
chiavi primarie sia di T1 che di T2; è da notare come in questo caso la chiave primaria
della tabella T3 possa essere costituita dalla totalità dei suoi attributi.
Gli eventuali attributi della relazione vengono inclusi come attributi della tabella in cui è
rappresentata la relazione (T3), quella che contiene le chiavi esterne.
3.6
Vincoli di integrità
Le strutture del modello relazionale ci permettono di organizzare le informazioni di interesse per le
nostre applicazioni. In molti casi, però, non è vero che qualsiasi insieme di tuple sullo schema
rappresenti informazioni corrette per l’applicazione.
A tale scopo è stato introdotto il concetto di vincolo di integrità, come proprietà che deve essere
soddisfatta dalle istanze che rappresentano informazioni corrette per l’applicazione.
È possibile classificare i vincoli a seconda degli elementi di una base di dati che ne sono coinvolti.
Distinguiamo due categorie, la prima delle quali ha alcuni casi particolari:
• Un vincolo è intrarelazionale se il suo soddisfacimento è definito rispetto a singole relazioni
della base di dati:
• Un vincolo di tupla è un vincolo che può essere valutato su ciascuna tupla indipendentemente
dalle altre.
• Come caso più specifico, un vincolo definito con riferimento a singoli valori viene detto
vincolo su valori o vincolo di dominio, in quanto impone una restrizione sul dominio degli
attributi. Ad esempio, se una componente di una tupla rappresenta il voto di un esame
universitario in esso sono ammessi valori compresi tra 18 e 30.
• Un vincolo è interrelazionale se coinvolge più relazioni.
Ad esempio se abbiamo una tabella Esami e una Studenti possiamo richiedere che un numero di
matricola compaia nella relazione Esami solo se compare nella relazione Studenti.
3.6.1 Vincoli di chiave
I vincoli di chiave sono i più importanti vincoli intrarelazionali. Nel modello relazionale ogni
relazione deve possedere una chiave e tale chiave deve identificare univocamente tutte le tuple della
relazione a cui afferisce. Anche se è permesso che delle tuple possano contenere valori nulli che
indicano l’assenza (o la non conoscenza) dell’informazione per il corrispondente componente, sulle
chiavi delle relazioni è vietata la presenza dei valori nulli pena l’identificazione stessa delle tuple.
3.6.2 Vincoli di integrità referenziale
I vincoli di integrità referenziale, la più importante classe di vincoli interrelazionali, stabiliscono
delle regole da seguire per salvare le relazioni definite tra tabelle durante l’immissione o
I&T Informatica e Telecomunicazioni SpA
27
Metodologia di progettazione database relazionali
l’eliminazione di record. Quando si applica l’integrità referenziale non è possibile aggiungere un
record ad una tabella correlata se nella tabella primaria non esistono record associati, modificare
valori contenuti nella tabella primaria che genererebbero record isolati in una tabella correlata ed
infine eliminare record della tabella primaria se in una tabella correlata sono inclusi dei record
correlati corrispondenti.
3.7
Algebra relazionale
Gli operatori dell’algebra relazionale permettono di eseguire le operazioni sui dati di un database
relazionale. Essi definiscono le operazioni rilevanti nella gestione delle tabelle (relazioni
algebriche) e possono essere classificati in operatori di base e operatori derivati.
I primi costituiscono un insieme funzionalmente completo, ovvero permettono di realizzare tutte le
operazioni di dati all’interno di uno di schema relazionale. I secondi sono derivabili dai primi
mediante opportune operazioni algebriche a volte complesse.
Gli operatori di base sono proiezione, selezione, prodotto, ridenominazione, unione e differenza. Gli
operatori derivati sono intersezione, giunzione naturale e giunzione.
Tutti gli operatori relazionali hanno la caratteristica comune di avere come argomento delle
relazioni (tabelle) e fornire come risultato altre relazioni (ancora tabelle). Nel seguito saranno usati
come sinonimi i termini relazione e tabella.
3.7.1 Operatori di base
Proiezione
Data una tabella e un insieme di attributi, la proiezione restituisce una tabella con tutte le righe di
quella di partenza ma con alcune colonne (attributi) eliminati e/o risistemati nell’ordine desiderato.
Selezione o restrizione
Data una tabella e una condizione logica sui suoi attributi, la selezione restituisce una tabella con gli
stessi attributi di quella di partenza ma con le sole righe che soddisfano la condizione.
Prodotto (cartesiano) o congiunzione
Date due tabelle, il loro prodotto restituisce una tabella le cui righe sono ottenute concatenando ogni
riga della prima con tutte le righe della seconda.
Ridenominazione
Data una tabella e una sequenza di attributi, la ridenominazione restituisce una tabella ottenuta dalla
tabella di partenza cambiandone tutti gli attributi ordinatamente in quelli della sequenza data come
argomento. Espressa in altri termini, la ridenominazione di una tabella in base a un insieme di nomi
consente di ridenominarne le colonne assegnando loro tali nomi.
Unione
Date due tabelle con gli stessi attributi restituisce come risultato una tabella contenente tutte le righe
delle due tabelle considerate.
Differenza
Anche in questo caso le tabelle devono avere la stessa struttura; il risultato è una tabella che
contiene tutte le righe della prima escluse quelle contenute nella seconda. In altre parole la tabella
restituita è uguale alla prima tabella epurata dalle righe uguali, cioè contenente gli stessi valori, a
righe presenti nella seconda tabella.
I&T Informatica e Telecomunicazioni SpA
28
Metodologia di progettazione database relazionali
3.7.2 Operatori derivati
Intersezione
Date due tabelle con gli stessi attributi, restituisce come risultato una tabella contenente tutte le
righe comuni alle due tabelle considerate.
Natural join (giunzione naturale)
Date due tabelle con un dominio in comune, restituisce una tabella ottenuta mediante il seguente
procedimento:
1) viene effettuato il prodotto cartesiano tra le due tabelle;
2) sulla tabella così risultante viene eseguita la selezione delle righe in cui gli attributi
appartenenti al dominio comune sono uguali;
3) vengono infine ridenominati gli attributi comuni con uno stesso nome, in modo che
compaiono una sola volta.
È possibile definire il natural join anche tra tabelle aventi più domini in comune. Se le tabelle non
hanno domini in comune il natural join si riduce al prodotto cartesiano.
Join (giunzione)
Date due tabelle con un dominio in comune, ed una condizione nella forma
A1 op A2
Dove A1 e A2 sono gli attributi delle due tabelle corrispondenti al dominio in comune e op è un
operatore di confronto (>, <, ≤, ecc.), la join restituisce una tabella ottenuta mediante il seguente
procedimento:
1) viene effettuato il prodotto cartesiano tra le due tabelle:
2) sulla tabella così risultante viene eseguita la selezione delle righe in cui gli attributi
appartenenti al dominio comune soddisfano la condizione:
3) vengono infine ridenominati gli attributi comuni con lo stesso nome, in modo che
compaiono una volta sola.
Se op è l’operazione di = la join viene chiamata equijoin.
Semijoin
Il semijoin della relazione R con la relazione S è la proiezione sugli attributi di R del natural join di
R e S.
I&T Informatica e Telecomunicazioni SpA
29
Metodologia di progettazione database relazionali
3.8
Normalizzazione dei dati
Una volta impostato uno schema logico relazionale è necessario effettuare una serie di verifiche
sulla correttezza del procedimento svolto. Queste potranno portare a modificare la struttura dello
schema stesso, al fine di renderlo corretto ed evitare il verificarsi, nella gestione dei dati, di errori
difficilmente ovviabili a posteriori.
Tale processo è detto normalizzazione dello schema relazionale ed è effettuabile mediante
procedimenti di tipo algebrico, basati sui concetti di dipendenza e di scomposizione.
Esistono cinque (anche di più) forme normali di cui le prime due sono molto semplici mentre quelle
più significative sono la terza e quella di Boyce-Codd che hanno certe proprietà desiderabili:
• assenza o quasi di ridondanza nelle relazioni
• eliminazione delle anomalie
• conservazione delle dipendenze
• ricostruzione della relazione di partenza a partire da quelle scomposte
• mantenimento dei vincoli di integrità del progetto originale.
3.8.1 Ridondanza e anomalie
Vediamo dei comportamenti poco desiderabili di uno schema di relazione tramite un esempio.
Supponiamo di avere la relazione:
INFO_FORN(NOME_FORN, INDIR_FORN, NOME_PROD, PREZZO)
che comprende tutte le informazioni di un fornitore di un particolare prodotto.
In questo schema si possono riscontrare diversi problemi.
• Ridondanza. L’indirizzo del fornitore è ripetuto una volta per ogni prodotto venduto.
• Inconsistenza potenziale (anomalie di aggiornamento). Come conseguenza della ridondanza
potremmo aggiornare l’indirizzo del fornitore in una tupla, lasciandolo inalterato in un’altra.
Non avremmo allora un unico indirizzo per ogni fornitore, come invece ci si aspetterebbe.
• Anomalie di inserimento. Non possiamo registrare un indirizzo di un fornitore, se questo
attualmente non fornisce almeno un prodotto. In una tupla potremmo porre dei valori nulli nelle
componenti NOME_PROD e PREZZO per quel fornitore, ma allora, quando per esso si
introducesse un prodotto, ci ricorderemmo di cancellare la tupla dei valori nulli? E ancora
peggio, NOME_PROD e NOME_FORN insieme formano una chiave per la relazione, e non è
ammissibile che si inseriscono dei valori nulli in una chiave.
• Anomalie in cancellazione. L’inverso del problema precedente è che se cancellassimo tutti i
prodotti di un fornitore, involontariamente perderemmo traccia del suo indirizzo.
Nell’esempio mostrato tutti i problemi precedenti svaniscono se sostituiamo la relazione
INFO_FORN con i due schemi di relazione seguenti:
FORNITORI(NOME_FORN, INDIR_FORN)
FORNISCE(NOME_FORN, NOME_PROD, PREZZO)
In tal caso FORNITORI contiene l’indirizzo di ogni fornitore esattamente una volta, quindi non vi è
ridondanza. Inoltre possiamo introdurre l’indirizzo di un fornitore anche se attualmente non fornisce
prodotti.
I&T Informatica e Telecomunicazioni SpA
30
Metodologia di progettazione database relazionali
Adesso però abbiamo lo svantaggio di dover eseguire una join tra le due relazione per ottenere gli
indirizzi dei fornitori di un certo prodotto.
Quello che abbiamo appena eseguito non è altro che una normalizzazione della relazione
INFO_FORN scomponendo tale relazione in altre due relazioni che conservano tutti i dati e le
dipendenze di partenza.
Vediamo adesso brevemente i concetti dipendenze e di scomposizione che sono alla base delle
forme normali.
3.8.2 Dipendenze
La ridondanza è strettamente legata alle dipendenze che esistono tra i vari attributi di una relazione.
Le dipendenze possono essere di vario tipo. La più importante è la dipendenza funzionale che
vedremo meglio di seguito. Un’altra interessante è la dipendenza a molti valori le cui ridondanze
introdotte vengono eliminate da una generalizzazione della forma normale di Boyce-Codd, la quarta
forma normale.
Dipendenze funzionali
Le dipendenze funzionali sono uno specifico strumento di lavoro che permette di studiare in
maniera sistematica i concetti introdotti in modo informale nel paragrafo precedente. Si tratta di un
particolare vincola di integrità per il modello relazionale che, come suggerisce il nome, descrive
legami di tipo funzionale tra gli attributi di una relazione.
Se ad esempio un attributo ne determina un altro in modo unico, come potrebbe essere che
Nome_Fornitore determina Indirizzo_Fornitore diciamo che vi è una dipendenza funzionale di
Indirizzo_Fornitore da Nome_Fornitore, o anche che Nome_Fornitore determina funzionalmente
Indirizzo_Fornitore, e si indica come segue:
{Nome_Fornitore} à {Indirizzo_Fornitore}
Da notare che il vincolo di dipendenza funzionale generalizza il vincolo di chiave. Per l’insieme di
attributi che formano una chiave per una relazione, si può dire che, gli altri attributi (anche un
sottoinsieme della chiave) sono determinati funzionalmente dalla chiave. La chiave quindi
determina funzionalmente una relazione.
Un’altra dipendenza funzionale dello schema di relazione Info_Forn è:
{Nome_Forn, Nome_Prod} à {Prezzo}
che ritroviamo nella seconda tabella della scomposizione.
Individuazione delle dipendenze
Per individuare tutte le dipendenze di uno schema di relazione non è plausibile andare a vedere le
tuple della relazione per dedurre le dipendenze valide.
Il solo modo per determinare le dipendenze funzionali che valgono per uno schema di relazione è
quello di considerare con attenzione il significato degli attributi.
3.8.3 Scomposizioni
Il motivo per eseguire una scomposizione è che essa permette di eliminare la maggior parte dei
problemi di ridondanza e anomalie. Abbiamo anche visto in precedenza che gli schemi di relazioni
FORNITORI e FORNISCE sono una scomposizione per lo schema di relazione INFO_FORN, e
risolvono i problemi riscontrati.
I&T Informatica e Telecomunicazioni SpA
31
Metodologia di progettazione database relazionali
Ma adesso sorge un dubbio, noi ci aspettiamo che le relazioni correnti degli schemi scomposti siano
la proiezione sui rispettivi attributi della relazione dello schema di partenza. Un modo per
controllarlo è quello di prendere il natural join delle relazioni scomposte e vedere se riotteniamo la
relazione dello schema di partenza. Se però il natural join non permette di ricostruire la relazione
originale, non vi è alcun modo di ripristinarla in modo univoco.
Scomposizione lossless join (senza perdita)
Le scomposizioni lossless join sono delle scomposizioni che soddisfano particolari proprietà che
garantiscono la ricostruzione della relazione originale dalle relazioni scomposte (si esegue tra questi
ultimi un natural join). In tal modo, interrogando le relazioni scomposte si ottengono gli stessi
risultati che si otterrebbero interrogando la relazione originale.
Per la scomposizione in soli due schemi vi è una regola molto semplice che dice che una relazione
si decompone senza perdita su due relazioni se l’insieme degli attributi comuni alle due relazioni è
chiave per almeno una delle due relazioni scomposte.
Scomposizioni che conservano le dipendenze
Un’altra proprietà importante di una scomposizione di uno schema di relazione è che essa mantenga
le dipendenze.
Diciamo che una scomposizione di uno schema di relazione conserva l’insieme delle dipendenze se
l’unione di tutte le dipendenze nello schema scomposto implica logicamente tutte le dipendenze
iniziali.
Il motivo per cui è desiderabile che una scomposizione mantenga le dipendenze è che le dipendenze
si possono considerare come vincoli di integrità (correttezza dei valori che si trovano nelle
componenti delle tuple) per lo schema di relazione.
In modo intuitivo possiamo dire che una decomposizione conserva le dipendenze se in ogni
decomposizione, ciascuna delle dipendenze funzionali dello schema originario coinvolge attributi
che compaiono tutti insieme in uno degli schemi decomposti.
In questo modo, è possibile garantire, sullo schema decomposto, il soddisfacimento degli stessi
vincoli il cui soddisfacimento è garantito dallo schema originario.
Una nota a sfavore delle scomposizioni è quella che aumentano i tempi di risposta delle
interrogazioni sul database quindi è apprezzabile nel momento in cui sia necessario risolvere
problemi come quello della ridondanza, ma non in altri casi.
Riassumendo possiamo dire che siamo interessati solo alle scomposizioni che sono senza perdita e
che conservano le dipendenze e, in base a queste considerazioni, effettuare la normalizzazione del
progetto della base di dati, non prima però di aver individuato tutte le dipendenze funzionali dello
schema di database.
3.8.4 Prima forma normale
Se lo schema di database non si trova già in prima forma normale lo riconduciamo.
La prima forma normale (First Normal Form – 1NF) stabilisce che in una tabella (relazione) non
possono esistere colonne (attributi) definite per contenere una molteplicità di valori. Una tabella
quindi non può contenere una struttura vettoriale o array, al contrario di quanto consentito in
linguaggi di programmazione tradizionali.
Le tabelle che contengono una colonna non rispondente a questa condizione vanno trasformate,
creando per ciascuna riga della tabella di partenza tante righe quanti sono i valori multipli presenti
nelle colonne della riga considerata, oppure, scomponendo in due tabelle in cui in una vengono
I&T Informatica e Telecomunicazioni SpA
32
Metodologia di progettazione database relazionali
spostate le colonne ripetute. L’associazione tra le due tabelle è stabilita con la combinazione della
primary key e foreign key.
Da notare che, nelle tabelle non normalizzate viene assegnato comunque spazio di memorizzazione
ai “campi ripetuti” anche se in essi non sono specificati valori. Inoltre il numero dei “campi
ripetuti”, è fisso, vincolando il numero di valori al massimo numero previsto. In ultimo, ma non per
importanza, se vogliamo ricercare un valore nella tabella suddetta lo dobbiamo fare per tutte le
colonne ripetute di ogni riga. Tutti questi problemi si risolvono trasformando o decomponendo
come detto sopra.
3.8.5 Seconda forma normale
La seconda forma normale (Second Normal Form – 2NF) riguarda le tabelle in cui la chiave
primaria sia composta da più attributi e stabilisce che, in questo caso, tutte le colonne corrispondenti
agli attributi dipendano dall’intera chiave primaria e non da una parte di essa. Naturalmente è
richiesto che la tabella sia già in 1NF. Se la tabella è dotata di chiave primaria mono attributo è già
in 2NF.
Le violazioni alla 2NF si risolvono individuando, guidati dalle dipendenze funzionali, una
decomposizione per la tabella originale che soddisfa le proprietà di lossless join e di conservazione
delle dipendenze. Le tabelle così ottenute eliminano buona parte dei problemi di ridondanza e di
anomalie.
3.8.6 Terza forma normale
La terza forma normale (Third Normal Form - 3NF) stabilisce che non esistono dipendenze tra
colonne di una tabella se non basate sulla chiave primaria, o se esistono, l’attributo determinato è
primario. Un attributo è primario se è membro di una qualunque chiave della relazione.
Naturalmente è richiesto che la tabella sia già in 2NF.
L’idea generale è di scomporre in modo che a ciascuna dipendenza corrisponde una diversa
relazione la cui chiave è proprio il primo membro della dipendenza stessa. In tale modo, il
soddisfacimento della 3NF è garantito, per la definizione stessa della 3NF.
In molti casi pratici la struttura delle dipendenze stesse, “naturalmente” separate e indipendenti
l’una dall’altra, permette una decomposizione che produce tante relazioni quante sono le
dipendenze funzionali definite (o meglio, le dipendenze funzionali con diverso primo membro).
In generale, purtroppo, le dipendenze possono avere una struttura complessa: può non essere
necessario (possibile) basare la decomposizione su tutte le dipendenze e può essere difficile
individuare quelle su cui si deve basare la decomposizione. Basti pensare al caso in cui ci sono
dipendenze che ricoprono tutti gli attributi di una relazione non suggerendo alcuna decomposizione
e quando ci sono più dipendenze funzionali fra loro interconnesse. In tal caso non si può fare a
meno di trattare la normalizzazione in modo formale.
3.8.7 Linee guida sulla normalizzazione
1) Partire dalle tabelle non normalizzate.
2) Individuare le chiavi primarie, ed eventuali altre dipendenze funzionali.
I&T Informatica e Telecomunicazioni SpA
33
Metodologia di progettazione database relazionali
3) Individuare e risolvere le violazioni della 1NF rimuovendo tutti gli attributi ripetuti.
• Se esistono attributi ripetuti trasformare la tabella in questione creando per ciascuna riga
della tabella di partenza tante righe quanti sono i valori multipli presenti nelle colonne
della riga considerata oppure spostando le colonne ripetute in un’altra tabella dove la
chiave primaria della prima tabella diventa chiave esterna in quest’ultima.
4) Individuare e risolvere le violazioni della 2NF assicurando che ciascun attributo dipenda
dall’intera chiave.
• Se alcuni attributi non dipendono dall’intera chiave (dipendenze funzionali in cui il
termine a sinistra non è l’intera chiave) creare una nuova tabella con gli altri attributi che
dipendono da parte di questa.
• Definire in questa nuova tabella la chiave primaria coincidente con la parte determinante
della chiave originale.
• Eliminare dalla tabella originale gli attributi (non chiave) spostati nella nuova tabella.
5) Individuare e risolvere le violazioni della 3NF assicurando che non esistano attributi non chiave
che dipendano da altri attributi non chiave.
• Se esiste un tale attributo, rimuoverlo dalla tabella originale insieme da tutti gli altri che
dipendono dallo stesso determinante (dipendenze funzionali tra attributi non chiave), e
creare una nuova tabella che li contenga.
• Gli attributi determinanti diventano chiave primaria nella nuova tabella e permangono
nella precedente tabella in qualità di chiavi esterne.
• (Eliminare gli attributi che sono dipendenti dai determinanti dalla tabella di partenza).
Il processo precedente permette di verificare la qualità delle relazioni, a volte non occorre fare
nessuna trasformazione, perché lo schema del database si trova già in 3NF, in questo contesto, la
teoria della normalizzazione costituisce un utile strumento di analisi della qualità di un progetto.
Il motivo per cui a volte non necessita fare alcuna trasformazione sullo schema del database è
perché la metodologia di progettazione (concettuale, logica) porta a schemi di database già in 3NF,
tramite l’individuazione e la separazione dei concetti fondamentali della realtà da modellare
creando entità e/o associazioni distinte.
Per la maggior parte delle situazioni quando un progetto di schema di database si trova in terza
forma normale è più che ottimo.
Esistono diverse altre forme normali, la prima in sequenza è la forma normale di Boyce-Codd
(BCNF) che stabilisce che non esistono dipendenze tra attributi di una relazione se non basate sulla
chiave primaria. La ragione che sta alla base della BCNF è quella di eliminare le ridondanze che
possono essere introdotte dalle dipendenze funzionali e non eliminate dalle precedenti forme
normali. In tale forma normale, facendo uso solo delle dipendenze funzionali, non è possibile
prevedere nessun valore dati gli altri.
Segue la quarta forma normale (4NF), una generalizzazione della precedente, che si applica a
schemi di relazione con dipendenze a molti valori, e che permette di eliminare le ridondanze
provocate da queste dipendenze e non eliminate dalle precedenti forme normali.
Ricordiamo ancora che le due più importanti proprietà per schemi di database sono il lossless join e
la conservazione delle dipendenze e sono viste come un tutt’uno.
I risultati cui è giunta la teoria della normalizzazione sono che per qualunque schema relazionale vi
è una scomposizione lossless join in forma normale Boyce-Codd e una in terza forma normale che
ha un lossless join e conserva anche le dipendenze. Tuttavia può non esserci una scomposizione di
uno schema relazionale in forma normale Boyce-Codd che conservi le dipendenze.
Si può quindi affermare che, talvolta, la forma normale di Boyce-Codd non è raggiungibile.
I&T Informatica e Telecomunicazioni SpA
34
Metodologia di progettazione database relazionali
3.9
Implementazione dello schema logico
Ricapitolando, il corretto progetto di una base di dati relazionale dovrebbe partire dalla definizione
dello schema derivato dall’esame della realtà di interesse, per arrivare alla definizione di uno
schema logico relazionale normalizzato.
Esistono strumenti informatici detti CASE (Computer Aided Software Engineering) che aiutano
l’analista in questo processo; esempi di questa classe di strumenti sono Bachman della Cayenne
Software Inc e ERwin della LogicWorks.
Lo schema relazionale deve essere tradotto utilizzando un RDBMS (Relational Database
Management System); tra i più diffusi troviamo Oracle, Informix, DB2, SQL Server, Sybase,
eccetera.
Un RDBMS, tramite il suo DDL, permette di implementare lo schema logico attraverso la creazione
di tabelle, chiavi primarie e esterne, indici, viste e così via, fa rispettare i vincoli di tupla, di
dominio, di unicità, di Not Null, di integrità referenziale, eccetera.
Nella pratica, nella progettazione dello schema logico, per ragioni di efficienza si deve compiere
spesso un ulteriore passo detto di denormalizzazione in cui, in parziale contrasto con la teoria
relazionale, si ammette una certa ridondanza dei dati in cambio di migliori prestazioni del sistema in
termini di tempi di risposta.
I&T Informatica e Telecomunicazioni SpA
35
Metodologia di progettazione database relazionali
4
Progettazione fisica
Nell’ambito del progetto di una base di dati, la fase finale è costituita dalla progettazione fisica, che,
ricevendo in ingresso lo schema logico di una base di dati e le caratteristiche del sistema scelto,
produce in uscita lo schema fisico del database, costituito dalle effettive definizioni delle relazioni e
soprattutto delle strutture fisiche di memorizzazione utilizzate, con i relativi parametri. Ad, esempio
una relazione può essere realizzata fisicamente per mezzo di un file sequenziale, o di un file hashed
o di file sequenziale con uno o più indici. Ogni tupla della relazione viene memorizzata come un
record fisico nella struttura dati scelta, e ogni componente della tupla è memorizzata in un campo
del record fisico.
L’attività di progettazione fisica di una base di dati relazionale, in realtà non è così semplice, perché
oltre alle scelte relative alle strutture fisiche può essere necessario definire molti parametri, che
vanno dalle dimensioni iniziali dei file alle possibilità di espansione, dalla contiguità di allocazione
alla quantità e alle dimensioni delle aree di transito per scambio di informazioni tra memoria
principale e secondaria.
La maggior parte delle scelte da effettuare nel corso della progettazione fisica dipende in effetti
dallo specifico sistema di gestione utilizzato, e quindi risulta difficile fornire una panoramica
completa. Indicheremo solo le linee principali, che possono però essere considerate sufficienti in
presenza di basi di dati di dimensioni non enormi o con carichi di lavoro non particolarmente
complessi.
Assumiamo che il DBMS a nostra disposizione preveda solo file non ordinati, con possibilità di
definizione di indici (strutture ausiliarie per il reperimento efficiente dei dati). In questo contesto,
ignorando gli altri parametri, la progettazione fisica può essere ricondotta ad una attività di
individuazione degli indici da definire su ciascuna relazione (a parte l’attività semplice di specifica
degli schemi delle relazioni nello specifico DDL del sistema usato, con i tipi di dati ammessi per i
vari attributi).
Per orientarci nella scelta degli indici, è opportuno ricordare che le operazioni più delicate in un
database relazionale sono quelle di selezione (che corrisponde all’accesso ad uno o più record sulla
base dei valori di uno o più attributi) e di join (che richiede di combinare ennuple di relazioni
diverse sulla base dei valori di uno o più attributi di ciascuna di tali relazioni). Ciascuna delle due
operazioni può essere eseguita in maniera più efficiente se sui campi interessati è definito un indice,
che permette un accesso diretto.
È interessante notare che molti dei join che si presentano nelle applicazioni sono equi-join e per
almeno una delle due relazioni i campi coinvolti formano una chiave (si può usare efficientemente il
metodo dei nested-loop – si scandisce sequenzialmente una relazione e si accede direttamente
all’altra tramite l’indice). Al tempo stesso possiamo notare come quasi sempre la chiave di una
relazione sia coinvolta in operazioni di selezione o di join (o entrambe). Pertanto possiamo dire che
è ragionevole definire, su ciascuna relazione, un indice in corrispondenza della relativa chiave
(indice primario). Tali indici solitamente vengono creati in automatico dal DBMS. Inoltre possono
essere definiti indici (indici secondari) su altri campi su cui vengono effettuate operazioni di
selezione oppure su cui è richiesto un ordinamento in uscita (perché un indice ordina logicamente i
record di un file, rendendo nullo il costo di un ordinamento). Queste osservazioni costituiscono la
base di una semplice strategia di progettazione fisica.
Definiti in questo modo gli indici, si può sperimentare sul campo il comportamento della nostra
applicazione: se le prestazioni risultano insoddisfacenti, si possono aggiungere altri indici,
procedendo però con grande attenzione, in quanto l’aggiunta di un indice comporta un aggravio del
carico per far fronte alle operazioni di modifica. Talvolta, inoltre, il comportamento del sistema è
imprevedibile, e l’aggiunta di indici non altera la strategia di ottimizzazione delle interrogazioni
principali, risultando del tutto inefficace. É buona norma, dopo l’aggiunta di un indice, verificare
che le interrogazioni ne facciano effettivamente uso. Per questo motivo, l’attività di scelta degli
I&T Informatica e Telecomunicazioni SpA
36
Metodologia di progettazione database relazionali
indici nell’ambito del progetto fisico delle basi di dati relazionali è svolta spesso in modo empirico,
con un approccio per tentativi; più in generale, l’attività di regolazione (tuning) del progetto fisico
consente spesso di migliorare le prestazioni della base di dati.
I&T Informatica e Telecomunicazioni SpA
37