Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Une conversation avec Michel Volle :
Modèle relationnel et modèle objet
Une compatibilité toute relative
Article mis en ligne le 19 novembre 2009
dernière modification le 1er avril 2014

par Laurent Bloch, Michel Volle

Cet article relate une conversation (en ligne) entre Michel Volle et Laurent Bloch au sujet du problème, pas si facile qu’il y paraît, de la mise en correspondance d’un langage à objets avec une bases de données relationnelle.

Problème posé par Michel Volle

MV : J’ai reçu un billet qui pointe vers un problème que j’avais senti, mais que je ne suis pas capable de traiter. Le voici : http://blog.pondaven.net/2009/01/la...
Qu’en penses-tu ? Quelle est la bonne solution ? XML, par exemple ?

Sur le même sujet, on peut lire aussi
http://en.wikipedia.org/wiki/Object....

LB : C’est un problème aujourd’hui dépourvu de solution et qui ressort périodiquement.

Le modèle relationnel a beaucoup de qualités, mais les gens des SGBDR n’ont historiquement pas été très proches des gens qui ont conçu les langages dominants du jour, alors, comme le signalent les articles que tu indiques, les concepts ne sont pas les mêmes, ou plutôt sont subtilement différents, ce qui est pire, et du coup le traitement d’une base de données Oracle par un programme Java est à coup sûr une usine à gaz épouvantable.

Il y a une douzaine d’années ont été lancés des SGDO (Systèmes de gestion de données objet). J’ai eu l’occasion
de travailler là-dessus pendant deux ans : horreur absolue, échec total,
à l’époque j’ai rencontré pas mal de gens qui avaient essayé, tout le
monde aboutissait à la même conclusion.

Là-dessus vient s’ajouter XML : très pratique pour les Web services. Enfin, tant qu’on n’a pas à y mettre la main, parce que triturer du XML « à la main » n’est pas très agréable.

Ce que font silencieusement les gens qui n’ont pas peur de se faire incendier par les responsables qualité : plutôt que d’avoir des gros ERP avec des milliers de tables dans une base Oracle
(oui, des milliers) pour faire trois additions et sortir un bilan, un grand livre, des factures et des bons de commande, ils font des applications plus sobres, PHP-MySQL, en utilisant les méthodes Unix-logiciel libre, c’est-à-dire la combinaison astucieuse de petits programmes qui ne font qu’une chose.

PHP est un langage agréable, mille fois moins complexe que Java
accompagné de ses environnements de développement, de ses frameworks et de ses toolkits. Mais bon, dans les grandes organisations, où la prolifération cancéreuse des cahiers des charges sert surtout à diluer les conflits internes, plus c’est lourd, compliqué et cher, plus on est content.

Le compte-rendu de mes travaux sur le sujet sont là : http://www.laurentbloch.org/Sgbo/ (cela mériterait sans doute un peu de rewriting).

Second échange

MV : L’article sur les difficultés que comporte la superposition d’un langage à objets à une BD relationnelle me tracasse. Jusqu’à présent, en effet, je pensais que cette superposition allait de soi.

Je me représente les choses selon un modèle en couches, superposant une couche « objet » à une couche « BD ».

La couche « BD » est comme un ensemble de tiroirs dans lesquels on peut commodément classer les données. À chaque classe du modèle à objets correspond une relation ; à chaque
attribut dans la classe, une variable de la relation ; à chaque objet, un tuple de la relation. L’héritage entre classes peut se traiter comme le produit cartésien de deux relations. L’association de deux objets, comme une association entre deux relations. Ainsi une part importante du modèle objets se transpose dans la couche « BD ».

Les « méthodes » associées à chaque classe, elles, résident dans la couche « objet » et non dans la BD relationnelle. Ainsi, c’est la couche « objet » qui assure l’encapsulation et le polymorphisme.

Evidemment, si l’on veut faire faire par la couche « BD » des choses qu’elle ne peut pas faire (encapsulation, polymorphisme), on tombe sur des impossibilités. Mais si on l’utilise pour ce qu’elle sait faire (stocker des données dont elle maintient l’intégrité), je ne vois pas où est le problème.

Qu’en penses-tu ?

LB : Les dissensions entre modèle relationnel et modèle objet ne sont pas d’ordre théorique, mais pratique.

Faire correspondre directement une classe à une relation n’est pas toujours possible : si un attribut de la classe n’est pas atomique (vecteur, liste) ou, pire, s’il est multivalué, cela n’entrera pas dans la table ; or si l’on a envie d’avoir des objets c’est justement pour pouvoir faire cela commodément : la classe Mère avec ses 0, 1, 2 ... n enfants, la classe Véhicule avec ses 1, 2, 3 ... n roues. Donc il va falloir éclater la classe en plusieurs tables, mais alors toute reconstruction de l’objet (traitement
côté « client ») est une opération lourde, cependant que les traitements qui ne concernent qu’une table (les enfants, considérés indépendamment de leurs liens de filiation ou de fraternité) seront efficaces (traitement côté « serveur »).

