Bibliographie & annexes
Présentation
Auteur(s)
-
Martial CHRISMENT : Ingénieur en informatique de l’École nationale supérieure d’électronique, d’électrotechnique, d’informatique et d’hydraulique de Toulouse (ENSEEIHT) Société TOOL OBJECT
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleINTRODUCTION
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).
L'expertise technique et scientifique de référence
VERSIONS
- Version courante de févr. 2012 par Martial CHRISMENT
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
Présentation5. Conclusion
La transposition d’un modèle objet en relationnel risque de rester encore pour quelques temps un problème d’actualité. En attendant une solution « clé en main », il est nécessaire de mettre en œuvre dès à présent des règles de transposition similaires à celles décrites dans cet article. Les outils de génération de structure et de classes restent des outils d’accompagnement très efficaces.
Cette approche permet aussi d’aller plus loin dans le concept de séparation des couches applicatives (concernant notamment la couche « données ») car elle permet d’encapsuler les accès aux données dans des méthodes bien définies. Changer le support de stockage — comme passer d’un stockage BD à un stockage fichier — n’en est que plus facile.
Enfin, cette approche est vraiment primordiale pour les applications de gestion — et notamment bancaire — qui manipulent d’importants volumes de données. Elle procure aussi une réactivité plus forte vis-à-vis des besoins des clients, ce qui est de plus en plus important dans le contexte actuel où tout évolue en permanence.
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Conclusion
BIBLIOGRAPHIE
-
(1) - GRIMES (S.) - Modeling Object/Relational Databases. - Avr. 1998.http://dbmsmag.com/9804d13.html
-
(2) - MULLER (P.A.), GAERTNER (N.) - Modélisation objet avec UML. - Eyrolles (2000).
-
(3) - MARÉE (C.), LEDANT (G.) - SQL 2 Initiation Programmation. - Armand Colin (1994).
-
(4) - FLANAGAN (D.) - Java in a nutshell. - O’Reilly (2000).
-
(5) - SOUTOU (C.) - Objet‐relationnel sous Oracle8. - Eyrolles (1999).
DANS NOS BASES DOCUMENTAIRES
ANNEXES
(liste non exhaustive)
Rational http://www.rational.com
Popkin Software http://www.popkin.com
Softeam http://www.objecteering.com
Cognicase http://www.cognicase.com
HAUT DE PAGE
L'expertise technique et scientifique de référence
Cet article fait partie de l’offre
Technologies logicielles Architectures des systèmes
(239 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
