Basi di dati
Basi di dati
di Paolo Atzeni
Basi di dati
sommario: 1. Introduzione. 2. I sistemi di gestione di basi di dati (DBMS). 3. Il modello relazionale dei dati. 4. Linguaggi per basi di dati. 5. Progettazione delle basi di dati. 6. Sviluppi recenti. 7. Il futuro. □ Bibliografia.
1. Introduzione
Come molti altri termini nel settore dell'informatica, database, o 'base di dati', può essere usato in due diverse accezioni, l'una sostanzialmente astratta e indipendente dagli aspetti realizzativi, l'altra legata agli strumenti tecnologici. Da una parte, si può dire che una base di dati è un insieme articolato e organizzato di dati di interesse in un certo contesto (ad esempio, un'azienda o un ente pubblico) che può essere gestito secondo qualunque modalità, non necessariamente automatizzata; in questo senso, l'insieme dei dati gestiti da un'anagrafe o da una banca costituiva una base di dati già cento o duecento anni fa, ben prima che i moderni calcolatori elettronici fossero inventati. Questa accezione sottolinea l'importanza dei dati come risorsa per il soggetto che ne dispone e la conseguente esigenza di una gestione attenta e sistematica. D'altra parte, però, proprio la necessità di un trattamento adeguato dei dati ha portato allo sviluppo di sistemi software per la loro gestione, chiamati DBMS (Data Base Management Systems), particolarmente sofisticati e in grado di svolgere un insieme articolato di funzioni in modo efficiente ed efficace. Secondo un'accezione più ristretta, ma forse più precisa, una base di dati è un insieme di dati gestito per mezzo di un DBMS.
2. I sistemi di gestione di basi di dati (DBMS)
Numerose sono le caratteristiche interessanti dei DBMS (e di conseguenza delle basi di dati da essi gestite). In primo luogo, un DBMS è in grado di mantenere basi di dati in modo permanente, e quindi in memoria secondaria; infatti, nella maggior parte dei casi la memoria principale è volatile, cioè perde il proprio contenuto in caso di spegnimento del sistema e quindi non è in grado di conservare i dati a lungo termine, come è invece necessario nel caso delle basi di dati, che costituiscono una risorsa spesso pregiata. Le basi di dati, poi, possono avere dimensioni anche imponenti ed essere utilizzate in modo intensivo: quelle più grandi sono ormai in grado di gestire centinaia di miliardi di elementi (un elemento potrebbe essere una scrittura contabile o un dettaglio di una prenotazione aerea) e di eseguire su di essi milioni di operazioni al minuto (ad esempio, registrazioni di scritture contabili o modifiche di prenotazioni); sostanzialmente, l'unico limite imposto è quello dello spazio complessivo di memoria secondaria disponibile.
Un'altra caratteristica fondamentale, usata spesso per distinguere il concetto di base di dati da quello di archivio, risiede nel fatto che una base di dati è di solito una risorsa condivisa fra più utenti. Ad esempio, in un'azienda i dati sui dipendenti potrebbero essere gestiti sia dall'ufficio del personale, responsabile delle assunzioni e delle progressioni di carriera, sia dall'ufficio stipendi, responsabile del calcolo delle retribuzioni sulla base dei contratti di lavoro e delle normative fiscali. I due insiemi di dati sono diversi, ma parzialmente sovrapposti: i dati sulle qualifiche dei dipendenti sono determinati e modificati quando necessario dall'ufficio del personale e sono utilizzati dall'ufficio stipendi. In questo contesto, una base di dati può contenere tutte le informazioni di interesse, permettendo a ciascun ufficio di leggere e modificare solo i dati di propria competenza, ma non gli altri. In tal modo si cerca di eliminare le ripetizioni dei dati (la cosiddetta 'ridondanza') e il conseguente rischio di incoerenza. Per una gestione appropriata della condivisione, i DBMS prevedono meccanismi di autorizzazione attraverso i quali si può garantire o limitare ai vari utenti l'accesso ai dati secondo le effettive necessità.
Un'importante proprietà dei DBMS, motivata dal valore delle basi di dati come risorse per le organizzazioni che le posseggono, è la 'affidabilità', ossia la capacità del sistema di garantire la correttezza del contenuto della base di dati anche in presenza di malfunzionamenti del sistema stesso o dell'ambiente di elaborazione o comunicazione in cui esso opera. Fondamentale in questo senso è il concetto di 'transazione', vale a dire una sequenza di operazioni da considerare come 'atomica', cioè da eseguire esclusivamente per intero. Tipico esempio di transazione è il trasferimento di fondi da un conto corrente bancario a un altro: esso è costituito da due operazioni - il prelevamento da un conto e il versamento su un altro - che però non possono essere separate, in quanto vanno eseguite entrambe e non l'una senza l'altra. Qualora si verifichi un guasto che renda impossibile l'esecuzione della seconda operazione, la prima dovrà essere annullata. Altre importanti proprietà delle transazioni sono la 'durabilità', la quale assicura che gli effetti di una transazione completata non vadano perduti, e l''isolamento', che prevede che, anche qualora le transazioni vengano eseguite in modo concorrente (cioè con la possibilità, in ogni momento, di avere più transazioni attive), il risultato di ciascuna non sia indebitamente influenzato dalle altre. Un esempio di comportamento indesiderabile in presenza di concorrenza è il seguente: due transazioni, la prima di mille euro e la seconda di duemila, hanno l'obiettivo di effettuare versamenti su un conto corrente il cui saldo precedente è pari a diecimila euro; entrambe le transazioni leggono contemporaneamente il saldo e ciascuna scrive il nuovo saldo quale somma di quello letto e dell'importo versato: la prima transazione scriverà quindi un valore di undicimila euro e la seconda di dodicimila, con un risultato scorretto, perché il saldo finale avrebbe dovuto essere pari a tredicimila euro. I sistemi di basi di dati impediscono errori di questo genere garantendo la cosiddetta 'serializzabilità', la quale fa sì che, in caso di esecuzione concorrente di transazioni, il risultato finale sia equivalente a quello che si sarebbe avuto se le transazioni fossero state eseguite serialmente, ossia prima per intero una e poi per intero l'altra.
Obiettivo fondamentale dei DBMS è il supporto alla gestione efficace delle basi di dati, intesa come capacità di rendere produttive le attività di coloro che le utilizzano, siano essi programmatori che realizzano i software per l'accesso alla base di dati oppure veri e propri utenti che si servono di tali programmi per svolgere il proprio lavoro (ad esempio, gli impiegati presso gli sportelli delle banche). A tal fine i DBMS vengono dotati di una serie di caratteristiche, le più importanti delle quali saranno illustrate nei prossimi due capitoli: da una parte i DBMS offrono (a utenti e programmatori) una visione naturale dei dati, che nasconde e semplifica molti dettagli tecnici, e dall'altra permettono l'accesso alle basi di dati (sia in sola lettura che con possibilità di modifica) attraverso una pluralità di linguaggi e interfacce estremamente potenti.
3. Il modello relazionale dei dati
I DBMS mantengono i dati su dispositivi di memoria secondaria - solitamente dischi - secondo modalità di organizzazione utilizzate anche in altri contesti (strutture disordinate oppure ordinate, indici primari e secondari), ma mettono a disposizione degli utenti modalità più semplici ed efficaci per la gestione e l'accesso. In particolare, i DBMS mostrano all'utente e al programmatore i dati come se questi fossero organizzati in forme più semplici e astratte. Viene chiamata organizzazione 'fisica' dei dati quella che fa riferimento alla effettiva struttura dei file, mentre gli utenti vedono la cosiddetta organizzazione 'logica'. Fondamentale, in questo contesto, è il concetto di 'modello' dei dati, ossia l'insieme dei costrutti per mezzo dei quali essi sono organizzati: il modello 'logico' è quello visibile a utenti e programmatori, mentre quello 'fisico', di competenza del progettista, può essere in molti casi ignorato. Nell'evoluzione dei sistemi di basi di dati, dalla metà degli anni sessanta a oggi, sono stati proposti diversi modelli dei dati, ma attualmente quello di gran lunga più interessante e diffuso è il modello 'relazionale', elaborato da Edgar F. Codd nel 1970, utilizzato per la prima volta in un DBMS commerciale nel 1981 e affermatosi definitivamente negli ultimi quindici anni.
Il modello relazionale è basato sul concetto matematico di relazione, inteso, come nella teoria degli insiemi, quale sottoinsieme del prodotto cartesiano di N insiemi (chiamati dominî della relazione), con una piccola variante rispetto alla definizione classica: i dominî (e di conseguenza i componenti di una ennupla della relazione) non sono identificati attraverso la posizione (il primo, il secondo, e così via), ma per mezzo di nomi, cioè gli attributi della relazione. Le relazioni possono essere rappresentate in modo naturale per mezzo di tabelle (e per questo spesso nella letteratura tecnica i due termini, relazione e tabella, sono considerati intercambiabili). Ad esempio, la fig. 1 mostra la rappresentazione per mezzo di tabelle di una piccolissima base di dati, contenente alcune informazioni relative agli impiegati di un'azienda e ai progetti cui essi partecipano.
Il modello relazionale, a differenza di quelli preesistenti (noti come modelli gerarchico e reticolare), è basato su valori: ciò significa che tutta l'informazione, inclusa quella necessaria per correlare informazioni contenute in insiemi diversi, è rappresentata per mezzo di valori visibili agli utenti. Nell'esempio, il fatto che l'impiegato Neri lavori al progetto Ulisse è rappresentato attraverso la presenza del codice ('A') del progetto Ulisse nella ennupla della relazione 'impiegati' concernente Neri. I riferimenti fra una relazione e l'altra sono di solito realizzati attraverso valori di attributi, detti 'chiave', che rivestono un ruolo fondamentale nel modello: una chiave è un insieme di attributi i cui valori identificano univocamente le ennuple della relazione (per i quali quindi non possono esistere due ennuple con lo stesso valore); nell'esempio, 'matricola' è chiave per la relazione 'impiegati' e 'codice' lo è per la relazione 'progetti'.
Il modello relazionale è un modello logico perché mostra all'utente un'organizzazione dei dati semplificata rispetto a quella fisica; in effetti, una relazione può essere realizzata in modi diversi, cioè scegliendo una struttura fisica tra diverse possibili, e l'utente può ignorare tale struttura facendo riferimento, come vedremo nel prossimo capitolo, solo alle relazioni.
In una base di dati è importante distinguere lo 'schema', cioè la struttura della base di dati, che è sostanzialmente invariante nel tempo e descrive quali sono le informazioni di interesse, dalla 'istanza' (termine derivato dall'inglese instance, 'esemplare', ormai entrato nell'uso comune), cioè il contenuto attuale della base di dati, che varia nel tempo, anche rapidamente. In una base di dati relazionale, lo schema è fondamentalmente costituito dall'intestazione delle tabelle, mentre l'istanza è il corpo delle stesse.
Il successo del modello relazionale è dovuto certamente alla sua semplicità, in quanto esso coniuga il solido fondamento matematico nella teoria degli insiemi (che ha permesso un fiorire di studi teorici) con l'efficace rappresentazione in forma tabellare (che lo ha fatto accettare agli utenti).
4. Linguaggi per basi di dati
L'accesso alle basi di dati viene specificato attraverso opportuni linguaggi e interfacce che permettono di descrivere in modo sintetico attività anche complesse. Le operazioni su una base di dati e le istruzioni per richiederle si possono suddividere in due categorie: 1) operazioni di definizione della struttura della base di dati (cioè operazioni sullo schema); 2) operazioni di interrogazione e aggiornamento del contenuto della base di dati (cioè operazioni sull'istanza). Attualmente esistono linguaggi (in particolare il linguaggio SQL, Structured Query Language) che prevedono entrambi i tipi di istruzioni, ma in passato si usavano linguaggi distinti per le operazioni sullo schema (il DDL, Data Definition Language) e per quelle sull'istanza (il DML, Data Manipulation Language).
Concentriamo la nostra attenzione sulle operazioni DML, in particolare su quelle per l'interrogazione, che permettono di evidenziare le caratteristiche già discusse del modello relazionale. Il linguaggio SQL, il più diffuso allo scopo, permette di scrivere istruzioni molto compatte e potenti. Per esempio, per estrarre dalla base di dati di fig. 1 matricola, cognome e titolo del progetto relativi agli impiegati che lavorano in un progetto svolto a Roma, possiamo in SQL scrivere:
select matricola, cognome, titolo
from impiegati, progetti
where progetto = codice
and sede = 'Roma'.
Intuitivamente, l'istruzione considera inizialmente le relazioni citate dopo la parola chiave from combinando fra loro tutte le ennuple, poi applica a queste combinazioni le condizioni specificate dopo la parola chiave where, selezionando quindi solo quelle che corrispondono a impiegati e progetti correlati attraverso lo stesso valore del codice (condizione progetto = codice) e che hanno Roma come sede del progetto; infine, l'istruzione restringe l'attenzione ai soli attributi indicati dopo la parola chiave select. Con riferimento alla base di dati in fig. 1, l'operazione produce il risultato in fig. 2.
L'esempio evidenzia il modo in cui SQL trae e sfrutta i riferimenti fra relazioni realizzati per mezzo di valori: le ennuple del risultato sono costruite concatenando le ennuple delle due relazioni di dati che fanno riferimento a uno stesso progetto. Secondo un approccio tradizionale, meno potente, avremmo dovuto esaminare una a una le ennuple della relazione 'impiegati', andando a verificare l'eventuale presenza di una ennupla con lo stesso codice di progetto nella relazione 'progetti' e selezionare solo quelle per le quali il progetto ha sede in Roma.
L'esempio permette anche di chiarire il concetto di indipendenza dei dati menzionato in precedenza. In un DBMS relazionale, i dati vengono mostrati all'utente e al programmatore sotto forma di relazioni o tabelle, proprio come in fig. 1, e a essi si accede con espressioni SQL come quella appena mostrata. Le relazioni, però, sono memorizzate dal DBMS secondo opportune strutture fisiche (ad esempio, ognuna in un file separato, oppure tutte in un unico file; e questo o questi file possono avere organizzazione ordinata o disordinata, possono essere supportati dalla presenza di indici, e così via) nascoste all'utente, che vede solo la struttura logica. In molti sistemi la struttura fisica può venire modificata, ma questo non influenza in alcun modo gli utenti (che continuano a vedere le relazioni) e i programmatori (che scrivono le istruzioni SQL facendo riferimento solo alle relazioni e non alle strutture fisiche), proprio perché tale struttura è nascosta. È evidente quindi come il concetto di indipendenza (che separa la struttura logica da quella fisica) faciliti l'utilizzo delle basi di dati e contribuisca all'efficacia dei DBMS.
5. Progettazione delle basi di dati
L'organizzazione dei dati in relazioni prevista dal modello relazionale favorisce senz'altro l'uso delle basi di dati, ma non è particolarmente conveniente in sede di progettazione, ossia quando, per riuscire a individuare la struttura più appropriata, debbono essere scelte le relazioni che compongono le basi di dati stesse, ciascuna con i relativi attributi. In molti casi, infatti, una base di dati può includere numerose relazioni, centinaia se non addirittura migliaia, ed è necessario procedere sistematicamente al fine di non disperdere gli sforzi e ottenere risultati di buona qualità.
Per questo motivo, il processo di progettazione di basi di dati viene di solito articolato in fasi, che richiamano quelle utilizzate nelle attività di sviluppo del software (v.informazione, scienza della: Software): analisi dei requisiti, progettazione concettuale, progettazione logica e progettazione fisica.
L'analisi dei requisiti non presenta particolari differenze rispetto a quanto accade in altri contesti, poiché è volta ad acquisire le informazioni sulle caratteristiche del sistema informativo da sviluppare e, soprattutto, sui dati di interesse. Le difficoltà fondamentali risiedono nella necessità di scoprire le effettive esigenze dei committenti e degli utenti e nel fatto che la comprensione dei dettagli del dominio applicativo non sempre è facile per l'analista, che di solito non ha familiarità con esso.
La progettazione concettuale è la più interessante e delicata (v. Batini e altri, 1992); essa parte dai requisiti ottenuti nella fase precedente e produce come risultato uno schema che descrive il contenuto della base di dati da realizzare, che è da una parte accurato e dall'altra indipendente dagli aspetti realizzativi. In questa fase per rappresentare le proprietà dei dati si usano i modelli 'concettuali' (così chiamati per il fatto che centrano l'attenzione sui concetti di interesse del mondo reale anziché sui dettagli realizzativi propri delle basi di dati), il più interessante e diffuso dei quali è il modello Entity-Relationship, abbreviato con E-R e citato di solito con il nome inglese per evitare confusione nella traduzione di relationship e relation (v. Chen, 1976). Esso si basa sui due costrutti fondamentali di entity, o 'entità' - utilizzato per rappresentare classi, persone, oggetti o concetti del mondo reale di interesse per la base di dati -, e di relationship - utilizzato per evidenziare legami logici fra entità. Terzo elemento importante del modello è l''attributo', che rappresenta proprietà rilevanti di entità o di relationship cui possa essere associato un valore. Interessante caratteristica del modello E-R è l'esistenza di una rappresentazione grafica per gli schemi, utile sia durante la fase di definizione degli stessi, sia come strumento di comunicazione fra progettisti e utenti. In fig. 3 è mostrato un semplice schema E-R che descrive la realtà di interesse cui si riferisce la base di dati di fig. 1. Le entità sono graficamente rappresentate per mezzo di simboli rettangolari e le relationships con blocchi a losanga. Abbiamo due entità, 'impiegato' e 'progetto', la relationship 'partecipazione' e tre attributi per ciascuna entità. Si può notare come, mentre nel modello relazionale la corrispondenza fra impiegati e progetti è realizzata attraverso l'attributo 'progetto' nella relazione 'impiegati', qui abbiamo la relationship che evidenzia esplicitamente il legame. Le annotazioni '(1, 1)' e '(0, N)' ai due estremi della relationship stanno a indicare le diverse cardinalità con cui le entità partecipano alla relationship stessa: per ogni impiegato abbiamo una e una sola partecipazione a progetti, mentre per ogni progetto possiamo averne zero, una o più. Lo schema concettuale per una base di dati reale può essere molto complesso, con centinaia di entità e di relationships, e quindi il processo di progettazione può essere lungo e laborioso, con molte interazioni con utenti e committenti e numerose verifiche e modifiche.
La fase di progettazione logica parte dallo schema concettuale, prodotto nella fase precedente, e lo 'traduce' in uno schema logico (relazionale se, come di solito accade, si utilizza un DBMS relazionale). La traduzione non è sempre immediata, perché alcuni costrutti del modello E-R (in particolare alcuni, pur importanti, che per semplicità abbiamo tralasciato) non hanno una traduzione diretta nel modello relazionale e anche perché, in questa fase, è necessario tener conto di aspetti quantitativi, ai fini di una realizzazione della base di dati che permetta di operare in modo efficiente su di essa. Pertanto, la progettazione logica viene di solito svolta in due fasi: nella prima si 'ristruttura' lo schema E-R trasformandolo in uno schema che non può più essere detto concettuale, perché non ha il solo obiettivo di rappresentare i concetti di interesse, ma tiene anche conto di problematiche realizzative; nella seconda fase si traduce questo schema ristrutturato in uno schema logico-relazionale.
La fase finale del processo di progettazione di una base di dati è la progettazione fisica, nel corso della quale si definiscono, per ciascuna delle relazioni di cui la base di dati relazionale è composta, le opportune strutture fisiche: ad esempio, si decide quanti e di che tipo debbano essere i file utilizzati e si individuano gli indici opportuni per favorire un accesso e una gestione efficienti.
6. Sviluppi recenti
Negli ultimi dieci anni la tecnologia delle basi di dati si è sviluppata in varie direzioni. In primo luogo, si è continuato ad avanzare lungo le linee sopra discusse, in particolare con l'introduzione di funzionalità sempre più ricche e flessibili, al fine di favorire l'efficacia (si possono segnalare la effettiva realizzazione delle 'regole attive' - v. Widom e Ceri, 1996 - e la possibilità di definire 'dominî e tipi complessi' - v. Stonebraker e Moore, 1996), e con il perfezionamento delle tecniche per la gestione efficiente e affidabile delle transazioni, nonché di quelle che permettono la valorizzazione delle architetture parallele.
In secondo luogo, sono state sviluppate e approfondite in varie direzioni le tecniche per la gestione di basi di dati distribuite su vari elaboratori (connessi in rete locale o anche geografica; v. Özsu e Valduriez, 19992) e, soprattutto, per il supporto alla interoperabilità di basi di dati (intesa come possibilità di interscambio di dati fra basi di dati diverse): un concetto che si va diffondendo sia nella ricerca sia nelle applicazioni è quello di 'base di dati federata', intesa come base di dati 'virtuale' ottenuta con dati effettivamente gestiti in basi di dati diverse, ma condivisi in modo efficace. Le tecniche per la gestione di basi di dati federate debbono tenere conto delle eterogeneità di sistemi e applicazioni, consentendo uno scambio dei dati che superi le differenze di rappresentazione dei vari sistemi e permetta una opportuna integrazione, conversione e riconciliazione dei dati fra un'applicazione e l'altra.
Un'altra area oggetto di notevole interesse negli ultimi anni è quella dei cosiddetti data warehouse (v. Inmon, 19962). Si tratta di grandi raccolte di dati utilizzate soprattutto a fini decisionali e statistici, quindi con grandi volumi di dati anche storici, che non richiedono un aggiornamento immediato, ma implicano l'esecuzione di operazioni complesse. Le applicazioni in questo contesto presentano notevoli differenze rispetto alle tradizionali basi di dati operative, sia per le caratteristiche dei dati, sia per le operazioni prioritarie, e quindi si preferisce di solito avere basi di dati separate da quelle usate per la gestione delle attività operative, seppure alimentate da esse.
La più recente, e forse più importante, linea di sviluppo delle basi di dati è legata al ruolo che esse possono svolgere in ambiente Internet e soprattutto nel contesto del World Wide Web (v. Atzeni e altri, 2002). Spesso è infatti possibile progettare e realizzare siti Web che abbiano molte pagine con la stessa struttura ma contenuto diverso, esattamente come nelle basi di dati si ha uno schema stabile e un contenuto variabile e assai ricco. È di conseguenza possibile definire una sorta di schema di un sito Web, composto di schemi di pagine, che descriva sinteticamente il contenuto del sito stesso. Il contenuto delle varie pagine di uno schema può poi essere facilmente costruito per mezzo di interrogazioni su una base di dati che abbia una struttura corrispondente (non necessariamente uguale) a quella del sito. In questo modo è possibile ricondurre il problema dell'aggiornamento dei contenuti di un sito Web a quello dell'aggiornamento di una base di dati e semplificare anche la manutenzione della struttura del sito stesso.
7. Il futuro
La grande sfida per la tecnologia delle basi di dati nel prossimo futuro è stata indicata da un gruppo di autorevoli studiosi (v. Bernstein e altri, 1998) e consiste nella gestione (acquisizione, memorizzazione, accesso, rielaborazione), per mezzo di basi di dati, della maggior parte delle informazioni di interesse in ogni contesto. Si può infatti supporre che, attraverso la continua crescita del World Wide Web, la quantità di informazione contenuta in rete possa aumentare enormemente; a quel punto, i dati disponibili saranno sempre più eterogenei, da vari punti di vista, e sarà sempre più difficile integrarli e correlarli: dovranno pertanto essere individuate tecniche efficienti (per gestire ingenti quantità di dati) ma anche efficaci (per aiutare progettisti e utenti nella comprensione e nell'integrazione).
bibliografia
Atzeni, P., Ceri, S., Paraboschi, S., Torlone, R., Basi di dati: concetti, linguaggi e architetture, Milano: McGraw-Hill libri Italia, 19992.
Atzeni, P., Mecca, G., Merialdo, P., Managing web-based data: database models and transformations, in "IEEE internet computing", 2002, VI, 4, pp. 33-37.
Batini, C., Ceri, S., Navathe, S. B., Conceptual database design: an entity-relationship approach, Redwood City, Cal.: Benjamin Cummings, 1992.
Bernstein, P. e altri, The Asilomar report on database research, in "SIGMOD record", 1998, XXVII, 4, pp. 74-80.
Chen, P. P., The entity-relationship model. Toward a unified view of data, in "ACM transactions on database systems", 1976, I, 1, pp. 9-36.
Codd, E. F., A relational model of data for large shared data banks, in "Communications of the Association for Computing Machinery", 1970, XIII, 6, pp. 377-387.
Gray, J., Reuter, A., Transaction processing: concepts and techniques, San Mateo, Cal.: M. Kaufmann, 1993.
Inmon, W. H., Building the data warehouse, Chichester: Wiley, 19962.
Özsu, M. T., Valduriez, P., Principles of distributed database systems, Upper Saddle River, N. J.: Prentice-Hall, 19992.
Stonebraker, M., Moore, D., Object-relational DBMSs: the next great wave, San Francisco: M. Kaufmann, 1996.
Weikum, G., Vossen, G., Transactional information systems, San Francisco: M. Kaufmann, 2002.
Widom, J., Ceri, S., Active database systems: triggers and rules for advanced database processing, San Francisco: M. Kaufmann, 1996.