Bases de données orientées objet : le secret d’un modèle de base de données

La plupart des personnes qui tra­vail­lent ré­gu­liè­re­ment avec des bases de données – pro­gram­meurs dans le dé­ve­lop­pe­ment Web ou la gestion des bi­blio­thèques – utilisent des bases de données re­la­tion­nelles, et plus pré­ci­sé­ment à l’aide de systèmes de gestion de bases de données (DBMS) adaptés comme MySQL ou MariaDB. Il existe pourtant des al­ter­na­tives : les bases de données orientées objet (aussi désignées par « bases de données objet ») sont certes rarement utilisées, mais elles peuvent faire con­si­dé­ra­ble­ment avancer certains projets.

Les modèles de bases de données orientées objet re­grou­pent des paquets de données très proches : un ensemble de données est regroupé avec tous ses attributs pour former un objet. Ainsi, toutes les in­for­ma­tions sont im­mé­dia­te­ment dis­po­nibles. Au lieu de tout répartir dans dif­fé­rentes tables, les données sont in­ter­ro­geables par ensemble. En plus des attributs, les objets peuvent aussi inclure des méthodes. Pour cette raison, la proximité des bases de données avec les langages de pro­gram­ma­tion orientés objets est frappante. Tout comme pour cette méthode de pro­gram­ma­tion, chaque objet peut exécuter des actions spé­ci­fiques.

Les objets sont à nouveau regroupés en classes. Pour le dire plus pré­ci­sé­ment : un objet est une unité concrète au sein d’une classe abstraite. Cette con­fi­gu­ra­tion engendre une hié­rar­chie entre classes et sous-classes. À l’intérieur de cette structure, les sous-classes adoptent les pro­prié­tés des classes du niveau supérieur et les com­plè­tent avec leurs propres attributs. Les objets d’une classe peuvent aussi être liés si­mul­ta­né­ment à une autre classe : cette hié­rar­chie forte s’en retrouve affaiblie au profit de la création d’une in­ter­con­nexion. Les objets simples se re­grou­pent en objets complexes.

Pour pouvoir in­ter­ro­ger les dif­fé­rents objets, le SGBD (système de gestion des bases de données) orienté objet attribue au­to­ma­ti­que­ment à chaque unité une iden­ti­fi­ca­tion unique. Celle-ci permet de retrouver fa­ci­le­ment les objets après leur en­re­gis­tre­ment.

Exemple : nous en­re­gis­trons un objet concret, un vélo, et toutes ses pro­prié­tés et méthodes en qualité d’unité orientée objet. Le vélo est rouge, peut rouler, présente une selle, etc. Cet objet fait également partie de la classe « vélos ». Au sein de cette classe, on peut par exemple trouver un vélo bleu et un vélo vert. La classe « Vélos » est elle-même une sous-classe de la catégorie « Véhicules », qui comprend aussi la classe « Voitures ». Notre objet a si­mul­ta­né­ment un lien avec la classe « Activités de loisir ». Lorsqu’on interroge cet objet à l’aide de son iden­ti­fiant unique, tous ses attributs et méthodes sont di­rec­te­ment mis à dis­po­si­tion.

Comme évoqué plus haut, les bases de données re­la­tion­nelles sont depuis longtemps la norme dans le dé­ve­lop­pe­ment de sites Web et de logiciels. Avec ce modèle, les in­for­ma­tions sont en­re­gis­trées dans des tables reliées les unes aux autres. Cette méthode permet aussi d’in­ter­con­nec­ter et d’in­ter­ro­ger des in­for­ma­tions complexes à partir de dif­fé­rents com­po­sants. Une base de données objets permet en plus d’in­ter­ro­ger im­mé­dia­te­ment tous les com­po­sants d’une unité, ce qui permet notamment de tra­vail­ler avec des ensembles de données bien plus complexes. Avec une base de données re­la­tion­nelle, on cherche plutôt à organiser des in­for­ma­tions simples. Plus les ensembles de données sont complexes, plus les in­ter­con­nexions se mul­ti­plient entre les objets, ce qui entraîne un ra­len­tis­se­ment de la base de données.

Le type de base de données le plus approprié à retenir dépend fortement de la nature du projet. Lorsque l’on travaille déjà avec des langages de pro­gram­ma­tion orientés objet, comme par exemple Java, une base de données objet est avan­ta­geuse. Les objets du code source peuvent sim­ple­ment être repris dans la base de données. Si l’on opte pour une base de données re­la­tion­nelle, ce qui n’est pas si rare, les objets complexes sont dif­fi­ciles à intégrer à l’ar­chi­tec­ture des tables.

La base de données objet présente l’in­con­vé­nient d’être dif­fi­ci­le­ment dif­fu­sable. Bien que ce modèle existe depuis les années 1980, jusqu’à présent, très peu de SGBD orientés objet ont vu le jour. Par con­sé­quent, la com­mu­nauté spé­cia­li­sée dans ce modèle est elle aussi réduite. La plupart des dé­ve­lop­peurs préfèrent donc utiliser les bases de données re­la­tion­nelles, plus répandues, bien do­cu­men­tées et ap­pro­fon­dies.

La solution qui peut présenter un avantage dans une situation donnée peut se trans­for­mer en in­con­vé­nient dans une autre : la com­plexité des objets vise à exécuter les demandes et les écritures complexes bien plus ra­pi­de­ment qu’avec un modèle re­la­tion­nel. Si les procédés s’avèrent plus simples, ils doivent malgré tout s’appliquer à une structure complexe, ce qui entraîne une perte de vitesse.