| Investigations |
Bienvenue ! |
|
| Aide |
|
| Table des matières |
|
|
Section 3 Ce modèle est en cours de révision et d'extension; la définition provisoire peut être trouvée sur le site web d'ODMG. Ce standard se compose de trois volets: un modèle objet propre, regroupant les caractéristiques communes aux langages cibles ; C++, Smalltalk et depuis peu Java. Cette définition est riche, en ce qu'elle doit entre autres définir des concepts de collections d'objets pour désigner les résultats de requête. Dans un second temps, un langage permettant de décrire les objets des différents langages supportés ainsi que les relations entre eux, en terme du modèle objet d'ODMG. À l'inverse, les collections du modèle objet d'ODMG doivent être implantés ou mis en correspondance avec des implantations propres aux langages spécifiques. Finalement, un langage de description de requêtes d'objets correspondant à SQL, et appelé OQL. Tentons de survoler les principales caractéristiques de ces composantes: Modèle objetLe modèle de base est un modèle classique à héritage multiple où les interfaces des objets sont découplées des implantations des objets dans les différents langages. Ce modèle est donc un peu plus riche que ce que permet Java (ou l'héritage de code est simple) mais fondamentalement compatible. Les objets sont créés via une fabrique (Factory), sont désignés comme transients ou persistants et les relations entre les objets doivent toujours être définies en paires inverses afin que les pointeurs puissent être traversés dans les deux directions. Les objets ont des identificateurs uniques permanents et peuvent être nommés ou indexés sur une ou plusieurs de leurs propriétés. Pour chaque type d'objets (classe), on peut demander l'extension de la classe, soit l'ensemble des objets de cette classe ou un sous-ensemble de cette extension qui prendra la forme d'une des classes de Collection d'objets (classes paramétrées par la classe de l'objet lui-même). Ces collections peuvent prendre un des formes suivantes: Bag, Set, List, Array, Dictionary. (Les définitions sont connues. Toutes les collections peuvent être parcourues et les Bag et Set permettent les opérations classiques d'union, d'intersection et de différence). La structure des types forme un ensemble de metadata, lui-même stocké dans la base de données. Le modèle définit aussi un modèle de transaction qui doit être atomique, consistante en tout temps, isolé des autres transactions, et durable. ODLODL permet de décrire les interfaces d'une classe de manière indépendante du langage. À partir d'une telle description, une base de données qui suit le standard ODMG devrait automatiquement pouvoir déduire une représentation interne utilisable des objets décrits et les stocker. De plus, il devrait être aisé de réimplanter un tel objet dans un autre langage orienté-objet. ODL est en fait une extension de la syntaxe d'IDL adaptée au modèle objet d'ODMG, légèrement plus étendu que celui de CORBA à cause, entre autres, de la définition des classes de collection. ODL englobe la fonctionnalité des syntaxes de description de modèles objets suivants: STEP/PDES (EXPRESS), ANSI X3H2 (SQL), ANSI X3H7 (Object Information Management), CFI (CAD Framework Initiative) et d'autres. OQLOQL est un parent de SQL 92 qui permet la spécification de groupe d'objets par des requêtes complexes et l'appel de méthodes sur ces objets. Les requêtes OQL renverront une collection d'objets (ou de types élémentaires, ou de " structures " rassemblant plusieurs types), la nature de la collection (bag, set ou list) étant déterminée par l'utilisation de clauses d'unicité (select distinct, etc. ) et/ou de tri. Les résultats peuvent aussi être groupés en plusieurs bags nommés. Les prédicats peuvent être très élaborés, la syntaxe permettant des opérateurs d'inclusion entre les ensembles, et même des quantificateurs. Ce qui fait vraiment la force du langage, c'est la possibilité de faire appel aux méthodes des objets à tout moment dans une expression OQL, que ce soit pour sélectionner des objets ou pour accomplir un effet de bord dans la base de données. Couplage avec JavaLa définition par ODMG du couplage avec Java n'est pas encore complètement défini. Manque encore, par exemple, la syntaxe permettant de barrer des objets avant modifications. Pour la base, le consortium a employé une règle minimaliste: Tout objet peut être attaché par un nom à une base de données et tous les objets reliés à cet objet racine seront alors enregistrés du même coup. Il est possible d'exclure certains liens du stockage automatique. Pour toute classe, il est possible de demander l'extension de la classe ou une partie de celle-ci correspondant à un prédicat. C'est la partie la plus délicate: des comportements doivent être ajoutés au niveau de chacune des classes existantes, sans modification au code de celles-ci. ODMG propose trois moyens d'y parvenir: éditer le code Java à l'aide d'un préprocesseur, éditer les fichiers compilés directement, ou proposer son propre interpr éteur Java. Le choix de l'implantation est laissé au vendeur. Il doit être souligné que chacune de ces options pose des problèmes particuliers. Ainsi, les clients Web ne bénéficieront certainement pas d'un interpréteur modifié; la modification au code source ou compilé peut interférer avec d'autres mécanismes utilisant les même moyens pour modifier le code; etc. D'autre part, les notions de Database, Transaction et Query ont été définies comme des classes, alors que les collections sont des interfaces. (Le Vector de Java peut être substitué à la notion d'array de ODMG.) Notons pour finir que même si le standard n'est pas complet, plusieurs membres du consortium ODMG ne l'ont pas attendu pour offrir des couplages de Java à leurs bases de données orientées-objet qui utilisent la définition en cours. Nous y reviendrons dans les sections relatives à chaque développeur.
|
 HAUT
Mise à jour de ce document - 12 novembre 1997 |