Title: E’ necessario distinguere fra informazione e dato
Author: Franco
Last saved by: Roberto Delle Donne

I database nella ricerca storica e archeologica 

Il modello entity-relationship
 e i database relazionali

Franco Niccolucci
Università di Firenze
niccolucci@unifi.it

1.	
Introduzione

Uno degli utilizzi più diffusi dell’informatica è la gestione di archivi di dati. In particolare, quando le informazioni possono essere rappresentate da testi o quantità (intese in senso lato: ad esempio, date), i dati e gli archivi che li contengono sono detti alfanumerici.

Naturalmente il sistema di archiviazione prevede la possibilità di reperire le informazioni che vi sono contenute in modo rapido, efficiente e sicuro: in tal caso il sistema prende il nome di base di dati o database. Un database è quindi un sistema di archiviazione di dati con un’organizzazione finalizzata al reperimento delle informazioni che essi contengono, in modo efficiente (nel senso delle prestazioni) e sicuro (nel senso di non perdere informazioni). Il modo con cui le informazioni vengono cercate (interrogazione del database) non è necessariamente semplice o agevole: tuttavia, quasi tutti i database sono dotati di un’interfaccia, cioè una modalità operativa, di uso relativamente semplice. Va notato, comunque, che tanto più è sofisticato l’uso che si intende fare del database, tanto meno è probabile che si possa usare un’interfaccia facile. Si deve quindi distinguere fra database (gli archivi) e sistema di gestione del database o DBMS (Data Base Management System), a suo volta costituito da motore del database (tecniche e programmi per ricercare i dati), sistema di interrogazione e interfaccia utente. 
Per utilizzare un DBMS ci si avvale quindi di un linguaggio di interrogazione: ogni interrogazione è cioè costituita da comandi, frasi scritte secondo regole rigidamente codificate con le quali si richiede l’esecuzione di determinate elaborazioni. 
A questa interfaccia a comandi va spesso a sovrapporsi (talvolta sfruttando sistemi appositamente progettati per questo) un’interfaccia utente di tipo grafico (Graphical User Interface o GUI). 
Poiché non è conveniente sviluppare DBMS finalizzati alla risoluzione di un solo problema, sono disponibili pacchetti (gruppi di programmi) genericamente in grado di gestire database rispondenti a determinati requisiti, che per essere utilizzati in un caso specifico richiedono una fase di personalizzazione, cioè di adattamento al problema e ai dati effettivamente da gestire.

È dunque necessario progettare accuratamente il sistema dei dati, in modo relativamente indipendente dalle caratteristiche del prodotto che poi si impiegherà per gestirlo. Infatti queste caratteristiche potrebbero condizionare eccessivamente la fase di progettazione, da un lato limitando la flessibilità del sistema per limiti del software di riferimento e dall’altro introducendo elementi non standard e quindi di difficile manutenzione nel tempo.

Ci si deve, al contrario, rifare, in fase di progettazione, a modelli del tutto generali, che solo successivamente saranno realizzati (implementati) utilizzando un determinato software. In questo modo, inoltre, si potrà chiaramente distinguere fra limiti dovuti al modello generale utilizzato e limiti invece dovuti al software poi effettivamente impiegato, scelto magari per considerazioni di altra natura (disponibilità, costo, facilità d’uso). Si dovrà quindi progettare il sistema prima di tutto a livello concettuale/semantico, individuando i soggetti portatori di informazione, le loro caratteristiche e le mutue interrelazioni. Da questo si potrà poi derivare il modello logico, in cui verrà tracciato lo schema della struttura dati corrispondente a quella informativa reale, che sarà successivamente implementato usando il software prescelto. Raramente, o per meglio dire quasi mai, ci si dovrà occupare del modello fisico, cioè di come i dati sono memorizzati nel computer, lasciando tale compito al software, che assicurerà l’integrità delle informazioni archiviate.

Il modello che prenderemo in considerazione è di applicabilità generale nel caso che le fonti di informazione possano essere strutturate, cioè che sia possibile classificarle come appartenenti a determinate tipologie, ciascuna delle quali ha le stesse caratteristiche. Questo primo passaggio è solo apparentemente semplice: è infatti frequente il caso in cui il livello di generalizzazione che consente questa classificazione impoverisce eccessivamente l’informazione rispetto alle necessità della ricerca. Va comunque tenuto presente che la classificazione o meglio la strutturazione delle informazioni prende in considerazione solo le caratteristiche utili per le finalità del sistema di archiviazione.

In campo storico, questa selezione presenta non poche difficoltà ed è oggetto di un acceso dibattito sulla sua effettiva possibilità. Un modo ragionevole, a mio avviso, di risolvere la questione è considerare la creazione del database una sorta di “edizione strutturata” delle fonti. 
Porre in questi termini la questione riporta nel giusto ambito il problema se la tecnologia utilizzata è adeguata: lo è tutte le volte che una tale “edizione” ha un senso storiografico, per la natura delle fonti, le loro caratteristiche, la loro estensione. Questo approccio, inoltre, restituisce dignità ad un’attività altrimenti considerata secondaria nella ricerca storica e può suggerire ampliamenti ed estensioni che la valorizzino come prodotto autonomo della ricerca stessa. D’altronde il concetto di edizione implica quello di pubblicazione, e quindi si apre tutto un altro capitolo, che non affronteremo in questa sede, relativo alla pubblicazione dei database come esito della ricerca, potenziale strumento per altri ricercatori e comunque patrimonio scientifico universale.

