FONDAMENTI DI BASI DI DATI
FONDAMENTI DI BASI DI DATI
Xxxxxxx Xxxxxx, Xxxxxxx Xxxxxx, Xxxxx Xxxxxxxxxxxxxxxxxxxxxxxxx
Copyright ⃝c
2019 X. Xxxxxx, X. Xxxxxx, X. Xxxxxx
Si concede il diritto di riprodurre gratuitamente questo materiale con qualsiasi mezzo o formato, in parte o nella sua interezza, per uso personale o per uso didattico alle seguenti condizioni: le copie non sono fatte per profitto o a scopo commerciale; la prima pagina di ogni copia deve riportare questa nota e la citazione completa, incluso il titolo e gli autori. Altri usi di questo materiale inclusa la ripubblicazione, anche di versioni modificate o derivate, la diffusione su server o
su liste di posta, richiede un permesso esplicito preventivo dai detentori del copyright.
12 febbraio 2019
INDICE
1 Sistemi per basi di dati 1
1.1 Sistemi informativi e informatici . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Evoluzione dei sistemi informatici . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Tipi di sistemi informatici . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Sistemi informatici operativi . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Sistemi informatici direzionali . . . . . . . . . . . . . . . . . . . . 6
1.4 I sistemi per basi di dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Funzionalita` dei DBMS 13
1.5.1 Definizione della base di dati 13
1.5.2 Uso della base di dati 17
1.5.3 Controllo della base di dati 19
1.5.4 Distribuzione della base di dati 23
1.5.5 Amministrazione della base di dati 24
1.6 Vantaggi e problemi nell’uso dei DBMS 25
Esercizi 26
2 I modelli dei dati 29
2.1 Progettazione e modellazione 29
2.2 Considerazioni preliminari alla modellazione 30
2.2.1 Aspetto ontologico 30
2.2.2 Aspetto linguistico astratto 38
2.2.3 Aspetto linguistico concreto 38
2.2.4 Aspetto pragmatico 38
2.3 Il modello dei dati ad oggetti 39
2.3.1 Rappresentazione della struttura
della conoscenza concreta 40
2.3.2 Rappresentazione degli altri aspetti
della conoscenza astratta 51
2.3.3 Rappresentazione della conoscenza procedurale 52
2.3.4 Rappresentazione della comunicazione . . . . . . . . . . . . . . . | ||
2.4 Altri modelli dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
2.4.1 Il modello entita`-relazione . . . . . . . . . . . . . . . . . . . . . . | ||
2.4.2 Il modello relazionale . . . . . . . . . . . . . . . . . . . . . . . . . | ||
2.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.2 Le metodologie di progettazione . . . . . . . . . . . . . . . . . . . . . . . | ||
3.2.1 Il ruolo delle metodologie . . . . . . . . . . . . . . . . . . . . . . . | ||
3.2.2 Le metodologie con piu` fasi . . . . . . . . . . . . . . . . . . . . . . | ||
3.2.3 Le metodologie con prototipazione . . . . . . . . . . . . . . . . . | ||
3.3 Gli strumenti formali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.3.1 I diagrammi di flusso dati . . . . . . . . . . . . . . . . . . . . . . . | ||
3.3.2 I diagrammi di stato . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.4 L’analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.4.1 Scopo dell’analisi dei requisiti . . . . . . . . . . . . . . . . . . . . | ||
3.4.2 Come procedere . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.4.3 Un esempio di analisi dei requisiti . . . . . . . . . . . . . . . . . . | ||
3.5 La progettazione concettuale . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.5.1 Scopo della progettazione concettuale . . . . . . . . . . . . . . . . | ||
3.5.2 Come procedere . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
3.5.3 I passi della progettazione concettuale . . . . . . . . . . . . . . . | ||
3.6 Riepilogo della metodologia di progettazione . . . . . . . . . . . . . . . | ||
3.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.1 Il modello dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.1.1 La relazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.1.2 I vincoli d’integrita` . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.1.3 Una rappresentazione grafica di schemi relazionali . . . . . . . . | ||
4.1.4 Operatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.2 Progettazione logica relazionale . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Rappresentazione delle associazioni binarie uno a molti e uno ad uno . . . . . . . . . . . . . . . . . . . . . . . | ||
4.2.2 Rappresentazione di associazioni molti a molti . . . . . . . . . . | ||
4.2.3 Rappresentazione delle gerarchie fra classi . . . . . . . . . . . . . | ||
4.2.4 Definizione delle chiavi primarie . . . . . . . . . . . . . . . . . . . | ||
4.2.5 Rappresentazione delle proprieta` multivalore . . . . . . . . . . . | ||
4.2.6 Appiattimento degli attributi composti . . . . . . . . . . . . . . . | ||
4.3 Algebra relazionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
4.3.1 Gli operatori primitivi . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.3.2 Operatori derivati . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.3.3 Proprieta` algebriche degli operatori relazionali . . . . . . . . . . | ||
4.3.4 Altri operatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.4 Calcolo relazionale su ennuple . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.5 I linguaggi logici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
4.6 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.1 Le anomalie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.2 Dipendenze funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.2.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.2.2 Dipendenze derivate . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.2.3 Chiusura di un insieme di dipendenze funzionali . . . . . . . . . | ||
5.2.4 Chiavi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.2.5 Copertura di un insieme di dipendenze . . . . . . . . . . . . . . . | ||
5.3 Decomposizione di schemi . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.3.1 Decomposizioni che preservano i dati . . . . . . . . . . . . . . . . | ||
5.3.2 Decomposizioni che preservano le dipendenze . . . . . . . . . . | ||
5.4 Forme normali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.4.1 Forma Normale di Xxxxx-Codd . . . . . . . . . . . . . . . . . . . | ||
5.4.2 Normalizzazione di schemi in BCNF . . . . . . . . . . . . . . . . | ||
5.4.3 Terza forma normale . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.4.4 Normalizzazione di schemi in 3NF . . . . . . . . . . . . . . . . . | ||
5.5 Dipendenze multivalore . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.6 La denormalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
5.7 Uso della teoria della normalizzazione . . . . . . . . . . . . . . . . . . . . | ||
5.8 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.1 SQL e l’algebra relazionale su multinsiemi . . . . . . . . . . . . . . . . . | ||
6.2 Operatori per la ricerca di dati . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.1 La clausola SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.2 La clausola FROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.3 La clausola WHERE . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.4 Operatore di ordinamento . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.5 Funzioni di aggregazione . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.6 Operatore di raggruppamento . . . . . . . . . . . . . . . . . . . . | ||
6.2.7 Operatori insiemistici . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.2.8 Sintassi completa del SELECT . . . . . . . . . . . . . . . . . . . . . | ||
6.3 Operatori per la modifica dei dati . . . . . . . . . . . . . . . . . . . . . . |
6.4 Il potere espressivo di SQL . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
6.5 QBE: un esempio di linguaggio basato sulla grafica . . . . . . . . . . . . | ||
6.6 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.1 Definizione della struttura di una base di dati . . . . . . . . . . . . . . . | ||
7.1.1 Base di dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.1.2 Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.1.3 Tabelle virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.2 Vincoli d’integrita` . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.3 Aspetti procedurali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.3.1 Procedure memorizzate . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.3.2 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.4 Progettazione fisica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.4.1 Definizione di indici . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.5 Evoluzione dello schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.6 Utenti e Autorizzazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.7 Schemi esterni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.8 Cataloghi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
7.9 Strumenti per l’amministrazione di basi di dati . . . . . . . . . . . . . . | ||
7.10 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.1 Linguaggi che ospitano l’SQL . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.1.1 Connessione alla base di dati . . . . . . . . . . . . . . . . . . . . . | ||
8.1.2 Comandi SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.1.3 I cursori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.1.4 Transazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.2 Linguaggi con interfaccia API . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.2.1 L’API ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.2.2 L’API JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.3 Linguaggi integrati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
8.4 La programmazione di transazioni . . . . . . . . . . . . . . . . . . . . . . | ||
8.4.1 Ripetizione esplicita delle transazioni . . . . . . . . . . . . . . . . | ||
8.4.2 Transazioni con livelli diversi di isolamento . . . . . . . . . . . . | ||
8.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Esercizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ||
Note bibliografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . |
9 Realizzazione dei DBMS 251
9.1 Architettura dei sistemi relazionali 251
9.2 Gestore della memoria permanente 252
9.3 Gestore del buffer 252
9.4 Gestore delle strutture di memorizzazione 253
9.5 Gestore dei metodi di accesso 257
9.6 Gestore delle interrogazioni 258
9.6.1 Riscrittura algebrica 258
9.6.2 Ottimizzazione fisica 261
9.6.3 Esecuzione di un piano di accesso 273
9.7 Gestore della concorrenza 273
9.8 Gestore dell’affidabilita` 274
Esercizi 277
Bibliografia 281
Prefazione
Dopo molti anni dalla pubblicazione della prima edizione del volume Fondamenti di Basi di Dati presso l’Editore Zanichelli, aggiornato con una seconda versione uscita
nel 2005, e` tempo di un’ulteriore ammodernamento, che coincide con la sua diffu-
sione con un canale diverso da quello della carta stampata: il web, attraverso il sito
xxxx://xxxxxxxxxxxxxxxxxxxxxx.xx.
Riteniamo che questo materiale possa essere utile non solo per i classici corsi di
Basi di Dati, fondamentali per le lauree in Informatica o Ingegneria Informatica, ma,
data l’attenzione cha sta oggi avendo l’informatica in sempre piuu` ampi settori della
formazione e dell’istruzione ad ogni livello, in molti altri corsi di laurea e momenti formativi, in forma anche parziale, come abbiamo potuto sperimentare di persona durante questi ultimi anni.
Il passaggio alla nuova modalita` di distribuzione, permettendo di mantenere ag-
giornati i contenuti, ci ha richiesto di modificare la struttura del sito di supporto al
libro, che non avra` piu` la parte di errata corrige e di approfondimenti, ma conterra`
materiale aggiuntivo utile per lo studio, come le soluzioni agli esercizi, i collegamenti ai software gratuiti, gli appunti del corso, e gli esempi scaricabili.
Organizzazione del testo
Il libro inizia presentando le ragioni che motivano la tecnologia delle basi di dati, ed i concetti principali che caratterizzano le basi di dati ed i sistemi per la loro gestione. In maggior dettaglio, il Capitolo 2 si sofferma sulle nozioni fondamentali di mo- dello informatico finalizzato al trattamento delle informazioni di interesse dei sistemi informativi delle organizzazioni e sui meccanismi d’astrazione per costruire model-
li informatici. Il modello di riferimento e` il modello ad oggetti, motivato non solo
dalla sua naturalezza per la progettazione di basi di dati, ma anche per essere il mo- dello dei dati dell’attuale tecnologia relazionale ad oggetti per basi di dati. Il formali- smo grafico adottato si ispira all’Unified Modeling Language, UML, ormai uno standard dell’ingegneria del software.
Il Capitolo 3 presenta una panoramica del problema della progettazione di basi di dati, si sofferma sulle fasi dell’analisi dei requisiti e della progettazione concettua-
INDICE viii
le usando il modello ad oggetti e il formalismo grafico proposto nel Capitolo 2, e descrive un metodo di lavoro per queste fasi.
I Capitoli 4 e 5 sono dedicati alla presentazione rigorosa del modello relazionale dei dati e ad un’introduzione alla teoria della normalizzazione. La scelta di dedicare que-
sto spazio all’argomento e` giustificata dal ruolo fondamentale che svolge il modello
relazionale per la comprensione della tecnologia delle basi di dati e per la formazione degli addetti.
I Capitoli 6, 7 e 8 trattano il linguaggio relazionale SQL da tre punti di vista, che corrispondono ad altrettante categorie di utenti: (1) gli utenti interessati ad usare interattivamente basi di dati relazionali, (2) i responsabili di basi di dati interessati a definire e gestire basi di dati, (3) i programmatori delle applicazioni.
Il Capitolo 9 presenta una panoramica delle principali tecniche per la realizzazione dei sistemi relazionali. Vengono presentate in particolare la gestione delle interroga- zioni e dei metodi di accesso e la gestione dell’atomicita` e della concorrenza in sistemi centralizzati.
Ringraziamenti
L’organizzazione del materiale di questo testo e` il risultato di molti anni di insegna- mento deii corsi di Basi di Dati per le lauree in Scienze dell’Informazione e in Informatica. Molte persone hanno contribuito con i loro suggerimenti e critiche costruttive a
migliorare la qualita` del materiale. In particolare si ringraziano i numerosi studenti
che nel passato hanno usato le precedenti versioni del testo e Xxxxxxxxx Xxxxx per la sua collaborazione.
Si ringrazia infine l’Editore Zanichelli per il supporto che ci ha dato in questi anni, e, adesso che il libro e` uscito dal suo catalogo, per il permesso di diffondere la nuova versione attraverso il web.
A. A.
G. G.
R. O.
Capitolo 3
LA PROGETTAZIONE DI BASI DI DATI
Progettare una base di dati significa definire lo schema globale dei dati, i vincoli d’integrita` e le operazioni delle applicazioni, per preparare la fase successiva in cui la base di dati e le operazioni verranno realizzate.1 La progettazione di una base di dati e` un’attivita` complessa, per la quale sono state proposte molte metodologie ed ambienti
di sviluppo. In questo capitolo viene presentato l’approccio metodologico piu` conso-
xxxxxx, soffermandosi in particolare sul problema della progettazione concettuale di basi di dati.
3.1 Introduzione
La costruzione di un qualunque sistema complesso, e in particolare di un qualunque sistema informatico, e` un processo che si articola in generale in tre fasi:
1. analisi dei requisiti: in questa fase si stabilisce che cosa il committente si aspetta dal sistema;
2. progetto del sistema: in questa fase si progetta un sistema che soddisfi le esigenze del committente;
3. realizzazione del sistema progettato.
Le fasi di analisi dei requisiti e progetto del sistema sono chiamate collettivamen-
te progettazione poiche´ realizzare.
il loro scopo e`
la produzione di un progetto del sistema da
Il problema della progettazione di basi di dati e` analogo a quello della progettazione di programmi studiato nell’area dell’ingegneria del software, ed e` stato affrontato con strategie simili:
1. La definizione di una metodologia di progettazione organizzata in una sequenza di fasi operative durante le quali il progettista prende un numero limitato di decisioni
alla volta. Ogni fase produce una definizione della soluzione ad un diverso livello di dettaglio e prevede l’impiego di opportuni strumenti. Ad esempio, nella meto- dologia che verra` presentata, nella prima fase (analisi dei requisiti) si specificano le informazioni da trattare e il comportamento esterno del sistema; nella seconda fase (progettazione concettuale) si raffina questa descrizione, fornendo in particolare uno schema globale dei dati e l’architettura delle operazioni; nella terza fase (progetta- zione logica) si specializza questa descrizione per i meccanismi di astrazione di uno specifico modello dei dati, e nella quarta fase (progettazione fisica) vengono aggiunti ulteriori dettagli riguardanti l’organizzazione fisica dei dati.
2. La definizione di strumenti metodologici da usare in ogni fase per espletare i passi della metodologia, per valutare i risultati della fase e per passare dai risultati di una fase a quelli della successiva. Questi strumenti sono di varia natura (proce- dure manuali, metodi di documentazione, rappresentazioni grafiche, modulistica e strumenti automatici) e finalizzati a scopi diversi a seconda della fase in cui si usano. Essi sono utilizzati per:
– analisi, progettazione e documentazione, al fine di aiutare il progettista e gli utenti a strutturare le informazioni eliminando ridondanze, segnalando conflitti ed incompletezze;
– la progettazione di dettaglio, cioe` per produrre un progetto di cio` che va realiz- zato che garantisca un uso efficiente delle risorse, assicurando i tempi di risposta desiderati dalle applicazioni;
– la realizzazione, per produrre un codice che rispetti le specifiche definite nelle fasi precedenti, per aiutare la coordinazione tra i diversi gruppi impegnati nella realizzazione, e per facilitare la manutenzione ed il test di tale codice.
Il capitolo e` strutturato come segue. Nella Sezione 3.2 si approfondisce il ruolo delle metodologie nella produzione di un sistema informatico, e si introduce una metodo- logia in quattro fasi. Nella Sezione 3.3 vengono introdotti alcuni strumenti formali, diagrammi di flusso dati e di stato, che vengono usati in tutte le fasi della progetta- zione per rappresentare gli aspetti dinamici del sistema da realizzare. Infine, nelle Se- zioni 3.4 e 3.5 vengono presentate in maggior dettaglio le prime due fasi, l’analisi dei requisiti e la progettazione concettuale, della metodologia delineata nella Sezione 3.2.
3.2 Le metodologie di progettazione
Una metodologia di progettazione e` una descrizione di come operare per progettare una base di dati. Una metodologia stabilisce in quali fasi dividere la progettazione, come operare per svolgere i compiti propri di ciascuna fase, e quali documenti pro- durre al termine di ciascuna fase per tenere traccia dei risultati della fase, delle scelte operate durante tale fase e delle motivazioni di tali scelte.
In questa sezione, dopo avere inquadrato il ruolo delle metodologie, viene presen-
tata una metodologia a piu` fasi e viene discusso il ruolo della prototipazione.
3.2.1 Il ruolo delle metodologie
Per capire pienamente l’importanza di una metodologia di progettazione, si consideri che la progettazione e realizzazione di un qualunque progetto software coinvolge in generale tre figure:
1. il committente, che ha un problema e paga una ditta fornitrice perche´ lo risolva
(il quadro non cambia quando la ditta fornitrice e` in realta` una divisione diversa
della stessa organizzazione a cui appartiene il committente);
2. il responsabile del progetto, che e` un dirigente della ditta fornitrice che dirige il
processo di produzione del software. Il responsabile in generale non partecipa diretta- mente alla progettazione, ma fissa assieme al committente gli obiettivi del proget- to, alloca tempi e risorse (in particolare risorse umane) alla progettazione stessa, e verifica il buon uso delle risorse ed il rispetto dei tempi e degli obiettivi;
3. il progettista, che, assieme ad altri progettisti, realizza il progetto rispettando i tem- pi e gli obiettivi fissati dal responsabile, o contratta con il responsabile modifiche a tempi e obiettivi che si rivelino non realistici. In generale gruppi diversi parte- cipano a fasi diverse della progettazione, e persone diverse possono avvicendarsi anche all’interno di una singola fase o di un singolo compito.
In questo contesto, una metodologia dovrebbe soddisfare i seguenti obiettivi:
1. controllo costante di qualita`: la metodologia dovrebbe permettere di verificare co- stantemente la rispondenza di tutti i progetti intermedi ai requisiti dell’utente, poiche´ la correzione di un errore in una fase avanzata ha un costo molto superiore rispetto alla correzione di un errore in una fase precedente;
2. supporto al progettista: la metodologia dovrebbe permettere al progettista di sape- re in ogni momento come operare, pur senza limitarne in modo eccessivo la liberta` di azione;
3. supporto alla gestione: la struttura della metodologia dovrebbe permettere a chi gestisce il progetto di allocare le risorse per le varie fasi riducendo al minimo gli errori di valutazione. Le attivita` di produzione di documenti (documentazione) e di revisione del lavoro dei progettisti da parte di altri, previste da ogni metodologia, dovrebbero permettere a chi gestisce il progetto di verificare costantemente il ri- spetto dei tempi e degli obiettivi, e dovrebbero permettere di sostituire, in ogni
momento, uno o piu` progettisti, senza che questo pregiudichi l’andamento del progetto;
4. sovraccarico limitato: le attivita` di documentazione, incontri e revisione previste da
ogni metodologia tolgono tempo alla progettazione; queste attivita` devono essere
calibrate in modo tale che i benefici ottenuti superino il costo. A questo scopo, e` fondamentale l’utilizzo di strumenti di supporto informatici per la metodologia (strumenti CASE) che permettano di automatizzare tutti i compiti ripetitivi e che facilitino la produzione e gestione della documentazione.
In conclusione, le metodologie impongono in genere al progettista, come al program- matore, un forte sovraccarico, superiore di norma al tempo che il progettista utilizza per le attivita` di progettazione vera e propria. Questo sovraccarico e` giustificato pero`
3.2.2 Le metodologie con piu` fasi
Per situazioni complesse e` inevitabile l’adozione di una metodologia a piu` fasi in
cui i parametri di progetto vengono considerati gradualmente e le varie fasi sono coordinate per ottenere una realizzazione soddisfacente. Questo modo di procedere e` basato sul principio che applicazioni complesse si sviluppano per livelli di astrazione progressivamente piu` dettagliati. L’orientamento piu` consolidato prevede quattro fasi (vedi Figura 3.1): una di analisi, l’analisi dei requisiti, e tre di progettazione in senso stretto, la progettazione concettuale, la progettazione logica e la progettazione fisica.
Progettazione concettuale
Progettazione logica
Progettazione fisica
Figura 3.1: Schema di una metodologia a piu` fasi
– L’analisi dei requisiti serve a definire i bisogni del committente. Durante l’anali- si dei requisiti si stabilisce, assieme all’organizzazione committente, quali sono le interazioni che i vari settori dell’organizzazione committente hanno con il sistema informativo dell’organizzazione, e quali sono le nuove interazioni che il commiten- te desidera rendere possibili. Si raccolgono inoltre i parametri quantitativi relativi
alle informazioni gestite, nonche´ eventuali requisiti rispetto ai tempi di risposta
che si richiedono al sistema. Il risultato di questa fase e` un documento, la specifica dei requisiti, che descrive, in modo non ambiguo e comprensibile dal committente, i bisogni informativi del committente stesso.
– La progettazione concettuale serve a tradurre la specifica dei requisiti in un proget- to della struttura concettuale dei dati, dei vincoli e delle operazioni su questi dati. In particolare la struttura dei dati viene descritta utilizzando un formalismo che sia il piu` naturale possibile, e le operazioni vengono descritte senza effettuare nessuna scelta di tipo realizzativo, utilizzando formalismi quali quelli che saranno introdot- ti nella Sezione 3.3. Il risultato principale di questa fase e` lo schema concettuale che
– La progettazione logica serve a tradurre lo schema concettuale nello schema logico, che e` espresso nel modello dei dati del sistema scelto per la realizzazione della base di dati. Parallelamente, anche la descrizione delle operazioni viene specializzata rispetto allo schema logico. Il lavoro da svolgere in questa fase dipende molto dalle differenze tra il potere espressivo del modello concettuale e logico dei dati. Maggiori sono le differenze, maggiori saranno le trasformazioni da fare per passare dallo schema concettuale allo schema logico.
– La progettazione fisica serve a produrre lo schema fisico, che arricchisce lo schema logico con le informazioni relative all’organizzazione fisica dei dati.
Si noti che, sebbene le fasi siano concettualmente una successiva all’altra, il processo
di progettazione non e` lineare, perche´ puo` capitare che il progettista ritorni su de-
xxxxxxx prese in precedenza, quando il risultato di una fase non lo soddisfi. Questa operazione e` in generale piuttosto costosa, poiche´ ogni modifica sul risultato di una fase si ripercuote su tutte le fasi che la seguono. Inoltre, anche se sulla scomposizione in quattro fasi c’e` un generale accordo, lo stesso non succede per l’ulteriore scompo- sizione delle fasi in passi. Accade, infatti, che ogni specifica metodologia fissi diverse sequenze di passi per ciascuna fase, con diverse priorita`, facendo a volte rientrare in una fase o in un’altra i passi che si collocano ai margini.
Nel processo di progettazione si trattano aspetti strutturali, aspetti dinamici e aspetti quantitativi:
– Gli aspetti strutturali riguardano la struttura della conoscenza concreta e la cono- scenza astratta.
– Gli aspetti dinamici riguardano la conoscenza procedurale e la comunicazione.
– Gli aspetti quantitativi riguardano le informazioni che descrivono quantitativamen- te i fatti rappresentati e il modo in cui essi evolvono nel tempo. Queste informazioni sono importanti nelle fasi di progettazione logica e fisica per utilizzare al meglio il DBMS e per garantire che le applicazioni possano essere realizzate con le prestazio- ni desiderate. Rientrano in questa categoria sia gli aspetti quantitativi riguardanti la struttura della base di dati sia quelli riguardanti le operazioni. I primi riguardano
una stima (a) del numero di entita` di ogni tipo, (b) del campo di variabilita` dei
valori delle proprieta` e di eventuali correlazioni fra i valori di proprieta` delle entita` dello stesso tipo, (c) del numero di entita` coinvolte in ogni associazione. I secondi riguardano una stima della frequenza di attivazione delle operazioni che usano la base di dati e del numero di entita` e di istanze di associazione coinvolte.
In Tabella 3.1 e` riassunto su quali aspetti si concentrano le diverse fasi. Per ogni fase sono stati sviluppati strumenti automatici per la raccolta delle specifiche, per la loro analisi e documentazione.
Progetto concettuale | Progetto logico | Progetto fisico | ||
Aspetti strutturali | S`i | S`i | S`i | S`i |
Aspetti dinamici | S`i | S`i | S`i | S`i |
Aspetti quantitativi | S`i | No | S`i | S`i |
Modello dei dati del DBMS | No | No | S`i | S`i |
Caratteristiche del DBMS | No | No | No | S`i |
Tabella 3.1: Aspetti trattati nelle varie fasi della progettazione.
3.2.3 Le metodologie con prototipazione
In generale il prodotto principale della progettazione e` la specifica della struttura del- la base di dati e delle operazioni in un linguaggio non eseguibile. Successivamente si passa alla fase di codifica nel linguaggio del DBMS prescelto e poi si procede con le altre fasi tradizionali del processo di sviluppo del software: validazione, prova, messa a punto e manutenzione (vedi Figura 3.2a). Questo modo di procedere ha un grosso incon- veniente: gli utenti possono verificare che il prodotto soddisfa le loro aspettative solo dopo che una prima realizzazione sia funzionante. Pertanto eventuali incomprensioni nella fase di raccolta dei requisiti, oppure la mancanza di chiarezza degli obiettivi da parte dei committenti, affiorano quando la realizzazione e` ormai gia` iniziata e i costi delle modifiche per adeguarla ai bisogni reali diventano maggiori.
Per evitare questo problema e` stato proposto un modo diverso di affrontare la pro- gettazione e realizzazione delle applicazioni, che prevede la costruzione di prototipi nelle fasi iniziali della metodologia tradizionale; ad esempio, dopo l’analisi dei re- quisiti, per fare prototipi delle interfacce, oppure dopo la progettazione concettuale
per fare un prototipo della base di dati. Un prototipo e` una versione preliminare e
funzionante di cio` che va realizzato, che esibisca le caratteristiche funzionali essen-
xxxxx, prescindendo dai requisiti sulle prestazioni. Ovviamente, affinche´ un impegno
di prototipazione risulti economicamente vantaggioso, il costo della realizzazione dei prototipi deve essere una piccola frazione del costo di una prima realizzazione delle applicazioni sul DBMS prescelto. Cio` e` possibile usando strumenti specializzati per la produzione rapida di prototipi. Disponendo rapidamente di un prototipo, sperimen- tabile dagli utenti in una fase iniziale del processo di progettazione, si e` in grado di verificare se il prodotto che si sta realizzando soddisfa le aspettative, prima di passare alla sua realizzazione, e di chiarire cos`ı prima possibile quali sono i reali bisogni degli utenti.
Specfica dei requisiti
Progettazione base di dati
Specifiche non eseguibili
Codifica Schema e programmi
Validazione
Prova
Messa a punto
Manutenzione
Progettazione concettuale
Prototipo
Validazione
Prova
Progettazione logica e fisica
Schema e programmi
Messa a punto
Manutenzione
(a) (b)
Figura 3.2: Approccio tradizionale e con prototipazione
Il prototipo della base di dati puo` essere del tipo “usa e getta”, nel senso che non ha
altro impiego nelle fasi successive della metodologia, oppure puo` essere trasformato
in un prototipo espresso a livello di progetto logico e costituire cos`ı una specifica operazionale della base di dati e delle applicazioni, oppure ancora puo` essere il punto di partenza per un modo diverso di realizzare le applicazioni, come schematizzato in Figura 3.2b: il codice delle applicazioni viene ottenuto applicando al prototipo una serie di trasformazioni automatiche, o semi automatiche. Sul codice cos`ı prodotto rimarra` solo da compiere un passo di completamento per trattare tutti quegli aspetti delle applicazioni non considerati nel passo di prototipazione.
3.3 Gli strumenti formali
Le metodologie presentate adottano meccanismi di astrazione e formalismi diver- si durante le varie fasi del processo di progettazione. Questi formalismi ricadono principalmente nelle seguenti categorie:
– diagrammi per la descrizione dei dati: servono a descrivere la struttura dei dati; i diagrammi entita`-relazioni e la rappresentazione grafica del modello a oggetti definiti nel Capitolo 2 sono esempi tipici;
– diagrammi di flusso dati: servono a descrivere le operazioni, mostrando in partico- lare come ognuna possa essere divisa in sottooperazioni e qual e` il flusso dei dati tra queste operazioni;
– diagrammi di stato: servono a descrivere in che modo lo stato del sistema, o meglio lo stato di una qualche componente del sistema, evolve in corrispondenza di un evento; servono a specificare sistemi che reagiscono ad eventi, quindi in particolare la parte di un’applicazione che gestisce il dialogo con l’utente.
I diagrammi di flusso dati ed i diagrammi di stato sono introdotti, senza pretese di completezza, nelle prossime sezioni.
3.3.1 I diagrammi di flusso dati
Un diagramma di flusso dati (Data Flow Diagram, DFD) rappresenta un sistema in cui alcuni processi, in cooperazione tra loro e con l’ausilio di alcuni depositi dati (data store), svolgono determinate funzioni e comunicano con alcuni agenti esterni detti interfacce, o attori. Processi, depositi dati ed interfacce sono rappresentati con le convenzioni grafiche riportate in Figura 3.3.
Deposito dati
Interfaccia
Figura 3.3: Simbologia dei diagrammi di flusso dati
Un diagramma di flusso dati rappresenta esplicitamente il flusso dei dati tra i vari processi e tra questi, i depositi e le interfacce, tuttavia non specifica il flusso del con- trollo o la temporizzazione, ovvero non specifica ne´ il fatto che un flusso dati avviene prima di un altro, ne´ il fatto che un flusso dati avviene solo sotto certe condizioni.
Un primo esempio di diagramma di flusso dati e` riportato in Figura 3.4. Questo dia- gramma rappresenta il fatto che il processo “gestione esami” (rappresentato attraverso un ovale) scambia informazioni con le interfacce “studente” e “docente”. Ad esem-
xxx, e` presente un flusso “consegna certificato” tra la gestione esami e lo studente,
ed un flusso “richiesta certificato” nella direzione opposta. Si osservi che i due flussi sono simmetrici, per cui il diagramma non specifica formalmente l’esistenza di una relazione causale o neppure temporale tra i due flussi. Il diagramma ha un’effettiva utilita` solo perche´ si suppone che queste informazioni relative al flusso del controllo
Nell’analisi e progettazione degli aspetti dinamici di un sistema informativo (analisi dinamica o analisi funzionale) si parte in genere da un diagramma di flusso dati in cui
l’intero sistema e` rappresentato da un unico processo sul quale convergono tutte le
richieste delle interfacce (gli agenti esterni), come quello rappresentato in Figura 3.4; questo particolare diagramma e` chiamato il diagramma di contesto.
Immissione dati esame
Studente
Richiesta certificato
Conferma o rifiuto esame
Consegna certificato
Gestione esami
Studente
Presentazione piano di studi
Figura 3.4: Diagramma di contesto
A questo punto ogni processo puo` essere suddiviso, se questo risulta utile, in
piu` sottoprocessi che comunicano attraverso flussi dati o attraverso depositi, come
esemplificato in Figura 3.6 per il processo “verifica e immissione dati esami”.
Il momento in cui interrompere questa suddivisione dipende dallo scopo del dia- gramma, ovvero dal livello di astrazione al quale si e` interessati. In generale, si segue il criterio dell’indipendenza funzionale tra processi, che specifica che (a) ogni sottopro- cesso deve fare una sola cosa e (b) che sottoprocessi diversi devono scambiare meno
dati possibile. Il criterio (a) indica in quali casi e` necessario scomporre un processo,
mentre il criterio (b) indica in quali casi la scomposizione si debba interrompere. L’analisi delle funzioni e` strettamente collegata all’analisi dei dati, ovvero alla pro-
duzione dello schema. Alcune metodologie prevedono infatti che l’analisi delle fun-
zioni sia eseguita per prima, poi si analizzi lo schema di ogni singolo deposito dati nominato nell’analisi funzionale, ed infine si integrino questi schemi per produrre lo schema concettuale globale.
one me | Co rifiu | |
Immissi dati esa
nferma o to esame
Studenti
Verifica e immissione dati esami
Richiesta certificato
Stampa certificati
Consegna certificato
Gestione piani di studio
Presentazione piano di studi
Esami
Studente
Studente
PianiDiStudio
Esami
DocentiCorsi
Figura 3.5: Diagramma di flusso, versione astratta
Docente | ||
sione ame | Con rifiut | |
ferma o o esame
Verifica dati esami Dati esame
Memorizzazione dati esami
Esami
DocentiCorsi
PianiDiStudio
Figura 3.6: Diagramma di flusso, versione meno astratta
Esempio 3.1 Ad esempio, l’analisi separata dei cinque depositi del diagramma di Figura 3.5 potrebbe produrre i cinque sottoschemi della Figura 3.7, quattro con una sola classe ed uno di due classi, i quali possono essere poi integrati, come descritto nella sezione 3.5.3, per produrre lo schema in Figura 3.8.
In questo esempio abbiamo volutamente estremizzato gli effetti dell’analisi se- parata dei depositi, per rendere piu` chiaro il fatto che l’integrazione di questi schemi comporta alcune ristrutturazioni degli schemi stessi. Ad esempio, in en- trambi gli schemi per i due depositi chiamati Esami, invece di riconoscere l’esi-
stenza di una seconda classe Studenti cui appartiene l’attributo Matricola, questa viene considerata un attributo dell’esame. Questo modello e` ragionevole solo se si considera il deposito Esami in maniera completamente isolata, ma e` scorretto non appena si considerano anche gli studenti come entita` di interesse.
Nome Codice
Insegna
Corsi
Codice Nome
Studenti
Nome Matricola
Esami
Matricola NomeCorso Data CodiceCorso CodiceDocente Voto
Esami
Matricola NomeCorso Data
Voto
PianiDiStudio
Nome Matricola
CorsiPrimoAnno
...
CorsiUltimoAnno
Figura 3.7: Schemi dei cinque depositi indicati nel diagramma precedente
Nome Matricola
HaPresentato
PianiDiStudio
HaSostenuto
Corsi Primo Anno
...
Corsi Ultimo Anno
Esami
Data Voto
Riguarda
Corsi E` TenutoDa Docenti
Codice Nome
Nome Codice
Figura 3.8: Schema prodotto integrando i cinque sottoschemi
Questa metodologia viene criticata, sulla base del fatto che l’insieme di operazioni che si richiedono ad un sistema informativo tende a cambiare nel tempo, e a produrre quindi schemi concettuali sempre diversi, ed ogni modifica dello schema concettuale ha un costo molto alto, poiche´ costringe a rieseguire tutte le fasi successive. Sono state quindi proposte metodologie in cui l’analisi dei dati, ovvero il disegno dello schema concettuale, viene eseguita tenendo conto per prima cosa della struttura della realta`
Per maggiori dettagli sui diagrammi di flusso dati si vedano ad esempio [Yourdon, 1989; Xxxxxx et al., 1992; Xxxxx, 1979; Xxxxxxxx et al., 1991].
3.3.2 I diagrammi di stato
Un diagramma di stato (state diagram) e` un grafo etichettato che modella il modo in
cui un sistema reagisce ad eventi esterni, ed e` quindi particolarmente indicato per
modellare il comportamento delle interfacce di un sistema informatico, ma anche per modellare in che modo un oggetto reagisce ai messaggi che riceve.
Un sistema viene modellato supponendo che esso si trovi in ogni momento in un determinato stato, durante il quale esso svolge un’attivita`; il sistema permane in questo stato fino a che un evento non provoca una transizione di stato. La differenza tra stati e transizioni e` che il sistema resta in uno stato per un tempo non trascurabile, mentre
la durata di una transizione di stato e` trascurabile (la transizione e` “istantanea”).
Quindi, come verra` esemplificato tra poco, la differenza tra una transizione ed una
terna <transizione, stato intermedio, transizione> non e` sempre ovvia, e dipende in generale dal livello di astrazione a cui ci si pone.
Ad esempio, il diagramma in Figura 3.9 specifica che l’operazione di registrazione esami passa attraverso tre stati, uno di acquisizione dati, uno di verifica dati ed uno di memorizzazione dati. Si osservi che, mentre gli eventi “immissione completa” e “richiesta abort” sono di origine esterna, gli eventi “fallimento verifica”, “dati verifi- cati” e “dati memorizzati” sono in effetti eventi generati dall’applicazione stessa. La notazione “e/a” indica che il sistema reagisce all’evento “e” compiendo contempora- neamente una transizione di stato ed un’azione istantanea “a”. La freccia con un pallino a sinistra indica lo stato iniziale del sistema.
Segnala abort
Immissione completa
Acquisizione dati
Fallimento verifica /
Segnala fallimento
Verifica dati
Dati verificati Memorizzazione dati
Memorizzazione completa
Figura 3.9: Un diagramma di stato
Anche i diagrammi di stato si prestano bene alla progettazione per raffinamento,
scomponendo uno stato in sottostati. In Figura 3.10 e` esemplificata una notazione
Immissione completa
Immissione corso Acquisizione e data completa dati corso e
data
Acquisizione dati studente e voto
Verifica dati
Segnalazione effettuata
Fallimento verifica
Segnala Abort
Richiesta abort
Richiesta abort
Figura 3.10: Diagramma di stato con sottostati
Nella stessa figura si mostra anche come, ad un maggior livello di dettaglio, un’a- zione associata ad una transizione (“segnala abort”) possa essere anche considerata un’operazione eseguita dal sistema in un certo stato. Ad un livello successivo, si po- trebbe effettuare un’ulteriore scomposizione anche dell’operazione “segnala abort”, che probabilmente visualizza una finestra con un messaggio di errore e attende una conferma dall’utente, mentre in parallelo memorizza l’avvenuto abort su di un ar- chivio opportuno. Un’analisi analoga potrebbe essere eseguita per l’azione “segnala fallimento” associata all’evento “fallimento verifica”.
Per i diagrammi di flusso sono stati definiti anche degli altri meccanismi di strut-
turazione piuttosto sofisticati, ad esempio per rappresentare il parallelismo che e`
concettualmente insito in molti sistemi. Per questi dettagli, e per approfondimenti, rimandiamo, ad esempio, a [Xxxxx, 1987; Xxxxxxxx et al., 1991].
Riassumendo, la differenza fondamentale tra i diagrammi di stato ed i diagrammi di flusso dati consiste nel fatto che i primi rappresentano il flusso del controllo, che viene essenzialmente ignorato nei secondi, mentre questi si concentrano sul flusso e sulla memorizzazione dei dati, ignorati nei primi. I due formalismi non sono comunque del tutto ortogonali e i diagrammi di stato sono meno utilizzati, rispetto a quelli di flusso dati, nelle metodologie per la progettazione di basi di dati.
3.4 L’analisi dei requisiti
In questa sezione e nella successiva presentiamo le caratteristiche principali delle fa- si di analisi dei requisiti e di progettazione concettuale, per dare dei suggerimenti su come procedere nella definizione dello schema concettuale di una base di dati. L’atten- zione xxxx` sostanzialmente rivolta agli aspetti strutturali (progettazione dei dati) con cenni agli aspetti dinamici (progettazione delle procedure). Infine, non verranno prese
in considerazione le fasi di progettazione logica e fisica, xxxxxx´ una trattazione di una metodologia completa esula dai fini di questo testo; per approfondire l’argomento si rinvia alla letteratura segnalata nelle note bibliografiche.
3.4.1 Scopo dell’analisi dei requisiti
L’analisi dei requisiti presuppone un adeguato studio preliminare dell’organizzazio- ne, e delle sue finalita`, che abbia valutato i seguenti aspetti:
1. gli obiettivi del sistema informatico da realizzare;
2. le attivita` dell’organizzazione che devono essere supportate dal sistema informati- co;
3. le unita` organizzative (settori o aree funzionali) che utilizzeranno il sistema informa- tico;
4. il piano di sviluppo del sistema informatico, ed uno studio di fattibilita` che abbia
stimato i costi e i tempi di tale piano di sviluppo, per verificarne l’effettiva conve- nienza.
Il risultato di questo studio preliminare riguarda pertanto scelte fondamentali del- l’organizzazione e del suo modo di funzionare, presumibilmente invarianti nel medio
termine, dalle quali non si puo` prescindere nell’affrontare l’analisi dei requisiti. Con
questo studio, inoltre, vengono gia` individuati, ad un massimo livello di astrazio-
ne, i bisogni informativi, le procedure di interesse e le loro interazioni con i settori dell’organizzazione.
L’analisi dei requisiti raffina i risultati dello studio preliminare specificando in ma-
niera piu` precisa cio` che l’organizzazione, ed i vari settori che la compongono, si
aspetta dal sistema informatico in corso di progettazione, arrivando a delineare in particolare la struttura delle informazioni da trattare e le procedure che dovranno essere realizzate.
Il risultato della fase di analisi dei requisiti consiste in una serie di documenti che specificano:
– Le informazioni scambiate o condivise tra i settori, fissando il significato dei ter- mini. Molto spesso, infatti, passando da un settore ad un altro, lo stesso termine e` usato con significati diversi (omonimi) oppure termini diversi denotano la stessa cosa (sinonimi).
– La struttura della conoscenza concreta e astratta.
– La conoscenza procedurale, ponendo l’attenzione sui servizi che il sistema deve offrire ai suoi utenti per definire cosa devono fare le operazioni, piuttosto che come lo fanno, e sulle loro modalita` di attivazione.
– Aspetti quantitativi riguardanti la struttura della base di dati e le modalita` dei dati.
– Fatti riguardanti il grado di privatezza e di sicurezza da prevedere sui dati.
d’uso
Il risultato della fase di analisi dei requisiti puo` essere dato in modi diversi, i qua-
li possono anche coesistere: (a) informalmente, con linguaggio naturale ristretto, (b)
con opportune tabelle integrate da rappresentazioni diagrammatiche o (c) con un linguaggio formale non eseguibile. Altre differenze fra le varie proposte riguardano i meccanismi di astrazione su cui si basa il linguaggio di specifica per trattare gli aspetti strutturali e dinamici.
3.4.2 Come procedere
La fase di analisi dei requisiti richiede un forte impegno e una notevole esperienza da parte del progettista. Egli acquisisce familiarita` con il funzionamento dell’organiz- zazione utilizzando fonti diverse: interviste agli utenti, analisi di documenti esistenti (modulistica, archivi cartacei, ordini di servizio, schemi dei dati di realizzazioni gia`
operative). Le informazioni sono di solito raccolte svolgendo due tipi di attivita` che
in linea di principio possono procedere in parallelo, ma che spesso si intrecciano e si influenzano a vicenda: l’analisi dei dati e l’analisi funzionale.
Con l’analisi dei dati, il progettista si dedica inizialmente alla comprensione e alla specifica degli aspetti strutturali, in particolare di quei fatti da memorizzare nella base di dati, cercando di darne una descrizione indipendente da come essi vengono utilizzati dalle operazioni. Successivamente si specificano le operazioni controllando che siano eseguibili con le informazioni disponibili.
Con l’analisi funzionale il progettista specifica inizialmente le operazioni delle appli- cazioni per ricavare, poi, una descrizione delle informazioni necessarie per eseguirle. Come gia` detto in precedenza, l’analisi dei dati e l’analisi funzionale possono essere eseguite in qualunque ordine, purche´ si effettui, alla fine, un controllo di coerenza tra i risultati delle due fasi; in pratica, risulta conveniente effettuare queste due analisi con un certo grado di parallelismo, tenendo presenti i risultati intermedi dell’una mentre
si esegue l’altra.
Sono stati proposti vari strumenti automatici, spesso integrati in ambienti CASE, per agevolare il trattamento e la gestione memorizzazione e l’aggiornamento delle varie forme di specifiche, per segnalare incompletezze e inconsistenze, per generare come documentazione opportune tabelle riassuntive e di incroci.
Nel seguito si mostra un esempio di metodologia di analisi dei requisiti, focaliz-
zata sull’analisi dei dati. La metodologia e` descritta informalmente ed esemplificata
attraverso l’analisi di un’applicazione per la gestione degli studenti di un’universita`. Per ogni settore aziendale si procede con i seguenti passi:
1. Si analizza il sistema informativo esistente raccogliendo una prima versione dei requisiti, espressa in linguaggio naturale.
2. Si rivedono i requisiti espressi in linguaggio naturale, per eliminare ambiguita`, imprecisioni e disuniformita` linguistiche.
3. Si raggruppano le frasi relative a categorie diverse di dati, vincoli e operazioni.
4. Si costruisce un glossario dei termini (questo passo viene in realta` temporaneamente ai due precedenti).
eseguito con-
5. Si definisce uno schema preliminare di settore, detto schema scheletro, con il quale si individuano ad un primo livello di dettaglio le classi e le associazioni fra le classi
piu` significative.
6. Si specificano le operazioni degli utenti.
7. Si verifica la completezza (tutti gli aspetti dei requisiti sono stati presi in consi- derazione) e consistenza (tutti i concetti usati nella specifica sono stati definiti, in particolare le operazioni fanno riferimento a dati definiti e i dati definiti sono usati dalle operazioni).
3.4.3 Un esempio di analisi dei requisiti
Immaginiamo di voler progettare una base di dati per la gestione della segreteria studenti di un Corso di Laurea in Informatica, e di effettuare l’analisi dei requisiti relativamente al settore che si occupa delle richieste di trasferimento al Corso di Lau- rea, occupandoci in particolare di quelle informazioni che servono alla progettazione della struttura dei dati.
Analisi del sistema informativo esistente e raccolta di una versione dei requisiti in linguaggio naturale (passo 1)
L’analisi del sistema informativo esistente permette al progettista di acquisire fami-
liarita` con i compiti svolti nei settori interessati all’automazione delle applicazioni,
interagendo con gli utenti dei diversi livelli gerarchici per comprendere le loro esi- genze e per far comprendere come potra` essere influenzato il loro lavoro. Il coinvol-
gimento degli utenti e` importante per avere la loro collaborazione nella raccolta dei
requisiti, perche´ imprecisioni in questa fase avranno notevoli ripercussioni sul costo
complessivo della realizzazione.
Nel nostro esempio, intervistando il personale, si e` ottenuta la seguente descrizione delle informazioni da gestire e dei servizi da prevedere.
Questa segreteria si occupa della gestione di alcune pratiche relative agli studenti del Corso di Laurea in Informatica. In particolare, noi gestiamo le richieste di trasferimento di studen- ti che provengono da altri Corsi di Xxxxxx. Quando uno studente desidera trasferirsi da noi, presenta domanda al Dipartimento di appartenenza, che la trasmette al nostra Dipartimento, che poi la trasmette a questa segreteria. La segreteria apre una pratica e trasmette la domanda alla commissione Pratiche Studenti del Consiglio del Corso di Studio (CCS) che prepara una bozza di delibera, nella quale si specificano quali esami vengono riconosciuti allo studente, eventualmente con un colloquio integrativo. Nel convalidare gli esami, si tiene conto del modo in cui esami analoghi sono stati convalidati in passato. Normalmente, cerchiamo di trattare nello stesso modo esami con lo stesso nome fatti nello stesso Dipartimento, ma possono esserci delle eccezioni quando i contenuti sono diversi. Per cio` che riguarda le informazioni da tratta- re, una domanda di trasferimento ha un numero di protocollo, e contiene il nome e il recapito dello studente che la presenta, il Corso di Xxxxxx di provenienza, la data di presentazione, e l’elenco degli esami esterni superati. Il numero di protocollo e` assegnato da noi ed e` diverso da pratica a pratica. Per ogni domanda di trasferimento viene creata una pratica di trasferimento, che ha un proprio numero d’ordine e che contiene la domanda di trasferimento ed eventuali nostre annotazioni, e conterra` poi la delibera relativa. Una bozza di delibera specifica come sono convalidati gli esami dello studente, e puo` contenere delle annotazioni. Una delibera approvata
contiene anche il numero e la data del verbale del CCS che ha approvato tale delibera. Un esa- me da convalidare e` caratterizzato da un’Universita`, un Dipartimento, un Corso di Laurea, un Nome, un Anno Accademico. L’Universita`, il Dipartimento e il Corso di Laurea dove l’esame e` stato superato non coincidono necessariamente con l’Universita` di provenienza, il Diparti- mento di provenienza e il Corso di Laurea di provenienza della domanda a cui l’esame esterno appartiene. Gli esami interni hanno un nome e un codice univoco. Quando un esame esterno e` convalidato per un esame interno, la convalida puo` essere “piena” o “previo colloquio”. Per alcuni esami esterni esiste una “convalida tipica”. Ad esempio, la convalida tipica dell’esame di Fisica I a Ingegneria Elettronica, Dipartimento di Ingegneria, e` “Fisica Generale”. La con- valida tipica sarebbe utile per la preparazione automatica della bozza di delibera. La convalida tipica puo` essere “previo colloquio”. Non sempre un esame dato da uno studente e` convalidato secondo la sua convalida tipica.
Siamo interessati ad un sistema che permetta di memorizzare tutte le informazioni relative alle pratiche di trasferimento che vengono via via sbrigate. Questo sistema dovrebbe essere anche in grado di preparare una bozza di verbale a partire dall’elenco degli esami allegato ad una domanda di trasferimento, lasciando pero` alla segreteria la possibilita` di intervenire per modificare i riconoscimenti proposti dal sistema.
Per ottenere la specifica dei requisiti, questa descrizione va rielaborata per eliminare le informazioni non rilevanti, aggiungere quelle mancanti, eliminare sinonimie (termini diversi che indicano la stessa cosa), omonimie (termini uguali che indicano cose di- verse) ed ambiguita`. Inoltre, e` bene che la specifica dei requisiti sia scritta utilizzando
frasi con una struttura il piu` possibile elementare ed omogenea, come nell’esempio che segue.
Revisione dei requisiti e raggruppamento delle frasi (passi 2 e 3)
La revisione dei requisiti produce la seguente specifica.
Frasi di carattere generale Si vogliono gestire informazioni relative a domande di trasfe- rimento ed alla corrispondenza tra corsi esterni e corsi interni.
Frasi relative alle domande di trasferimento Di una domanda di trasferimento interessa- no: il numero di protocollo, che la identifica, il nome e il recapito dello studente che la presenta, l’Universita` di provenienza, il Dipartimento di provenienza, il Corso di Laurea di provenienza, la data di presentazione, l’elenco dei corsi esterni per i quali e` stato superato l’esame.
Frasi relative alle pratiche di trasferimento Di una pratica di trasferimento interessano: la domanda di trasferimento cui si riferisce, il numero progressivo che la identifica, le eventuali annotazioni e l’eventuale delibera relativa.
Frasi relative alle delibere Di una delibera interessa: la pratica relativa, l’insieme di con- valide di esami, le eventuali annotazioni, la data ed il numero del verbale del CCS che ha approvato il trasferimento (che puo` mancare se si tratta solo di una bozza).
Frasi relative ai corsi esterni Di un corso esterno interessano: il nome del corso, l’Anno Accademico, l’Universita`, il Dipartimento e il Corso di Laurea dove l’esame relativo al cor- so e` stato superato. L’Universita`, il Dipartimento e il Corso di Laurea dove l’esame e` stato superato non coincidono necessariamente con l’Universita` di provenienza, il Dipartimento di provenienza e il Corso di Laurea di provenienza della domanda di trasferimento a cui il corso esterno appartiene.
Frasi relative ai corsi interni Di un corso interno interessano: il nome e il numero di crediti.
Frasi relative ad una convalida di un esame Di una convalida di un esame interessano: il corso esterno, il corso interno e sapere se l’esame e` stato convalidato “previo colloquio”. Il corso esterno di una convalida e` detto “convalidato per” il corso interno.
Frasi relative ad una convalida tipica Di una convalida tipica interessano: il corso ester- no, il corso interno e se l’esame viene convalidato “previo colloquio”.
La convalida tipica non vincola le convalide degli esami, ma puo` essere utilizzata per la pre- parazione automatica di una prima versione della bozza di delibera a partire da una domanda di trasferimento.
Frasi relative alle operazioni Il servizio che il sistema deve offrire agli utenti prevede
le seguenti operazioni, per le quali andranno definite opportune modalita` di interazione da
concordare con gli interessati (tra parentesi e` riportata una stima della frequenza d’uso):
1. Inserimento di corsi interni (3 volte all’anno).
2. Immissione di una domanda di trasferimento (70 volte all’anno).
3. Generazione di una bozza di delibera a partire dall’elenco dei corsi esterni superati allegato ad una domanda (70 volte all’anno).
4. Correzione manuale di una bozza di delibera (30 volte all’anno).
5. Trasformazione di una bozza di delibera in delibera approvata (70 volte all’anno).
Costruzione del glossario (passo 4)
Come gia` detto, il glossario viene in realta` costruito durante la fase di revisione dei
requisiti. In particolare, ogni volta che si sceglie, in un gruppo di sinonimi, quello che verra` utilizzato nella specifica dei requisiti, questa scelta deve essere riportata subito nel glossario, come esemplificato sotto per i termini “Riconoscimento di esame” e “Convalida di esame”.
Si riportano, a titolo di esempio, le definizioni di alcuni dei termini usati nella specifica dei requisiti:
CCS : Consiglio di Corso di Studio
Bozza di delibera Versione preliminare di una delibera relativa alla domanda di tra- sferimento di uno studente. Specifica un insieme di convalide per i xxxxx xxxxx-
ni superati dallo stesso studente. Puo` essere modificata. Diventa una “delibera
approvata”, immutabile, dopo che e` verbale.
stata approvata dal CCS. Sinonimi: Bozza di
Bozza di verbale Usa: Bozza di delibera.
Convalida di esame Parte di una delibera; stabilisce che l’esame esterno X e` convali- dato per il superamento dell’esame di un corso interno Y, eventualmente previo il superamento di un colloquio. Sinonimi: Riconoscimento di esame.
Corso esterno Corso attivato presso un’istituzione universitaria o assimilata, ma non
presso il Corso di Laurea in Informatica dell’Universita` in questione; ad esem-
xxx: il corso di “Analisi I” attivato dal Corso di Laurea in Ingegneria Elettronica, Dipartimento di Ingegneria, Universita` di Padova, nell’Anno Accademico 2004/05.
Corso esterno superato Un corso esterno e` stato superato da uno studente quando
lo studente ha superato con successo l’esame relativo a tale corso.
Corso interno Corso attivato presso il Corso di Laurea in Informatica dell’Universita` in questione.
Crediti Unita` di misura della dimensione di un corso, in relazione all’impegno ne-
xxxxxxxx ad uno studente medio per la preparazione al corso. L’impegno totale dei corsi da superare in un anno e`, di norma, di 60 crediti.
Domanda di trasferimento Domanda con la quale uno studente iscritto in altro Cor- so di Xxxxxx chiede il trasferimento a questo Corso di Xxxxxx, chiedendo che gli vengano convalidati alcuni esami che ha superato (esami esterni).
Esame Il processo attraverso cui si verifica che lo studente abbia appreso i contenuti di un corso. Quando la verifica da` esito positivo, l’esame e` superato.
Esame esterno Xxxxx relativo ad un xxxxx xxxxxxx, xxxxxxxx prima di fare la doman- da di trasferimento. Non e` stato necessariamente superato presso il Corso di Laurea al quale lo studente era iscritto nel momento in cui ha presentato la domanda di trasferimento.
Riconoscimento di esame Usa: Convalida di esame.
Definizione dello schema scheletro (passo 5)
Lo schema scheletro di settore puo` essere definito a diversi livelli di dettaglio. Alcu-
ne metodologie piu` recenti orientate agli oggetti prevedono di terminare la specifica
dei requisiti con uno schema dei dati completo, usando un formalismo come quello suggerito nel capitolo precedente. Altre metodologie suggeriscono invece di limitarsi in questa fase ad uno schema dei fatti essenziali, da completare poi nella fase di pro- gettazione concettuale, e altre ancora non prevedono uno schema dei dati nella fase di analisi dei requisiti. Si preferisce non entrare nel merito di cosa convenga definire in uno schema scheletro e nello sviluppo dell’esempio si decide di considerare come
fatti essenziali le classi e le associazioni ritenute piu` importanti, ma si lascia al pro-
gettista l’eventuale decisione di anticipare alcuni dei passi di raffinamento suggeriti
piu` avanti per aggiungere altri dettagli. Si tenga comunque presente che una visione
panoramica di alto livello della struttura della base di dati consente di anticipare con i committenti una verifica sulla corretta interpretazione degli aspetti essenziali dei requisiti, prima di procedere con i passi di raffinamento e di completamento previ-
sti nella fase di progettazione concettuale. Lo schema scheletro si definisce, pertanto,
procedendo come segue (tenendo conto che ciascuno di questi passi puo` di modificare alcune scelte fatte nei passi precedenti):
1. Identifica le classi.
2. Descrivi le associazioni fra le classi.
3. Individua le sottoclassi.
richiedere
Identificare le classi
Si produce una lista preliminare delle classi di oggetti che interessa modellare e si assegna ad ognuna di esse un nome appropriato. Questo elenco iniziale ha un gra-
do di completezza e di significativita` che dipende dal grado di comprensione della
realta` osservata e, in generale, xxxx` soggetto a modifiche mano a mano che si procede.
Nella scelta iniziale delle classi si tengono presenti le entita` di cui si vogliono ricor-
dare alcuni fatti, senza nessuna pretesa di minimalita`. Eventuali ridondanze verranno eliminate successivamente.
Supponiamo che le classi individuate in questa fase siano DomandeTrasferimento, PraticheTrasferimento, Delibere, ConvalideTipiche, CorsiEsterni, CorsiInterni.
Descrivere le associazioni fra le classi
|
Domande Trasferimento
Causa
|
Pratiche Trasferimento
ConsideratoIn
|
ApprovataIn
|
— EvasaDa
Delibere
—
Convalida Esami
— Convalida
CorsiEsterni
|
|
CorsiInterni
ConvalideTipiche
PrevioColloquio
Figura 3.11: Prima versione dello schema
L’analisi delle associazioni puo` indurre ad eliminare una classe che puo` essere rap-
presentata da un’associazione, o ad aggiungere una nuova classe per rappresentare un’associazione, in particolare se interessa rappresentare alcuni attributi di quell’as- sociazione.
Ad esempio, la classe delle convalide tipiche contiene solo delle coppie (corso ester- no, corso interno), con un attributo booleano che indica se e` richiesto un colloquio. In
questa fase si puo` decidere di rappresentare tale informazione attraverso un’associa-
zione tra corsi esterni e corsi interni.
Viceversa, si consideri l’associazione ternaria tra Delibere, CorsiEsterni e CorsiInterni, che stabilisce, per ogni delibera, quali specifiche convalide sono state effettuate. In
questa fase si puo` decidere di rappresentare tale associazione con una nuova classe
ConvalideEsami, che conterra` quindi un elemento per ogni “convalida specifica”, quale ad esempio “l’esame di Analisi I superato l’A.A. 2004/05 ad Ingegneria Civile da Xxxxx Xxxxx e` convalidato per Analisi I interna”.
Individuare le sottoclassi
Per definire le sottoclassi si esaminano tutte le classi gia` definite per capire (a) se puo` essere utile definirne di nuove per caratterizzare particolari sottoinsiemi di alcune classi, (b) se esistono classi che sono un sottoinsieme di altre e quindi possono esse- re ridefinite, e (c) se esistono oggetti di classi che possono assumere nel tempo stati significativi per l’applicazione, caratterizzati da attributi propri (ad esempio, gli stati di “bozza” e di “delibera approvata” di una delibera), e quindi suggeriscono l’oppor- tunita` di specializzare le relative classi per distinguere gli oggetti in base allo stato in cui si trovano.
Ad esempio, in questa fase possiamo individuare le sottoclassi BozzeDiDelibera e DelibereApprovate che distinguono le delibere sulla base del loro stato di approvazione (Figura 3.12).
|
Domande Trasferimento
Causa
|
Pratiche Trasferimento
ConsideratoIn
|
Convalida Esami
ApprovataIn
|
— EvasaDa
Delibere
—
— Convalida
CorsiEsterni
|
|
CorsiInterni
BozzeDi Delibere
Delibere Approvate
ConvalideTipiche
PrevioColloquio
Figura 3.12: Schema con sottoclassi
Specifica delle operazioni (passo 6)
In Figura 3.13 e` mostrata la specifica dell’operazione degli utenti ImmissioneDomanda- DiTrasferimento usando il formalismo proposto nel capitolo precedente. Si noti come in questa fase di un’operazione si specifica sostanzialmente l’interazione con l’utente e i depositi dei dati interessati, volendo usare la terminologia dei diagrammi di flusso dati.
Operazione ImmissioneDomandaDiTrasferimento
Scopo Immissione dei dati di una domanda di trasferimento
Argomenti NomeStudente :string,
RecapitoStudente :string, UniversitaDiProvenienza :string, DipartimentoDiProvenienza :string, CorsoDiLaureaDiProvenienza :string, ElencoEsamiEsterniSuperati :seq CorsoEsterno;
Risultato ( OperazioneEseguita; Errore );
Errori Usa
Modifica DomandeDiTrasferimento, CorsiEsterni, DomandeDiTrasferimento;
Prima Poi
Figura 3.13: Esempio di specifica preliminare di operazione.
3.5 La progettazione concettuale
3.5.1 Scopo della progettazione concettuale
Scopo della progettazione concettuale e` tradurre il risultato dell’analisi dei requisiti
settoriali in una descrizione formale ed integrata degli aspetti strutturali e dinamici del sistema informatico studiato. Mentre l’analisi dei requisiti analizza cosa si aspettano i singoli settori dal sistema, in questa fase l’attenzione e` su come disegnare una base di dati ed un insieme di operazioni che garantiscano per tutti i settori le funzionalita`
desiderate. Il risultato della progettazione concettuale e` lo schema o progetto con-
cettuale, scritto in un linguaggio formale, indipendente dal DBMS che verra` usato
nella realizzazione, con costrutti ad alto livello, adatti a descrivere in modo naturale il significato di cio` che si sta modellando.
Il passaggio dalla specifica dei requisiti al progetto concettuale avviene quindi at- traverso un processo di formalizzazione e raffinamento dei requisiti settoriali ed at- traverso la loro integrazione in un progetto globale. Inoltre, in questa fase gli aspetti quantitativi vengono riformulati con riferimento allo schema concettuale prodotto.
Il progetto concettuale gioca un ruolo fondamentale nel processo di sviluppo del sistema informatico, principalmente per le seguenti ragioni:
– e` utilizzato dal progettista per ragionare ad un giusto livello di astrazione sulle
scelte fatte e per produrre un modello soddisfacente della realta` osservata;
– e` utilizzato dalle diverse figure professionali coinvolte nella progettazione e nel-
la codifica delle applicazioni come specifica formale e dettagliata di cio` che va realizzato;
– e` un preciso riferimento a cui ricondursi per modificare il sistema realizzato o per sviluppare nuove applicazioni quando il sistema e` gia` operativo;
– e` utilizzabile nelle discussioni con i committenti non informatici che devono appro- vare le scelte di progetto, usando opportune rappresentazioni grafiche degli aspetti principali;
– e` utilizzabile come prototipo che puo` essere validato dagli utenti finali dopo espe- rimenti su dati campione, se il linguaggio in cui e` espresso e` eseguibile.
Un buon progetto concettuale e` un obiettivo irrinunciabile all’aumentare della com-
plessita` del sistema da realizzare, poiche´ il processo di sviluppo richiede un tale impe- gno di risorse da rendere difficilmente praticabile una riprogettazione del sistema in
caso di funzionamento non soddisfacente. Le principali proprieta` che caratterizzano un buon progetto concettuale sono le seguenti:
Completezza concettuale Vanno specificati tutti gli aspetti rilevanti delle applicazio- ni, in modo dettagliato, per consentirne una realizzazione corretta.
Indipendenza dalle applicazioni Lo schema concettuale non deve essere fatto in fun- zione dell’efficienza di particolari applicazioni, ma con l’obiettivo di una efficace modellazione. Considerazioni sull’efficienza verranno fatte nelle fasi successive.
Indipendenza dal DBMS Nello schema concettuale si prescinde da aspetti specifici del DBMS impiegato nella realizzazione.
Sono stati proposti modi diversi per descrivere i vari aspetti di un progetto concet- tuale: rappresentazioni grafiche, linguaggi formali non eseguibili oppure linguaggi
formali eseguibili. Per quanto riguarda gli aspetti strutturali, le soluzioni piu` comuni sono basate su estensioni del modello entita`-relazione e su un modello a oggetti.
3.5.2 Come procedere
Per produrre lo schema concettuale di una base di dati e` necessario raffinare la de-
finizione degli schemi scheletro settoriali definiti nella specifica dei requisiti e pro-
durre uno schema globale. La produzione di uno schema globale puo` procedere per
particolarizzazione o per integrazione.
Nell’approccio per particolarizzazione, in un primo passo si definiscono i dati comu- ni a tutti i settori, successivamente si particolarizzano le definizioni prodotte tenendo conto delle esigenze specifiche di ciascun settore. Il vantaggio di questo modo di pro- cedere sta nel fatto che, una volta uniformata l’interpretazione dei dati comuni, si
ha una maggiore stabilita` del progetto e si puo` procedere anche in tempi successi-
vi alla definizione dei dati delle diverse classi di utenti, senza dover ritornare sulle definizioni gia` date. Le difficolta` sorgono durante il lavoro preliminare effettuato per
individuare le informazioni in comune. Questo approccio e` usato nelle situazioni piu` semplici o quando e` stato gia` possibile fondere i requisiti nella fase precedente.
Nell’approccio per integrazione, in un primo passo si definisce per ogni settore uno schema parziale delle informazioni, eventualmente per aggregazioni successive dei sottoschemi associati ad ogni applicazione. Nel passo successivo si provvede ad xxx- xxxxxxx ed integrare questi schemi parziali in un unico schema concettuale che soddisfi i requisiti di tutti i settori. Il secondo passo e` particolarmente critico dovendo indivi- duare e risolvere i conflitti espliciti ed impliciti che sorgono per una diversa model- lazione degli stessi fatti in schemi di settori diversi. Per conflitti espliciti si intendo- no quelli rilevabili da un’analisi degli schemi parziali: ad esempio un fatto descritto come proprieta` in uno schema e come entita` in un altro, oppure un’associazione mo-
dellata con una cardinalita` e vincolo di dipendenza diversi. I conflitti impliciti sono
invece quelli piu` difficili da rilevare poiche´ riguardano le omonimie e le sinonimie.
Questo approccio e` usato nei casi piu` complessi, quando esistono molti utenti e ap-
plicazioni, ed e` l’unico possibile in quelle metodologie in cui l’analisi dei dati viene
effettuata a partire dai risultati dell’analisi funzionale, integrando i sottoschemi che rappresentano le informazioni usate da ciascuna applicazione.
In entrambi i casi, il lavoro del progettista dipende da come sono stati specificati i requisiti. Se si ha una rappresentazione in linguaggio naturale, la specifica dello sche- ma concettuale dipendera` molto dall’intuizione e dall’esperienza del progettista. Se si ha invece una rappresentazione formale, il processo richiedera` meno sforzi interpreta- tivi. Una volta generata la descrizione globale dei fatti riconducibili a dati, lo schema si completa in ogni dettaglio con la specifica degli aspetti procedurali, dinamici e quantitativi.
Vediamo piu` in dettaglio come si procede per la produzione del progetto concettuale nell’approccio per integrazione. La progettazione richiede i seguenti passi:
1. definisci gli schemi di settore;
2. integra gli schemi di settore;
3. ristruttura eventualmente lo schema finale;
4. definisci l’architettura delle operazioni degli utenti e i metodi degli oggetti;
5. controlla la completezza delle operazioni degli utenti e di base.
3.5.3 I passi della progettazione concettuale
Vediamo ora come si puo` concettuale.
procedere per effettuare i singoli passi della progettazione
Il primo passo verra` esemplificato con riferimento ai requisiti specificati nella sezio- ne precedente. Poiche´ in tale esempio non sono previsti schemi di settore da integrare, il passo di integrazione sara` trattato invece con un esempio diverso.
1. Definizione di uno schema di settore
Le indicazioni che verranno date in questa sezione sono utilizzabili sia nell’approccio
Lo schema scheletro specificato nella fase di analisi dei requisiti si raffina proceden- do con i seguenti passi:
1. definisci la struttura degli elementi delle classi;
2. individua le generalizzazioni;
3. tratta le dipendenze funzionali;
4. completa le definizioni delle associazioni;
5. completa le definizioni delle classi.
1. Definire la struttura degli elementi delle classi
Per ogni classe si elencano le proprieta` descrittive interessanti dei suoi elementi, speci- ficando, per ognuna di esse, il nome e il tipo. In questa fase le proprieta` non vengono riportate nello schema perche´ non e` ancora quello definitivo.
In questo passo va prestata molta attenzione alla possibilita` che i valori di alcune
proprieta` siano piu` significativi come oggetti a se´ stanti, e quindi convenga introdurre nuove classi, o viceversa al fatto che talune entita` possano essere rappresentate come
semplici attributi di altre. Inoltre, e` frequente il caso in cui, tentando di elencare le
proprieta` di un oggetto, si scopre che la classe non era ben definita ed occorre rifarsi al significato di cio` che si sta descrivendo per decidere come procedere.
In questo caso, potremmo ad esempio scoprire che, poiche´ interessa mantenere il
recapito di ogni studente che fa domanda di trasferimento, potrebbe essere opportuno aggiungere una classe degli Studenti, e considerare Universita`, Dipartimento e CorsoDi- LaureaDiProvenienza come attributi degli studenti (Figura 3.14).
I tipi degli elementi delle classi possono essere definiti come in Figura 3.15.
2. Individuare le generalizzazioni
In questo passo si fissa l’attenzione su quelle classi di oggetti con proprieta` che hanno
lo stesso significato. Se puo` essere utile, si definisce una nuova classe dalla quale si
possono ridefinire le altre per specializzazione.
Ad esempio, nel nostro caso possiamo scoprire che e` utile definire una superclasse comune Corsi da cui i corsi esterni ed interni ereditano alcune proprieta` (Figura 3.16). Convalide e domande di trasferimento possono ora essere piu` correttamente collegate a Xxxxx, anziche´ a CorsiEsterni, dato che uno studente che chiede il trasferimento po- trebbe avere superato alcuni degli esami internamente, ad esempio se si era trasferito nel passato nella direzione inversa.
Si ridefiniscono le proprieta` di Corsi, CorsiInterni e CorsiEsterni.
3. Trattare le dipendenze funzionali
Siano X ed Y due insiemi di attributi; diremo che X determina funzionalmente Y, o che Y e` determinato funzionalmente da X, se in ogni possibile estensione della classe due elementi distinti che hanno lo stesso valore per gli attributi di X (il determinante)
Studenti
—
DichiaratoIn
Causa
|
Domande Trasferimento
|
Pratiche Trasferimento
ConsideratoIn
|
Convalida Esami
ApprovataIn
|
— EvasaDa
Delibere
—
— Convalida
CorsiEsterni
|
|
CorsiInterni
BozzeDi Delibere
Delibere Approvate
ConvalideTipiche
PrevioColloquio
Studenti
Nome Recapito
:string
:string
Universita`DiProvenienza :string DipartimentoDiProvenienza :string CorsoDiLaureaDiProvenienza :string
DomandeTrasferimento
NumProtocollo :int DataPresentazione :date
PraticheTrasferimento
Annotazioni :string NumeroProgressivo :int
Figura 3.14: Schema arricchito con gli studenti
Annotazioni :string
BozzeDi Delibere
DelibereApprovate
DataVerbale :date NumVerbale :int
CorsiEsterni
Nome :string
Universita` :string
Dipartimento :string CorsoDiLaurea :string AnnoAccademico :int
CorsiInterni
Nome :string Unita`Didattiche :int
ConvalideEsami
PrevioColloquio :bool
Figura 3.15: Classi con la struttura dei tipi
Studenti
DichiaratoIn
|
—
Domande Trasferimento
Causa
|
Pratiche Trasferimento
ConsideratoIn
|
ApprovataIn
|
— EvasaDa
Delibere
—
Convalida Esami
—
Corsi
Convalida
BozzeDi Delibere
Delibere Approvate
CorsiEsterni | | CorsiInterni
ConvalideTipiche
PrevioColloquio
Figura 3.16: Schema dopo la generalizzazione
hanno anche lo stesso valore per gli attributi di Y (il determinato). Quando si riscontra una dipendenza funzionale in cui il determinante non e` una chiave, occorre decidere se le proprieta` che formano la dipendenza (determinante e determinato) non si pos- sano meglio vedere come le proprieta` degli elementi di una classe a se´ stante. In caso
affermativo, si crea la nuova classe e si sostituiscono tutte le proprieta` della dipen-
denza funzionale con un’associazione fra la vecchia e nuova classe. Nel caso, invece, che si decida di non generare una nuova classe bisognera` ricordarsi di trattare questo fatto come ogni altro vincolo d’integrita`.2
Ad esempio, nel nostro caso potremmo stabilire che gli attributi CorsoDiLaurea e
Universita` della classe dei corsi esterni determinano l’attributo Dipartimento, nell’ipo-
tesi che non esistano in nessuna universita` due corsi di laurea con lo stesso nome in due dipartimenti diversi. Questa osservazione ci potrebbe spingere a raggruppare le tre proprieta` in una nuova classe CorsiDiLaurea associata alla classe degli corsi esterni (Figura 3.17), oppure potremmo mantenere lo schema gia` scelto e trattare questo fatto come un vincolo di integrita`.
Studenti
DichiaratoIn
|
—
Domande Trasferimento
Causa
|
Pratiche Trasferimento
ConsideratoIn
|
ApprovataIn
|
— EvasaDa
Delibere
—
Convalida Esami
—
Corsi
Convalida
BozzeDi Delibere
Delibere Approvate
CorsiEsterni | | CorsiInterni
ConvalideTipiche
SvoltoIn PrevioColloquio
CorsiDiLaurea
Figura 3.17: Schema con la classe CorsiDiLaurea
4. Completare la definizione delle associazioni
Se nello schema grafico le associazioni non sono state gia` definite, si completa la loro definizione specificandone il nome, le proprieta` strutturali e gli attributi.
5. Completare la definizione delle classi
Si completa la definizione delle classi specificando per ognuna:
1. quali proprieta` sono costanti e quali sono modificabili;
2. quali proprieta` sono memorizzate e quali calcolate, eventualmente a partire da
altre, specificando la regola del calcolo;
3. le chiavi, ovvero gli insiemi minimali di attributi che individuano univocamente un elemento della classe;
4. eventuali altri vincoli di integrita` sugli elementi della classe;
5. i tipi ausiliari utilizzati.
E` importante stabilire quali proprieta` siano modificabili per prevedere poi opportuni
metodi per cambiare il loro valore, eventualmente rispettando certi vincoli d’integrita`.
Nei vincoli di integrita` useremo una notazione per cui, se esiste un’associazione
binaria R tra la classe a cui appartiene a ed una classe B, allora a.R denota l’insieme di elementi della classe B associati ad a, o l’unico elemento di B associato ad a se l’associazione e` univoca. Se X e` un insieme di elementi, X.R e` l’unione degli insiemi
a.R, per ogni elemento a 2 X. `
Nel caso di vincoli di chiave, puo accadere che gli elementi di una classe siano
univocamente determinati a partire dall’elemento associato in un’altra classe e da un
insieme di attributi; ad esempio, un corso esterno e` identificato dal corso di laurea
associato, dal nome e dall’anno accademico. Questo vincolo sara` espresso come un
⌧
vincolo di chiave, facendo uso della notazione K (attributi o elementi) come nella classe CorsiEsterni dell’esempio.
Studenti
PresentataDa
Nome Recapito
Universita`DiProvenienza
:string ⌧K
:string ⌧K
:string
DipartimentoDiProvenienza :string CorsoDiLaureaDiProvenienza :string
—
|
Causa
|
DichiaratoIn
|
ConvalidaEsami
PrevioColloquio :bool
ApprovataIn
|
— XxxxxXx Xxxxxxxx
Annotazioni :string
—
ConsideratoIn —
Corsi
Nome :string ⌧K
Convalida
CorsiEsterni CorsiInterni
AnnoAccademico :int | | Unita`Didattiche :int
SvoltoIn
ConvalideTipiche
PrevioColloquio :bool
:string ⌧K
Dipartimento :string
Nome :string ⌧K
Universita`
CorsiDiLaurea
NumeroProgressivo :int ⌧K
:string
Annotazioni
PraticheTrasferimento
:int ⌧K
DataPresentazione :date
NumProtocollo
DomandeTrasferimento
Il risultato di questo passo e` mostrato in Figura 3.18.
DataVerbale :date ⌧K NumVerbale :int ⌧K |
BozzeDi Delibere
Figura 3.18: Schema finale
2. Integrazione di schemi di settore
Una volta definiti gli schemi di settore, si procede con i seguenti passi alla loro integrazione per produrre lo schema globale:
1. Risolvi i conflitti di nome, di tipo e di vincoli d’integrita`.
2. Fondi gli schemi.
3. Analizza le proprieta` interschema.
Poiche´ nell’esempio sviluppato finora non sono previsti schemi di settore da integrare, per illustrare le idee che sono alla base del processo di integrazione, si considera l’esempio in Figura 3.19, tratto da [Xxxxxx et al., 1987], dove sono riportati due possibili schemi da integrare.
Editori
Nome :string Indirizzo :string
Pubblica
Libri
Titolo :string
Tratta
Argomenti
Nome :string
Documenti
Nome :string Editore :string Codice :string
Tratta
Descrittori
Nome :string Codice :string
Schema 2
Figura 3.19: Due schemi da integrare
Risoluzione dei conflitti di nome, di tipo e di vincoli d’integrita`
Si supponga di aver verificato che:
– il significato di Argomenti nel primo schema sia lo stesso di Descrittori nel secondo;
– Documenti nel secondo schema sia un concetto piu` astratto di Libri nel primo sche-
ma, perche´ esso include libri, atti, giornali, monografie ecc.
Per integrare i due schemi, poiche´ Argomenti e Descrittori rappresentano lo stesso con- cetto, i due nomi vanno unificati: scegliamo, ad esempio, il nome Argomenti. Un’altra
differenza fra i due schemi e` che lo stesso concetto Editore e` rappresentato nel pri-
mo schema come entita`, mentre nel secondo come attributo. Per uniformare le due rappresentazioni, decidiamo di trattare Editori come entita` anche nel secondo schema, assegnandogli l’attributo Nome (vedi Figura 3.20).
Fusione degli schemi di settore
Analisi delle proprieta` interschema
Lo schema integrato viene esaminato per eventuali arricchimenti, dovuti ad esempio al fatto che si scoprono relazioni fra concetti provenienti da schemi diversi (proprieta` interschema). Un esempio e` la relazione di sottoinsieme tra i concetti Libri e Documenti, che, aggiunta, porta allo schema in Figura 3.22.
Editori
Nome :string Indirizzo :string
Pubblica
Libri
Titolo :string
Tratta
Argomenti
Nome :string
Editori
Nome :string
Pubblica
Documenti
Titolo :string Codice :string
Tratta
Descrittori
Nome :string Codice :string
Schema 2
Figura 3.20: Schemi uniformati
Nome :string Indirizzo :string
PubblicaLibri
Libri
Titolo :string
LibroTratta
Argomenti
Nome :string Codice :string
PubblicaDocumenti
Documenti
Titolo :string Codice :string
DocumentoTratta
Figura 3.21: Schema integrato
Nome :string Indirizzo :string
Pubblica
Documenti
Titolo :string Codice :string
Tratta
Argomenti
Nome :string Codice :string
Libri
Figura 3.22: Arricchimento dello schema integrato con una proprieta` interschema
Questo esempio di integrazione di schemi, nonostante la sua semplicita`, evidenzia i problemi di base che nascono nel processo di integrazione, dovuti alle seguenti ragioni:
1. Differenza di percezione dei fatti rappresentati negli schemi iniziali. Nel processo di progettazione, gruppi differenti di utenti o progettisti possono percepire lo stes- so concetto in modo diverso, nel senso che ad esso possono essere associati nomi
e proprieta` differenti. Nell’esempio visto, allo stesso concetto erano stati dati due
nomi differenti (Argomenti e Descrittori).
2. Impiego di costrutti diversi per rappresentare le stesse informazioni. Ad esempio, in Figura 3.19 l’informazione sugli Editori e` stata modellata con un attributo in uno schema e con un’associazione nell’altro.
3. Diversita` di interpretazione di concetti comuni. Stessi concetti sono modellati con
significati diversi, ad esempio un’associazione fra due classi e` prieta` strutturali diverse.
descritta con pro-
3. Ristrutturazioni dello schema finale
Una volta ottenuta una prima versione dello schema finale, che rappresenta tutte le informazioni di interesse di eventuali settori aziendali diversi, si valuta l’opportunita`
di possibili ristrutturazioni per migliorare la leggibilita` dello schema o per elimina-
re ridondanze, come quelle dovute a cammini distinti fra due classi che modellano associazioni equivalenti.
4. Definizione dell’architettura delle operazioni degli utenti e dei metodi degli oggetti
In questo passo si completa la specifica delle operazioni, con riferimento allo schema globale della base di dati.
Una volta definite le operazioni, si verifica che siano state previste tutte le opera- zioni di base necessarie. Risultano di solito utili matrici di controllo come quella che prevede una riga per ogni operazione e una colonna per ogni classe, con elementi che
contengono nessuno, uno o piu` simboli del tipo:
– U se l’operazione utilizza la classe;
– C se l’operazione crea un elemento della classe;
– M se l’operazione modifica un elemento della classe;
– D se l’operazione distrugge un elemento della classe.
Colonne di classi prive di alcuni di questi simboli sono indizi utili per stabilire la non completezza della specifica.
Per maggiori dettagli su questa fase si rinvia ai testi citati nelle note bibliografiche.
3.6 Riepilogo della metodologia di progettazione
1. Analisi dei requisiti (da effettuare per ogni settore aziendale)
1.1 Analizza il sistema informativo esistente e raccogli una prima versione dei re- quisiti, espressa in linguaggio naturale.
1.2 Rivedi i requisiti espressi in linguaggio naturale per eliminare ambiguita`, im- precisioni e disuniformita` linguistiche.
1.3 Raggruppa le frasi relative a categorie diverse di dati, vincoli e operazioni.
1.4 Costruisci un glossario dei termini.
1.5 Definisci uno schema preliminare di settore.
1.5.1 Identifica le classi.
1.5.2 Descrivi le associazioni fra le classi.
1.5.3 Individua le sottoclassi.
1.6 Specifica le operazioni degli utenti.
1.7 Verifica la completezza e consistenza della specifica.
2. Progettazione concettuale
2.1 Definisci gli schemi di settore.
2.1.1 Definisci la struttura degli elementi delle classi.
2.1.2 Individua le generalizzazioni.
2.1.3 Tratta le dipendenze funzionali.
2.1.4 Completa le definizioni delle associazioni.
2.1.5 Completa le definizioni delle classi.
2.2 Integra gli schemi di settore.
2.2.1 Risolvi i conflitti di nome, di tipo e di vincoli d’integrita`.
2.2.2 Fondi gli schemi.
2.2.3 Analizza le proprieta` interschema.
2.3 Ristruttura eventualmente lo schema finale.
2.4 Definisci l’architettura delle operazioni degli utenti e i metodi degli oggetti.
2.5 Controlla la completezza delle operazioni degli utenti e di base.
3.7 Conclusioni
Sono state presentate le caratteristiche generali delle metodologie di progettazione di
basi di dati e in particolare della fase di progettazione concettuale, che e` la fase piu`
critica del processo perche´ produce la rappresentazione delle informazioni da trattare per soddisfare i bisogni informativi degli utenti. La progettazione concettuale avviene con metodi poco formali e richiede quindi al progettista molta competenza, intuizione ed esperienza. Una volta trovato lo schema concettuale della base di dati, la progetta- zione logica e fisica si avvale di metodi formalizzati che rendono necessari opportuni strumenti automatici di ausilio. L’attenzione e` verso ambienti che integrino un insie- me di strumenti per costituire un “banco di lavoro” che agevoli l’arduo compito del progettista in casi complessi in modo da consentirgli di concentrarsi sugli aspetti piu` creativi del processo, rinviando alla macchina i compiti di gestione e produzione della documentazione, di controllo sulle attivita` svolte ed eventualmente di addestramento. Ambienti di questa natura sono chiamati CASE, termine coniato inizialmente per
indicare semplici strumenti di analisi e documentazione. Attualmente il termine e`
usato per indicare un insieme di strumenti e metodi per un approccio alla gestione, allo sviluppo e alla manutenzione di un progetto software basato su un insieme di
attivita` ben definite, coordinate e ripetibili con rappresentazioni, regole di progetta-
zione e standard di qualita`. Fra gli strumenti tipici di un ambiente CASE si ricordano i seguenti:
– strumenti di supporto all’analisi del sistema informativo;
– strumenti per la progettazione delle applicazioni con funzionalita` di diagramma-
zione, di controllo di consistenza fra le varie rappresentazioni del progetto e di
stampa;
– strumenti di supporto per il processo di produzione del codice;
– strumenti per la generazione del codice.
Esercizi
1. Condom`ıni
Si supponga di dover memorizzare in una base di dati le informazioni di interesse per un amministratore di condom`ıni. Di un condominio interessano l’indirizzo e il numero del conto corrente dove vengono fatti i versamenti per le spese sostenute. Un condominio si compone di un certo numero di appartamenti, dei quali inte- ressano il numero dell’interno, il numero dei vani, la superficie, lo stato (libero od occupato).
Gli appartamenti possono essere locati, e dell’inquilino interessano il nome, il co-
dice fiscale, il telefono e il saldo, cioe` la somma che l’inquilino deve all’ammini-
strazione condominiale per le spese sostenute. Alcuni appartamenti locati possono essere stati disdetti, ed in questo caso interessa la data della disdetta.
Un appartamento puo` avere piu` proprietari, e un proprietario puo` possedere piu`
appartamenti. Di ogni proprietario interessano il nome, il codice fiscale, l’indirizzo,
il telefono e il saldo, cioe` la somma che il proprietario deve all’amministrazione
condominiale per le spese sostenute.
Le spese riguardano i condom`ıni e di esse interessano il codice di identificazione, la natura (luce, pulizia, ascensore ecc.), la data e l’importo. Fra le spese si distinguono quelle straordinarie, a carico dei proprietari, e quelle ordinarie, a carico degli in- quilini. Le spese ordinarie vengono pagate in un’unica rata, mentre le spese straor-
dinarie possono essere pagate in piu` rate e di ognuna di esse occorre ricordare la data e l’importo.
Progettare lo schema della base di dati e dare la specifica delle operazioni per l’immissione dei dati.
2. Societa` Mega S.p.A.
Si vogliono gestire informazioni riguardanti gli impiegati, le loro competenze, i progetti a cui partecipano e i dipartimenti a cui appartengono.
Ogni impiegato ha una matricola che lo identifica, assegnata dalla societa`. Di ogni impiegato interessano il nome, la data di nascita e la data di assunzione. Se un impiegato e` coniugato con un altro dipendente della stessa societa`, interessano la data del matrimonio e il coniuge. Ogni impiegato ha una qualifica (ad esempio, se- gretaria, impiegato, programmatore, analista, progettista ecc.). Dei laureati e delle segretarie interessano altre informazioni. Dei laureati interessa il tipo di laurea e delle segretarie le lingue straniere conosciute.
La societa` e` organizzata in dipartimenti, identificati da un nome e da un numero
di telefono. Un impiegato afferisce ad un solo dipartimento. Ogni dipartimento si
approvvigiona presso vari fornitori e un fornitore puo` rifornire piu` dipartimenti.
Di ogni fornitore interessano il nome e l’indirizzo. Interessano, inoltre, la data e il fornitore dell’ultimo acquisto fatto da un dipartimento.
La societa` lavora a diversi progetti, ciascuno dei quali e` localizzato in una citta`.
Xxx` impiegati partecipano ad un progetto e un impiegato puo` partecipare a piu`
progetti, ma tutti localizzati sulla stessa citta`. Di ogni citta` con un progetto in
corso interessano la sua popolazione e la regione. Un impiegato puo` avere piu`
competenze, ma usarne solo alcune per un particolare progetto. Un impiegato usa ogni sua competenza in almeno un progetto. Ad ogni competenza e` assegnato un codice unico e una descrizione. I progetti in corso sono identificati da un numero ed interessa una stima del loro costo.
Progettare lo schema della base di dati e dare la specifica delle operazioni per l’immissione dei dati.
3. Anagrafe
Si vogliono trattare informazioni sulle persone che vivono o sono decedute in un comune italiano.
Di una persona interessano: nome, cognome, codice fiscale, data di nascita (giorno, mese, anno), eta`, indirizzo (via, numero, cap, comune), sesso (m, f), stato civile (celibe (nubile), coniugato(a), vedovo(a), separato(a), divorziato(a), deceduto(a)), madre, padre e antenati.
Una persona puo` essere vivente o deceduta. Di una persona vivente interessano:
indirizzo, numeri telefonici, comune di residenza, familiari conviventi, figli viventi e figli conviventi. Le persone di un nucleo familiare condividono lo stesso indirizzo, telefono e comune di residenza.
Di una persona deceduta interessano: data del decesso, eta`, comune del decesso, comune dove e` stata seppellita.
Di un matrimonio interessano: data, sposo, sposa e comune dove e` stato celebrato. Non sono ammessi matrimoni fra consanguinei ovvero fra persone che hanno uno stesso antenato.
Di un comune interessano: nome, se capoluogo di provincia, prefisso telefonico, gli abitanti, il numero degli abitanti, le persone seppellite e decedute, il numero delle persone seppellite e decedute.
Xxxxx previste le seguenti operazioni per le quali vanno fissati i parametri e il tipo del risultato:
– creazione di una persona nubile o celibe;
– nascita di un figlio;
– matrimonio;
– antenati viventi di una persona;
– nome e cognome dei genitori di una persona;
– nome, cognome e relazione di parentela dei familiari conviventi di una persona;
– cambio di residenza di una persona e dei suoi familiari conviventi;
– una persona e i suoi conviventi vanno a vivere con un’altra persona;
– una persona va a vivere da sola;
– decesso di una persona.
4. Ufficio della motorizzazione
Si vogliono modellare i seguenti fatti di interesse di un ipotetico Ufficio della motorizzazione.
Produttori di automobili C’e` un certo numero di produttori di automobili, ciascu- no identificato da un nome (FIAT, FORD ecc.). I dati di nuovi produttori possono essere immessi in ogni momento, se il produttore ha l’autorizzazione ad iniziare l’attivita` commerciale.
L’autorizzazione non puo` essere ritirata e non piu` di cinque produttori possono
essere in attivita` contemporaneamente. Un produttore e` considerato attivo finche´
possiede automobili registrate come prodotte da lui e non ancora vendute; nel mo- mento in cui un produttore non possiede auto, il suo permesso di operare puo` esse- re sospeso. I dati di un produttore vengono eliminati solo quando viene eliminata la storia di tutte le auto da lui prodotte.
Automobili Un’automobile e` caratterizzata da un modello, dall’anno di produ-
zione, da un numero di serie assegnatogli dal produttore, unico fra le automobili da lui prodotte. I dati di un’automobile vengono immessi all’atto della sua regi- strazione presso l’Ufficio della Motorizzazione. Al momento della registrazione, all’automobile viene assegnato un numero, unico per ciascuna automobile e non modificabile, e la data di registrazione. Il produttore viene registrato come primo proprietario.
Un’automobile puo` essere registrata in qualsiasi giorno dell’anno in cui e` stata
costruita, ma puo` essere registrata solo entro il 31 gennaio se costruita l’anno
precedente. Nel caso di distruzione, viene registrata la data di distruzione, e da
questo momento l’automobile non puo` essere piu` trasferita. Infine, la storia di
un’automobile va conservata per due anni dopo la sua distruzione.
Modelli di automobile Ogni automobile e` caratterizzata da un modello (Panda,
Uno, Escort ecc.). Le automobili di ciascun modello sono prodotte dallo stesso
produttore, il quale e` libero di introdurre nuovi modelli sul mercato in qualsiasi
momento. Il nome di ciascun modello e` unico fra tutti i modelli registrati. Le auto- mobili di uno stesso modello hanno lo stesso consumo di benzina. Un modello ha una potenza di almeno 6 cavalli e una cilindrata compresa fra 400 e 3.000 cc.
I dati su un modello vanno conservati finche´ esiste nella base di dati un’automobile di tale modello. Le automobili di un certo modello non possono essere registrate se tale modello non e` ancora noto all’Ufficio della motorizzazione.
Rivenditori I rivenditori sono preposti alla distribuzione di automobili nuove, o usate, ai privati. Di un rivenditore interessano il nome, l’indirizzo, il telefono e l’eventuale numero del fax. Nuovi rivenditori possono sorgere in ogni momento,
ma la loro attivita` commerciale puo` iniziare solo se hanno ricevuto il permesso
dagli uffici competenti. Un rivenditore puo` produttori diversi.
trattare automobili nuove di al piu`
tre
Ogni rivenditore e` considerato operante finche´ possiede automobili; in caso contra- rio puo` richiedere la sospensione del permesso di operare. I dati di un rivenditore non operante vengono eliminati solo se questo non e` stato proprietario di un’auto di cui si conserva la storia.
Privati I privati sono persone proprietarie di una o piu` automobili gia` registrate.
Di un privato interessano il nome, l’indirizzo e il telefono. I dati dei privati vengono immessi con l’acquisto della prima automobile, ed eliminati solo se essi non sono stati proprietari di un’automobile di cui si conserva la storia.
Trasferimenti di proprieta` In ogni momento un’automobile puo` essere possedu-
ta: dal suo produttore (automobile invenduta), da un rivenditore, oppure da un gruppo di privati.
All’atto del trasferimento della proprieta` di un’automobile vengono registrate le
seguenti informazioni: un codice che identifica il trasferimento, la data di trasferi- mento, l’automobile trasferita, il vecchio e il nuovo proprietario.
Vi sono norme che vincolano il trasferimento di un’automobile:
– un’automobile distrutta non puo` essere trasferita;
– un’automobile puo` essere venduta da un produttore solo ad un rivenditore, e
un produttore non puo` acquistare automobili;
– un’automobile puo` privati.
essere venduta da un rivenditore solo a privati o gruppi di
I dati su un trasferimento possono essere eliminati solo quando l’automobile cessa di essere di interesse per l’Ufficio della Motorizzazione.
Xxxxx previste le seguenti operazioni.
– Registrazione di una nuova auto.
– Distruzione di un’auto.
– Registrazione della vendita di un’auto.
– Eliminazione della storia delle auto distrutte da almeno due anni.
– Registrazione di un nuovo produttore in attesa del permesso di operare.
– Autorizzazione di un produttore ad operare.
– Sospensione delle attivita` di un produttore.
– Eliminazione di un produttore non operante.
– Registrazione di un nuovo modello.
– Registrazione di un nuovo rivenditore.
– Sospensione delle attivita` di un rivenditore.
– Eliminazione di un rivenditore non operante.
5. Organizzazione di una conferenza
Si vogliono trattare i dati riguardanti le Working Conferences dell’IFIP ( Interna-
tional Federation for Information Processing). Una IFIP Working Conference e` una
conferenza internazionale intesa a riunire esperti di tutti i paesi aderenti all’I-
FIP per discutere problemi che interessano uno o piu` IFIP Working Group. Ogni
Working Group opera sotto gli auspici di un Technical Committee costituito dai rappresentanti nazionali dei paesi aderenti all’IFIP.
Alla conferenza possono partecipare solo persone che hanno ricevuto un invito.
L’invito e` inviato a tutti i membri dei Working Groups e Technical Committees
interessati. Il numero delle persone che parteciperanno ai lavori deve essere supe- riore ad una soglia minima, per garantirsi la copertura dei costi, ed inferiore ad una soglia massima, per non superare le capacita` ricettive delle strutture.
La conferenza e` organizzata da due comitati: il Comitato di Programma e il Comi- tato Organizzatore. Il primo cura gli aspetti scientifici della conferenza: nomina il Comitato dei Revisori, che esaminera` gli articoli sottoposti alla conferenza, e decide quali articoli accettare, non superando il numero massimo prestabilito.
Il Comitato Organizzatore cura gli aspetti finanziari, logistici, gli inviti e la pubbli-
cita`. Ogni comitato e` costituito da esperti ed e` previsto un Chairman per ogni
comitato ed un General Chairman per la conferenza. Tutti i comitati lavorano utilizzando dati comuni che vanno raccolti ed elaborati in modo consistente.
Procedure da automatizzare L’applicazione da realizzare ha lo scopo di agevolare
le attivita` di entrambi i comitati, pensati come due settori aziendali che operano
utilizzando dati in comune. I comitati devono svolgere le seguenti attivita`.
Comitato di Programma
– Preparare la lista degli esperti a cui sollecitare la presentazione di un articolo.
– Registrare le lettere d’intenti, cioe` le risposte date da coloro che intendono invia-
re un lavoro. Ogni esperto invia al piu` una lettera che verra` presa in considera-
xxxxx solo se perviene entro la data prestabilita. I lavori con nessun autore fra gli esperti che hanno risposto con una lettera d’intenti avranno una priorita` bassa, se il numero complessivo dei lavori da esaminare supera il massimo prestabilito.
– Preparare la lista degli esperti da invitare alla conferenza. Nella lista devono essere inclusi: i membri di tutti i Technical Committees e Working Groups inte- ressati; i membri del Comitato dei Revisori e tutti coloro che hanno proposto un
articolo. Occorre evitare di mandare alla stessa persona piu` di un invito.
– Registrare le adesioni alla conferenza pervenute entro la data prefissata.
– Generare la lista finale dei partecipanti alla conferenza. Se le adesioni superano
il numero massimo prestabilito, verra` data priorita`, nell’ordine, ai membri dei
– Registrare gli articoli proposti per la conferenza e pervenuti entro una data prefissata.
– Distribuire i lavori fra i membri del Comitato dei Revisori. Ogni lavoro sara` revisionato da 3 a 5 revisori, a seconda del numero complessivo dei lavori pervenuti.
– Raccogliere i pareri dei revisori e selezionare il numero prefissato di lavori da presentare alla conferenza.
– Raggruppare i lavori selezionati in sessioni e scegliere un Chairman per ogni sessione fra i membri del Comitato di Programma.
Note bibliografiche
Metodologie a piu` fasi per la progettazione di basi di dati sono descritte in [Atzeni
et al., 2002], [Xxxxxxxx and Xxxx, 2000], [Xxxxxx et al., 1992], [Ceri, 1983], [Teorey, 1999]. Molte delle metodologie attuali, quali Rational Unified Process (RUP), si basano sul modello ad oggetti e sul linguaggio Unified Modeling Language (UML) [Xxxxxxxx and
Xxxx, 2000], [Xxxxxxxxx, 2002].
Per alcuni tipici esempi di strumenti CASE per basi di dati, si vedano sulla re- te le descrizioni di ER/Studio (Embarcadero), XXXxx (Computer Associates), Oracle Designer (Oracle), Power Designer (Sybase).
BIBLIOGRAFIA
Xxxxxxxxx, S. and Xxxxxx, N. (1984). An algebra for non normalized relations. In Proceedings of the ACM SIGACT-SIGMOD Symposium on Principles of Database Systems (PODS). 135
Xxxxxxxxx, S., Xxxx, R., and Xxxxx, V. (1995). Database Foundations. Addison-Xxxxxx, Reading, Massachusetts. 27, 136, 178
Xxxxxx, X. (2001). Costruire sistemi per basi di dati. Addison-Xxxxxx, Milano. 220, 252, 279
Xxxxxx, X., Xxxxxxxxx, X., and Xxxxxx, G. (2000). View operations on objects with roles for a statically typed database language. IEEE Transactions on Knowledge and Data Engineering, 12(4):548–567. 40, 48, 49
Xxxxxx, X., Xxxxxxxx, X., and Xxxxxx, R. (1985). Galileo: A strongly typed, interactive conceptual language. ACM Transactions on Database Systems, 10(2):230–260. Also in S.B. Xxxxxx and X. Xxxxx, editors, Readings in Object-Oriented Database Systems, Xxxxxx Xxxxxxxx Publishers, Inc., Xxx Xxxxx, Xxxxxxxxxx, 0000. 40, 48, 49
Xxxxxxxxx, X. (1974). Dependency structures of database relationships. In Proceedings of the IFIP Congress, pages 580–583. 143
Xxxxxx, X. and Xxxxxxxxxx, V. D. (1993). Relational Database Theory. Xxxxxx Xxxxxxxx Publishers, San Mateo, California. 136, 156, 178
Xxxxxx, P., Xxxx, S., Xxxxxxxxxx, S., and Xxxxxxx, R. (2002). Basi di dati. Modelli e linguaggi di interrogazione. McGraw-Xxxx, Milano. 27, 99
Xxxxxx, C., Xxxx, S., and Xxxxxxx, S. (1992). Conceptual Database Design. An Entity-Relationship Approach. The Xxxxxxxx/Xxxxxxxx Publishing Company, Inc., Redwood City, California. 72, 99
Xxxxxx, X., Xxxxxxxxx, M., and Xxxxxxx, S. (1987). A comparative analysis of me- thodologies for database schema integration. ACM Computing Surveys, 18(4):2–18. 90
Xxxxx, X. and Xxxxxxxxx, P. (1979). Computational problems related to the design of normal form relational schemas. ACM Transactions on Database Systems, 4(1):30–59. 147
Xxxxxxxxx, X. (1976). Synthesizing third normal form relations from functional
dependencies. ACM Transactions on Database Systems, 1(4):277–298. 169
Xxxx, X., editor (1983). Methodology and Tools for Database Design. North-Xxxxxxx, Amsterdam. 99
Xxxx, X., Xxxxxxx, X., and Xxxxx, L. (1990). Logic Programming and Data Bases. Springer- Verlag, Berlin. 136
Xxxx, X. (1970). A relational model for large shared data banks. Communications of the ACM, 13(6):377–387. 136, 141
Xxxxxxxx, X. and Xxxx, C. (2000). Database Solutions. A step-by-step guide to building databases. Addison-Xxxxxx, Reading, Massachusetts. 99
Xxxxxxxxx, X. and Xxxxxx, J. (1988). New methods and fast algorithms for database normalization. ACM Transactions on Database Systems, 13(3):339–365. 152
Xxxxxxx, X. and Xxxxxxx, S. (2001). Sistemi di basi di dati. Fondamenti. Prima edizione italiana. Addison-Xxxxxx, Milano. 27
Fraternali, X. and Xxxxx, L. (1995). A structured approach for the definition of the semantics of active databases. ACM Transactions on Database Systems, 20(4):414–471. 216
Xxxxx, X. (1987). Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8:231–274. 73
Xxxxx, X., Xxxxxxxxx, X., and Xxxxx, P. M. (2005). Database Systems. Addison-Xxxxxx, Reading, Massachusetts, second edition. 27, 202, 250
Xxxxxxxx, X. and Xxxxxx, S. (1978). Candidate keys for relations. Journal of Computer and System Sciences, 17(2):270–280. 148
Xxxxxxxxx, X. X. (2002). Sviluppo di sistemi informativi con UML. Addison-Xxxxxx, Milano. 99
Xxxxx, X. (1983). The Theory of Relational Databases. Computer Science Press, Rockville, Maryland. 136, 152, 153, 178
Xxxxxxx, X. and Ra¨iha¨, K. (1992). The Design of Relational Databases. Addison-Xxxxxx, Reading, Massachusetts. 178
Xxxxx, X. X. (1979). Structured Analysis and System Specification. Xxxxxxxx Xxxx, Inc., Englewood Cliffs, New Jersey. 72
Xxxxxxxxxxxx, X. and Xxxxxx, X. (2003). Sistemi di basi di dati. McGraw-Xxxx, Milano.
Xxxxxxxx, X., Xxxxx, M., Xxxxxxxxxx, X., Xxxx, X., and Xxxxxxxx, X. (1991). Object- Oriented Modeling and Design. Xxxxxxxx Xxxx International, Inc., London. 72, 73
Xxxxxxx, X. (1977). Some high level language constructs for data of type relation. ACM Transactions on Database Systems, 2(3):247–261. 239
Xxxxxx, X. and Xxxxxx, P. (2002). Database Tuning: principles, experiments, and troubleshooting techniques. Xxxxxx Xxxxxxxx Publishers, San Mateo, California. 226 Xxxxxxxxxxxx, H. F., Xxxxx, H. F., and Xxxxxxxxx, S. (2002). Database System Concepts.
McGraw-Xxxx, New York, 4th edition. 27, 136
Xxxxxx, X. (1999). Database Modeling and Design. The E-R Approach. Xxxxxx Xxxxxxxx Publishers, San Mateo, California, third edition. 99
Xxxx, D. and Xxxxxxx, P. (1982). Decomposition of a relation scheme into Xxxxx-Codd
Normal Form. ACM SIGACT News, 14(3):23–29. 165
Xxxxxx, X. (1983). Principles of Database Systems. Computer Science Press, Rockville, Maryland, second edition. 158
Xxxxxx, X. X. xxx Xxxxx, J. (2001). A First Course in Database System. Xxxxxxxx Xxxx,
Inc., Englewood Cliffs, New Jersey, second edition. 27, 136, 152
xxx xxx Xxxx, X. (2001). Introduzione a SQL. Seconda edizione italiana. Addison-Xxxxxx, Milano. 202, 250
Xxxxx, X. and Xxxx, S., editors (1996). Active Database Systems: Trigger and Rules for Ad- vanced Database Programming. Xxxxxx Xxxxxxxx Publishers, San Mateo, California. 226
Xxxxxxx, X. (1989). Modern Structured Analysis. Yourdon Press, Englewood Cliffs, New Jersey. 72
Xxxxxxx, C., Xxxx, S., Xxxxxxxxx, C., Xxxxxxxxx, R., Subrahmanian, V., and Xxxxxx, R., edi- tors (1997). Introduction to Advanced Database Systems. Xxxxxx Xxxxxxxx Publishers, San Mateo, California. 226
INDICE ANALITICO
2PL (Two Phase Lock), 273 3NF, 165
4GL (Fourth Generation Languages), 18, 239
affidabilita`, 19 algebra relazionale differenza, 119
funzioni di aggregazione, 130 giunzione, 124
unione, 119 analisi
funzionale, 69, 75
assiomi di Xxxxxxxxx, 143 associazione, 33, 44
rappresentazione grafica, 44 attributo
di un oggetto, 42 estraneo, 151
bloccaggio dei dati, 242 blocco a due fasi, 273, 274 Xxxxx-Codd
calcolo relazionale di ennuple, 132 CASE, 75, 93
di dipendenze funzionali, 145 di un insieme di attributi, 144 classe, 43
comunicazione, 37 conoscenza astratta, 35
285
operazioni degli utenti, 37 operazioni di base, 37
controllo
data flow diagram, 68 data store, 68
DBA (Data Base Administrator), 24 strumenti per il, 224
architettura dei sistemi relazionali, 251 catalogo, 223
DDL (Data Definition Language), 11 deadlock, 274
decomposizione, 154 che preserva i dati, 154
che preserva le dipendenze, 156 con perdita di informazione, 139 definizione per ereditarieta`, 47 denormalizzazione, 172
derivazione di una dipendenza, 143 diagramma
di contesto, 69 di flusso dati, 68 di stato, 68, 72
per la descrizione dei dati, 68 dipendenze
funzionali, 85, 141
distribuzione della base di dati, 23 DML (Data Manipulation Language), 11
tipo, 31 ereditarieta` singola, 48
generatore
di rapporti, 19 gerarchia
di inclusione multipla, 49 di tipi, 47
gestione delle interrogazioni albero fisico, vedi piano di accesso operatori fisici, 261
ottimizzazione fisica, 261 piano di accesso, 261 riscrittura algebrica, 258 gestore
dei metodi di accesso, 257 del buffer, 252
della memoria permanente, 252 delle interrogazioni, 258
delle strutture di memorizzazione, 253 giornale, 275
giunzione
metodo index nested loop, 267 metodo merge join, 267
identita` degli oggetti, 41 indice, 255 indipendenza
integrazione di schemi di settore, 89 integrita` dei dati, 19
di un tipo oggetto, 41 istanza
JDBC (Java Data Base Connectivity), 237 linguaggio
di quarta generazione, 18 per basi di dati, 11, 18
log, vedi giornale
fallimento di sistema, 21 fallimento di transazione, 21 metadati, 8
metodologia di modellazione, 38 modellazione, 29
aspetto linguistico astratto, 38 aspetto linguistico concreto, 38 aspetto ontologico, 30
aspetto pragmatico, 38 modello dei dati, 10 ad oggetti, 39
relazionale, 56, 101, 118
normalizzazione, 139, 161
ODBC (Open Data Base Connectivity), 235
oggetto composto, 44 OID (Object Identifier), 41 operatore fisico
per eliminare duplicati, 262 per il raggruppamento, 270 per l’intersezione, 272
per la differenza, 272 per la giunzione, 267 per la proiezione, 262 per la restrizione, 263 per la scansione, 262
organizzazione dei dati, 253 ad albero, 254
seriale (heap) e sequenziale, 254 statica o dinamica, 255 ottimizzazione fisica, 261
piano di accesso esecuzione, 273
processo, 68 progettazione concettuale, 82
logica relazionale, 107 progettazione di basi di dati, 61 analisi dei requisiti, 62, 73
concettuale, 62, 64, 82
strumenti formali, 67 proiezione di dipendenze, 157
quarta forma normale, 172 query language, 12
RID (Row Identifier), 253 ripristino dopo fallimento, 275 riscrittura algebrica, 126
schema concettuale, 82 della base di dati, 8 di relazione, 101
di relazione universale, 140 esterno, 13, 223
scheletro, 79 sicurezza dei dati, 22 sistema
informatico, 2
di supporto alle decisioni, 8 direzionale, 6
per basi di dati, vedi DBMS sottoclassi, 48
nei linguaggi di programmazione, 228 potere espressivo, 198
procedure memorizzate, 212 tipi di giunzione, 185 transazione, 242
superchiave, 57, 104, 148 terza forma normale, 165
TID (Tuple Identifier), 253 tipo
transazione, 20, 242 livelli di isolamento, 246 realizzazione, 274
UML (Unified Modeling Language), 99 universo del discorso, 29