Database orientato agli oggetti: un sug­ge­ri­men­to sui modelli di database

La maggior parte delle persone che si occupa re­go­lar­men­te di database, per esempio in pro­gram­ma­zio­ne software, sviluppo web o bi­blio­te­co­no­mia, lavora con database re­la­zio­na­li e con i ri­spet­ti­vi sistemi di gestione di base di dati (DBMS) come MySQL o MariaDB. Esistono però anche delle al­ter­na­ti­ve: i database orientati agli oggetti (noti anche come database a oggetti) sono uti­liz­za­ti raramente, ma in alcune tipologie di progetto possono dare un grande con­tri­bu­to.

Il modello di database orientato agli oggetti collega tra loro pacchetti che ap­par­ten­go­no allo stesso gruppo: un set di dati viene associato con tutti i suoi attributi ad un unico oggetto. In tal modo, tutte le in­for­ma­zio­ni sono di­ret­ta­men­te di­spo­ni­bi­li. Così, invece di essere di­stri­bui­ti in diverse tabelle, i dati sono di­spo­ni­bi­li insieme. Oltre agli attributi, negli oggetti vengono me­mo­riz­za­ti anche i metodi. Qui si fa chiara la vicinanza di questi database ai linguaggi di pro­gram­ma­zio­ne orientati agli oggetti. Come nel metodo di pro­gram­ma­zio­ne, ogni oggetto ha de­ter­mi­na­te attività che può svolgere.

A loro volta gli oggetti sono rag­grup­pa­ti in classi. Più pre­ci­sa­men­te: un oggetto è un’unità concreta di una classe astratta. Da qui si crea una gerarchia di classi e sot­to­clas­si. All’interno di questo costrutto, le sot­to­clas­si assumono le proprietà delle classi superiori e ag­giun­go­no 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 rag­grup­pa­ti per formare oggetti complessi.

Per in­di­riz­za­re i diversi oggetti, il DBMS orientato agli oggetti cor­ri­spon­den­te assegna au­to­ma­ti­ca­men­te ad ogni unità un’iden­ti­fi­ca­zio­ne univoca. In questo modo è facile ri­chia­ma­re gli oggetti dopo che sono stati salvati.

Un esempio: come unità orientata all’oggetto me­mo­riz­zia­mo l’oggetto concreto di una bi­ci­clet­ta con tutte le sue proprietà e i suoi metodi. È rosso, si muove, ha una sella, e così via. Quest’oggetto fa parte della classe “Bi­ci­clet­te”. All’interno della stessa classe, ad esempio, si possono trovare una bi­ci­clet­ta blu e una verde. La classe “Bi­ci­clet­te” è a sua volta una sot­to­ca­te­go­ria di “Veicoli”, alla quale ap­par­tie­ne anche la classe “Auto”. Allo stesso tempo, però, l’oggetto ha anche un col­le­ga­men­to con la classe “Attività per il tempo libero”. Se ri­chia­mia­mo il nostro oggetto at­tra­ver­so il suo ID univoco, saranno di­ret­ta­men­te di­spo­ni­bi­li anche tutti i suoi attributi e metodi.

Come già detto, i database re­la­zio­na­li sono stati per molto tempo lo standard uti­liz­za­to nello sviluppo web e software. In questo modello le in­for­ma­zio­ni sono me­mo­riz­za­te in tabelle connesse tra loro. Anche in questo caso, in­for­ma­zio­ni più complesse pro­ve­nien­ti da com­po­nen­ti diversi possono essere me­mo­riz­za­te e re­cu­pe­ra­te at­tra­ver­so i col­le­ga­men­ti. Con un database a oggetti, tuttavia, tutti i com­po­nen­ti dell’intera unità sono im­me­dia­ta­men­te di­spo­ni­bi­li. Questo permette di lavorare con record di dati anche molto più complessi. Con un database re­la­zio­na­le, si cerca piuttosto di or­ga­niz­za­re in­for­ma­zio­ni semplici. Quanto più complesso diventa il set di dati, tanto più estesi sono i col­le­ga­men­ti, cosa che può portare ad un ral­len­ta­men­to del database.

La scelta del modello di database dipende molto dal caso d’uso. Un database a oggetti è par­ti­co­lar­men­te van­tag­gio­so se si lavora con linguaggi di pro­gram­ma­zio­ne orientati agli oggetti come Java. Gli oggetti del codice sorgente possono essere fa­cil­men­te inclusi nel database. Se si utilizza un database re­la­zio­na­le, che non è affatto insolito, risulta difficile integrare nella co­stru­zio­ne della tabella so­prat­tut­to gli oggetti complessi.

Uno svan­tag­gio è so­prat­tut­to la cattiva di­stri­bu­zio­ne. No­no­stan­te 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 è re­la­ti­va­men­te piccola. Pertanto, la maggior parte degli svi­lup­pa­to­ri pre­fe­ri­sce uti­liz­za­re i database re­la­zio­na­li che sono più diffusi, ben do­cu­men­ta­ti e altamente svi­lup­pa­ti.

Ciò che è un vantaggio in certe si­tua­zio­ni, però, può diventare uno svan­tag­gio in altri contesti: la com­ples­si­tà degli oggetti fa sì che anche le query e i processi di scrittura complessi possano essere eseguiti molto più ve­lo­ce­men­te rispetto ai modelli re­la­zio­na­li. Tuttavia, anche quando i processi sono re­la­ti­va­men­te semplici, va uti­liz­za­ta una struttura complessa, con una con­se­guen­te perdita di velocità.