1. ANALISI DEI REQUISITI: si stabilisce cosa si vuole rappresentare esattamente;
   
2. PROGETTO DEL SISTEMA: si progetta un sistema basandosi sulle informazioni ricavate dall’analisi dei requisiti;
   
3. REALIZZAZIONE DEL SISTEMA: quello che faremo con Access.

Le prime due fasi, insieme, sono chiamate progettazione, lo scopo è quello di fornire lo schema della base di dati, cioè il progetto. Queste fasi sono uguali per tutti i modelli relazionali, mentre la terza fase dipende dal programma che si utilizza per creare l’archivio.
Eventuali errori nella progettazione non sono facilmente risolvibili, una volta inseriti i dati è difficile poter cambiare lo “schema”, spesso bisogna ripartire da zero e rifare l’intero archivio. Anche una modifica che sembra banalissima potrebbe causare il cambiamento di parte dello schema, cioè della base di dati, in conseguenza a ciò si dovrebbe rifare l’applicazione e si dovrebbero inserire nuovamente tutti i dati. Si deve avere la massima attenzione nella fase di progettazione, perché eventuali errori o dimenticanze non possono essere risolti nella fase successiva.
Per quanto riguarda la seconda fase in Access, è necessario, prima di iniziare a lavorare con il programma stesso, progettare il database. È molto utile fare lo schema grafico delle tabelle necessarie e delle loro relazioni. Il primo passo, per definire le tabelle, consiste nel determinare quali oggetti rappresentare e quali operazioni si vogliono fare sui dati. Ogni oggetto verrà rappresentato con una tabella, che ha le seguenti caratteristiche: un nome, più colonne (campi), più record, una chiave primaria.

ANALISI DEI REQUISITI

Spesso chi crea la base di dati non è la stessa persona o la stessa società che poi utilizzerà l’applicazione finita. L’analisi dei requisiti serve a chi deve creare e progettare l’archivio, per definire “cosa” si deve realizzare. Questa fase è necessaria anche per chi costruisce il database per sé, cioè quando l’utilizzatore e il creatore dell’archivio sono la stessa persona.
L’analisi dei requisiti è lo studio preliminare che si deve fare prima di creare la base di dati, per stabilire:

· gli obiettivi dell’archivio
· i “campi di interesse”
· gli oggetti da rappresentare
· le azioni che si vorranno svolgere sull’archivio
· la durata che avrà l’archivio
· l’ambito in cui dovrà lavorare la base di dati
· tutto ciò che abbia a che fare con l’archivio stesso.

ESEMPIO. Capire l’analisi dei requisiti.
La frase “si vuole realizzare una base di dati per memorizzare i libri” sembra essere sufficiente per definire un tipo di archivio. Questo non è vero, la frase individua solamente “l’obiettivo” principale del database, ma se cento persone dovessero progettare un archivio a partire da questa frase, probabilmente si avrebbero cento risultati diversi. Lo scopo dell’analisi dei requisiti è “analizzare a fondo l’obiettivo” per scoprire tutto ciò che serve per la creazione della base di dati. Per esempio si deve sapere se l’archivio serve per i libri di casa, oppure per una biblioteca, oppure per una libreria. Per i libri di casa sono importanti alcuni aspetti, per la biblioteca altri, per la libreria altri ancora. Per memorizzare i libri di casa non è importante il prezzo di ogni libro, non è importante la data di nascita di ogni autore o la sua nazionalità. Per la biblioteca è molto importante che sia gestito in modo accurato l’ordinamento dei libri e la loro disposizione negli scaffali, in modo che siano recuperabili velocemente. Per la libreria, che vende i libri, è importante conoscere l’aliquota IVA applicabile, sapere se un testo è scontato, si dovrà avere un elenco di clienti con i relativi dati per le fatture.
Una base di dati rappresenta una o più situazioni della vita reale, in base all’utilizzo dell’archivio, gli aspetti della vita reale che sono interessanti cambiano, quindi cambia anche il risultato finale, cioè il programma finale che è il risultato della progettazione e della realizzazione.
L’analisi dei requisiti è praticamente una interrogazione che deve fare chi progetta la base di dati, al committente (colui che richiede la creazione di un archivio). Questa interrogazione deve essere accuratissima, perché in questa fase devono risultare tutti i requisiti necessaria per il database stesso. Ogni singolo oggetto, caratteristica o dato che serve nell’archivio deve essere esplicato e deve “uscire” in questa fase.
La fase successiva, il progetto del sistema, si basa sull’analisi dei requisiti, per cui se la prima fase non è completa o è errata, anche il progetto risulterà incompleto o errato, di conseguenza anche la realizzazione finale sarà sbagliata. Se si trovano errori o elementi mancanti nelle fasi successive, si deve iniziare da capo, dalla prima fase.
Se la persona che “commissiona” il database è la stessa che lo realizza, si deve comunque fare l’analisi dei requisiti. È vero che, in questo caso, chi realizza il database è anche colui che ne ha bisogno e quindi ha già in testa tutto ciò che serve per la realizzazione, ma è meglio utilizzare carta e penna per elencare i requisiti, gli oggetti e gli aspetti da rappresentare. Se non si procede nel modo descritto e si inizia subito da una fase successiva, è facile (e succede quasi sempre quando si procede in questo modo) dimenticare gli aspetti che sembrano marginali o meno importanti. Ci si accorge degli errori solo dopo la creazione dell’applicazione finale, solo quando si inseriscono o si utilizzano i dati, ma, a quel punto, è troppo tardi per rimediare.