Tornando al problema della progettazione, in sede preliminare si deve verificare se:
•	le fonti hanno una struttura coerente
•	gli elementi portatori di informazione sono coerenti, ben definiti e chiaramente individuabili
•	si può individuare una strategia efficiente nei riguardi di elementi anomali (unità di misura, valuta, cronologia, caratteri inusuali), incoerenti (variazioni nella grafia), indefiniti (di nuovo la cronologia o la designazione di persone) o errati. 

Si osservi che comunque è necessario risolvere i problemi che derivano dagli ultimi due punti, a prescindere dall’uso del computer per organizzare i dati. In sostanza, quindi, il punto decisivo è il primo, riguarda cioè la prevalenza della caratteristica “testuale” rispetto a quella “strutturata”: non soltanto le caratteristiche proprie delle fonti, ma anche, e soprattutto, in riferimento all’indagine che si deve condurre. Di nuovo, considerare il database un’edizione strutturata sposta la questione in campo storico e permette, di solito, una risposta ragionevole.
Alcune ricerche hanno affrontato il problema di individuare modelli teorici più confacenti alla ricerca storica rispetto a quelli strutturati: in tal senso si sono mosse le proposte di Thaller (si veda la bibliografia relativa, peraltro di non facile reperibilità, citata nel volume di Townsend, Chappel e Strujvé indicato in bibliografia) e, molto recentemente, di altri (si veda la sessione dedicata allo Historical Text Encoding nelle conferenze DRH e E-AHC tenute a Londra nel settembre 1999). Va detto, in ogni modo, che il modello strutturato fornisce risposte soddisfacenti a gran parte dei problemi.

Diverso e in un certo senso più semplice è il caso dei dati archeologici, in quanto questa disciplina ha da tempo stabilito al proprio interno strumenti descrittivi strutturati, di facile trasposizione in ambito informatico. In parte, comunque, si ripropone la stessa difficoltà quando si intende prendere in considerazione il cosiddetto “diario di scavo”, per il quale recentemente (n. 11/1999 di Archeologia e Calcolatori, di prossima pubblicazione) sono state proposte soluzioni alternative.
2.	
Modelli concettuali: il modello entità – relazioni.

Come si è detto, il modello concettuale è indipendente dalla particolare realizzazione (hardware e software) e fornisce un contesto per lo sviluppo della struttura del database (schema).

I paradigmi più comuni per la descrizione dei modelli concettuali sono 

•	il metodo entità – relazioni (entity – relationships o ERM, Entity–Relationship Modelling)
•	il metodo a oggetti.

In questa sede prenderemo in esame soltanto il metodo ERM che si presta perfettamente ai problemi in esame.
 
I concetti principali del metodo ERM sono i seguenti.

Entità (entity) – Ogni soggetto portatore di informazione.

Classe di entità (class) – Insieme di entità simili, ai fini del problema in studio.

Attributo (attribute) – Proprietà delle entità rilevanti ai fini del problema. 
Tutte le entità di una stessa classe possiedono gli stessi attributi, eventualmente con valore diverso. Due entità di una stessa classe sono distinguibili in quanto almeno uno dei loro attributi ha un valore diverso, quindi due entità della stessa classe i cui attributi hanno tutti lo stesso valore non sono distinguibili.

Relazione (relationship) – Connessione logica fra classi di entità, che determinano relazioni fra singoli soggetti (entità) delle classi stesse. 
Ad esempio la relazione “autore di” fra le classi “Persone” e “Libri” si esplica stabilendo che “Manzoni” è autore di “I promessi sposi”. Quindi una relazione divide le possibili coppie (abbinamenti) formate con i soggetti di una classe e quelli di un’altra in due insiemi: l’insieme delle coppie che si corrispondono nella relazione (nell’esempio precedente le coppie autore – opera) e le altre (abbinamenti casuali, come “Manzoni” – “La Divina Commedia”). Una relazione è direzionale, nel senso che ha rilevanza l’ordine in cui si enuncia la corrispondenza (“Manzoni è autore dei Promessi Sposi” è diverso da “I Promessi Sposi sono autori di Manzoni”). Ciò significa che ogni relazione definisce implicitamente anche la relazione inversa (“autore di” → “scritto da”).

Evento (event) – Modifica avvenuta nel tempo del valore di un attributo di un’entità o di una relazione (una coppia appartenente alla relazione non lo è più e/o una coppia non appartenente alla relazione ora vi appartiene).

Chiave (key) – attributo o insieme di attributi (chiave composta) che identifica, in modo univoco, un’entità all’interno della classe di appartenenza: soggetti diversi hanno chiavi diverse. 

Gerarchia (hierarchy) – tipo speciale di relazione che determina l’ereditarietà degli attributi; una delle due classi è, in effetti, una specializzazione dell’altra ed ha, perciò, ulteriori attributi rispetto alla prima. Ad esempio, si può definire una classe di “eventi storici” con attributi data e luogo e poi definire la classe delle “battaglie” come specializzazione degli “eventi storici”, dotata quindi degli stessi attributi, con in più altri (comandanti, eserciti in campo, ecc.) che la classe più generale non possiede. Ogni chiave per la classe più generale è anche una chiave, detta chiave derivata, per la classe derivata (borrowed key).

Le classi, gli attributi e le relazioni possono essere rappresentati in un diagramma che utilizza simboli convenzionali:

•	rettangoli per le classi
•	cerchi per gli attributi
•	rombi per le relazioni, rappresentate come una linea che congiunge le classi.

Relazione

Attributo

Classe

A

B

C

p

q

r

x

y

Il diagramma precedente illustra il caso di due entità A (con attributi p, q, r) e B (con attributi x, y) connesse dalla relazione C.

Una relazione fra due classi A e B può essere:

