Progettazione di database: aspetti teorici

Con questo primo articolo diamo il via ad una serie di lezioni dedicate alla progettazione, allo sviluppo ed alla gestione di database.
Abbiamo scelto di partire, prima, da alcune importanti informazioni teoriche che costituiscono la chiave di volta per comprendere tutte le problematiche più complesse legate alle basi di dati.
La trattazione dei temi presentati in questo articolo necessiterebbero un’analisi certamente più ampia e dettagliata. Il nostro obiettivo primario è e resta comunque quello di fornire buone basi per approfondire, poi, successivamente l’argomento.

Ecco le linee guida dei nostri quattro articoli dedicati ai database:

1. Introduzione alla progettazione di database
2. Progettazione di database in pratica (modello Entity-Relationship; implementazione in Access)
3. Linguaggio SQL (introduzione all’algebra ed al calcolo relazionale; uso di SQL per effettuare interrogazioni sulle basi di dati)
4. Esempi pratici di utilizzo del linguaggio SQL: basi di dati esemplificative

Un DBMS (Database Management System) è un sistema (prodotto software) in grado di gestire insiemi di dati che siano grandi (di dimensioni molto maggiori della memoria centrale dei sistemi di calcolo utilizzati), persistenti (con un periodo di vita indipendente dalle singole esecuzioni dei programmi che attingono ai dati), condivisi (utilizzati da applicazioni diverse).
Il DBMS deve garantire affidabilità (resistenza a malfunzionamenti hardware e software) e privatezza (controllo degli accessi). Come ogni prodotto informatico, un DBMS deve essere anche efficiente ed efficace.

Oggi chiunque, a vari livelli, desideri memorizzare e gestire semplicemente dei dati e delle informazioni deve ricorrere all’utilizzo di DBMS: dal libero professionista che vuole servirsi di uno strumento per la gestione delle proprie fatture, alla banca (che necessita di un sistema informativo sicuro e performante per la gestione delle operazioni dei propri clienti).

Probabilmente il DBMS più famoso a livello “consumer” è Microsoft Access. Esistono comunque decine di DBMS, particolarmente indicati per usi professionali (MySQL, PostgreSQL, IBM DB2, Oracle, Microsoft SQL Server, Sybase, FileMaker,…).

Dati e informazioni
Cominciamo col fare un pò di chiarezza sulla differenza che intercorre tra il concetto di dato e quello di informazione.
Il dato può essere definito come “la registrazione, tramite uno speciale codice, di un aspetto della realtà”. I dati hanno bisogno di essere interpretati per fornire conoscenza: di per sé, quindi, i dati non forniscono informazione. L’insieme di dati, invece, opportunamente organizzati, può dare informazione.
L’informazione può essere definita come “la percezione di un insieme di dati, attraverso un processo di interpretazione”.
“212” e “Mario” sono due dati. Di per sé non significano nulla. In risposta alla domanda: “Qual è l’interno della persona che si occupa della gestione del personale?” i due dati vengono invece a fornire informazione.

Basi di dati e sistemi informativi
I DBMS gestiscono basi di dati. Ciò significa che i database sono in grado di operare su collezioni di dati (basi di dati) utilizzate per rappresentare le informazioni di interesse, necessarie per le applicazioni più disparate.
Il concetto di sistema informativo si collega direttamente alle basi di dati: si tratta infatti dell’insieme di informazioni utilizzate, memorizzate ed elaborate. Un sistema informativo, in senso informatico, può utilizzare più basi di dati e costituisce la piattaforma utilizzata da un’azienda per la gestione automatizzata delle proprie attività.
Va comunque sottolineato che il concetto di sistema informativo esula anche dall’ambiente informatico: esistono organizzazioni la cui ragion d’essere è la gestione di informazioni (per esempio i servizi anagrafici e le banche) che operano da secoli (ben prima dell’avvento dei computer e dei sistemi informatici in generale).

