Object Oriented Database Systems
|
|
Dr. Carlo Pescio Object Oriented Database Systems |
L'introduzione di un nuovo modello di riferimento è spesso
associata ad un periodo di confusione, nel quale non è
chiaro quali requisiti un prodotto debba soddisfare per dichiararsi
aderente al modello.
Il mondo delle basi dati non fa eccezione, e negli anni passati
abbiamo visto molti database venduti come "relazionali"
senza esserlo, e negli anni a venire vedremo molti sistemi venduti
come "object oriented" pur non avendone le caratteristiche.
La teoria dei database relazionali è stata introdotta dal
matematico Codd nel 1970 [1], ma solo quindici anni dopo è
stato pubblicato un "manifesto" dei database relazionali,
in cui venivano definite senza ambiguità le caratteristiche
che un DBMS deve soddisfare per poter essere chiamato relazionale
[2]; negli anni seguenti, ogni nuovo pacchetto che aspirasse a
definirsi "database relazionale" ha dovuto quindi misurarsi
con le "Codd's rules", spesso con risultati poco dignitosi
[3].
Un simile problema esiste anche per i database object oriented:
proprio per evitare il proliferare di prodotti che sostenessero,
senza disporre di una pietra di paragone, di essere "database
object oriented", nel 1989 si è riunito un comitato
di esperti per definire con precisione i requisiti di un DBMS
che aspiri al titolo di OODBS. Tali requisiti vengono suddivisi
in obbligatori, opzionali, ed aperti (ovvero suscettibili di scelta
da parte del produttore); una descrizione approfondita dei singoli
punti si può trovare in [4], ma sono qui brevemente riassunte
le caratteristiche fondamentali di un database object oriented:
Requisiti obbligatori (Golden Rules)
Oggetti Complessi
Deve essere possibile costruire oggetti complessi aggregando oggetti
più semplici; diversi metodi di aggregazione (tuple, array,
set, eccetera) devono essere previsti. I metodi di aggregazione
devono essere ortogonali, ovvero applicabili ad ogni oggetto;
notiamo che ad esempio nei database relazionali, l'aggregazione
tupla è applicabile solo ai valori atomici e il
set solo alle tuple: ciò non è accettabile
in un database object oriented.
Object Identity
Il concetto di object identity è molto semplice: un oggetto
ha una sua esistenza che prescinde dal suo valore; pertanto possiamo
avere due oggetti uguali come valore ma distinti come identità.
Notiamo nuovamente la differenza con l'approccio relazionale,
dove un oggetto è identificato dal suo valore; il concetto
di object identity è molto utile per modellare lo sharing
di oggetti e semplificare le operazioni di update, ed è
anche centrale nei rispetti dell'incapsulazione (vedi oltre) in
quanto un oggetto non dovrebbe esporre la propria struttura.
Incapsulazione
Come ormai ben noto, un oggetto espone al mondo esterno un'interfaccia
che ne isola i dettagli implementativi, incapsulando i dati e
le procedure che vi operano. Osserviamo che l'idea di memorizzare
le procedure stesse nell'oggetto è piuttosto inusuale nel
mondo dei database. Si suppone che l'incapsulazione possa essere
bypassata in alcuni casi, come le query ad-hoc, ove requisiti
di mantenibilità non siano rilevanti.
Tipi e Classi
Un database O.O. deve supportare il concetto di tipo o di classe;
la scelta di un modello specifico è lasciata ai progettisti
del database.
Gerarchia di Tipi e Classi
Sia che venga utilizzato un sistema basato su tipi o su classi,
deve essere possibile derivare da un tipo/classe un nuovo elemento;
non viene comunque prescritto alcun modello specifico di ereditarietà.
Polimorfismo (overriding, overloading, late binding)
Concetti ormai noti dei linguaggi di programmazione object oriented,
devono essere disponibili anche all'interno di un OODB.
Completezza Computazionale
Deve essere possibile esprimere ogni funzione computabile nel
linguaggio di manipolazione dei dati associato al database; notiamo
che ad esempio SQL non è computazionalmente completo.
Estendibilità
Non deve esserci alcuna differenza tra tipi/classi built-in e
user-defined: ovvero, può esservi una differenza in termini
di prestazioni o di gestione interna, ma deve essere comunque
trasparente per l'utente del sistema. Molti prodotti che sostengono
di essere "database O.O." non rispettano questo punto.
Persistenza
Questo requisito è ovvio da un punto di vista dei database
systems: gli oggetti devono sopravvivere all'esecuzione del processo,
e possono essere utilizzati in altri processi. Si tratta di uno
dei punti che distinguono un OODB da un normale linguaggio object
oriented.
Gestione della memoria di massa
La persistenza degli oggetti è normalmente realizzata attraverso
l'uso di memorie di massa; ciò coinvolge l'utilizzo di
diverse tecniche, come l'indicizzazione, il clustering, il buffering,
eccetera. Nessuna di queste tecniche deve richiedere l'intervento
dell'utente: chi scrive una applicazione in un OODB non deve preoccuparsi
di gestire indici o di muovere dati dalla memoria di massa o viceversa.
Concorrenza
Caratteristica ormai piuttosto comune, un OODB deve supportare
più utenti allo stesso tempo, l'atomicità di una
sequenza di operazioni, la serializzabilità delle operazioni,
eccetera.
Recovery
Deve esistere un meccanismo per riportare il database ad uno stato
consistente dopo un crash hardware o software.
Query Ad-Hoc
Deve esistere la possibilità di interrogare il database
con sufficiente completezza. Non viene richiesto un particolare
modello o linguaggio: un browser avanzato può essere sufficiente,
o un completo linguaggio di interrogazione può essere fornito;
viene auspicato l'uso di meccanismi il più possibile dichiarativi
e non procedurali.
Requisiti opzionali
Ereditarietà multipla
Il dibattito tra ereditarietà singola e multipla è
lungi dall'essersi esaurito; l'ereditarietà multipla è
indicata quindi come opzionale in un OODB.
Type Checking e Type Inference
Non viene definito il grado di type checking che il sistema deve
eseguire a compile-time, ma viene auspicato un controllo molto
stretto. L'inferenza dei tipi complessi a partire da quelli base
è un elemento opzionale del sistema.
Distribuzione
Questa caratteristica è totalmente ortogonale rispetto
alle problematiche object oriented, e quindi un OODB può
essere distribuito o meno.
Design delle Transazioni
La possibilità di avere transazioni complesse o il nesting
di transazioni è auspicata ma opzionale.
Gestione delle Versioni
In molti casi, è importante conoscere la versione
di una certa struttura dati per poterla gestire correttamente.
Anche se non fa parte del nucleo delle funzionalità di
un OODB, la gestione automatica delle versioni è un interessante
elemento opzionale.
Scelte aperte
Paradigma di programmazione
Al di là del supporto per i principi della programmazione
O.O. (incapsulazione, ereditarietà, polimorfismo), un
qualunque paradigma per il linguaggio di manipolazione dei dati
è accettabile: esistono OODB basati su paradigma logico,
funzionale, o imperativo. In altri casi, il linguaggio è
esterno al database ed è possibile selezionare un diverso
paradigma.
Sistema di Rappresentazione
Vi è completa libertà su come rappresentare gli
elementi dei tipi base e le aggregazioni.
Type System
Anche le possibili aggregazioni sono lasciate all'implementazione:
l'unico requisito è che venga rispettato il principio di
incapsulazione.
Uniformità
Come nei linguaggi di programmazione, vi è un ampio dibattito
sul grado di uniformità che il sistema deve fornire: una
classe è un oggetto? Un metodo è un oggetto? O si
tratta invece di concetti diversi? Il problema, che ha aspetti
diversi a livello di implementazione, semantica del linguaggio
e interfaccia, è troppo lontano da una soluzione ampiamente
accettata, ed ogni decisione in merito è pertanto lasciata
all'implementazione.
Bibliografia
[1] E. F. Codd: "A Relational Model of Data for Large Shared
Data Banks", Communication of ACM, Giugno 1970.
[2] E. F. Codd: "The Twelve Rules for Determining How Relational
a DBMS Product Is", TRI Technical Report, The Relational
Institute, Maggio 1986.
[3] F. Pascal: "dBASE IV Breaks Codd's Rules", DBMS,
Febbraio 1989.
[4] Atkinson, Bancilhon, DeWitt, Dittrich, Maier, Zdonik: "The
Object Oriented Database System Manifesto", 10 Settembre
1989.