1 a 1 (uno-a-uno): in tal caso essa fa corrispondere 1 entità di A ad 1 entità di B. Possono esistere elementi di A oppure di B che non hanno corrispondenti nella relazione, ma non può esistere alcun entità, né di A né di B, che compaia due volte, abbinata con entità diverse.

1 a N (uno-a-molti): in tal caso ad un’entità di A possono corrispondere più entità di B. Non è, invece possibile che la stessa entità di B corrisponda a entità distinte di A.

N a M (molti-a-molti): in tal caso a entità distinte di A possono corrispondere entità distinte di B e viceversa.

La relazione N a 1 cioè molti-a-uno è l’inversa di una relazione uno-a-molti.

Questa tipologia prende il nome di molteplicità della relazione.

3.	
Un esempio di applicazione

Vediamo in un esempio l’applicazione del modello entità – relazioni.

Si intende creare un database contenente le delibere prese da un’assemblea elettiva (ad esempio, consiglio comunale). 
I dati che interessano sono i seguenti:

•	Titolo della delibera
•	Data di votazione della delibera
•	Oggetto secondo una descrizione standardizzata
•	Presidente della seduta
•	Proponente della delibera
•	Votanti (nomi)
•	Risultato della votazione.

Poiché lo scopo dell’indagine è analizzare il comportamento dei consiglieri rispetto alla propria affiliazione politica e rispetto alla propria collocazione sociale, per ciascun consigliere si archivieranno le relative informazioni, avendo predisposto una lista di casi possibili per ciascuna in modo da standardizzarne la descrizione. 
Si aggiungono quindi alla lista precedente:

•	Affiliazione
•	Professione

Per quanto riguarda l’oggetto delle delibere, un’indagine preliminare fa riscontrare la presenza di delibere con oggetti “multipli”, concernenti cioè argomenti diversi.
Per semplicità, si supporrà in un primo momento che la seduta sia presieduta sempre dalla stessa persona, salvo poi considerare il caso più generale.

Un primo esame del problema porta ad individuare quattro entità: la delibera, i consiglieri, la seduta e la votazione. Descriviamo le caratteristiche rilevanti di ciascuna.

Delibera:	ha un titolo e un oggetto; è proposta da un consigliere; è votata in una votazione.
Consigliere:	ha un’affiliazione politica e una professione; può essere proponente di una delibera; può essere presidente di una seduta; partecipa a una votazione
Votazione:	ha un risultato numerico; riguarda una delibera; sono presenti consiglieri.
Seduta:	ha una data; è presieduta da un consigliere.

Possiamo semplificare questo modello riscontrando che l’entità seduta non ha praticamente contenuti informativi, potendosi trasferire alla votazione le caratteristiche individuate per essa. In questo modo si generalizza addirittura il modello, potendosi considerare presidenti diversi nella stessa seduta e sedute che durano più giorni, quindi con date diverse, mentre l’attimo della votazione è certo, come pure chi riveste, in quel momento, il ruolo di presidente. 

Si ottiene allora il modello descritto nella tabella seguente.

Entità/attributi | Relazioni | Con l’Entità | Moltepl.

Delibera
	Titolo
	Oggetto

È  proposta da

Consigliere

N-M

| È votata in | Votazione | 1-1

Consigliere
	Nome
	Affiliazione
	Professione

Propone

Delibera

M-N

| Presiede | Votazione | 1-N
| Partecipa a | Votazione | M-N

Votazione
	Risultato
	Data

È presieduta da

Consigliere

N-1

| Vi partecipa | Consigliere | N-M
| Vota | Delibera | 1-1
	
Nella tabella è stata anche introdotta la molteplicità delle relazioni: esaminiamola in dettaglio.

Ogni delibera può essere proposta da più consiglieri; ogni consigliere può proporre più delibere: è una relazione molti-a-molti.
In ogni votazione si vota una sola delibera; ogni delibera è votata una sola volta: è una relazione uno-a-uno.
Ogni votazione è presieduta da un consigliere; ogni consigliere presiede più votazioni: è una relazione uno-a-molti (un consigliere-presidente, molte votazioni)
Ad ogni votazione partecipano più consiglieri; ogni consigliere partecipa a più votazioni: è una relazione molti-a-molti.

Si noti che le relazioni sono state inserite due volte, considerando ogni volta la relazione e la sua reciproca; naturalmente alla fine le si considererà una sola volta, trattandosi della stessa relazione.

Il diagramma risulta il seguente.

Delibera

Titolo

Oggetto (multiplo)

Consigliere

Affiliazione

Professione

Risultato

Votazione

Data

Propone

Partecipa

Presiede

Vota

N

M

1

1

1

N

M

N

Nome

Nessuno degli attributi “naturali” può rivestire il ruolo di chiave per la relativa classe. Infatti fra i consiglieri possono esserci degli omonimi e ovviamente affiliazione e professione non sono idonee, neppure combinate; né titolo né oggetto individuano univocamente la delibera; infine, in una stessa data possono esservi più sedute. 
Si ovvierà allora a questa mancanza introducendo attributi “artificiali” da usare come chiave, per esempio un numero progressivo per ciascuna classe o un numero progressivo generale per gli oggetti creati nel database. La scelta dipenderà dal sistema più semplice per l’utilizzo, di solito una numerazione progressiva all’interno di ciascuna classe.

4.	Modelli logici di dati: il modello relazionale

Il modello relazionale è il più diffuso modello logico di struttura dati.

In esso il database è rappresentato come un insieme di tabelle. I concetti principali sono i seguenti.

Relazione (relation): tabella bidimensionale, per evitare confusione chiamata anche semplicemente tabella (table).