ESEMPIO. Banale analisi dei requisiti.
Si vuole rappresentare la lista degli studenti di un corso. I dati che interessano sono il nome, il cognome, la data di nascita, la città di residenza, il numero di telefono. La lista serve semplicemente per fare l’appello e per eventuali comunicazioni urgenti.
Il risultato di questa “pseudo analisi dei requisiti” è una semplice tabella, figura 3.01.
 

 
FIG. 3.01
 

Se non fosse stata fatta l’analisi dei requisiti, il progettatore avrebbe potuto inserire molte altre colonne nella tabella, per esempio indirizzo, e-mail, codice fiscale e professione.

ESEMPIO. Analisi dei requisiti.
Questo esempio è tratto interamente dal libro “BASI DI DATI RELAZIONALI E A OGGETTI”, di Albano, Ghelli e Orsini.
“Questa segreteria si occupa della gestione di alcune pratiche relative agli studenti del Corso di Laurea e del Corso di Diploma in Informatica. In particolare, noi gestiamo le richieste di trasferimento di studenti che provengono da altri Corsi di Laurea o che si spostano tra Corso di Laurea e Corso di Diploma. Quando uno studente desidera trasferirsi da noi, presenta domanda alla Facoltà di appartenenza, che la trasmette alla nostra Facoltà, che poi la trasmette a questa segreteria. La segreteria apre una pratica e trasmette la domanda alla Commissione Pratiche Studenti del Consiglio di Corso di Laurea e di Diploma (CCLD) che prepara una bozza di delibera, dalla 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 cono lo stesso nome fatti nella stessa Facoltà, ma possono esserci delle eccezioni quando i contenuti sono diversi. Per ciò che riguarda le informazioni da trattare, una domanda di trasferimento ha un numero di protocollo e contiene il nome e il recapito dello studente che la presenta, il Corso di Laurea di provenienza, la data di presentazione e l’elenco degli esami esterni superati. Il numero di protocollo è assegnato da noi ed è 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. Una delibera approvata contiene anche il numero e la data del verbale del CCLD che ha approvato tale delibera. Un esame da convalidare è caratterizzato da un’Università, una Facoltà, un Corso di Laurea, un Nome, un anno Accademico. L’università, la Facoltà e il Corso di Laurea dove l’esame è stato superato non coincidono necessariamente con l’Università di provenienza, la Facoltà di provenienza e il Corso di Laurea di provenienza della domanda a cui l’esame esterno appartiene. Gli esami interni hanno un nome, un codice univoco, ed un numero di unità didattiche che varia da uno a quattro. Ogni esame interno può appartenere al Corso di Diploma, al Corso di Laurea, o ad entrambi. Quando un esame esterno è convalidato per un esame interno, la convalida può essere “piena” o con “previo colloquio”. Per alcuni esami esterni esiste una “convalida tipica” per uno studente che passa alla Laurea ed una “convalida tipica” per uno studente che passa al Diploma. Ad esempio, la convalida tipica dell’esame di Fisica I a Ingegneria Elettronica, Facoltà di Ingegneria, è “Fisica Generale (1 UD)” per uno studente che passa al Diploma ed è “Fisica Generale 1 (2 UD)” per uno studente che passa alla laurea. Se la convalida tipica di un esame esterno per uno studente che passa alla Laurea o al Diploma è un esame comune tra Laurea e Diploma, allora, per questo esame, la convalida tipica per la Laurea è uguale alla convalida tipica per il Diploma. La convalida tipica sarebbe utile per la preparazione automatica della bozza di delibera. La convalida tipica può essere “previo colloquio”. Non sempre un esame dato da uno studente è 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 però alla segreteria la possibilità di intervenire per modificare i riconoscimenti proposti dal sistema”.

Successivamente, l’analisi dei requisiti dovrebbe essere rielaborata e scritta in una forma più tecnica, ottenendo così un documento che si chiama SPECIFICA DEI REQUISITI. Per quanto riguarda utenti non programmatori, possiamo dire che si deve semplicemente stilare una lista di oggetti e requisiti che dovranno caratterizzare il database. Per capire cosa deve comprendere questa lista, però, si devono conoscere tutte le altre fasi e si deve avere un’idea chiara di cos’è un database, cioè si deve avere coscienza di come sarà l’applicazione finale. Solo dopo aver provato a realizzare un archivio completo si riesce a capire come stilare la lista.

PROGETTO DEL SISTEMA