D’où la tentative des SGDO : on stocke les objets « tels quels », c’est à dire selon leur représentation en mémoire. Nous aurons alors des caractéristiques opposées : l’accès à la mère et à tous ses enfants est direct (traitement « côté client »), en revanche parcourir la population des enfants (traitement côté « serveur ») demandera la déconstruction et l’analyse de chaque instance pour construire un tableau, que le modèle relationnel aurait fourni directement.

Il y a une dizaine d’années j’avais suivi à l’INRIA un séminaire de Gary Lindstrom, que Wikipédia décrit comme "Emeritus Professor of Computer Science at the University of Utah", qui étudiait ces questions. Ses mesures montraient que dès que l’on devait passer d’un modèle à l’autre, les temps de traitement étaient multipliés en gros par trois, ce qui recoupait mes propres expériences, moins systématiques.

Les SGDO semblaient une bonne idée : pourquoi ont-ils échoué et finalement disparu (quoiqu’il en survive quelques-uns, cachés à l’intérieur d’autres logiciels) ? Toute l’explication est dans la locution « on stocke les objets “tels quels”, c’est à dire selon leur représentation en mémoire ». Le problème, c’est que ladite représentation en mémoire dépend et du langage, et de la plate-forme matérielle. Impossible d’attaquer en Java une BD créée en C++. Un autre facteur d’échec, dirimant : les groupes de
travail de l’OMG n’ont jamais réussi à produire l’équivalent de SQL pour les SGDO, et s’ils ont échoué malgré des efforts considérables c’est probablement parce que les difficultés étaient encore plus considérables. Un point fort du modèle relationnel, c’est SQL, et notamment le fait que SQL ne soit pas Turing-équivalent, ce qui autorise, dans les coulisses,
des optimisations et une grande variété de représentations physiques.

Donc, que fait-on maintenant si l’on programme en Java et qu’il faut une base de données ? Eh bien si l’on veut faire cela de façon un peu systématique on a une couche d’interface, assez complexe et consommatrice (facteur 3 de Lindstrom), de nos jours cela s’appelle un framework, par exemple Hibernate, pour avoir la BD accessible au monde extérieur, et pour la cuisine interne on a une couche de persistance qui abrite temporairement les objets « tels quels ». Du coup cela renforce ma préférence pour un langage plus fruste, PHP, qui est très inefficace mais qui fait tout cela plus simplement, donc ce qui est perdu ici ne l’est pas là, le résultat sera souvent comparable.

Pourtant les idées des SGDO étaient bonnes, mais pas appliquées à la bonne couche. Le système d’exploitation de l’avenir, selon mes vaticinations (inspirées par des conversations avec Christian Queinnec), sera basé sur ces principes. Ainsi, l’accès aux objets « tels quels » sera fourni de façon uniforme à tous les programmes, y compris par le réseau, ce qui nous débarassera d’une plaie : les fichiers ! J’évoquais un peu ça
dans mon livre de système.

Troisième échange

MV : J’avoue que je ne comprends pas pourquoi l’on a rencontré tant de difficultés, mais sans doute n’est-ce là qu’une conséquence de mon ignorance (abyssale) de certains aspects techniques. On ne relit jamais assez Donald Knuth ! et pourtant, j’y ai passé des journées.

Tu dis que les BD relationnelles ne sont pas faites pour contenir des listes, des vecteurs, ou encore des attributs multivalués. Mais rien n’empêche de définir les types correspondants, puis de mettre dans la BD des pointeurs qui permettent d’accéder aux valeurs de ces attributs ; leur traitement, lui, sera comme pour les autres « méthodes » réalisé par la couche « objet ». Où est le problème ?

Le mot « relation », dans un SGBDR, désigne en fait deux choses qu’il faut distinguer : la relation1 qui est un ensemble d’attributs, qualifiés par leur type, et analogue à la définition d’une classe dans le monde « objet » ; et la relation2, ensemble de tuples stockant les valeurs des attributs
observées sur une population d’individus particulière.
L’héritage entre des classes peut se transcrire, dans le SGBDR, en considérant la relation1 : il s’agit de définir une liste d’attributs qui (1) reprend tous ceux de la classe mère, mais (2) y ajoute ceux propres à la classe enfant : c’est un produit cartésien. Et là aussi, où est le problème ?

Il doit y avoir des choses que je ne perçois pas !

LB : Michel, tu perçois bien tout. Simplement, tu te places au niveau du modèle conceptuel, alors que l’article qui t’avait interloqué et dont j’essaie de développer le propos ici se place au niveau du modèle physique. L’informatique est un art tout d’exécution !

Dans une base de données relationnelle on n’insère pas de pointeurs, mais des références à d’autres tables, références qu’il faudra résoudre pour reconstruire les objets.

Certes, la relation1 est bien analogue à la définition d’une classe dans le monde « objet ». Simplement, chaque accès à une instance de classe un peu complexe pour un traitement côté « client » va nécessiter la reconstruction de l’objet en extrayant ses attributs des tables de la base. Il faudra aussi tenir compte des types dont les définitions dans le langage SQL peuvent ne pas être exactement les mêmes que dans le langage de programmation utilisé. Bref, rien d’impossible, mais une cuisine lourde (facteur 3 de Lindstrom à appliquer au temps de calcul), et des programmes qui deviennent vite compliqués.