Attributo (attribute):  colonna della tabella. Chiamato anche colonna (column) e campo (field).

Dominio di un attributo (domain): insieme dei valori ammissibili per quell’attributo.

Tupla (tuple): riga (row) della tabella, chiamata anche record 
•	Non sono permesse tuple doppie
•	Non è ipotizzata l’esistenza di un ordine particolare delle tuple.

Chiave (key): attributo/colonna della tabella o insieme di colonne il cui valore identifica in modo univoco la tupla. 
•	Esiste sempre una chiave
•	Possono esistere più chiavi, fra cui se ne sceglie una arbitrariamente (cioè con criteri estranei alla struttura dati).

E’ sempre possibile definire, dunque, una chiave: infatti, nell’ipotesi estrema, l’insieme di tutte le colonne è una chiave, in quanto non possono esistere due righe identiche. Di solito, comunque, la chiave sarà costituita da una sola colonna o comunque un numero ridotto di colonne. In una tabella si può spesso scegliere fra più chiavi possibili: la scelta è dettata, in tal caso, da considerazioni esterne alla progettazione (semplicità – compattezza – significatività rispetto al problema in studio), essendo da un punto di vista operativo del tutto arbitraria. >Le chiavi possibili, ma non utilizzate, sono chiamate chiavi candidate (candidate key).

Per quanto riguarda una tabella, è necessario distinguere tra schema e estensione. Lo schema è la descrizione della struttura, e ne definisce il numero e il nome degli attributi, i loro domini, le eventuali chiavi. L’estensione è invece il contenuto, cioè l’insieme delle tuple con i valori rispettivamente assegnati a ciascun attributo di esse.

Rispetto al modello concettuale sopra descritto, una tabella è una struttura in cui sono contenuti gli attributi di una particolare classe di entità (corrispondenti ciascuna a una tupla, riga della tabella) ovvero è contenuta una relazione.
Occorre distinguere fra relazione (relationship), nozione del modello concettuale sinonimo di corrispondenza fra classi di entità, e relazione (relation), nozione del modello logico dei dati sinonimo di tabella. Per questo, in italiano si usa il termine originale inglese o la si chiama tabella.

Per derivare il modello (logico) relazionale corrispondente a un dato modello (semantico) entity-relationship si possono seguire le seguenti regole:

•	Occorre una tabella distinta per ogni classe di entità
•	Per definire una tabella che rappresenta una classe di entità, si associa una colonna della tabella a ciascun attributo della classe.
•	Per rappresentare una relazione uno-a-uno fra due classi è sufficiente descrivere le corrispondenze fra le chiavi delle tabelle corrispondenti, introducendo come attributo in una qualsiasi delle due tabelle la chiave dell’altra. Ogni tupla di tale tabella sarà composta dal valore dei propri attributi e nella colonna aggiuntiva avrà il valore della tupla corrispondente nell’altra.
•	Per rappresentare una relazione uno-a-molti fra due classi è sufficiente descrivere le corrispondenze fra le chiavi delle tabelle corrispondenti, introducendo come attributo nella tabella del lato “molti” la chiave della tabella del lato “uno”. Ogni tupla di tale tabella sarà composta dal valore dei propri attributi e nella colonna aggiuntiva avrà il valore della chiave della (unica) tupla a cui essa corrisponde.
•	Per rappresentare una relazione molti-a-molti è necessaria un’apposita tabella, in cui sono presenti come attributi le chiavi delle due classi che si corrispondono nella relazione. Il contenuto della tabella, cioè le sue tuple, sono coppie di chiavi di elementi corrispondenti.

Quando in una tabella è presente un campo che corrisponde alla chiave di un’altra tabella, allo scopo di collegarne i contenuti informativi (come nel caso sopra descritto delle tabelle che rappresentano relazione molti-a-molti), tale campo prende il nome di chiave esterna (foreign key).

La descrizione del database viene di solito compiuta in termini astratti, senza far riferimento ad una sua particolare implementazione, cioè alla sua realizzazione concreta che impiega un DBMS (Data Base Management System). Spesso per brevità anche quest’ultimo viene chiamato impropriamente database, confondendo l’oggetto dell’elaborazione con il software di elaborazione. Essa deve contenere i seguenti elementi:

•	Nome delle tabelle che compongono il database
•	Nome degli attributi di ciascuna tabella
•	Dominio di ciascun attributo
•	Chiave prescelta per ciascuna tabella

Per l’implementazione, questa descrizione deve essere tradotta nel linguaggio di descrizione dati del DBMS prescelto oppure va immessa nel sistema per mezzo della GUI, se disponibile. (Vedremo un esempio del primo caso applicato al database delle delibere).
Ogni DBMS ha un proprio insieme nativo di tipi di dati, che è in grado di gestire, e per passare all’implementazione è necessario definire i domini in termine dei tipi di dati ammessi. Ad esempio, un attributo con dominio “data” può avere come tipo di data quello “data” solo se il DBMS lo consente; altrimenti ci si dovrà arrangiare con altri tipi, ad esempio un tipo “testo” in cui si registra la data come un testo nella forma in cui viene scritta. La scelta del tipo di dato è legata prima di tutto, naturalmente, al dominio dell’attributo, ma soprattutto alle operazioni che vi si devono compiere, anche solo concettualmente. Nel caso suddetto della data, la sua codifica come “testo” impedisce di compiere semplici operazioni come “un anno dopo”.
Per questo a volte la scelta del tipo di dato è apparentemente astrusa: nello stesso esempio, converrebbe codificare la data come numerico, rappresentandola come numero di giorni trascorsi da un inizio prefissato, il che consentirebbe di compiervi operazioni del tipo richiesto, a prezzo di una pressoché totale illeggibilità del dato. Si tratta quindi di un compromesso, che può venire aiutato da opportune funzioni di conversione di cui è dotato il DBMS.

