L'aspetto più importante dei database è l'organizzazione dei dati a livello logico. All'inizio della storia dei database, possiamo dire negli anni '60, esistevano vari metodi per organizzare le informazioni da archiviare ma erano lenti nell'accesso ai dati e facilmente portavano ad errori. In quegli anni il dottor E.C. Codd, ricercatore in IBM, lavorava sui sistemi di archiviazione ed era insoddisfatto dell'inefficienza dei metodi esistenti. Codd si mise a studiare il problema e, essendo un matematico, finì per formulare una teoria che rese nota nel 1970 con un articolo divenuto ormai famoso dal titolo "A relational model of data for large shared databanks" (Un modello relazionale dei dati per banche dati di grandi dimensioni).

 

Un programmatore, Larry Ellison, lesse l'articolo e iniziò a lavorare ad un software che potesse mettere in pratica le teorie del Dr. Codd. Ellison commercializzò questo prodotto dando così i natali alla fortunata storia della società Oracle, la più grande azienda produttrice di database per grandi e grandissime organizzazioni. Ellison è diventato uno degli uomini più ricchi del mondo, Codd è rimasto un matematico soddisfatto del suo lavoro ...

 

Approfitto per ricordare, come ho fatto in altre parti di questo corso, come sia importante il contributo della matematica, materia insegnata malissimo, incompresa nell'impiego quotidiano e soprattutto nel ruolo insostituibile che ha nelle attività umane. Oggi si tende a focalizzare l'attenzione sul "progresso tecnologico" con l'idea che comunque ormai la "tecnologia va avanti". Se questo è vero, lo è perché c'è la matematica sotto che è andata avanti. Senza sostanziali risultati matematici che visti in sé possono apparire astratte e inutili costruzioni del pensiero, non si ricostruirebbe una TAC, non esisterebbero le ricerche in Internet, non esisterebbe la gestione dei conti correnti bancari, le carte di credito, i bancomat, i telefonini, l'ABS e praticamente tutto quello che oggi sembra normale e scontato. Riflettiamo gente ...

 

Tornando all'organizzazione dei database, le idee di Codd si sono realizzate in quella cosa che oggi si chiama database relazionale. In questo tipo di database le informazioni vengono strutturate in tabelle.

Vediamo un semplice esempio per la gestione di una segreteria di studenti iscritta all'università. Si potrebbe pensare di organizzare tutte queste informazioni in una tabella di questo tipo:

 

DATI STUDENTI

MATR	COGNOME	NOME	DATA NASCITA	COMUNE	CAP	PREF. TELEF.	PROV.	ESAME	CREDITI	DATA	VOTO	...
11000	Birillo	Cecco	28-10-85	Chieti	66100	0871	CH	Fisica	3	20-01-2007	28
11001	Frescolini	Sigismondo	12-5-85	Bologna	40100	051	BO	Informatica	3	15-01-2007	26
11002	Paolino	Paperino	18-12-82	Milano	20100	02	MI

 

In realtà, l'impiego di una tabella non è solo un modo ordinato di rappresentare le informazioni ma comporta una precisa strutturazione dei dati: la tabella nasce in seguito alla decisione di quale sia l'entità fondamentale da catalogare e dall'individuazione di tutti gli attributi che la determinano utilmente. Nel nostro caso, nome, cognome, dati anagrafici, esami sostenuti, date e crediti.

 

Senza dubbio il formato di una tabella sembra un buon modo di rappresentare le informazioni ma il problema non è di sola rappresentazione bensì anche di gestione dei dati. Non è che non si possa strutturare un database immaginando i dati organizzati come nella tabella precedente e questo in passato è stato fatto. Si tratta in sostanza di scrivere del software che sia in grado di manipolare una tabella simile. Facciamo un paio di esempi.

