Le décor

L'informatique d'entreprise a aujourd'hui une poignée de buts relativement clairs :

  • automatiser des tâches
  • fluidifier la circulation de l'information entre les personnes
  • produire de l'information (croisement de données par exemple)
  • garder trace des actions passées (stockage des données)

Atteindre ces buts passe par la modélisation de l'entreprise. Diagrammes, description de processus. Une multitude d'outils existe pour modéliser la réalité sur le papier.
Si l'on revient à la liste ci-dessus, pour chacune des lignes il existe une modélisation simple, et un système qui rend compte du modèle de manière quasiment bijective :
Dés qu'il s'agit de données, de stockage, de reporting, le modèle relationel, et le système sous-jacent la base de données font merveille, forment une stratégie éprouvée et robuste, aboutie depuis le temps qu'elle existe. C'est le paradigme relationnel.

Lorsqu'il s'agit d'objet métiers et de processus (processi?), le modèle objet avec ses différentes solutions techniques (plateformes Java et .Net...) est un outil qui présente de nombreux avantages (maintenabilité, clarté de lecture, évolutivité etc.). C'est le paradigme objet.

Décalage et incompatibilité des paradigmes

Malheureusement pour nous, les paradigmes, ou modélisations, présentés précédemment présentent par essence des incompatibilités qui vont compliquer la vie des employés du département informatique :

différence de granularité

Là ou le modèle objet propose des objet de granularité graduelle (Client / adresse / code postal), le modèle relationel (le SGBD en fait) propose 2 niveaux de granularités : table et colonnes...

polymorphisme

Un client a un moyen de paiement. Le modèle objet nous permet de définir différents types de paiement, très différents, tels que carte de crédit ou compte bancaire. Dans la base de données, un moyen de paiement, s'il n'est pas spécifiquement décrit, n'existe pas, et ne peut être traduit dans une table. Est-ce une carte de crédit ou un compte bancaire?

Identité

L'identité de 2 objets en Java peut se comprendre de 2 manières différentes : == ou equals. Dans le modèle relationnel, deux objets seront égaux s'ils ont la même clés.

associations

Dans le modèle objet, un client peut avoir une adresse sans que l'adresse "sache" qu'elle est liée à ce client (donnant ainsi la possibilité d'avoir la même adresse pour plusieurs clients). Il s'agit d'une relation navigable, qui peut être one-to-many, one-to-one ou many-to-many. Il y a ici une notion de sens et de multiplicité.

Avec le modèle relationel, s'il y a une relation, elle n'est pas navigable. Si un client est lié à une adresse, alors connaitre cette adresse permettra de connaitre le client. L'implication directe de cette constatation est qu'il est trop compliqué voire impossible d'avoir une relation many-to-many dans le modèle relationnel. (Un client a n adresses et une adresse est liée à m clients).

navigation dans les données

L'extraction du compte bancaire d'un client, en modèle objet se fait le plus naturellement du monde avec le code suivant :

myClient.getBillingInfos().getAccountNumber() par exemple.

si l'on traduit en terme de requètes SQL, le résultat va s'avérer désastreux. Lorsque l'on sait que le moyen efficace de dialoguer avec la base de données est de minimiser le nombre de requètes...On pourra bien sur s'en tirer à bon compte avec force "joins". Mais que se passe-t-il lorsque l'on répète cette opération n fois et que n grandit? On rencontre le fameux problème des n+1 select. La ou un seul (gros?) select pourrait distribuer les résultats et agir de manière beaucoup plus efficace. Un problème de scalabilité du système est donc induit ici par la différence entre les navigations dans les deux paradigmes. Probablement le plus crucial des problèmes de cette liste.

Conclusion?

Ce problème, selon G. King et C. Bauer, auteurs de "Java persistence with Hibernate" coûte en moyenne 30% de l'effort investi dans les projets informatiques, et pose un réel problème de design, et donc de coûts à court et long terme. Toujours une histoire de $ finalement !
La solution à nos problèmes va donc consister à introduire une couche de persistence (persistence layer) qui va nous aider à simplifier, nous guider dans les choix de design et nous soutenir sur les problèmes répétitifs (automated plumbing !).