5.	Operazioni sui dati e sulle tabelle

Le operazioni più comuni di manipolazione dei dati sono costituite dalle seguenti:

•	inserimento di dati (insert)
•	cancellazione di dati (delete)
•	modifica di dati (update) detta anche aggiornamento
•	ricerca di dati (retrieve)
•	visualizzazione di dati (report)

Altre operazioni riguardano la manutenzione del database, come il suo compattamento, che ottimizza i formati interni di archiviazione, il backup, la creazione di indici, cioè di file ausiliari per migliorare le prestazioni durante le operazioni di ricerca. Altre ancora riguardano la struttura dati, come la creazione di tabelle e la loro modifica o cancellazione.
Una ricerca di dati viene anche chiamata interrogazione (query) del database.
Le operazioni di inserimento, cancellazione, aggiornamento sono in genere standard. Possono utilizzare maschere (form) che facilitano il compito dell’operatore.
La complessità dei report riguarda le modalità di visualizzazione e quindi le caratteristiche “tipografiche” dell’output. Quasi tutti i DBMS dispongono di formati standard di output e della possibilità di modificarli o di definirne di propri. Un report opera su un insieme predefinito di dati, risultato di una query.
Maggiore attenzione va quindi dedicata alle ricerche, che per loro natura non seguono uno schema fisso e quindi necessitano di modalità operative più flessibili e per questo più complesse.
Una query conduce alla definizione di un sottinsieme delle tuple del database. Si può utilizzare una delle forme standard di visualizzazione per prendere conoscenza dei risultati della query, oppure la query può essere utilizzata per operazioni diverse, ad esempio il conteggio delle tuple rispondenti a determinate condizioni oppure la creazione di un database estratto da quello dato.

Una query si basa su operazioni sulle tabelle, in conseguenza delle quali si ottengono nuove tabelle da esse derivate. Le nuove tabelle così ottenute non sono permanenti, nel senso che non sono automaticamente archiviate nel database in modo permanente (a meno che non se ne faccia esplicita richiesta) in quanto sono destinate a un uso transitorio. In genere, quindi, una query successiva cancella il risultato della precedente, come un’operazione su una calcolatrice cancella i risultati delle operazioni precedenti.

Le operazioni più importanti sulle tabelle, utilizzate per le query, sono le seguenti.

•	Selezione: una selezione opera su una sola tabella e produce come risultato una sottotabella di questa, formata da un sottoinsieme delle sue tuple, che conservano inalterate i loro attributi. In genere, quindi il risultato di una selezione è costituito da una tabella con lo stesso numero di colonne e un numero minore (o tutt’al più uguale) di righe. La scelta delle tuple da inserire nel risultato è dettata da condizioni prescelte.

•	Proiezione: una proiezione opera su una sola tabella, producendo come risultato una sua sottotabella formata dalle stesse tuple ma con un sottinsieme degli attributi originari. In genere quindi la proiezione di una tabella ha lo stesso numero di righe ma un numero minore (o tutt’al più uguale) di colonne. Anche in questo caso la scelta delle colonne da inserire nel risultato è dettata da condizioni prescelte, di itpo Sì/No.

•	Join: opera su due tabella producendone una nuova le cui tuple risultano dalla combinazione di una tupla della prima e di una tupla dell’altra, secondo determinate regole stabilite dall’operazione in svolgimento. In questo caso perciò le colonne della nuova tabella saranno composte da quelle della prima e da quelle della seconda, mentre le righe saranno in numero variabile, in quanto gli abbinamenti dipenderanno dalle condizioni stabilite dal join: il caso estremo è costituito da un join senza condizioni in cui ogni tupla della prima tabella è abbinata a ogni tupla dell’altra. Più frequente è il join corrispondente a una relazione fra le due tabelle, in cui vengono abbinate le tuple che si corrispondono nella relazione. 

Ad esempio, in un database composto dalle due tabelle “autori” e “libri”, una selezione sugli “autori” è definita dalla condizione “nati nel XX secolo” e produce la tabella “autori nati nel XX secolo”, in cui ciascuna riga conterrà tutti gli attributi del relativo autore. Una proiezione sugli autori è definita dalla condizione “nome e cognome degli autori”, e produce una tabella con tutti gli autori ma contenente soltanto i loro nomi e cognomi. Un join fra le due tabelle è generato, ad esempio, dall’attribuzione ad ogni autore dei suoi libri: la tabella così prodotta ha tutti gli attributi dell’autore (nome, cognome, data di nascita, ecc.) e del libro (titolo, editore, ecc.), ma le sue tuple corrispondono soltanto ad abbinamenti reali, escludendo casi come “Alessandro Manzoni La Divina Commedia” perché esclusi dalla condizione prescelta.
In linea di principio, la condizione di query può essere del tutto arbitraria o assente. Ad esempio, la tupla “Alessandro Manzoni La Divina Commedia” apparentemente illogica potrebbe divenire logica se lo scopo della query fosse quello di determinare per ogni autore le opere a sua disposizione: in questo contesto la tupla suddetta non sarebbe illogica, mentre lo sarebbe “Alessandro Manzoni Ulisse”. Questo per sottolineare come la logicità o meno di un’operazione dipenda da considerazione estranee al modello e il funzionamento delle operazioni vada considerato o descritto soltanto in base alla coerenza interna di essa.

