Fig. 1.8 – Exemple d’utilisation d’Hibernate
génierie Dirigé par les Modèles (IDM). Pour la mise en œuvre du prototype de notre architecture de base de données, nous avons largement utilisé les techniques de l’IDM pour l’implémentation de chacune de ses composants [46, 128].
Dans la section suivante, nous présentons brièvement l’IDM que nous illustrons avec le langage EXPRESS.
3.5 Transformation de modèle et l’Ingénierie Dirigée par les Modèles
L’ingénierie des systèmes informatiques se base toujours sur des modèles. Pendant longtemps, les modèles ont seulement constitué une aide pour les utilisateurs humains, permettant de dé-velopper manuellement le code final des applications informatiques. L’approche de l’Ingénierie Dirigée par les Modèles (IDM) consiste à représenter les modèles comme instances d’un méta-modèle à traiter par programme les données ainsi constituées, et à les utiliser pour générer le code final des applications. Le MDA [10, 7] (Modèle Driven Architecture) de l’OMG est l’approche la plus connue d’ingénierie dirigée par les modèles. Le MDA est basé sur le standard UML pour la définition des modèles et sur l’environnement de méta-modélisation MOF (Meta-Object Facility) [63] pour la programmation au niveau modèle et la génération de code. Basé sur un ensemble de langages différents (UML, XML, OCL), MDA est une architecture lourde et difficile à maîtriser. Nous présentons dans la section suivante l’environnement d’IDM EXPRESS. Construit au-tour du langage EXPRESS [79, 143], cet environnement est au moins aussi ancien et mature que l’environnement basé sur les standards de l’OMG (UML, OCL, MOF, MDA et XMI). Il a un domaine d’application plus restreint, puisqu’il ne traite que les modèles de données et non les modèles de systèmes. Il est, par contre, beaucoup plus simple à mettre en œuvre car le même lan-gage, EXPRESS, peut être utilisé pour les différentes tâches impliquées dans une activité d’IDM : modélisation, méta-modélisation, instanciation et transformation de modèles. Nous exploiterons largement dans le chapitre 4, cet environnement pour le développement, par génération de code, du système de base de données à base ontologique réalisé au cours de notre thèse. Gérant de façon uniforme les données et les modèles, le système ainsi développé permettra également de montrer l’intérêt des concepts clés de l’IDM, de la méta modélisation et des actions au niveau
3. Gestion persistante des objets modèle, lorsqu’ils sont transposés au niveau de l’utilisateur final, qu’il soit utilisateur interactif ou programmeur d’application.
En EXPRESS, deux environnements existent pour faire de l’IDM : – transposition de modèle : EXPRESS-X,
– transformation de modèles : Programmation EXPRESS. Nous les présentons dans les deux sections suivantes. 3.5.1 Transposition de modèle : EXPRESS-X
EXPRESS-X est un complément déclaratif du langage EXPRESS (ISO 10303-14) [2] dont l’objectif est de permettre une spécification déclarative des relations de correspondances (map-ping ) existant entre des entités de différents schémas EXPRESS. Ce langage supporte deux types de constructions :
1. SCHEMA_VIEW qui permet de déclarer des vues sur les données d’un schéma EXPRESS ; 2. SCHEMA_MAP qui permet de déclarer des règles de transformation ("mapping") entre des entités ou des vues d’un (ou plusieurs) schéma(s) EXPRESS source(s) vers un (ou plusieurs) schéma(s) EXPRESS cible(s).
Dans l’exemple de la figure 1.9, nous déclarons un mapping pour faire migrer les instances du schéma de la figure 1.3 en des instances du schéma person (première colonne du tableau). La deuxième colonne du tableau montre la déclaration du mapping. Il transforme les instances de l’entité salarié en des instances d’entités employee de la manière suivante :
– le noSS de salarié correspond à l’attribut id de l’entité employee ;
– l’attribut name de l’entité employee est la concaténation des attributs nom et prénom de l’entité salarié.
– l’attribut good_salary de type BOOLEAN est dépendant de l’attribut salaire de l’entité salarié. La valeur de l’attribut est VRAI si la valeur de l’attribut salaire est supérieur à 1999 et FAUX dans le cas contraire.
La dernière colonne du tableau montre l’application du mapping sur deux instances de l’entité salarié. Si ce langage est essentiellement déclaratif, on peut néanmoins utiliser toute la puissance du langage procédural pour calculer des attributs (dérivés) du schéma source destinés a être transposés dans le schéma cible.
3.5.2 Programmation EXPRESS et transformation de modèles
Les environnements de modélisation EXPRESS permettent soit de coder un programme dans un langage classique (C, C++, JAVA) en utilisant des interfaces normalisées pour accéder aux données (niveau modèle et niveau instance) associées à un modèle EXPRESS, soit de coder un programme directement dans le langage procédural associé à EXPRESS. Si la première ap-proche est adaptée pour certains types de programmes, elle présente l’inconvénient de nécessiter la connaissance à la fois d’EXPRESS et d’un langage de programmation. De plus, l’intégra-tion d’EXPRESS dans un langage de programmal’intégra-tion pose les problèmes usuels qu’impliquent
SCHEMAPerson ;
ENTITYEmployee;
id : NUMBER; name : STRING; good_salary : BOOLEAN;
UNIQUEur1 : id;
END_ENTITY;
END_SCHEMA
Schéma cible
(*Instances du schéma de source*)
#2 = SALAIRE(13457,‘Jean’, ‘Hondjack’ , 27, #3, 1000); #3 = SALAIRE(23215,‘Jean’, ‘Nathalie’, 25, #2, 2500);
(*Résultats de mapping *)
#502 = EMPLOYEE(13457, ‘Jean Hondjack’, ‘FALSE’); #503 = EMPLOYEE(23215, ‘Jean Nathalie’, ‘TRUE’);
SCHEMA_MAP mapping_exemple;
REFERENCE FROMUniversitaire AS SOURCE;
REFERENCE FROMPersonAS TARGET;
MAP U_Salarié_mapASemp : Employee;
FROM sal : Salarié;
SELECT
emp.id :=sal.noSS; emp.name:=sal.nom_prenom; emp.good_salary:= is_good(sal.salaire);
END_MAP;
FUNCTION is_good (salaire : REAL) : BOOLEAN;
IF salaire > 1999THEN RETURN TRUE
ELSE RETURN FALSE;
END_IF; END_FUNCTION; END_SCHEMA; Instances de données Schéma de mapping SCHEMAPerson ; ENTITYEmployee; id : NUMBER; name : STRING; good_salary : BOOLEAN;
UNIQUEur1 : id;
END_ENTITY;
END_SCHEMA
Schéma cible
(*Instances du schéma de source*)
#2 = SALAIRE(13457,‘Jean’, ‘Hondjack’ , 27, #3, 1000); #3 = SALAIRE(23215,‘Jean’, ‘Nathalie’, 25, #2, 2500);
(*Résultats de mapping *)
#502 = EMPLOYEE(13457, ‘Jean Hondjack’, ‘FALSE’); #503 = EMPLOYEE(23215, ‘Jean Nathalie’, ‘TRUE’);
SCHEMA_MAP mapping_exemple;
REFERENCE FROMUniversitaire AS SOURCE;
REFERENCE FROMPersonAS TARGET;
MAP U_Salarié_mapASemp : Employee;
FROM sal : Salarié;
SELECT
emp.id :=sal.noSS; emp.name:=sal.nom_prenom; emp.good_salary:= is_good(sal.salaire);
END_MAP;
FUNCTION is_good (salaire : REAL) : BOOLEAN;
IF salaire > 1999THEN RETURN TRUE
ELSE RETURN FALSE;
END_IF; END_FUNCTION; END_SCHEMA;
Instances de données Schéma de mapping
Fig. 1.9 – Exemple de transformation de modèle avec EXPRESS-X.
les conversions de types (impédance mismatch) . La seconde permet, par contre, une prise en main rapide qui permet d’exploiter un modèle EXPRESS dans un environnement homogène de développement. Le langage procédural associé à EXPRESS n’est pas complet. Pour en faire un langage complet de programmation, il ne lui manque que deux fonctions :
– les primitives d’entrée/sortie (read/write) ;
– la primitive ("run") permettant de demander l’exécution d’une procédure.
Tous les environnements existants l’enrichissent de ces deux primitives pour en faire un langage de programmation à part entière permettant de réaliser un environnement simple à mettre en œuvre. Ce langage permet alors de réaliser à la fois :
– le développement d’un modèle conceptuel ;
– la spécification de l’ensemble des contraintes d’intégrités ;
– la manipulation et les transformations de modèles et d’instances.
3.5.3 Environnements d’IDM en EXPRESS
Différents environnements existent. Certains permettent de rendre persistante les instances créées. Par exemple l’environnement ECCO [147] génère à partir de la compilation de modèle EXPRESS une application C++ qui représente automatiquement toutes les instances EXPRESS sous forme d’instances C++, et toutes les contraintes sous forme de méthodes C++. Le schéma est lui-même, représenté sous forme d’instances C++ d’un méta-schéma. Cette application, qui comporte en particulier les fonctions de lecture/écriture de fichiers physiques, peut être exploi-tée par une interface graphique, par une API utilisable en C, C++, et Java et directement en EXPRESS par une application compilée avec le modèle. Une fois les traitements effectués, les instances doivent être sauvegardées sous forme d’un fichier physique pour être conservées.
D’autres environnements, tel que EXPRESS Data Manager (EPM Technology), sont liés à une base de données. Toute compilation d’un schéma EXPRESS génère automatiquement le schéma de base de données correspondant, les contraintes assurant l’intégrité de la base et l’interface
4. Limites des méthodes classiques de conception des bases de données SDAI permettant d’accéder à la fois aux schémas et aux instances.
4 Limites des méthodes classiques de conception des bases de
données
A l’issue du bref état de l’art de l’art présenté jusque là sur les méthodes actuelles de concep-tion de bases de données, il nous parait important de souligner deux difficultés majeures aux-quelles elles donnent lieu. Ceci nous permettra alors de fonder la principale proposition que nous développerons dans cette thèse, à savoir représenter explicitement la sémantique des données dans les bases de données.
4.1 Les problèmes
Dans la section 1.2, nous avons vu que la conception de bases de données était un processus qui se déroulait en trois étapes allant (1) de la conception du modèle conceptuel, (2) à l’élabo-ration du modèle logique et enfin (3) à la définition de vues utilisateur. La mise en œuvre de ce processus présente, en particulier dans le contexte d’évolution des formalismes de modélisation de l’information et de gestion des données vus aux sections 1 et 3, deux inconvénients de plus en plus significatifs :
1. l’écart existant en général entre les modèles conceptuels et les modèles logiques des données, qui s’accroit avec la divergence des formalismes.
2. la très forte dépendance des modèles vis-à-vis des concepteurs et des besoins applicatifs particuliers, ce qui rend difficile les activités d’intégration indispensables dans les sociétés modernes d’information et de communication.
4.1.1 L’écart entre les modèles conceptuels et les modèles logiques des données L’un des objectifs essentiel de la modélisation conceptuelle est de permettre le développement d’un modèle logique de données qui permettra la création d’une base de données. Le passage du modèle conceptuel au modèle logique, nécessite, comme nous l’avons vu, des opérations de traduction complexes. Le modèle logique résultant de cette traduction est alors très différent du modèle conceptuel initial. Les entités et les associations sont éclatées en de multiples tables (dans le cas des bases de données relationnelles). Le modèle logique résultant peut, très vite devenir incompréhensible (surtout pour des grands modèles conceptuels conséquents), pour un utilisateur et ne permet plus alors d’appréhender le problème traité. Ceci impose, en général, de recoder dans tous les différents applicatifs d’accès, l’ensemble des concepts existants initialement dans le modèle conceptuel. Même si des techniques d’Ingénierie Dirigée par les Modèles, ou les outils tels que PowerAMC de Sybase ou Hibernate [70] peuvent aider dans ce travail, il s’agit toujours de développement très important, coûteux et difficile à maintenir.
4.1.2 Forte dépendance des modèles vis à vis des concepteurs et des objectifs ap-plicatifs
Comme nous l’avons déjà mentionné, le modèle conceptuel d’un univers quelconque est spé-cifique des questions très précises auxquelles on souhaite que le système puisse répondre. En d’autres termes, le modèle conceptuel dépend étroitement de l’objectif applicatif du système en cours de développement. Cela aboutit donc à des modèles conceptuels qui seront toujours différents, même s’ils adressent essentiellement le même domaine et ce, sans qu’il soit possible d’identifier par des moyens automatiques, ceux des concepts qui se correspondent, et ceux qui sont effectivement différents.
Les bases de données qui résulteront de ces différents modèles conceptuels seront alors force-ment hétérogènes et occasionneront de nombreux problèmes lors de toute tentative d’intégration future des données contenues dans ces bases de données [18, 16, 20, 27, 92, 162]. Kim et al. [93] présente les différentes incohérences, sous le nom de conflits, pouvant exister entre sources de données résultant de deux modèles conceptuels différents d’un même domaine. Les principaux conflits sont les suivants.
1. Les conflits de nommage interviennent lorsqu’un même concept C de deux modèles concep-tuels est nommé différemment. Par exemple : dans un MC, on peut rencontrer le concept de salarié et le concept de employé dans un autre.
2. Les conflits de subsomption intervient lorsqu’une hiérarchie de classes est différente d’un modèle à un autre. Par exemple : dans M C1, la classe élève est subsumée la classe personne et dans M C2, élève est subsumé étudiant.
3. Les conflits de structure interviennent lorsqu’une classe n’est pas décrite par les mêmes propriétés d’un MC à un autre. Par exemple dans M C1, personne est décrite par les propriétés : id, nom, prénom, adresse et dans M C2par id, nom, prénom, téléphone, télécopie. 4. Les conflits de granularité d’un concept interviennent qu’un concept C est décrit comme une classe dans un modèle conceptuel et comme un attribut dans un deuxième modèle. Par exemple adresse dans M C1 est décrite comme une classe et dans M C2 comme une propriété de la classe personne (id, nom, adresse)
5. Les conflits de type de propriétés intervient lorsque une propriété P possède des domaines différents entre deux modèles conceptuels. Par exemple, la propriété sexe dans M C1 a pour type STRING ("F" = féminin et "M" = masculin) et dans M C2 a pour type ENTIER (0 = féminin et 1 = masculin).
6. Les conflits de granularité d’attributs interviennent lorsqu’un attribut est décrit de façon atomique dans un modèle conceptuel et composé dans un autre. Par exemple, dans la classe personne de M C1, on a deux propriétés distinctes nom et prénom et dans M C2 une propriété nom_prénom qui compose le nom et le prénom.
7. Les conflits d’unité de mesures interviennent lorsque les valeurs des propriétés sont dans des unités différentes (décrites formellement ou de façon informelle suivant la richesse du formalisme de représentation) d’un modèle à un autre. Par exemple la mesure de la propriété salaire de la classe salarié est en euro et dans M C2 la mesure est en CFA2.
2
4. Limites des méthodes classiques de conception des bases de données 8. Les conflits d’identificateurs d’objets interviennent lorsque l’identifiant d’un classe (qui peut
être un ensemble de propriétés) est différent d’un modèle à un autre.
9. Les conflits de contraintes d’intégrités interviennent lorsqu’une propriété identique dans deux modèles différents est associée à des contraintes d’intégrités différentes. Par exemple le salaire d’un salarié dans le modèle M C1 est inférieur à 10000(implicitement exprimé en euros) et dans le modèle M C2 est inférieur 1000000.
10. Les conflits de contextes interviennent lorsqu’un concept est perçu différemment d’un mo-dèle conceptuel à un autre. Cette différence est souvent dû à des objectifs légèrement différents des systèmes cibles. Par exemple le concept prix est considéré dans le modèle M C1 selon le point de vue TTC et dans le modèle M C2, il est vue selon l’aspect HT.
Les conflits évoqués ci-dessus résultent du fait qu’un modèle conceptuel est seulement consi-déré comme une étape intermédiaire dans la définition d’une base de données, elle-même struc-turée en fonctions des objectifs applicatifs du système cible. Le modèle conceptuel est donc crée de façon isolé. Il contient exclusivement ce qu’il apparaît pertinent au concepteur de représenter effectivement. Cette représentation est effectuée selon une structure qui dépend beaucoup des spécificités du concepteur. Deux modèles conceptuels conçus par deux équipes différentes pour deux systèmes visant à remplir la même fonction dans le même domaine seront donc toujours :
– partiellement différents du point de vue du domaine exact modélisé, – très différents du point de vue de la structure du modèle résultant.
Les modèles logiques seront alors encore plus différents, et nécessiteront un énorme travail manuel d’intégration sémantique, chaque fois qu’il faudra intégrer deux de ces bases de données.
4.2 Une solution : représenter la sémantique des données
Ces deux problèmes ci-dessus résultent de deux conséquences des méthodes traditionnelles de conception des bases de données.
(1) Les modèles conceptuels ne sont plus accessibles lorsque la base de données est achevée. (2) Chaque modèle conceptuel est spécifique à un projet de conception d’une base de données. Pour éviter la première conséquence, il est alors apparu intéressant de donner plus de place et d’autonomie à la notion de modèle conceptuel pour permettre sa représentation effective dans une base de données. Différents travaux menés au cours des années 1990, ont visé à atteindre cet objectif [153, 110]. Cela permettrait de faire abstraction du modèle logique au moyen de programmes qui accédaient directement aux modèles conceptuels. Pour atteindre cet objectif, il était nécessaire de :
– trouver une représentation des modèles conceptuels dans la base de données pour qu’ils puissent être accessibles,
– d’établir une liaison entre le modèle logique et le modèle conceptuel représenté dans la base de données.
Aucune représentation formelle des modèles conceptuels n’étant alors disponible, ces travaux n’ont pas entraîné de réelle évolution des pratiques de conception. Quoi qu’il en soit, ils n’au-raient pas permis de résoudre les problèmes d’intégration qui nécessitent qu’en plus, les modèles conceptuels soient aussi, pour leurs parties communes consensuelles.
Ce sont ces deux difficultés qui vont être levées par les ontologies. En effet, une ontologie définit de façon formelle, explicite et consensuelle l’ensemble des concepts partagés d’un domaine. – Formel signifie qu’elle est définie dans un langage traitable par machine. Les ontologies
seront donc représentables.
– Consensuelle signifie qu’elle est acceptée par les membres d’une certaine communauté. Tous les concepts partagés pourront donc être modélisés à l’identique par tous les membres de cette communauté, qui peut être, avec les ontologies normalisées, l’ensemble d’un secteur professionnel.
– Explicite signifie que le domaine modélisé est décrit indépendamment d’un point de vue ou d’un contexte implicite. Plusieurs points de vues, légèrement différents pourront donc partagés les mêmes concepts.
Un modèle conceptuel peut être représenté comme un sous-ensemble (fragment) d’une onto-logie. C’est la raison pour laquelle nous proposons dans cette thèse :
1. De promouvoir le développement d’ontologies partagées (OP) de domaine, au moins dans les domaines où les problèmes d’intégration de bases de données peuvent être anticipés (étape 1 figure 1.10).
2. De précéder de développement d’un modèle conceptuel (MC) par le développement d’une ontologie locale (OL) utilisant un formalisme standard de modélisation d’ontologie et conçue, si elle existe, par l’emprunt d’une ontologie (ou plusieurs) ontologies partagées (étape 2 figure 1.10).
3. De représenter un modèle conceptuel comme un sous-ensemble de l’ontologie locale (étape 3 figure 1.10).
4. De représenter l’ontologie locale, le modèle conceptuel et les données au sein de la même base de données (étapes 4, 5, 6 figure 1.10).
Nous appelons ce type de bases de données des bases de données à base ontologique, et nous proposons dans ce travail un modèle d’architecture appelé OntoDB, qui montre la faisabilité d’une telle implémentation.
5 Conclusion
Nous avons vu dans ce chapitre les différentes approches de modélisation de l’information et de leurs représentations dans des bases de données. Concernant la modélisation de l’informa-tion, deux grandes approches sont actuellement utilisées dans la littérature : l’approche entité-association et l’approche objet. L’approche objet, qui se généralise aujourd’hui, consiste à hiérar-chiser des catégories par des relations de subsomption associées à un mécanisme d’héritage. Les
5. Conclusion
Fig. 1.10 – Methodologie de conception de bases de données à l’aide d’ontologie
classes sont caractérisées par des propriétés qui peuvent être de types complexes. Elles peuvent également être associées à de la connaissance procédurale exprimée sous forme de contraintes, de règles et/ou de méthodes. Ces différents mécanismes permettent de modéliser de façon de plus en plus fine la connaissance d’un domaine.
Concernant la persistance des données, essentiellement deux approches existent : le modèle relationnel et le modèle objet. Le modèle relationnel, basé sur l’algèbre relationnelle, est un sys-tème efficace, simple, mature et normalisé. Il bénéficie d’excellentes performances résultant de nombreuses années d’expériences, de fondements mathématiques solides et d’un grand succès commercial. Le modèle de base de données objet, apparu suite au succès de la modélisation ob-jet, permet de rendre persistants des objets. Les systèmes de bases de données objets n’ont pas connu le même succès que la modélisation objet. Les systèmes de bases de données relationnelles semblent avoir repris le dessus grâce à leur performance et à leur maturité industrielle, même s’ils s’ouvrent progressivement, et en ordre dispersé, à l’introduction de quelques concepts objets dans le relationnel à travers l’implantation progressive de la norme SQL99.