Conclusion
Transposition d’un modèle objet dans un contexte relationnel

La programmation objet est à l’heure actuelle incontournable dans le monde industriel, comme le montre la place de plus en plus importante accordée à des technologies telles que Java, C++, EJB (Enterprise Java Bean), Corba ou DCOM (Distributed COM). En effet, ce type de programmation a l’avantage de rester proche de la conception et facilite à la fois la maintenance et l’évolutivité.

Même si, dans un modèle d’architecture 3-tiers (séparation de la présentation, du traitement et des données), les concepts objet sont aussi présents dans la couche « présentation » (par exemple, à travers la notion de Java Bean), leur couche de prédilection demeure cependant la couche « traitement » où réside le cœur même du métier. La couche « données » reste, quant à elle, très en retard dans ce domaine. Les systèmes de gestion de bases de données purement objet sont peu nombreux sur le marché, alors que les systèmes de gestion de bases de données relationnelles intégrant des concepts objet (relationnel orienté objet [1]) restent encore immatures en occultant très souvent les problématiques d’héritage.

Le problème de transposition d’applications conçues avec une approche objet et destinées à être implantées dans un contexte relationnel est, de ce fait, de plus en plus récurrent au sein des entreprises. Pour y pallier, on a souvent recours à la mise en œuvre de requêtes SQL (Standard Query Language) spécifiques qui ne tiennent pas compte du modèle objet de départ. Bien que relativement efficace, cette solution rend plus complexe toute évolution du modèle objet car les impacts au niveau de la couche « données » sont difficiles à évaluer et rarement négligeables.

Une solution intéressante consiste en la définition de règles de transposition du modèle objet en modèle relationnel, tant au niveau statique (définition des tables relationnelles) qu’au niveau dynamique (méthodes d’accès aux données).