I modi di esprimere le operazioni e le query formano il linguaggio di interrogazione, che è, con alcune varianti, uno standard internazionale.

Le operazioni di selezione e di proiezione, entrambe di tipo sottrattivo, possono essere facilmente realizzate come filtri, la prima sulle righe e la seconda sulle colonne di una tabella. Esiste un modo grafico assai semplice di definire un filtro, che consiste nell’usare lo stesso schema descrittivo tabellare, per la proiezione marcando le colonne da conservare e per la selezione inserendovi la condizione di selezione eventualmente operante sull’attributo corrispondente. Le operazioni di join vengono invece rappresentate graficamente, collegando (come nello schema rappresentativo del modello entity-relationship) le tabelle coinvolte e sottintendendo che la condizione di join consiste nell’uguaglianza fra un determinato attributo dell’una e un determinato attributo dell’altra, attributi che possono essere specificati a parte.
Questo tipo di query è detto Query By Example (QBE).

L’altra modalità consiste nell’enunciare le operazioni da compiere in una istruzione, scritta in un linguaggio codificato detto SQL (Structured Query Language). Per risparmiare la fatica di apprendere lo SQL, molti DBMS possiedono dei generatori di query di maggiore o minore complessità e flessibilità.

A titolo puramente di esempio, supponiamo di voler elencare i libri del nostro database accompagnati dal relativo autore. Per semplicità supporremo che nella nostra biblioteca non vi siano omonimi, di modo che il campo cognome è una chiave per la tabella autori. Per ogni autore sono stati archiviati almeno i dati necessari per questa query cioè nome, cognome, data di nascita; per i libri i campi sono invece titolo, cognome dell’autore (chiave esterna) e quant’altro desiderato. Supponiamo inoltre di voler ottenere soltanto un elenco composto da titolo del libro, nome e cognome dell’autore. La query sarà così formulata:

SELECT titolo, nome, cognome
FROM autori, libri
WHERE cognome = autore

L’ultimo rigo specifica la condizione di join: si otterranno solo tuple in cui l’attributo autore della tabella libri sia uguale all’attributo cognome della tabella autori. Il secondo rigo specifica le tabelle utilizzate per il join. Il primo rigo specifica una proiezione: nel risultato non verranno mostrati tuttigli attributi ma solo quelli indicati.

Le parole SELECT, FROM, WHERE sono specifiche del linguaggio SQL e indicano le diverse parti dell’istruzione, che viene così ad essere formata da “clausole” distinte che noi per comodità abbiamo indicato rispetto alle posizioni.

Una selezione destinata a produrre un elenco degli autori del XX secolo è così definita

SELECT *
FROM autori
WHERE data-di-nascita successiva 1/1/1900

La condizione di selezione è descritta nell’ultimo rigo (clausola WHERE), il secondo (clausola FROM) elenca le tabelle utilizzate, una sola in questo esempio, il primo (clausola SELECT) dovrebbe descrivere le proiezioni richieste, in questo caso assenti e quindi rappresentate da un * che significa “tutti gli attributi”. 

Con una sola istruzione si possono compiere molte operazioni contemporaneamente:

SELECT titolo, nome, cognome
FROM autori, libri
WHERE cognome = autore AND data-di-nascita successiva 1/1/1900

che combina le due query precedenti, unificandone le condizioni (una di join e una di selezione) nella clausola WHERE, qui composta da due condizioni distinte, di cui è richiesto il verificarsi congiunto mediante il connettore logico AND.

Vediamo il modello logico dei dati nell’esempio delle delibere. Applicando le regole sopra descritte si ottengono le tabelle seguenti.

Tabella Delibere
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente) –  chiave
Titolo	Testo 
Oggetto	Testo (standardizzato) – Valori multipli

Tabella Consiglieri
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente)
Nome	Testo
Affiliazione	Testo (standardizzato)
Professione	Testo (standardizzato)

Tabella Votazioni
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente)
Data	Data
Risultato	Coppia di numeri (a favore/contrari)
Presidente	Numero (equivale alla relazione 1-N è presieduta da)
Delibera	Numero (equivale alla relazione 1-1 vota la delibera)

Tabella Proponenti
Attributo	Dominio
Delibera	Numero
Consigliere	Numero
La coppia (delibera x, consigliere y) è presente in questa tabella se la delibera x è stata proposta dal consigliere y.

Tabella Votanti
Attributo	Dominio
Consigliere	Numero
Votazione	Numero
La coppia (consigliere x, votazione y) è presente in questa tabella se il consigliere x ha votato nella votazione y.

6.	Forme normali. Normalizzazione

Le operazioni sulle tabelle, le query e, in generale, la corretta operatività di un DBMS è assicurata soltanto se si rispettano alcune regole di progettazione che conferiscono al database determinate proprietà di regolarità.

Una tabella è in prima forma normale (1NF) se

•	tutti i suoi campi sono atomici, cioè non ulteriormente decomponibili;
•	ogni campo contiene un solo dato

In altri termini, non sono ammessi né sottocampi né campi multipli.

La regolarità consiste nel fatto che vi è certezza sul contenuto di un campo: un solo dato.  Il trattamento di sue suddivisioni (sottocampi o componenti singole di un campo multiplo) non potrebbe essere definito all’interno dello schema progettuale a meno di non introdurre una sorta di indice di posizione, che non ha alcun collegamento con la natura del problema (spesso, infatti, i “sottocomponenti” sono in ordine casuale o imprecisato).

Il modello logico della tabella delle delibere sopra descritto ha la tabella Delibere che non è 1NF in quanto presenta campi multipli. Lo si può ricondurre a 1NF introducendo una tabella “Oggetti delle delibere” ed eliminando l’attributo oggetto dalla tabella delibera. Si dovrà poi istituire una relazione fra le delibere e gli oggetti. 

