DBMS: le fasi della realizzazione
Continua il nostro piccolo viaggio nel mondo dei Data Base. Dopo aver introdotto il concetto di dato, leggermente piu' esteso di quello adoperato generalmente in Basic, in questo numero analizzeremo un po' piu' da vicino le tre fasi della realizzazione di una base di dati presso una qualsiasi azienda, con particolari riferimenti all'esempio della biblioteca gia' visto il mese scorso.
Le tre fasi
Si parte dai Bisogni degli Utenti: cio' che i committenti della Base vogliono automatizzare. Generalmente le basi di dati vengono istallate in posti dove gia' esiste un sistema informativo: combinazione di risorse umani e materiali e di procedure organizzate per la raccolta, archiviazione elaborazione e scambio dell'informazione. In merito all'esempio della biblioteca, gli addetti ai prestiti e consultazioni maneggiano informazione anche senza l'ausilio di computer. L'insieme di schedari, registri, gli elenchi (cartacei) di tutti gli utenti sono "informazione" allo stesso modo dei milioni o miliardi di bit sparsi su una unita' a dischi rigidi. Non bisogna mischiare le due cose. Quando salta fuori il computer, si parla di sistema informatico, come sottoinsieme di sistema informativo, finalizzato al trattamento automatico dell' informazione.
Il primo vero e proprio passo verso l'automazione e' la Raccolta dei Requisiti: in questa fase si analizzano le procedure (manuali) gia' esistenti, estraendo da queste il comportamento che dovra' avere il sistema da realizzare. La buona riuscita di questa fase (tra l'altro anche la piu' divertente e in alcuni casi spassosa) sta tutta nella abilita' di chi la cura. Si tratta di compiere vere e proprie indagini sul comportamento della attivita' non automatizzata: scoprire cosa effettivamente vale la pena di far fare a un computer, quali nuove procedure inserire, di cosa il futuro utente della base di dati avra' bisogno ed altro. Il tutto interrogando gli "omini" del luogo (gli addetti, per intenderci) che di solito sono un po' restii a dare informazioni. Essenzialmente per due motivi: primo, l'innata paura della macchina che fa cose da uomini; in secondo luogo chiunque ha ben imparato il suo mestiere difficilmente svela i suoi trucchi. E cosi' la prima cosa da fare e' familiarizzare coi dipendenti della societa' committente....
Raccolti tutti i requisiti, il passo successivio e' estrarre da questi:
Le categorie di dati che andranno trattati dal sistema informatico.
Le condizioni che devono soddisfare i dati perche' siano significativi.
Le procedure aziendali da automatizzare.
Parametri quantitativi sul volume di dati da trattare.
Grado di privatezza e sicurezza dei dati.
Per quanto riguarda il primo punto c'e' ben poco da dire. Di solito i dati trattati dal sistema informatico sono direttamente ereditati dal sistema informativo gia' esistente, con al piu' nuove classi, se necessarie, a causa di inserimento di nuove procedure non contemplate precedentemente.
Il secondo punto riguarda i cosiddetti vincoli di integrita': opportune specifiche atte a rendere quanto piu' significativi e reali i dati mantenuti. Tanto per fare un esempio, un vincolo di integrita' potrebbe essere il controllo sulla data di riconsegna di un libro, necessariamente postcedente a quella di prestito. Sembrerebbe una cosa inutile, ma serve, insieme agli altri vincoli descrivibili, a minimizzare possibili errori fra i dati.
Il terzo punto va analizzato ponendo l'attenzione su cosa devono fare le varie procedure piu' sul come farlo. E' solo nella fase di realizzazione vera e propria che verranno descritti i funzionamenti.
Per quanto riguarda i parametri quantitativi sul volume di dati, la cosa che bisogna maggiormente considerare, e' il loro tasso di crescita e la frequenza di attivazione delle procedure aziendali. In alcuni casi, la mole di dati iniziali e' solo una frazione dei dati effettivamente usati in seguito dalla base.
L'ultimo punto riguarda la privatezza e la sicurezza dei dati. Piu' che ad una biblioteca proviamo a pensare a una banca, e a che cosa potrebbe succedere se i dati non fossero abbastanza al sicuro. Cosa direste se un giorno andando in banca dovessero comunicarvi che non sanno piu' quanto avete in deposito€£?
Sicurezza tanto contro inconvenienti involontari, quanto contro quelli a carattere pirateggiante.
Compreso accidentale mancanza di elettricita', sul piu' bello di una modifica alla base di dati.
Progettazione e Realizzazione
Dopo la fase di raccolta e definizione dei requisiti, si passa al progetto concettuale della base di dati. Purtroppo non esiste un'unica definizione di progetto concettuale: uno dei punti di accordo e' che il progetto non sia troppo orientato ad aspetti realizzativi, ma sia usato essenzialmente per verificare la congruenza con i requisiti specificati, nonche' come mezzo di comunicazione non ambiguo tra i progettisti e con il committente della base di dati. Vengono partoriti i vari schemi, tra cui quelli che mettono in luce le associazioni tra dati.
E' questo il punto cardine di tutto il discorso: il vero passo in avanti portato dall'introduzione sul mercato dei sistemi di gestione per basi di dati e' la possibilita' di agire simultaneamente su piu' insiemi di dati, correlati tra loro. Con i normali sistemi di archiviazione, cio' non era possibile. L'insieme o era unico, o la correlazione tra insiemi di dati doveva essere realizzata dal programmatore a livello di software. La domanda comunque resta sempre: Perche' organizzare dati in piu' insiemi e correrarli tra loro€£?
Tanto per cambiare, il motivo principale e' minimizzare la ridondanza, ossia ripetizioni di dati (di informazione) con ovvio spreco di memoria. Oltre a questo, una migliore organizzazione degli stessi, permette di sfruttare facilmente nuove procedure non utilizzate precedentemente. Per chiarire meglio questo concetto, facciamo un ulteriore esempio. Immaginiamo di voler costruire una mini base di dati su un insieme di indirizzi e numeri telefonici dei nostri conoscenti, sparsi un po' in tutta Italia, ma con ovvi picchi nella nostra citta'.
Ogni registrazione (elemento registrato) sara' composta dai seguenti campi:
Nome
Cognome
Recapito
N.Civico
Telefono
Prefisso
C.A.P.
Citta'
E' chiaro che se conosciamo 50 persone a Bergamo, 25 a Chieti e 30 a Caltanissetta, nel nostro insieme di dati, la sequenza Citta=Bergamo, Cap=24100, Prefisso=035 sara' inutilmente ripetuta 50 volte, cosi' come per Chieti e Caltanissetta e loro relativi Cap e Prefissi.
Se scomponiamo il nostro insieme di indirizzi in due insiemi, Localita' e semi-indirizzi, potremo risparmiare un po' di memoria (nel riquadro i conticini). L'insieme dei semi-indirizzi sara' composto dai seguenti campi:
Nome
Cognome
Recapito
N.Civico
Telefono
SiglaCitta'
Mentre l'insieme delle localita', dai campi:
SiglaCitta'
NomeCitta'
Prefisso
C.A.P.
Per ogni conoscente di Bergamo bastera' specificare BG, nel campo SiglaCitta'. Per quelli di Chieti e Caltanissetta, rispettivamente CH e CL. Il nostro insieme di localita' sara composto da soli tre elementi:
SiglaCitta'=BG
NomeCitta'=Bergamo
Prefisso=035
C.A.P.=24100
SiglaCitta'=CH
NomeCitta'=Chieti
Prefisso=0871
C.A.P.=66100
SiglaCitta'=CL
NomeCitta'=Caltanissetta
Prefisso=0934
C.A.P.=93100
La correlazione tra dati e' rappresentata dal comune campo SiglaCitta' nei due insiemi. Nella costruzione della Base di Dati, si specifica che SiglaCitta' non e' normalissimo campo, ma un puntatore all'insieme Localita'. Automaticamente, il sistema, ad ogni interrogazione sull'indirizzo di un determinato conoscente, ricostruira' l'ennupla completa, agendo su tutt'e due le classi, restituendo:
Nome
Cognome
Recapito
N.Civico
Telefono
SiglaCitta'
NomeCitta'
Prefisso
C.A.P.
Come si puo' notare, pur avendo risparmiato un bel po' di spazio, non abbiamo rinunciato a nulla, anzi abbiamo anche l'informazione circa la sigla automobilistica. Per quanto riguarda l'aspetto procedurale, se abbiamo conoscenti in tutta Italia (forse a questo punto e' meglio parlare di clienti di qualche ditta, per essere piu' reali), organizzando in questo modo i dati, potremmo usare l'informazione in nostro possesso per conoscere ad esempio il Cap di qualche citta' senza necessariamente ricorrere a qualche elemento che abita li'.
Dopo la definizione dei vari schemi, delle classi di dati che useremo, delle varie procedure che saranno utilizzate con la Base di Dati, inizia la vera e propria fase di realizzazione. E' solo in questo momento che entrano in ballo le caratteristiche specifiche del sistema di gestione per basi di dati da noi utilizzato. L'ultimo passo dipende cioe' dallo specifico linguaggio adottato. Come gia' anticipato nel numero scorso, un SGBD e' paragonabile a un potentissimo linguaggio di programmazione, particolarmente orientato al trattamento dei dati. Gli operatori disponibili sono a decine, e tutti dalla potenza incredibile. La fase di realizzazione, dopo aver eseguito una buona raccolta e definizione dei requisiti e un buon progetto concettuale, diventa la piu' facile delle tre operazioni.
Il programmatore (quasi) non deve far altro che tradurre in un linguaggio piu' preciso, quanto partorito nelle due precedenti fasi. Oggi, istallare una base di dati, non vuol dire organizzare informazione su memoria di massa. Niente problemi di Sort (ordinamento), raccolta, verifica e recupero dei dati: a tutto questo pensa il sistema. Anzi, la tendenza attuale e' proprio quella di ottenere l'indipendenza delle applicazioni dall'organizzazione fisica e logica dei dati. Indipendenza fisica vuol dire che se un sistema e' Data Base, non dovremo mai sentirci limitati da come vengono organizzati fisicamente su disco i dati. Se vogliamo trattare l'informazione in un determinato modo, il sistema non deve impedircelo.
L'indipendenza logica e' un po' piu' complicata da spiegare e allo stesso tempo anche piu' difficile da garantire. In parole povere, dopo aver progettato e realizzato una Base di Dati secondo uno schema logico, modifiche a questo non devono ripercuotersi anche sui programmi applicativi (procedure) gia' scritte. Sempreche' le modifiche non siano radicali.
Meno parole...
Con gli elementi in nostro possesso, possiamo divertirci un po' a simulare l'istallazione di una Base di Dati preso una biblioteca. La prima operazione che compiremo, e' definire le categorie di dati da trattare. Immaginiamo che possa usufruire della biblioteca qualsiasi cittadino, dotato di regolare documento di riconoscimento. E' possibile consultare qualsiasi libro o pubblicazione e prendere in prestito per un limitato numero di giorni (diciamo al piu' 10 gg.) solo un sottoinsieme del materiale in possesso della biblioteca. Cio' per evitare che testi di particolare interesse siano non disponibili per la consultazione. Inoltre, se un testo non e' presente, l'utente puo' lasciare una prenotazione che blocca il testo al momento della riconsegna per 24 ore, tempo massimo concesso per il nuovo ritiro, senza che altri glielo "rubino".
Tra i vincoli che imporremo: ogni utente non puo' prendere in possesso piu' di tre libri e non gli vengono piu' concessi prestiti se precedentemente ha riconsegnato un libro con piu' di due giorni di ritardo.
I dati che tratteremo riguardano i materiali in possesso della biblioteca, la lista di tutti gli utenti che consultano o prendono il prestito libri o pubblicazioni, tutte le prenotazioni e l'insieme dei materiali in prestito. La situazione e' mostrata in figura 1 ed e' la stessa vista nel numero scorso, con la sola aggiunta dei nomi delle associazioni tra oggetti di classi diverse.
Di maggiore rilevanza e' curare l'aspetto procedurale: quale sara' il comportamento della base di dati una volta funzionante. Le principali operazioni che verranno svolte saranno appunto quelle inerenti prestiti, consultazioni e restituzione dei materiali. Oltre a queste, la possibilita' di conoscere la lista dei libri che dovrebbero essere restituiti in giornata (di ogni libro prestato si conosce la data di restituzione), la lista degli utenti ritardatari, i testi maggiormente richiesti ed altro. Inutile dire che il sistema dovra' automaticamente stabilire se concedere o meno un prestito. In altre parole, oltre a sapere se il libro sia o no presente tra gli scaffali, deve controllare i quattro seguenti vincoli:
Il testo e' tra quelli prestabili.
L'utente non ha piu' di due testi gia' in prestito.
L'utente non e' un ritardatario.
Il testo non e' stato gia' prenotato da qualcuno (o la prenotazione e' scaduta).
Al momento della riconsegna, il sistema esegue le due seguenti operazioni:
Toglie il testo dalla classe dei Materiali Prestati.
Controlla che non siano passati piu' di 12 giorni dalla data di consegna (altrimenti segnala l'utente nella classe come utente ritardatario).
Per questo mese ci fermiamo qui. Sul prossimo numero vedremo come sia possibile realizzare una tale base col modello semantico dei dati sfruttato dal Basic-micatanto e dai linguaggi SGBD dell'ultima generazione. Teniamo a ricordarvi che il Basic-micatanto, seppur inventato di sana pianta per mostrare come si operi su insiemi di registrazioni, non differisce molto dai sistemi di gestione per basi di dati oggi in commercio: il suo uso e' particolarmente adatto a noi (basic-dipendenti) maledettamente abituati ai numero linea e ai GOTO.