Dai dati memorizzati nella tabella appare che due dei tre studenti abbiano fatto un esame. Ma che succede quando faranno altri esami? Sarà necessario aggiungere delle celle alla riga di ogni studente che farà un esame in più, precisamente una terna di celle per ogni nuovo esame. Avremo quindi una situazione nella quale ogni riga avrà, in generale, un numero di celle diverso in dipendenza del numero di esami superati da ciascuno studente. Non è impossibile scrivere un software che gestisca così i dati ma, operando su grandi quantità di dati, il recupero delle informazioni può essere molto lento e il rischio di errori elevato. Facciamo un altro esempio.

Supponiamo che, ad un certo punto, il Consiglio del Corso di Laurea decida di attribuire un diverso numero di crediti ad un corso, per esempio che il corso di fisica passi da tre quattro crediti. Per aggiornare il database sarà necessario aggiornare tutte le celle della tabella dove appaiono i crediti relativi all'esame di fisica, qunid in tutti i casi nei quali uno studente abbia fatto l'esame di fisica. Anche questo si può fare ma risulterebbe in procedure lente e esposte ad errori. Una semplice modifica del genere richiederebbe la modifica di migliaia di dati in un database reale.

Gli esempi che abbiamo fatto sono banali e ingenui ma bastano per capire il concetto. Ebbene, la teoria concepita da Codd, che ha dato vita ai database relazionali, serve proprio ad ottimizzare problemi di questo tipo ottenendo grande velocità di accesso e minima probabilità di errore. L'esempio che abbiamo visto, alla luce della teoria dei database relazionali, verrebbe trasformato segmentando l'informazione in più tabelle, ciascuna legata ad un tipo di informazione distinto e ciascuna dotata di righe con un numero fisso di colonne.

 

Per esempio avremmo una tabella con i dati anagrafici degli studenti:

 

ANAGRAFICA

MATR	COGNOME	NOME	DATA NASCITA	COMUNE
11000	Birillo	Cecco	28-10-85	Chieti
11001	Frescolini	Sigismondo	12-5-85	Bologna
11002	Paolino	Paperino	18-12-82	Milano

 

una relativa alle informazioni pertinenti ai comuni:

 

DATI COMUNI

COMUNE	CAP	PREFISSO TELEFONO	PROVINCIA
Milano	20100	02	MI
Cagliari	09100	070	CA
Bologna	40100	051	BO
Chieti	66100	0871	CH

 

un'altra agli esami sostenuti:

 

ESAMI SOSTENUTI

MATRICOLA	CODICE ESAME	DATA	VOTO
11000	X15	20-01-2007	28
11000	W2	04-12-2006	30
11001	Z31	15-01-2007	26

 

e infine una per gli esami disponibili:

 

DATI ESAMI

CODICE ESAME	DENOMINAZIONE ESAME	CREDITI
A15	Biologia	3
A16	Istologia	5
X15	Fisica	3
W2	Anatomia	5
W3	Scienze Umane	3
Z31	Informatica	3

 

Ci rendiamo subito conto che, in primo luogo non c'è più il problema di dover gestire righe di lunghezza variabile e, in secondo luogo, è molto più semplice fare delle modifiche. Per esempio se si deve cambiare il numero di crediti dell'esame di fisica basta farlo solamente nella cella appropriata della tabella degli esami.

 

Anche se si ha subito la sensazione di una struttura più nitida, può sembrare che al fine di ridurre delle complicazioni se ne siano introdotte delle altre; infatti prima avevamo una sola tabella ed ora ne abbiamo quattro. Ebbene, Codd ha dimostrato che le nuove complicazioni sono molto più accettabili delle precedenti. Con i database relazionali è possibile archiviare strutture molto complesse riuscendo a gestirle con velocità e sicurezza. Per avere un'idea palpabile delle complessità che può avere un database in un esempio che potete, per così dire, toccare con mano, potete dare un'occhiata allo schema del database di ATutor, il quale ospita le lezioni con tutti i vari supporti, quali i test di autovalutazione e il forum di discussione, i dati degli iscritti e la traccia di tutte le loro attività.

 

 