Si ottengono così le seguenti modifiche:

Tabella Delibere (modificata)
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente) – chiave
Titolo	Testo (di lunghezza variabile)

Tabella Oggetti (nuova)
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente) – chiave
Descrizione	Testo

Tabella Oggetti-Delibere (nuova)
Attributo	Dominio
Delibera	Numero
Oggetto	Numero
La coppia (delibera x, oggetto y) è presente in questa tabella se la delibera x ha oggetto y.

Le altre tabelle restano invariate.

Un database con tutte tabelle in prima forma normale, presenta, di solito, un elevato numero di ripetizioni. Ad esempio, tutti i valori degli attributi collegati o dipendenti da un altro sono ripetuti più volte senza aggiungere informazione. Supponiamo, ad esempio, di considerare nel nostro esempio bibliografico la tabella autori, nel caso in cui vi sia più di un autore, inserendo i dati di ciascuno. Se fra questi dati c’è anche l’anno di nascita, esso sarà ripetuto ogni volta che compare (in gruppi diversi) la stessa persona, essendo la data di nascita sempre la stessa, senza però aggiungere informazione. Un database in prima forma normale presenta quasi sempre questo tipo di ridondanze, dovuta alla dipendenza funzionale di un attributo da un altro, cioè al fatto che ad ogni valore del secondo (il nome di una persona) risulta univocamente assegnato un valore del primo (l’anno di nascita).

Ogni relazione uno-a-uno stabilisce una doppia dipendenza funzionale, nei due sensi; una relazione uno-a-molti stabilisce una dipendenza funzionale (il valore dal lato uno è funzionalmente dipendente da ciascuno dei corrispondenti dal lato molti); una relazione molti-a-molti non stabilisce dipendenze funzionali.

Si può decomporre una tabella senza perdita di informazione se l’operazione inversa, effettuata mediante un join, non produce tuple aggiuntive.
Nell’esempio precedente, la tabella contenente i nomi degli autori e le rispettive date di nascita può essere decomposta, senza perdita di informazione, in due tabelle una con i soli nomi degli autori e una con il nome di ciascuno e il relativo anno di nascita, che così compare una sola volta in corrispondenza dell’unica comparsa del nome. La tabella originaria può essere ricomposta mediante un join delle due nuove tabelle, combinando gli elementi che hanno lo stesso nome.

Rossi | 1970 | Verdi | 1975 | | Rossi | Verdi | | Rossi | 1970
Rossi | 1970 | Neri | 1960 | → | Rossi | Neri | + | Neri | 1960
Neri | 1960 | Verdi | 1975 | | Neri | Verdi | | Verdi | 1975
… | … | … | … | | | | | |

Una tabella è in seconda forma normale (2NF) se è in prima forma normale e tutti i suoi attributi dipendono dalla chiave, cioè se non possiede attributi funzionalmente dipendenti da una sua parte. Nell’esempio precedente, la chiave è costituita dai due nomi degli autori, e l’anno di nascita è funzionalmente dipendente da un solo nome, parte della chiave. 

Per ricondurre una tabella a essere 2NF si attua una decomposizione:  gli attributi che dipendono funzionalmente da una parte della chiave vengono messi in una tabella separata insieme a questa parte della chiave, come nell’esempio precedente, e sono rimossi dalla tabella originale, in cui invece rimane la parte della chiave che funge da chiave esterna per la nuova tabella creata. Nella tabella dell’esempio precedente, la chiave della tabella è formata dai due cognomi; l’anno, che è l’attributo funzionalmente dipendente da uno dei due cognomi, tolte dalla tabella ed è messo in un’altra tabella assieme al cognome (parte della chiave da cui esso dipende). Uno dei cognomi, rimasto nella tabella principale, è chiave esterna per la nuova tabella creata.
Applicando questo procedimento di decomposizione quante volte è necessario, nell’eventualità che vi siano più dipendenze funzionali, si perviene a una serie di tabelle tutte 2NF. 

Il vantaggio delle tabelle 2NF è che evitano ridondanza di informazione e incongruenze fra dati analoghi che vengono standardizzati (l’anno di nascita, ad esempio, è scritto sempre nello stesso modo e non 1990, ’90, 90). Questo secondo aspetto è particolarmente importante, tanto che proprio per questo scopo alcuni campi vengono codificati, viene cioè introdotta volontariamente una dipendenza funzionale fra i dati per standardizzarne la classificazione mediante un codice, la cui descrizione in chiaro è data da una tabella a parte.

La decomposizione così definita ha le caratteristiche di non perdere informazione e di conservare le dipendenze funzionali, trasformando in una relazione quelle parziali.

La tabella usata nell’esempio precedente si basa sull’ipotesi che essa sia stata definita in relazione a un problema per il quale la coppia (Rossi - Verdi) ha un significato diverso dalla coppia (Verdi – Rossi). In questo caso si tratta soltanto di un esempio illustrativo del metodo di decomposizione per ricondurre la tabella a 2NF, ma in un caso reale sarebbe sensato chiedersi se questa ipotesi è realistica: si possono facilmente immaginare situazioni in cui lo è e altre in cui non lo è affatto. Naturalmente, in un problema reale, il processo sarebbe partito dalla realtà per poi definire il modello, anziché inventare un problema per giustificare una tabella esemplificativa. Tutto ciò per sottolineare come determinate valutazioni, quale quella appena esposta, possano trovare risposta soltanto tornando al caso reale che il modello vuol rappresentare.