Il modello relazionale. Relazioni e tabelle.
Per l’organizzazione dei dati all’interno di un DBMS vengono utilizzati dei modelli logici totalmente indipendenti dalla struttura fisica del database.
Il modello relazionale è certamente quello oggi più utilizzato: proposto già nel 1970 da E.F. Codd diventò disponibile in DBMS reali solo a partire dal 1981.
La sua peculiarità consiste nel fatto che è basato sui valori. Ciò significa che i riferimenti tra dati in strutture (relazioni o tabelle) diverse sono rappresentati per mezzo dei valori stessi.
Avviando Microsoft Access ci si imbatterà subito nelle tabelle.
Una tabella (coincide con il concetto di “relazione” di E.F. Codd) è costituita da righe e colonne; ad ogni colonna (dominio) è associato un attributo univoco (diverso da tutti gli altri) che ne descrive il ruolo. Ad esempio:

InCasa	FuoriCasa	RetiInCasa	RetiFuoriCasa
Inter	Lazio	3	0
Roma	Juventus	2	1
Juventus	Bologna	1	0
Roma	Inter	0	2
Chievo	Udinese	4	3
Parma	Atalanta	1	0

Gli attributi sono “InCasa”, “FuoriCasa”, “RetiInCasa” e “RetiFuoriCasa”.
In una tabella, inoltre, i valori di ogni colonna sono tra loro omogenei (non è ammissibile, ad esempio, trovare il valore “Inter” nella colonna “RetiInCasa”).
Va sottolineato, infine, che in una tabella l’ordinamento delle righe (così come quello delle colonne) è del tutto irrilevante. L’informazione, insomma, non è legata alla posizione dei dati: conoscendo la semantica (ossia il signficato degli elementi memorizzati in ogni singola colonna), grazie agli attributi, pur scambiando la posizione delle colonne, l’informazione non viene alterata.
Ecco perché Microsoft Access ed altri database simili sono detti database relazionali. Si tratta di un modello basato su valori perché i riferimenti fra dati in tabelle diverse sono rappresentati per mezzo dei valori che compaiono all’interno delle varie righe di ciascuna tabella.

Perché usare più tabelle?
Chi non ha mai utilizzato un DBMS è facile che si chieda per quale motivo si renda necessario l’utilizzo di più tabelle quando, probabilmente, sarebbe possibile memorizzare le varie informazioni in un’unica tabella. In realtà una pratica simile deve essere assolutamente evitata.
Immaginate di avere a che fare con il database di un hotel: se esso fosse costituito da un’unica grande tabella, qualora volessimo intervenire sui dati anagrafici di un cliente dovremmo modificare ogni sua prenotazione memorizzata; se volessimo cancellare una prenotazione, inoltre, elimineremmo tutti gli altri dati relativi al cliente.
L’uso di più tabelle ci consente di organizzare i dati secondo tipologie ben definite (è possibile, per esempio, creare una tabella per l’anagrafica di tutti i clienti; una per le prenotazioni; un’altra per i servizi erogati; un’altra ancora per le fatture emesse e così via…). Non solo, usando più tabelle si evita il problema della ridondanza (non è necessario memorizzare più volte gli stessi dati), si risolvono problemi legati all’inconsistenza dei dati, si velocizzano in generale le operazioni di recupero, modifica e cancellazione dei dati.

Il modello basato sui valori: tabelle e vincoli

Modello basato su valori: come si legano più tabelle
Si tratta di un concetto di fondamentale importanza. Nel modello relazionale, utilizzato dai moderni DBMS, il legame tra tabelle diverse si basa sul valore.
Analizziamo un esempio pratico in modo da chiarificare le idee:

Tabella IMPIEGATI:

Cod_fiscale	Cognome	Nome	Data_nascita
BNC PRI 56D08 D612O	Bianchi	Piero	08/04/1956
RSS NTN 66R15 G702T	Rossi	Antonio	15/10/1966
CSR GLI 37S24 H501C	Cesare	Giulio	24/11/1937
BNP GPP 80D20 L219D	Bonaparte	Giuseppe	20/04/1980
VRD MRA 76H63 C352W	Verdi	Maria	23/06/1976

Tabella PROGETTI:

Sigla	Titolo	Descrizione
AF123	Sviluppo di un software per la gestione magazzino	Il progetto consiste nello sviluppo di…
AA824	Sviluppo di sistema per l’acquisizione di dati da dispositivi TWAIN	Il progetto consiste nel realizzare…
MP777	Algoritmo di compressione MPEG-5 🙂	Il progetto consiste nell’implementare…

Tabella PARTECIPAZIONE:

Impiegato	Progetto	Data
RSS NTN 66R15 G702T	MP777	01/04/2003
BNP GPP 80D20 L219D	MP777	20/02/2003
VRD MRA 76H63 C352W	AF123	18/01/2003
BNP GPP 80D20 L219D	AA824	24/02/2003
BNC PRI 56D08 D612O	AA824	05/03/2003

E’ immediato notare come – tra le tre tabelle – intercorra un legale basato sui valori in esse “memorizzati”. E’ facile rendersi conto di come il dominio Progetto (contenuto nella tabella Partecipazione) sia in relazione con il dominio Sigla (contenuto nella tabella Progetti). Inoltre, il dominio Impiegato (contenuto nella tabella Partecipazione) sembra essere in relazione con il dominio Impiegato (contenuto nella tabella Progetti).
Analizzeremo e caratterizzeremo meglio, tra poco, i legali che intercorrono tra le varie tabelle.
Prima di procedere è bene però fare luce su un punto cruciale: la mancanza di informazione.

Quando si ha a che fare con informazioni incomplete: soluzioni
Abbiamo detto poco fa che il dato può essere definito come “la registrazione, tramite uno speciale codice, di un aspetto della realtà”. Talvolta, durante la creazione di una base di dati, è possibile imbattersi in un problema non di poco conto: l’informazione incompleta.
Come fare quando, per esempio, non si conosce un dato? Nel nostro ultimo esempio supponiamo di non conoscere (o comunque, di non avere a disposizione) la data di inizio partecipazione ad un determinato progetto. Com’è possibile risolvere il problema? Quale valore dobbiamo inserire?
In passato programmatori poco “attenti” usavano utilizzare valori come 0, 99 (e simili) per “marcare” tutti i dati sconosciuti. Si tratta, però, di una pratica del tutto sconsigliabile: alcuni dei valori inseriti potrebbero infatti risultare, in talune circostanze, significativi; potrebbero non esistere valori “non utilizzati”; in fase di utilizzo della base di dati sarebbe necessario ogni volta tenere conto del significato di tali valori.

Per risolvere il problema i moderni DBMS adottano lo speciale valore NULL. Esso non fa parte di alcun dominio: si tratta di un “valore indefinito” che può essere adottato nel caso si abbia a che fare con valori sconosciuti, inesistenti o senza informazione.

Tabella PARTECIPAZIONE:

Impiegato	Progetto	Data
RSS NTN 66R15 G702T	MP777	01/04/2003
BNP GPP 80D20 L219D	MP777	20/02/2003
VRD MRA 76H63 C352W	AF123	18/01/2003
BNP GPP 80D20 L219D	AA824	24/02/2003
BNC PRI 56D08 D612O	AA824	NULL

In questo caso, per esempio, non conosciamo la data di inizio partecipazione al progetto siglato AA824 per l’impiegato cui è associato il codice fiscale BNC PRI 56D08 D612O.

Va sottolineato, comunque, che i valori NULL debbono essere impiegati con estrema cura e cautela. Utilizzandoli senza alcun criterio rischieremmo, infatti, di “deteriorare” la nostra base di dati:

Tabella PARTECIPAZIONE:

Impiegato	Progetto	Data
RSS NTN 66R15 G702T	MP777	01/04/2003
NULL	MP777	20/02/2003
VRD MRA 76H63 C352W	NULL	18/01/2003
NULL	NULL	24/02/2003

Nell’esempio è chiaro come la tabella Partecipazione (e quindi la nostra base dati) risulti deteriorata a causa del “selvaggio” utilizzo dei valori NULL: nella seconda riga non si ha alcuna informazione sull’impiegato; nella terza è sconosciuto il nome del progetto; nell’ultima non si conosce né impiegato né relativo progetto (informazione assolutamente inutile).
Questo tipo di situazioni va, quindi, evitato mediante un utilizzo “intelligente” e limitato dei NULL.

Utilizzo di vincoli: chiavi
In tutti i database è possibile far uso dei cosiddetti vincoli di integrità: essi permettono di “vigilare” sulla qualità dei dati inseriti; permettono di descrivere la realtà in modo più accurato; sono utili nella progettazione e vengono usati anche dai DBMS nella esecuzioni di interrogazioni (query) sui dati.
Il vincolo più importante a livello di singola tabella si chiama chiave: si dice “vincolo intrarelazionale” perché vale all’interno di una singola singola.
La chiave permette di identificare, in modo univoco, le righe di una tabella.
Nell’esempio precedente, l’attributo Cod_fiscale è chiave per la tabella Impiegati: esso infatti consente di identificare, in modo univoco, ogni singola riga (si chiamano anche n-uple) che compone la tabella.
Nella tabella Progetti, utilizziamo l’attributo Sigla come chiave.
Nella tabella Partecipazione, invece, la chiave è costituita da due attributi: Impiegato e Progetto.
Le chiavi primarie, ricorrenti in tutti i DBMS, sono chiavi che non ammettono la presenza di valori nulli (NULL). Le chiavi che abbiamo citato sono tutte chiavi primarie.

Per indicare una chiave primaria suggeriamo di utilizzare una notazione basata sulla sottolineatura:
Impiegati(Cod_fiscale, Cognome, Nome, Data_nascita)
Progetti(Sigla, Titolo, Descrizione)
Partecipazione(Impiegato, Progetto, Data)

Vincoli di integrità referenziale
Le chiavi sono vincoli di tipo “intrarelazionale” perché valgono a livello di una singola tabella. Ma come è possibile, a questo punto, correlare le informazioni che memorizziamo in tabelle diverse?
E’ possibile stabilire un legame stretto tra le varie tabelle che compongono il nostro database mediante i valori assunti dalle chiavi primarie.
Nel nostro esempio diremo che esitono i vincoli di integrità referenziale seguenti:
– Tabella PARTECIPAZIONE: vincoli di integrità referenziale fra Progetto e la relazione PROGETTI e fra Impiegato e la relazione IMPIEGATI

E’ importante sottolineare i vincoli di integrità referenziale (foreign key) sussistono tra gli attributi X di una tabella T1 ed un’altra tabella T2. Ciò significa che il vincolo di integrità referenziale impone ai valori dell’attributo X (contenuto nella tabella T1) di comparire come valori della chiave primaria della tabella T2.

Quando si tenta di eliminare delle righe di una tabella (n-uple) sottoposte a vincoli, i DBMS rispondono con azioni compensative: è possibile rifiutare l’operazione di cancellazione; effettuare eliminazioni in cascata (ad esempio delle n-uple correlate in altre tabelle); introdurre valori nulli. Vedremo nel seguito le varie possibilità.

– Nella prossima lezione analizzeremo la progettazione di database in pratica servendoci dei cosiddetti modelli concettuali (essi permettono di descrivere in modo succinto – e senza perdersi in inutili dettagli – i concetti del mondo reale che si desiderano gestire mediante la propria base di dati). Passeremo quindi all’implementazione di una base dati in Microsoft Access.