TRIBUNE
Chronique du Net

Comment réconcilier les modèles relationnel et objet?

Partie (1/2)

L’architecture des systèmes d’informations modernes est généralement basée sur la notion d’architecture n-tiers. L’idée de ces architectures est de séparer clairement les différents niveaux de traitements informatiques nécessaires pour la mise en oeuvre d’une application.


Ces tiers sont généralement au nombre de trois et ils s’appliquent à résoudre les problématiques suivantes :

la présentation de l’information à l’utilisateur (tiers de présentation);

la résolution des problématiques relatives au métier des utilisateurs (tiers métier);

la persistance des données traitées par l’application (tiers de persistance).


Ces architectures sont déclinées dans des environnements de développement orientés objet et les données de travail sont donc modélisées par des classes d’objets.
Le modèle relationnel a vu le jour au cours de l’année 1970 lorsque le Dr. E. F. Cobb a publié un document intitulé «A Relational Model of Data for Large Shared Data Bank». La première implémentation commerciale a vu le jour en 1979, éditée par la société Relational Software Inc. qui est connue de nos jours sous le nom d’Oracle Corporation. Depuis, les bases de données relationnelles se sont largement implantées dans les entreprises.
Aujourd’hui, les entreprises maîtrisent bien le modèle relationnel et doivent adopter des modèles objet pour répondre aux contraintes de flexibilité. Afin de ne pas remettre en cause l’investissement colossal du passé, les entreprises doivent marier les deux modèles à l’aide des outils de mapping objet/relationnel.

Généralités
Le modèle objet

Le modèle objet permet de modéliser un système d’information, aussi bien au niveau des données qu’au niveau des processus.
Un modèle objet est organisé autour de la notion de classe d’objet spécifiée par un ensemble d’attributs et un ensemble de méthodes.
Chaque objet élément de cette classe est appelé une instance qui est caractérisée par son état, ensemble des valeurs d’attributs de la classe de l’objet et son identité le différenciant de tous les autres objets.
Les liens entre les objets sont dénommés associations. Par exemple, un objet de classe Père peut avoir de 0 à n objets de classe Enfant associés.
L’héritage est un mécanisme cher au modèle de programmation objet qui permet de définir une nouvelle classe d’objet à partir des caractéristiques d’une autre classe. La nouvelle classe hérite de tous les attributs et méthodes de la première et il est alors possible de lui rajouter des attributs ou des méthodes à volonté.
... Le groupe SQLI, présent en Suisse
(Genève, Lausanne), est spécialisé dans les nouvelles technologies
et propose conseil, ingénierie,
formation et veille technologique.
Ch de la Rueyre 116-118
1020 Renens
Tél. : 021/637 72 30
Fax : 021/637 72 31
e-mail : sqlich@sqli.com
Web : www.sqli.com
Par exemple, les classes Père et Enfant peuvent hériter de la classe Homme car l’enfant et le père ont des propriétés et comportements en commun.
Le polymorphisme permet à des classes différentes d’avoir un même comportement et d’être capables de répondre à un même ensemble de messages. Un exemple est celui de la mobilité. Un véhicule et un homme n’ont aucune caractéristique commune; en revanche, ils sont tous les deux mobiles et peuvent être considérés comme des «mobiles» et répondre aux messages «avancer» ou «reculer».
La puissance de modélisation apportée par les concepts objet, ainsi que les méthodes de conception associées (UML, OMT...) permettent de réaliser des applications plus facilement maintenables et extensibles.

Le modèle relationnel

Le modèle relationnel est basé sur la notion de relation. Il permet de décrire l’ensemble des données du système d’information mais ne permet pas de décrire les processus métier mettant en œuvre ces données. La description des processus se fait séparément de celle des données. Un modèle relationnel est composé de relations, spécifiées par l’ensemble des domaines des attributs et les «tuples», éléments de la relation. Ce sont des ensembles d’attributs connus comme vérifiant la relation.
Par exemple : Town { CP, name } est la relation qui signifie qu’il existe une ville dont le nom est la valeur de l’attribut name et le code postal est la valeur de l’attribut CP. Un tuple élément de cette relation est : Town { ‘75000’ , ‘Paris’ } signifiant que Paris est une ville dont le code postal est 75’000.
Les relations sont plus communément appelées tables et les attributs sont les colonnes de ses tables.
La clef primaire d’une relation est l’attribut ou l’ensemble d’attributs qui permet d’identifier un tuple de la relation de façon unique. Une clef étrangère est un ensemble d’attributs d’une relation qui fait référence à une clef primaire d’une autre relation. La combinaison de l’utilisation de ces deux types de clefs permet de définir des liens entre les différentes relations.
Par exemple : Country{ CODE, NAME } où CODE est la clef primaire de la relation. Et Town( CP, Country.CODE, NAME } où CODE est une clef étrangère. La clef étrangère permet d’identifier uniquement le pays dans lequel se situe la ville.