Nell’esempio delle delibere, tutte le tabelle sono 2NF e quindi non necessiterebbe di ulteriori manipolazioni. Può tuttavia essere consigliabile codificare gli elementi fissi per evitare errori di digitazione o registrazioni non standardizzate, modificando la tabella consiglieri e creando due nuove tabelle.

Tabella Consiglieri
Attributo	Dominio
Numero	Numero intero (assegnato automaticamente) – chiave 
Nome	Testo
Affiliazione	Numero (o sigla)
Professione	Numero (o sigla)

Tabella Affiliazioni
Attributo	Dominio
Codice	Numero (o sigla) ) – chiave
Descrizione	Testo

Tabella Professioni
Attributo	Dominio
Codice	Numero (o sigla) ) – chiave
Descrizione	Testo

In una tabella 2NF possono sussistere attributi dipendenti oltre che dalla chiave anche da altri attributi, a loro volta dipendenti dalla chiave: possono cioè esistere dipendenze transitive. Supponiamo, ad esempio, di aver archiviato nel nostro database autori il nome, la data (completa) di nascita e il segno zodiacale. Questa tabella è 2NF perché tutti gli attributi dipendono dalla chiave (il nome) ma il segno zodiacale è dipendente dall’attributo data di nascita e quindi transitivamente dipendente dalla chiave.

Una tabella si dice in terza forma normale (3NF) se non sono presenti dipendenze transitive del tipo sopra definito. Una tabella 2NF può essere riportata a 3NF ponendo gli attributi dipendenti funzionalmente da un altro attributo in una tabella separata: nell’esempio, ponendo in una tabella separata la data di nascita e il segno zodiacale.

La normalizzazione può essere ancora spinta ulteriormente, ma nei casi pratici è in genere sufficiente fermarsi alla 3NF o alla 2NF soltanto.

La trascrizione della descrizione del database nel linguaggio di descrizione dati tipico del DBMS utilizzato di questo si può, come già detto, quasi sempre evitare, ricorrendo a un’interfaccia utente per la creazione delle tabelle, nella quale si devono inserire le informazioni relative a ciascuna adattando i domini degli attributi ai tipi di dati previsti dal DBMS usato. 
Quando ciò non è possibile, occorre creare il comando o meglio la sequenza di comandi (detta script) necessari per tale operazione.

A titolo di curiosità si riporta lo script SQL da usare per creare le tabelle Delibere, Consiglieri e Votazioni usando il comando CREATE TABLE che ha appunto questa funzione. Come già detto, il linguaggio SQL è, con qualche variante “dialettale”, uno standard internazionale (ISO/IEC 9075:1992), chiamato SQL92 ed è disponibile per quasi tutti i DBMS relazionali (RDBMS, Relational DBMS).

CREATE TABLE delibere (
	numero	int4,
	titolo		text);

CREATE TABLE consiglieri (
	numero	int4,
	nome		text,
affiliazione	int4,
professione	int4);

CREATE TABLE votazioni (
	numero	int4,
	data		date,
favorevoli	int4,
contrari	int4,
presidente	int4,
delibera	int4);

CREATE TABLE oggetti (
	numero	int4,
	descrizione	text);

CREATE TABLE oggetti_delibere (
	oggetto	int4,
	delibera	int4);

CREATE TABLE affiliazioni (
	codice		int4,
	descrizione	text);

CREATE TABLE professione (
	codice		int4,
	descrizione	text);

CREATE TABLE proponenti (
	delibera	int4,
	consigliere	int4);

CREATE TABLE votanti (
	consigliere	int4,
	votazione	int4);

Il codice int4 designa un numero intero, usato per i codici e per i progressivi di sistema. Si noti che non essendo disponibile un tipo dati “coppia di numeri” è indispensabile spezzare l’attributo “risultato” della votazione in “favorevoli” e “contrari”.  Nella fase di creazione si dovrebbe inoltre specificare i campi usati come chiave, utilizzando apposite qualificazioni del linguaggio SQL.

Bibliografia

Si elencano di seguito alcuni manuali o raccolte di saggi sull’argomento specificamente orientati alle problematiche storiche e archeologiche, segnalando che quelli in lingua inglese sono in generale più approfonditi e dettagliati e sono quindi da preferire. Su quelli italiani può essere interessante la problematica metodologica o, come nel caso del volume di D’Andria, la trattazione del caso studiato. 

•	Moscati, P. Archeologia e Calcolatori  Giunti, Firenze 1987
•	Mawdsley, E. – Munck, T. Computing for historians. An introductory guide Manchester University Press, Manchester 1993. ISBN 0-7190-3548-1
•	Greenstein D. I. A Historian’s Guide to Computing Oxford University Press, Oxford 1994. ISBN 0-19-823521-6
•	Soldani S. – Tomassini L. (a cura di) Storia e Computer. Alla ricerca del passato con l’informatica  Bruno Mondadori, Milano 1996. ISBN 88-424-9317-1
•	Harvey C. – Press J. Databases in Historical Research Macmillan Press Ltd., Houndmills, Basingstoke and London 1996. ISBN 0-333-56844-3
•	Niccolucci, F. Dal database all’ipertesto. Applicazioni dell’informatica ai dati storici e territoriali  Centro 2P, Firenze 1997
•	D’Andria, F. (a cura di) Metodologie di catalogazione dei beni archeologici Martano - Edipuglia, Lecce - Bari 1997
•	Townsend, S. –  Chappel, C. – Strujvé, O. Digitising History. A Guide to Creating Digital Resources from Historical Documents (AHDS, History Data Services). Oxbow Books, Oxford 1999. ISBN 1-900188-91-0