La tabella è quindi l'elemento fondamentale di un database relazionale. Abbiamo visto che la prima riga in alto della tabella contiene i nomi degli attributi della tabella. Questi nomi, nel linguaggio dei database, si chiamano campi. Per esempio nella tabella ANAGRAFICA i campi sono MATR, COGNOME, NOME, DATA NASCITA e COMUNE.

 

Le righe successive contengono gli oggetti archiviati, uno per ogni riga. Questi prendono il nome di record, dove ogni record è costituito dall'insieme dei valori che assumono i campi per quell'oggetto. Per esempio il primo record della tabella ANAGRAFICA è costituito dai valori 11000, Birillo, Cecco, 28-10-85, Chieti.

 

Il legame fra le diverse tabelle è costituito da una serie di relazioni che vengono definite fra alcuni dei campi che compaiono nelle tabelle. Da questo viene la denominazione database relazionale. Proviamo ad individuare qualche relazione nel nostro esempio. È vero che la tabella ANAGRAFICA contiene solo informazioni anagrafiche ma implicitamente contiene anche dei riferimenti ad altre tabelle: infatti le sue colonne intitolate MATRICOLA e COMUNE compaiono rispettivamente anche nella tabelle DATI COMUNI e ESAMI SOSTENUTI. Ho usato i colori per identificare le celle che sono poste in relazione fra loro. I campi utilizzati per creare le relazioni prendono il nome di chiavi. In ogni caso ogni tabella deve avere almeno una chiave, detta chiave primaria, che deve assumere un valore unico per ogni riga della tabella e che viene utilizzata dal sistema per reperire rapidamente le informazioni. Altri campi che vengono messi in relazioni con chiavi primarie di altre tabelle, prendono il nome di chiavi esterne. È il caso del campo COMUNE nel nostro esempio.

 

Concludiamo questa descrizione osservando che essa è molto sommaria e semplificata, dovendo solo servire a dare un'idea dei concetti fondamentali. La teoria dei database relazionali fornisce delle regole ben precise per progettare correttamente le tabelle di un database. Malgrado questo, la progettazione di un database che sia veloce e sicuro da usare è un processo complesso che richiede esperienza e intuito. La creazione di un database esula da questo corso, limitiamoci a dire che, prima ancora di avvicinarsi al computer, è necessario un lavoro preliminare composto da quattro fasi:

1. analisi delle informazioni da memorizzare, con la quale si cerca di capire bene quale sia la natura delle informazioni e cosa sia realmente necessario archiviare e cosa sia invece superfluo;
2. creazione dello schema delle informazioni, dove si determinano gli oggetti che devono essere catalogati nelle varie tabelle e quali siano esattamente gli attributi che li determinano; gli attributi sono quelli elencati nella prima riga in alto mentre i singoli oggetti sono elencati nelle righe successive, un oggetto per ogni riga;
3. determinazione degli elementi delle tabelle mediante la descrizione dei tipi di dati (per esempio numeri, date, valuta, nomi) e la definizione della chiave primaria;
4. definizione delle relazioni fra gli attributi delle tabelle.

 

Esistono sistemi per la creazione e la gestione di database locali, interamente contenuti ed impiegati all'interno del proprio computer. Vi accenneremo successivamente. Sono sistemi interamente basati su interfacce grafiche, come è usuale oggi per quasi tutti i tipi di software di largo uso. Questo non deve però trarre in inganno lasciando pensare che con poca fatica e pochi click si possa mettere su un database. A meno che non si voglia utilizzarne qualcuno già preconfenzionato per qualche semplice scopo, tipo la gestione di una rubrica di contatti, la pianificazione del database non è per niente semplice.

 

Elementi fondamentali di un DMBS

 

Vediamo ora cosa è un DBMS dal punto dell'utente, dove con il termine utente intendiamo chi consulta ed aggiorna regolarmente un database: l'impiegato delle ferrovie che fa le prenotazioni per i viaggiatori, l'impiegato nell'accettazione di un'azienda ospedaliera, la caposala di un reparto ospedaliero per gestire la disponibilità dei farmaci che servono in reparto, l'impiegato di un'agenzia di viaggi, di uno sportello bancario e via via gli esempi sono innumerevoli. Anche voi che state leggendo siete utenti di un database quando accedete per un qualsiasi motivo alla piattaforma di questo corso. Per tutti questi diversi tipi di utenti, un DBMS è composto sostanzialmente da maschere, query e report.

 