Stockage d’objets
dans un schéma relationnel

Les objets ont une nature vivante et résident généralement dans la mémoire vive des systèmes lorsque l’on veut les utiliser. Pour assurer la persistance des objets, ceux-ci doivent être sauvegardés dans un système de stockage permanent, qui est généralement une base de données relationnelles. Les objets peuvent également persister dans une base de données objet ou une structure de fichiers. Nous aborderons ici le problème du stockage des objets dans un support relationnel.
La mise en œuvre de la couche de persistance peut être appréhendée de différentes manières plus ou moins génériques.
L’approche la moins générique consiste à définir des méthodes de chargement, de sauvegarde et de mise à jour de la base de données pour chaque classe du modèle ainsi que des classes de recherche d’objets dans la base. Ces méthodes et classes sont codées en effectuant directement des appels à la base de données relationnelle dans les méthodes considérées. L’utilisation des fonctions d’accès à la base est alors disséminée dans toutes les méthodes assurant la persistance.
L’approche opposée consiste à extraire la problématique de la projection (ou mapping) entre le modèle objet et le modèle relationnel en séparant sa description de la définition des classes du modèle. Un module externe de mapping est alors utilisé pour effectuer le travail de façon générique et sans codage spécifique. Le framework utilisé doit permettre d’éviter l’écriture de toute ligne de code spécifique à la base de données utilisée.
Cette dernière approche offre beaucoup d’avantages :

+

la maintenabilité du code s’en trouve améliorée. Le code relatif à la persistance est localisé dans un module précis et n’est pas modifié au cours des différents cycles de vie du développement;

+

la taille du code global est réduite car le code de persistance, est complètement générique et n’est pas redistribué dans toute l’application;

+

la tâche des développeurs est facilitée car ils n’ont plus à se pencher sur les problématiques de persistance et peuvent se concentrer sur la résolution des problèmes métiers, seule valeur ajoutée d’un développement informatique;

+

la portabilité de l’application est améliorée : de nombreux frameworks de mapping objet relationnel permettent l’utilisation transparente de la majorité des SGBDR du marché.

Choix d’un outil de mapping

La définition de la correspondance des éléments du modèle objet avec ceux du modèle relationnel doit se faire simplement. Beaucoup de solutions utilisent des fichiers de configuration XML. Une interface graphique de configuration est un plus et il est souhaitable que celle-ci puisse s’intégrer dans l’environnement de développement utilisé par les équipes de projet.
Les outils de mapping peuvent être plus ou moins génériques et leur capacité à s’adapter à l’existant est un élément de choix important. En effet, la récupération d’informations stockées en base relationnelle peut s’avérer très complexe si l’outil de mapping impose des contraintes fortes sur le modèle relationnel utilisé.
La boîte à outils doit fournir les fonctionnalités de recherche, de chargement et de mise à jour des objets dans la base de données. Ces mécanismes doivent gérer correctement les problématiques de transactions et s’adapter à l’architecture du système d’information cible tel que le serveur applicatif utilisé. De plus, les spécifications des objets à extraire de la base de données doivent être codées au niveau de la couche d’objet métier. Il n’existe pas encore de langage universel tel que SQL pour écrire ces spécifications bien que OQL commence à voir le jour. Il faut que l’outil permette d’écrire des spécifications de recherche dans le langage cible des objets métiers si celui-ci ne supporte pas OQL. Toute autre possibilité imposera un apprentissage supplémentaire.
La description des types de données diffère d’un modèle à l’autre. L’outil de mapping doit permettre de traduire les différences entre les types de données objets et les types de la base relationnelle.

Suite ici

Nicolas Farges,
Responsable R&D - SQLI
*Nouvelles technologies de l’information et de la communication


Toutes les Chroniques du Net sont ici: Le Répertoire