Database ad Oggetti

I database ad oggetti ( object-oriented ) potranno forse in futuro affermarsi nei confronti di quelli relazionali, ma sono ormai alcuni anni che si dicono le stesse cose ed ancora non è cambiato molto, trattiamo però questo argomento per mettere in risalto alcune lacune che presentano i database relazionali.
Il modello relazionale, introdotto nel 1970 da E. Codd, si basa sul concetto di relazione, o tabella. Ogni tabella è composta da un insieme di righe o record, che a loro volta sono composti da un insieme di colonne o campi. Tutte le righe hanno la medesima struttura ed i tipi ammissibili per ognuna delle colonne sono fissi o predefiniti, comunque tipi semplici; ogni tabella risulta del tutto indipendente dalle altre. Per questo motivo le relazioni tra le tabelle possono essere espresse semplicemente sulla presenza di un campo in comune sulle due tabelle. A causa di queste caratteristiche il modello relazionale di database risulta poco adatto a rappresentare informazioni complesse, come ad esempio sistemi CAD o CASE.
Consideriamo ad esempio un programma cartografico per la gestione di mappe geografiche, l’oggetto gestito da questo programma, cioè la mappa, è molto complesso ed è composto da diversi elementi; volendo rappresentare un oggetto di questo tipo si dovrebbe definire un insieme di tabelle per rappresentare ognuna degli elementi che lo compongono, in pratica l’oggetto mappa geografica avrà bisogno di molte tabelle per essere memorizzato.
I programmatori che utilizzano C++ o C# o Java sanno benissimo come rappresentare un oggetto anche complesso, però un linguaggio di programmazione non è in grado di salvare su disco informazioni relative ad un oggetto di questo tipo e poi ripristinarli in un secondo tempo tramite una ricerca.
I database ad oggetti sono nati con lo scopo di superare gli attuali limiti dei database relazionali in termini di potenza e rappresentazione dei dati. Possiamo definire un database object-oriented come uno strumento che offra all’applicazione la possibilità di rendere persistenti i dati che gestisce, fornendo funzionalità di accesso universali e ricerca dei dati. Utilizzando uno strumento di questo tipo potremmo rappresentare una mappa geografica con la stessa struttura utilizzata nel programma, in questo modo viene ad essere superato uno dei limiti dei database relazionali, noto come impedance mismatch, costituito appunto dalla differenza concettuale tra i modelli di rappresentazione dei dati utilizzati dall’applicazione e dal database. Questa limitazione comporta da parte del programmatore una nuova implementazione di un algoritmo di conversione nei due sensi.
Il limite principale dei database ad oggetti è costituito dalla mancanza di standardizzazione, presente invece nei database relazionali. Grazie a SQL, ODBC o OleDB, infatti, i database relazionali sono diventati praticamente tutti compatibili tra loro ed infatti un’applicazione gestionale concepita per gestire un database Oracle può facilmente essere convertita per poter gestire MS SQL Server o altro DBMS. Un’applicazione collegata ad un database ad oggetti difficilmente potrà essere convertita per gestire dati residenti su un altro OODBMS. Per porre rimedio a questa situazione è nata un’organizzazione denominata ODMG ( Object Database Management Group ), che ha definito un insieme di linguaggi per la definizione degli schemi e per la gestione dei dati che dovrebbero costituire per i database object-oriented ciò che SQL è stato per i database relazionali. Questi linguaggi denominati ODL ( Object Definition Language ) e OQL ( Object Query Language ) sono stati però solo parzialmente adottati dagli odierni database ad oggetti.