Maschere

 

Le maschere servono per l'introduzione di nuovi dati nel database e per formulare delle query, le query servono per cercare dati e i report per mostrare i risultati delle ricerche.

Le maschere sono pagine Web conformate per l'introduzione di dati. Tipicamente, un operatore può avere la necessità di introdurre un nuovo oggetto nel database. Per esempio, quando vi siete registrati su questa piattaforma, avete dovuto inserire alcuni vostri dati nel sistema. Ebbene, la pagina dove avete fatto questa operazione è una maschera. La maschera vi ha consentito di riempire un certo numero di campi con i vostri dati, con l'operazione di invio finale avete aggiunto al database un oggetto, costituito dall'insieme dei dati che vi caratterizzano. Per il database della piattaforma il concetto di studente è semplicemente costituito da nome di login, password, nome, cognome, indirizzo di posta elettronica.

Anche quando scrivete un messaggio nel forum utilizzate una maschera. In questo caso essa offre semplicemente due campi da riempire con del testo, quello del titolo del messaggio e quello per il testo del medesimo.

Quando chiedete informazioni sulla disponibilità di posti in un treno ad uno sportello della stazione, l'impiegato ha di fronte a se una maschera che gli consente di formulare al database delle ferrovie la domanda che voi gli avete fatto.

 

Query

 

La query è un'interrogazione fatta al database. Implicitamente, quando utilizzate la piattaforma, voi formulate molte query. Ogni volta che richiedete un certo tipo di immagine viene composta una query che si risolve nel recupero di un insieme di informazioni. Per esempio, quando decidete di leggere qualcosa nel capitolo 3 e fate click sul link corrispondente, il sistema ATutor compone una query per recuperare dal database il contenuto corretto e tutti gli altri elementi ad esso connesso, come per esempio i riferimenti alle voci del glossario che servono in quel capitolo.

La piattaforma, come la maggior parte dei sistemi che utilizzano un database, provvede alla composizione della query. Questo vuol dire che compone un testo formalizzato in un linguaggio preciso che può essere inviato al DBMS per effettuare la ricerca desiderata. Il linguaggio di gran lunga più usato si chiama SQL (Structured Query Language). Per darvi un'idea, eccome appare in SQL la richiesta di estrarre tutti nomi e cognomi degli studenti archiviati nel database:

 

SELECT NOME, COGNOME FROM ANAGRAFICA

 

dove ho scritto in rosso i comandi SQL, i nomi rimasti in nero sono invece nomi di campi e tabelle, NOME, COGNOME e ANAGRAFICA.

Non è quasi mai necessario ricorrere alla formulazione diretta delle query in SQL, è proprio uno dei compiti delle applicazioni di gestione quello di comporre la query da somministrare al DBMS offrendo all'utente comodi sistemi grafici per la formulazione dei quesiti.

Riprendendo l'esempio della richiesta di prenotazione di un posto in treno, in seguito alla vostra richiesta ed alla compilazione della maschera per le prenotazioni fatta dall'impiegato, l'applicazione di gestione provvede poi a formulare una query al DBMS. Se il posto è disponibile e scegliete di prenotarlo, l'impiegato introduce un nuovo oggetto nel database mediante un'altra maschera.

 

Report

 

Infine, i report sono la rappresentazione delle informazioni richieste. Possono essere sotto forma di semplici tabulati ma possono anche essere testi, immagini o qulasiasi altra cosa. I contenuti disponibili nella piattaforma possono essere pensati come una raccolta di particolari report. Il biglietto che vi consegna l'impiegato delle ferrovie è un report che contiene i dati del treno che avete scelto e del posto che vi è stato prenotato.