In questa fase si definisce lo schema della base di dati. A partire dal risultato dell’analisi dei requisiti, si deve strutturare l’archivio, definendo gli insiemi omogenei di dati (tabelle), i “campi di interesse” di ogni insieme (colonne delle tabelle), le caratteristiche di ogni campo (si tratta di un testo, di una data, di un numero, ecc.) e le relazioni tra gli insiemi (i collegamenti tra le tabelle).
Il risultato di questa fase è lo schema della base di dati, “redatto” con carta e penna. Questo schema è indipendente dal DBMS che poi sarà utilizzato per realizzare il database.

ESEMPIO. Semplice progetto.
Una società che propone corsi di informatica vuole creare una base di dati per memorizzare gli iscritti e i corsi frequentati. L’analisi dei requisiti seguente non è reale, è stata creata appositamente per rendere semplice l’esempio, altrimenti lo schema risultante sarebbe troppo complesso da capire con i pochi concetti introdotti. Sono stati appositamente ridotti i requisiti dell’archivio, per arrivare ad avere esattamente due tabelle.
ANALISI DEI REQUISITI
La nostra società organizza corsi di informatica aperti a chiunque. Ogni corso prevede un nome del corso, un insegnante, un’aula, un orario di inizio e di termine delle lezioni, i giorni della settimana in cui le lezioni sono proposte e un prezzo. Degli iscritti siamo interessati a memorizzare il cognome, il nome, l’indirizzo, il numero di telefono e il corso a cui si iscrivono.
Questa analisi non è completa, come detto sopra, ma per semplicità teniamo conto delle seguenti considerazioni, valide solo per l’esempio, ma improponibili nella realtà:

• Una persona si può iscrivere ad un solo corso alla volta, se si iscrive a più corsi si procede come se fosse un nuovo iscritto, cioè un’altra persona.
  
• Non si tiene conto dei pagamenti.
  
• Non sono considerati gli insegnanti, che nella realtà dovrebbero essere memorizzati con i loro campi di interesse.
  
• Non si tiene conto del calendario, cioè numero del giorno, mese e anno delle lezioni.
  

 
FIG. 3.02
 

Nello “schema” iniziale, i nomi delle colonne sono messi nelle righe, per risparmiare spazio, in modo da vedere insieme tutte le tabelle (nell’esempio sono solo 2, ma potrebbero essere molte di più in una situazione reale).
Si devono poi stabilire le relazioni tra le tabelle. Si vede che le due tabelle hanno un oggetto comune: NomeCorso, questo significa che un dato accomuna le due tabelle, cioè le mette in relazione. Le relazioni verranno trattate dettagliatamente più avanti, per ora accenniamo solo che si deve fare un ragionamento simile al seguente: per come è stata stilata l’analisi dei requisiti, una persona può iscriversi ad un solo corso, un corso può avere più iscritti. Si dice che esiste una relazione uno a molti tra le tabelle Corsi e iscritti.
Per ogni colonna si deve stabilire un nome e un “tipo di dati”, cioè se si tratta di testo, numeri o altro, figura 3.03.
 

 
FIG. 3.03
 

Dopo aver definito le tabelle, i campi e le relazioni tra le tabelle, si deve fare la NORMALIZZAZIONE delle tabelle. Questo argomento verrà trattato dettagliatamente nel capitolo 6, perché sono necessari alcuni concetti che ancora non abbiamo definito. Per il momento si può dire che, per la normalizzazione, si parte dallo schema delle tabelle e relazioni appena costruito e si controlla se questo corrisponde a dei canoni “standard” di correttezza delle tabelle. Se gli insiemi definiti non corrispondono a questi canoni, si devono modificare le tabelle, con le regole che verranno spiegate nel capitolo 6.

REALIZZAZIONE DEL SISTEMA

La realizzazione del sistema è l’unica fase in cui si utilizza Access 2000, o un altro DBMS, solo in questa fase è importante la scelta del programma più adeguato alle proprie esigenze. Consiste nel partire dallo schema della base di dati realizzato nella fase precedente e crearlo, inserirlo, nel computer (si creano quelli che abbiamo chiamato i metadati). In questa fase non si dovrebbero incontrare difficoltà, salvo errori, in quanto tutto è stato “progettato”, preparato, analizzato, nelle fasi precedenti.
Spesso sui manuali (quelli cartacei) si afferma che Access è un programma facile, questo è vero considerando che, una volta superate le fasi precedenti, la difficoltà di Access è pari a quella di ogni altro programma. Il punto è che le fasi precedenti sono di solito svolte da programmatori esperti e non sono né semplici, né intuitive.

Quanto detto fino ad ora non deve scoraggiare nessuno, è difficile per tutti. Per capire molti degli argomenti trattati nei primi capitoli, si dovrà arrivare agli ultimi capitoli. Solo alla fine del manuale si avrà un’idea chiara di cos’è un database e sarà possibile capire cosa serve nell’analisi dei requisiti e cosa è necessario fare nella progettazione. Una volta letto il manuale, dovrete provare a creare semplici archivi, per impratichirvi con gli strumenti imparati, solo così riuscirete a lavorare “facilmente” in Access.
Come già detto nel capitolo introduttivo del manuale, verranno portati avanti due esempi, che alla fine del manuale saranno database completi. Si consiglia di provare a costruire questi due archivi man mano che si procede con la lettura del manuale, perché aiutano molto a capire quanto spiegato.