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

La plupart des personnes qui travaillent régulièrement avec des bases de données – programmeurs dans le développement Web ou la gestion des bibliothèques – utilisent des bases de données relationnelles, et plus précisément à l’aide de systèmes de gestion de bases de données (DBMS) adaptés comme MySQL ou MariaDB. Il existe pourtant des alternatives : 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 considérablement avancer certains projets.

Les modèles de bases de données orientées objet regroupent 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 informations sont immédiatement disponibles. Au lieu de tout répartir dans différentes tables, les données sont interrogeables 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 programmation orientés objets est frappante. Tout comme pour cette méthode de programmation, chaque objet peut exécuter des actions spécifiques.

Les objets sont à nouveau regroupés en classes. Pour le dire plus précisément : un objet est une unité concrète au sein d’une classe abstraite. Cette configuration engendre une hiérarchie entre classes et sous-classes. À l’intérieur de cette structure, les sous-classes adoptent les propriétés des classes du niveau supérieur et les complètent avec leurs propres attributs. Les objets d’une classe peuvent aussi être liés simultanément à une autre classe : cette hiérarchie forte s’en retrouve affaiblie au profit de la création d’une interconnexion. Les objets simples se regroupent en objets complexes.

Pour pouvoir interroger les différents objets, le SGBD (système de gestion des bases de données) orienté objet attribue automatiquement à chaque unité une identification unique. Celle-ci permet de retrouver facilement les objets après leur enregistrement.

Exemple : nous enregistrons un objet concret, un vélo, et toutes ses proprié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 simultanément un lien avec la classe « Activités de loisir ». Lorsqu’on interroge cet objet à l’aide de son identifiant unique, tous ses attributs et méthodes sont directement mis à disposition.

Comme évoqué plus haut, les bases de données relationnelles sont depuis longtemps la norme dans le développement de sites Web et de logiciels. Avec ce modèle, les informations sont enregistrées dans des tables reliées les unes aux autres. Cette méthode permet aussi d’interconnecter et d’interroger des informations complexes à partir de différents composants. Une base de données objets permet en plus d’interroger immédiatement tous les composants d’une unité, ce qui permet notamment de travailler avec des ensembles de données bien plus complexes. Avec une base de données relationnelle, on cherche plutôt à organiser des informations simples. Plus les ensembles de données sont complexes, plus les interconnexions se multiplient entre les objets, ce qui entraîne un ralentissement 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 programmation orientés objet, comme par exemple Java, une base de données objet est avantageuse. Les objets du code source peuvent simplement être repris dans la base de données. Si l’on opte pour une base de données relationnelle, ce qui n’est pas si rare, les objets complexes sont difficiles à intégrer à l’architecture des tables.

La base de données objet présente l’inconvénient d’être difficilement diffusable. 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 conséquent, la communauté spécialisée dans ce modèle est elle aussi réduite. La plupart des développeurs préfèrent donc utiliser les bases de données relationnelles, plus répandues, bien documentées et approfondies.

La solution qui peut présenter un avantage dans une situation donnée peut se transformer en inconvénient dans une autre : la complexité des objets vise à exécuter les demandes et les écritures complexes bien plus rapidement qu’avec un modèle relationnel. 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.