Database orientato agli oggetti: un suggerimento sui modelli di database

La maggior parte delle persone che si occupa regolarmente di database, per esempio in programmazione software, sviluppo web o biblioteconomia, lavora con database relazionali e con i rispettivi sistemi di gestione di base di dati (DBMS) come MySQL o MariaDB. Esistono però anche delle alternative: i database orientati agli oggetti (noti anche come database a oggetti) sono utilizzati raramente, ma in alcune tipologie di progetto possono dare un grande contributo.

Il modello di database orientato agli oggetti collega tra loro pacchetti che appartengono allo stesso gruppo: un set di dati viene associato con tutti i suoi attributi ad un unico oggetto. In tal modo, tutte le informazioni sono direttamente disponibili. Così, invece di essere distribuiti in diverse tabelle, i dati sono disponibili insieme. Oltre agli attributi, negli oggetti vengono memorizzati anche i metodi. Qui si fa chiara la vicinanza di questi database ai linguaggi di programmazione orientati agli oggetti. Come nel metodo di programmazione, ogni oggetto ha determinate attività che può svolgere.

A loro volta gli oggetti sono raggruppati in classi. Più precisamente: un oggetto è un’unità concreta di una classe astratta. Da qui si crea una gerarchia di classi e sottoclassi. All’interno di questo costrutto, le sottoclassi assumono le proprietà delle classi superiori e aggiungono i loro attributi. Allo stesso tempo, gli oggetti di una classe possono essere collegati anche ad altre classi. Questo rompe la rigida gerarchia e crea una rete. Gli oggetti semplici possono essere raggruppati per formare oggetti complessi.

Per indirizzare i diversi oggetti, il DBMS orientato agli oggetti corrispondente assegna automaticamente ad ogni unità un’identificazione univoca. In questo modo è facile richiamare gli oggetti dopo che sono stati salvati.

Un esempio: come unità orientata all’oggetto memorizziamo l’oggetto concreto di una bicicletta con tutte le sue proprietà e i suoi metodi. È rosso, si muove, ha una sella, e così via. Quest’oggetto fa parte della classe “Biciclette”. All’interno della stessa classe, ad esempio, si possono trovare una bicicletta blu e una verde. La classe “Biciclette” è a sua volta una sottocategoria di “Veicoli”, alla quale appartiene anche la classe “Auto”. Allo stesso tempo, però, l’oggetto ha anche un collegamento con la classe “Attività per il tempo libero”. Se richiamiamo il nostro oggetto attraverso il suo ID univoco, saranno direttamente disponibili anche tutti i suoi attributi e metodi.

Come già detto, i database relazionali sono stati per molto tempo lo standard utilizzato nello sviluppo web e software. In questo modello le informazioni sono memorizzate in tabelle connesse tra loro. Anche in questo caso, informazioni più complesse provenienti da componenti diversi possono essere memorizzate e recuperate attraverso i collegamenti. Con un database a oggetti, tuttavia, tutti i componenti dell’intera unità sono immediatamente disponibili. Questo permette di lavorare con record di dati anche molto più complessi. Con un database relazionale, si cerca piuttosto di organizzare informazioni semplici. Quanto più complesso diventa il set di dati, tanto più estesi sono i collegamenti, cosa che può portare ad un rallentamento del database.

La scelta del modello di database dipende molto dal caso d’uso. Un database a oggetti è particolarmente vantaggioso se si lavora con linguaggi di programmazione orientati agli oggetti come Java. Gli oggetti del codice sorgente possono essere facilmente inclusi nel database. Se si utilizza un database relazionale, che non è affatto insolito, risulta difficile integrare nella costruzione della tabella soprattutto gli oggetti complessi.

Uno svantaggio è soprattutto la cattiva distribuzione. Nonostante il modello sia noto fin dagli anni '80, finora sono stati creati solo pochi DBMS per database a oggetti. La community che si occupa del modello è relativamente piccola. Pertanto, la maggior parte degli sviluppatori preferisce utilizzare i database relazionali che sono più diffusi, ben documentati e altamente sviluppati.

Ciò che è un vantaggio in certe situazioni, però, può diventare uno svantaggio in altri contesti: la complessità degli oggetti fa sì che anche le query e i processi di scrittura complessi possano essere eseguiti molto più velocemente rispetto ai modelli relazionali. Tuttavia, anche quando i processi sono relativamente semplici, va utilizzata una struttura complessa, con una conseguente perdita di velocità.