Système d'accès à des Bases de Données Hétérogènes réparties en vue d'une aide à la décision (SABaDH)

Transcription

1 N d ordre Année 1998 Thèse Système d'accès à des Bases de Données Hétérogènes réparties en vue d'une aide à la décision (SABaDH) Présentée devant L institut national des sciences appliquées de Lyon Pour obtenir Le grade de docteur Formation doctorale : Informatique École doctorale : École doctorale IIS Par Cécile NICOLLE (Ingénieur) Soutenue le décembre 2001 devant la Commission d examen Jury MM. Y. AMGHAR Maître de Conférence - HDR (INSA de Lyon) Rapporteur P. BAZEX Professeur (IRIT - UPS) Rapporteur C. BERRUT Chargé de recherche (CLIPS - IMAG, Grenoble) B. CHABBAT CNEDI de Lyon J-M. PINON Professeur (INSA de Lyon) Président V. PRINCE Professeur (LIRMM)

2 Système d'accès à des Bases de Données Hétérogènes réparties en vue d'une aide à la décision Résumé De nos jours, un décideur doit faire face à de nombreuses données, de types très variés, avant de prendre une décision. Il n'est alors pas aisé de trier les informations qui lui sont utiles, ni de déterminer où chercher lesdites informations. Les systèmes d'aide à la décision procurent une aide précieuse dans la recherche des informations pertinentes à une prise de décision. Néanmoins, il faut tenir compte de nombreux facteurs lors de l'élaboration d'un tel système. En effet, les données sont nombreuses, hétérogènes (textuelles, structurées, image, son, alphanumériques, etc.) et le décideur n'a pas toujours la connaissance requise pour trouver toutes les données pertinentes. Nous proposons un système qui permet de prendre en compte les bases de données existantes ainsi que l'ajout de nouvelles bases, tout en offrant au décideur la possibilité de rechercher des informations sans avoir une connaissance spécifique dans le domaine de recherche. Nous nous basons sur le principe des wrappers et médiateurs ainsi que sur le langage XML afin de rendre le système le plus générique possible. Mots-Clés: bases données hétérogènes, système accès, XML, médiateur, wrapper, aide à la décision, structure donnée, base connaissance Architecture of Access system of heterogeneous database for decision making Abstract Since all time, for decision making, decider had to be faced with access problem of all needed data to take the better decision. Nowadays, most systems provide help for this decision making. But it's always difficult to know where the decider can find relevant data. Furthermore, decider can't know type of all data which he need to make his decision. That's why we propose an architecture of an access system which allows decider ask his request in language like natural language, without more detail about their location. Our system can find this data, and provides all information in relation with searched data, these information being relevant. Our system can alleviate some deficiency about search domain. Our system uses wrapper principle, and XML as internal language and request and answer language. Two prototype have been realized, one about search in legal texts base, the other about XML interrogation of Progress base with answer in XML. Mots-Clés: heterogeneous data, access system, XML, wrapper, mediator, knowledge base, decision making, structured data. 2 / 124

3 INSA DE LYON DEPARTEMENT DES ETUDES DOCTORALES SEPTEMBRE 2000 ECOLES DOCTORALES ET DIPLOMES D ETUDES APPROFONDIES HABILITES POUR LA PERIODE ECOLES DOCTORALES N code national RESPONSABLE PRINCIPAL CORRESPONDANT INSA DEA INSA N code national RESPONSABLE DEA INSA CHIMIE DE LYON (Chimie, Procédés, Environnement) EDA206 M.D. SINOU UCBL sec Fax M.P. MOSZKOWICZ Sec Fax Chimie Inorganique Sciences et Stratégies Analytiques M.J.F.QUINSON Tél Fax Sciences et Techniques du Déchet M. P.MOSZKOWICZ Tél Fax ECONOMIE ESPACE ET MODELISATION DES COMPORTEMENTS (E 2 MC) EDA417 M A.BONNAFOUS LYON Sec Fax Mme M.ZIMMERMANN Fax Ville et Sociétés Dimensions Cognitives et Modélisation Mme M.ZIMMERMANN Tél Fax M. L.FRECON Tél Fax ELECTRONIQUE, ELECTROTECHNIQUE, AUTOMATIQUE (E.E.A.) EDA160 M. G.GIMENEZ INSA de LYON Fax Automatique Industrielle Dispositifs de l Electronique Intégrée Génie Electrique de Lyon M. M. BETEMPS Tél Fax M. D.BARBIER Tél Fax M. J.P.CHANTE Tél Fax Images et Systèmes Mme I.MAGNIN Tél Fax EVOLUTION, ECOSYSTEME, MICROBIOLOGIE, MODELISATION (E2M2) EDA403 INFORMATIQUE ET INFORMATION POUR LA SOCIETE EDA 407 INTERDISCIPLINAIRE SCIENCES- SANTE (EDISS) EDA205 MATERIAUX DE LYON UNIVERSITE LYON 1 EDA 034 M. J.P.FLANDROIS UCBL Sec Fax M. J.M.JOLION INSA de LYON Fax M. A.J.COZZONE UCBL Sec Fax M. J.JOSEPH ECL Sec Fax M. S.GRENIER Fax M. M.LAGARDE Fax M. J.M.PELLETIER Fax Analyse et Modélisation des Systèmes Biologiques Documents Multimédia, Images et Systèmes D Information Communicants Extraction des Connaissances à partir des Données Informatique et Systèmes coopératifs pour l Entreprise Biochimie Génie des Matériaux : Microstructure, Comportement Mécanique, Durabilité Matériaux Polymères et Composites M. S.GRENIER Tél Fax M. A.FLORY Tél Fax M. J.F.BOULICAUT Tél Fax M. A.GUINET Tél Fax M. M.LAGARDE Tél Fax M. R.FOUGERES Tél Fax M. H.SAUTEREAU Tél Fax Matière Condensée, Surfaces et Interfaces M. G.GUILLOT Tél Fax MATHEMATIQUES ET INFORMATION FONDAMENTALE (Math IF) EDA 409 MECANIQUE, ENERGETIQUE, GENIE CIVIL, ACOUSTIQUE (MEGA) EDA162 M. NICOLAS UCBL Fax M. J.BATAILLE ECL Sec Fax M. J.POUSIN Fax M. M.MIRAMOND Fax Analyse Numérique, Equations aux dérivées partielles et Calcul Scientifique Acoustique Génie Civil Génie Mécanique Thermique et Energétique M. G.BAYADA Tél Fax M. J.L.GUYADER Tél Fax M. M.MIRAMOND Tél Fax M. G.DALMAZ Tél Fax Mme M.LALLEMAND Tél Fax En grisé : Les Ecoles Doctorales et DEA dont l'insa est établissement principal 3 / 124

4 INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON Directeur : A. STORCK AUDISIO S PHYSICOCHIMIE INDUSTRIELLE BABOUX JC GEMPPM* BALLAND B PHYSIQUE DE LA MATIERE BARBIER D PHYSIQUE DE LA MATIERE BASTIDE JP THERMODYNAMIQUE APPLIQUEE BAYADA G MAPLY - MATHÉMATIQUES APPLIQUÉES DE LYON BERGER C (Mlle) PHYSIQUE DE LA MATIERE BETEMPS M AUTOMATIQUE INDUSTRIELLE BLANCHARD JM LAEPSI *** BOISSON C VIBRATIONS ACOUSTIQUES BOIVIN M MECANIQUE DES SOLIDES BOTTA H Equipe DEVELOPPEMENT URBAIN BOTTA-ZIMMERMAN M (Mme) Equipe DEVELOPPEMENT URBAIN BOULAYE G (Prof. émérite) INFORMATIQUE BRAU J CENTRE DE THERMIQUE DE LYON Thermique du bâtiment BRISSAU M GENIE ELECTRIQUE ET FERROELECTRIQUE BRUNET M MECANIQUE DES SOLIDES BRUNIE L INGENIERIE DES SYSTEMES D INFORMATION BUREAU JC THERMODYNAMIQUE APPLIQUEE CAVAILLE JY GEMPPM* CHANTE JP CEGELY**** - Composants de puissance et applications CHOCAT B UNITE DE RECHERCHE EN GENIE CIVIL Hydrologie urbaine COUSIN M UNITE DE RECHERCHE EN GENIE CIVIL Structures DOUTHEAU A CHIMIE ORGANIQUE DUFOUR R MECANIQUE DES STRUCTURES DUPUY JC PHYSIQUE DE LA MATIERE EMPTOZ H RECONNAISSANCE DES FORMES ET VISION ESNOUF C GEMPPM* EYRAUD L (Prof. émérite) GENIE ELECTRIQUE ET FERROELECTRIQUE FANTOZZI G GEMPPM* FAVREL J PRISMa PRoductique et Informatique des Systèmes Manufacturiers FAYARD JM BIOLOGIE FONCTIONNELLE, INSECTES ET INTERACTIONS FAYET M MECANIQUE DES SOLIDES FERRARIS-BESSO G MECANIQUE DES STRUCTURES FLAMAND L MECANIQUE DES CONTACTS FLEISCHMANN P GEMPPM* FLORY A INGENIERIE DES SYSTEMES D INFORMATION FOUGERES R GEMPPM* FOUQUET R GEMPPM* FRECON L INFORMATIQUE GERARD JF MATERIAUX MACROMOLECULAIRES GIMENEZ G CREATIS** GOBIN P.F. (Prof. émérite) GEMPPM* GONNARD P GENIE ELECTRIQUE ET FERROELECTRIQUE GONTRAND M GEGELY**** - Composants de puissance et applications GOUTTE R (Prof. émérite) CREATIS ** GRANGE G GENIE ELECTRIQUE ET FERROELECTRIQUE GUENIN G GEMPPM* GUICHARDANT M BIOCHIMIE ET PHARMACOLOGIE GUILLOT G PHYSIQUE DE LA MATIERE GUINET A PRISMa PRoductique et Informatique des Systèmes Manufacturiers GUYADER JL VIBRATIONS ACOUSTIQUES GUYOMAR D GENIE ELECTRIQUE ET FERROELECTRIQUE JACQUET-RICHARDET G MECANIQUE DES STRUCTURES JOLION JM RECONNAISSANCE DES FORMES ET VISION JULLIEN JF UNITE DE RECHERCHE EN GENIE CIVIL Structures JUTARD A (Prof. émérite) AUTOMATIQUE INDUSTRIELLE KASTNER R UNITE DE RECHERCHE EN GENIE CIVIL Géotechnique KOULOUMDJIAN J INGENIERIE DES SYSTEMES D INFORMATION LAGARDE M BIOCHIMIE ET PHARMACOLOGIE LALANNE M (Prof. émérite) MECANIQUE DES STRUCTURES LALLEMAND A CENTRE DE THERMIQUE DE LYON Energétique et thermique LALLEMAND M (Mme) CENTRE DE THERMIQUE DE LYON Energétique et thermique LAREAL P UNITE DE RECHERCHE EN GENIE CIVIL Géotechnique LAUGIER A PHYSIQUE DE LA MATIERE LAUGIER C BIOCHIMIE ET PHARMACOLOGIE LEJEUNE P GENETIQUE MOLECULAIRE DES MICROORGANISMES 4 / 124

5 LUBRECHT A MARTINEZ Y MAZILLE H MERLE P MERLIN J MILLET JP MIRAMOND M MOREL R MOSZKOWICZ P NARDON P (Prof. émérite) NAVARRO A NOURI A (Mme) ODET C OTTERBEIN M (Prof. émérite) PASCAULT JP PAVIC G PELLETIER JM PERA J PERACHON G PERRIAT P PERRIN J PINARD P (Prof. émérite) PINON JM PLAY D POUSIN J PREVOT P PROST R RAYNAUD M REDARCE H REYNOUARD JM RIGAL JF RIEUTORD E (Prof. émérite) ROBERT-BAUDOUY J (Mme) (Prof. émérite) ROUBY D ROUX JJ RUBEL P RUMELHART C SACADURA JF SAUTERAU H SCAVARDA S THOMASSET D TROCCAZ M UNTERREINER R VELEX P VIGIER G VINCENT A VUILLERMOZ PL (Prof. émérite) Directeurs de recherche C.N.R.S. : BERTHIER Y COTTE-PATAT N (Mme) FRANCIOSI P MANDRAND MA (Mme) QUINSON JL ROCHE A SEGUELA A Directeurs de recherche I.N.R.A. : FEBVAY G GRENIER S Directeurs de recherche I.N.S.E.R.M. : PRIGENT AF (Mme) MAGNIN I (Mme) MECANIQUE DES CONTACTS INGENIERIE INFORMATIQUE ET INDUSTRIELLE PHYSICOCHIMIE INDUSTRIELLE GEMPPM* GEMPPM* PHYSICOCHIMIE INDUSTRIELLE UNITE DE RECHERCHE EN GENIE CIVIL Hydrologie urbaine MECANIQUE DES FLUIDES LAEPSI*** BIOLOGIE FONCTIONNELLE, INSECTES ET INTERACTIONS LAEPSI*** MAPLY - MATHÉMATIQUES APPLIQUÉES DE LYON CREATIS** LEAPSI*** MATERIAUX MACROMOLECULAIRES VIBRATIONS ACOUSTIQUES GEMPPM* UNITE DE RECHERCHE EN GENIE CIVIL Matériaux THERMODYNAMIQUE APPLIQUEE GEMPPM* ESCHIL Equipe SCiences Humaines de l Insa de Lyon PHYSIQUE DE LA MATIERE INGENIERIE DES SYSTEMES D INFORMATION CONCEPTION ET ANALYSE DES SYSTEMES MECANIQUES MAPLY - MATHÉMATIQUES APPLIQUÉES DE LYON GRACIMP Groupe de Recherche en Apprentissage, Coopération et Interfaces Multimodales pour la Productique CREATIS** CENTRE DE THERMIQUE DE LYON Transferts Interfaces et Matériaux AUTOMATIQUE INDUSTRIELLE UNITE DE RECHERCHE EN GENIE CIVIL Structures CONCEPTION ET ANALYSE DES SYSTEMES MECANIQUES MECANIQUE DES FLUIDES GENETIQUE MOLECULAIRE DES MICROORGANISMES GEMPPM* CENTRE DE THERMIQUE DE LYON INGENIERIE DES SYSTEMES D INFORMATION MECANIQUE DES SOLIDES CENTRE DE THERMIQUE DE LYON Transferts Interfaces et Matériaux MATERIAUX MACROMOLECULAIRES AUTOMATIQUE INDUSTRIELLE AUTOMATIQUE INDUSTRIELLE GENIE ELECTRIQUE ET FERROELECTRIQUE CREATIS** MECANIQUE DES CONTACTS GEMPPM* GEMPPM* PHYSIQUE DE LA MATIERE MECANIQUE DES CONTACTS UNITE MICROBIOLOGIE ET GENETIQUE GEMPPM* UNITE MICROBIOLOGIE GENETIQUE GEMPPM* MATERIAUX MACROMOLECULAIRES GEMPPM* BIOLOGIE FONCTIONNELLE, INSECTES ET INTERACTIONS BIOLOGIE FONCTIONNELLE, INSECTES ET INTERACTIONS BIOLOGIE ET PHARMACOLOGIE CREATIS** *GEMPPM GROUPE D ETUDE METALLURGIE PHYSIQUE ET PHYSIQUE DES MATERIAUX ** CREATIS CENTRE DE RECHERCHE ET D APPLICATIONS EN TRAITEMENT DE L IMAGE ET DU SIGNAL ***LAEPSI LABORATOIRE d ANALYSE ENVIRONNEMENTALE DES PROCEDES ET SYSTEMES INDUSTRIELS ****CEGELY CENTRE DE GENIE ELECTRIQUE DE LYON 5 / 124

6 6 / 124

7 A mes parents (votre amour est le plus fabuleux des encouragements), A ma grand-mère, A mes chers disparus (heureusement, votre souvenir reste dans nos cœurs), A mon frère (têtu, mais que j'adore!), A Fabien (il saura pourquoi!) 7 / 124

8 Remerciements Je remercie sincèrement Monsieur Alain Folliet pour m'avoir accueilli au sein du CNEDI durant ses trois années de thèse, ainsi que Monsieur Jacques Faveeuw pour m'avoir accueilli dans son équipe. Je remercie M. Chabbat pour avoir accepté de m'encadrer tout au long de ma thèse et m'avoir prodigué ses conseils. Je tiens à remercier Messieurs Jean-Marie Pinon et Youssef Amghar pour avoir été mes encadrants durant ces trois années de thèse, et pour leur précieuse aide (en fonction de leur temps, évidemment!). Vous avez su être là quand il le fallait, me remonter le moral lorsque c'était nécessaire et m'encourager. Merci. J'envoie mes sincères remerciements à mes collègues de travail du cnedi, et notamment à Karine, pour sa patience, ses remarques constructives (ou destructrices?!) et sa joie de vivre (ainsi que ses sifflotements!). Je remercie aussi David pour sa bonne humeur et ses remarques judicieuses. Je tiens aussi à remercier mes parents, pour leur soutien, leur patience (et il leur en a fallut!) tout au long de ces trois ans, et avant aussi! Sans eux, je n'en serais pas là. Toi aussi, mon cher frérot, je te remercie, pour tes conseils et pour m'avoir montré que la thèse existait. Et enfin, je remercie Fabien, pour avoir été là quand il fallait, lui aussi pour avoir été patient (surtout pendant la rédaction du rapport!), et tout simplement pour être à mes côtés. Et pour terminer, merci à tous ceux que j'ai côtoyé au cours de ma thèse, à mes amis d'avant et d'aujourd'hui qui ont su me faire rire quand j'en avais besoin, et me soutenir dans mes actions. Merci à vous tous. Que tous ceux que je n'ai pas nommé ici ne s'offusquent pas : je pense à vous, mais, je ne peux pas citer tous les noms ici, alors, vous aurez droit à mes remerciements de vive voix! 8 / 124

9 Table des matières REMERCIEMENTS... 8 TABLE DES MATIÈRES... 9 TABLE DES ILLUSTRATIONS CHAPITRE 1 INTRODUCTION CHAPITRE 2 PROBLÉMATIQUE CONTEXTE D'ÉTUDE L'AIDE À LA DÉCISION CHAPITRE 3 ETAT DE L'ART LA STRUCTURATION DES DOCUMENTS INTRODUCTION MOYENS SGML, HTML, XML SGML HTML XML XMI CONCLUSION L'AIDE À LA DÉCISION INTRODUCTION LES OUTILS D'AIDE À LA DÉCISION / 124

10 2.3. LE RAISONNEMENT LES PRINCIPAUX SYSTÈMES : THÉORIE Les infocentres Les SIAD Les systèmes experts L'entrepôt de données CONCLUSION LES SYSTÈMES DE RECHERCHE D'INFORMATION DANS DES BASES DE DONNÉES HÉTÉROGÈNES GÉNÉRALITÉS ARCHITECTURE GÉNÉRALE LES WRAPPERS ET MÉDIATEURS EXEMPLES DE SYSTÈMES WHIPS SQUIRREL TSIMMIS CONCLUSION CHAPITRE 4 ARCHITECTURE D'UN SYSTÈME D'ACCÈS À DES BASES DE DONNÉES HÉTÉROGÈNES : SABADH UN SYSTÈME D'ACCÈS À DES BASES DE DONNÉES HÉTÉROGÈNES RAPPEL DE LA PROBLÉMATIQUE Exemples de Prises de décision Analyse d'impact Notification de Droit de Paiement Ouverture d'une nouvelle permanence CARACTÉRISTIQUES DU SYSTÈME COMPOSANTS DU SYSTÈME D'ACCÈS L'analyseur de requêtes le sous-requêteur filtre de décomposition Plan de séquencement la base de connaissances / 124

11 Rôle et contenu Schémas homogènes L'aiguilleur Dispatching des sous-requêtes Mise à jour des schémas de bases de données Les wrappers Le rédacteur de réponse Quelques Diagrammes de fonctionnement CHAPITRE 5 GESTION DE LA COHÉRENCE GÉNÉRALITÉS GESTION DE LA COHÉRENCE DANS UNE BASE DE DOCUMENTS STRUCTURÉS LA BASE DE DONNÉES JURIDIQUES (BDJ) Présentation De BDJ Gestion des Versions et des Liens Les documents Les versions Formalisation des documents Les liens LES VERSIONS ET LES LIENS Contexte juridique estampillé Définition d'un CJE Exemple de manipulation de CJE Formalisation d'un contexte Caractéristiques d'un lien versionnalisé Caractéristiques générales Caractéristiques de versionnalisation Formalisation des liens versionnalisés Incidences des mises à jour GESTION DE LA COHÉRENCE DANS LE SYSTÈME D'ACCÈS LA BASE DE CONNAISSANCES LE DICTIONNAIRE / 124

12 CHAPITRE 6 PROTOTYPAGE RÉALISATION INTERROGATION D'UNE BASE DE DOCUMENTS STRUCTURÉS INTRODUCTION PRÉSENTATION DE BASIS BASISPlus BASISDesktop BASISWebServer RÉSULTATS LE PROTOTYPE TRADUCTION DE REQUÊTES XML EN LANGAGE PROPRIÉTAIRE BASE DE DONNÉES CHAPITRE 7 CONCLUSION BIBLIOGRAPHIE PRINCIPAUX SIGLES UTILISÉS DANS CE DOCUMENT / 124

13 Table des illustrations Figure 1 : Organisation de la Sécurité Sociale 17 Figure 2 : Exemples de données manipulées par les CAF 18 Figure 3 : Modélisation des textes réglementaires aux Allocations Familiales 19 Figure 4 : Exemple de portion de document juridique rédigé selon SGML 26 Figure 5 : Fichier au format HTML et sa représentation graphique sous IE5 29 Figure 6 : illustration schématique des relations entre SGML et HTML 30 Figure 7 : DTD fournit par XMI pour UML 34 Figure 8 : architecture générale d'un SIAD 39 Figure 9 : Architecture d'un data warehouse 40 Figure 10 : illustration des informations contenues dans une métadonnée 42 Figure 11 : Principe schématique des médiateurs et wrappers 45 Figure 12 : schématisation du processus du système WHIPS 46 Figure 13 : Architecture du système WHIPS pour la maintenance de l'entrepôt de données 47 Figure 14 : Schématisation du système Squirrel 49 Figure 15 : Schématisation du principe du système Tsimmis 51 Figure 16 : Illustration d'une analyse d'impact 54 Figure 17 : Présentation de l'architecture du système actuel de traitement des NDP 56 Figure 18 : Illustration du traitement suite à des incohérences dans les NDP 57 Figure 19 : illustration du processus de prise de décision pour l'ouverture d'une nouvelle permanence 59 Figure 20 : Schéma général des entrées/sorties du système d'accès 64 Figure 21 : Schéma général de notre système d'accès 65 Figure 22 : Schéma de notre système, avec les Entrées/sorties de chaque module 66 Figure 23 : Schéma des Entrées / Sorties de l'analyseur de requêtes 68 Figure 24 : Schématisation des entrées/sorties du module de sous-requêtes 70 Figure 25 : modèle de notre base de connaissances 73 Figure 26 : schématisation du processus d'homogénéisation des schémas de bases de données 75 Figure 27 : Exemple d'un schéma au format UML traduit en XML 76 Figure 28 : Messages d'entrées/sorties en mode d'interrogation / 124

14 Figure 29 : Messages d'entrées / sorties en mode de mise à jour des schémas de bases de données 78 Figure 30 : Composants internes d'un wrapper 79 Figure 31 : Fonctionnement d'un wrapper en mode d'interrogation de base de données 80 Figure 32 : Fonctionnement d'un wrapper en mode de mise à jour des schémas de base de données 81 Figure 33: Diagramme de Collaboration (UML) de l'interrogation des Bases de données via SABaDH 83 Figure 34 : Diagramme de Séquencement de l'interrogation des bases de données 84 Figure 35 : Hiérarchie des textes de droit 86 Figure 36 : Illustration des différents types de textes produits aux Allocations Familiales 87 Figure 37 : Texte externe (article D du Code de la Sécurité Sociale) et texte interne (circulaire CNAF) 89 Figure 38 : Représentation arborescente de l'article D du Code de la Sécurité Sociale 90 Figure 39 : Exemple de versions pour l'article D du Code de la Sécurité Sociale 93 Figure 40 : illustration des liens de référence et de partage d'information 96 Figure 41 : Exemple de contextes juridiques estampillés pour un document 100 Figure 42 : illustration d'une recherche d'un document précis à une date précise 101 Figure 43 : illustration d'une recherche de version de fragment de document à une date donnée 102 Figure 44 : Articulation des divers outils BASIS 109 Figure 45 : interface graphique du prototype Basis / 124

15 Introduction Chapitre 1 Introduction De nos jours, l'informatique se situe à tous les niveaux de l'entreprise. Grâce à l'informatique, nous avons accès à toutes sortes d'informations, qu'elles soient sur le site d'interrogation ou à distance, qu'elles soient internes à l'entreprise ou à l'extérieur. Malgré ces bons côtés, il reste encore bien des progrès à faire, notamment en ce qui concerne la mise à disposition des données. L'objectif de cette thèse est de proposer une architecture de système d'information permettant d'accéder à diverses bases de données, hétérogènes, réparties, existantes ou non, dans le cadre de l'aide à la décision. Le but de ce système est de permettre à divers types d'utilisateurs (juristes, employés CAF 1, concepteurs d'applications, etc.) d'accéder aux données dont ils ont besoin pour prendre une décision, quelle qu'elle soit. Les connaissances des utilisateurs sur les données recherchées sont très hétéroclites et par conséquent, le système doit avoir la connaissance nécessaire afin de pallier aux diverses "lacunes" (ou faiblesses) des utilisateurs. Dans le cadre de notre étude, trois types de données principales sont considérés : des textes réglementaires, des règles de droit (puis de systèmes experts, après transformation), et enfin des données factuelles. Ces travaux ont été réalisés au sein de la Caisse Nationale des Allocations Familiales (CNAF) qui gère un très grand volume de données, aussi divers qu'évolutif. Notre étude s'inscrit donc dans le contexte général de la branche famille de la Sécurité Sociale. Le travail réalisé a permis de proposer une architecture générique, dont une instanciation peut être réalisée en utilisant les données manipulées par l'institution qu'est la CNAF. Dans un premier temps, nous présentons la problématique de notre thèse. La partie "Etat de l'art" présente un aperçu des principaux domaines nécessaires à notre étude, organisés en trois chapitres : la structuration des documents, l'aide à la décision, les systèmes de recherche d'information dans des bases de données hétérogènes. Le premier chapitre sur la structuration des documents nous permet de déterminer quel format de documents puis, plus généralement, de données, nous pouvons utiliser dans notre système. Notre étude nous conduit à choisir XML, à la fois dans la structuration de certaines de nos données et dans l'échange de données 1 Caisse d'allocations Familiales 15 / 124

16 Introduction entre notre système et l'extérieur (que ce soit une application ou un utilisateur). Le second chapitre concernant l'aide à la décision nous permet de présenter les divers types de systèmes d'aide à la décision existants. Ils ont constitué la principale source d'inspiration pour notre système, notamment pour la façon d'organiser le système afin de répondre au mieux aux besoins des utilisateurs. Enfin, le troisième chapitre permet de présenter les systèmes de recherche d'information pour des bases de données hétérogènes. En particulier, l'architecture des médiateurs et des wrappers dont notre système s'inspire, proposant sa propre architecture de wrappers. La partie suivante a pour but de présenter notre travail, c'est-à-dire une architecture de système d'accès à des bases de données hétérogènes, dans le contexte de l'aide à la décision. Nous détaillons l'architecture de notre système ainsi que les wrappers, extérieurs à notre système mais néanmoins indispensables pour le bon fonctionnement de notre système. Cette partie présente aussi une gestion de la cohérence dans une base de documents structurés en XML 2. Cette gestion est réutilisée en partie pour maintenir la cohérence à l'intérieur de notre base de connaissances ainsi que du dictionnaire de données. Enfin, la conclusion met en évidence le travail réalisé au cours de cette thèse, ainsi que les perspectives que ce travail peut engendrer. Une bibliographie récapitule l'ensemble des références bibliographiques utilisées tout au long de l'étude, et un tableau de sigles permet de trouver la définition de chaque sigle utilisé dans ce rapport, ou ayant un rapport direct avec des sujets abordés dans le discours. 2 extended Markup Language 16 / 124

17 Problématique Chapitre 2 Problématique 1. Contexte d'étude L'étude réalisée au cours de cette thèse s'est déroulée dans le contexte général des Allocations Familiales, laquelle fait partie de la Sécurité Sociale. L'organisation de cette dernière est présentée figure 1. La Sécurité Sociale comprend 4 branches principales : la branche maladie, notamment pour les remboursements suite à une maladie, la branche vieillesse, notamment pour gérer les retraites, la branche famille, notamment pour les allocations familiales, et la branche recouvrement, qui est la seule à récupérer de l'argent, et non pas uniquement à le distribuer. Notre contexte de travail se situe au sein de la branche Famille. Recouvrement Maladie Vieillesse Famille ACOSS CNAM CNAV CNAF 16 CRAM 9 CERTI 11 CNEDI 105 URSSAF 129 CPAM 125 CAF Cotisants individuels Entreprises Assurés / Allocataires + ayants droit Figure 1 : Organisation de la Sécurité Sociale Plus précisément, notre étude a été conduite au CNEDI 3 de Lyon, sous la responsabilité de la CNAF 4. Cet organisme doit gérer un grand volume d'informations, de types divers. Certaines de ces informations sont internes à la CNAF (comme les données concernant les allocataires), alors que d'autres sont fournies par l'extérieur (comme les informations fournies 3 Centre National d'etudes et de Développement Informatique 4 Caisse Nationale des Allocations Familiales 17 / 124

18 Problématique par l'insee 5 ). De nombreuses décisions sont prises à partir de ces données (voir Partie 1, Chapitre 2). La figure 2 montre la diversité des données manipulées par les CAF 6. Réglementation Locale Suivi Législatif Liste d'anomalies Marchés publics Droit du travail Données INSEE Présentation PowerPoint Notes de Service Doc Versions DGI Stat. Assedic Données Externes Thesaurus Données budgétaires Situations génériques Données Allocataires Règles de systèmes experts Dictionnaire de données d'entreprise Données Internes Figure 2 : Exemples de données manipulées par les CAF Dans le cadre de notre étude, nous nous intéressons plus particulièrement : aux documents textuels que sont les textes réglementaires (voir figure 3), qui définissent notamment les droits des allocataires ; aux diverses bases de données gérées par l'organisme, dont la base de données des allocataires et la base de textes dérivés des textes réglementaires (voir chapitre 2, 2.1.a) ; aux règles extraites des documents réglementaires qui permettent de calculer les droits des allocataires. 5 Institut National de la Statistique et des Etudes Economiques 6 Caisse d'allocations Familiales 18 / 124

19 Problématique Il est à noter qu'une première étude, réalisée dans le cadre de la thèse de Bertrand Chabbat [Chabbat, 1997], a permis de modéliser les textes réglementaires représentés selon la norme SGML (voir figure 3). Ces textes évoluent à présent vers le standard XML. De plus, les diverses données consultées ont bien souvent des liens les unes avec les autres, que ce soit de façon directe ou indirecte. Les textes réglementaires, par exemple, sont liés les uns aux autres (voir chapitre 2, 2.1.b). Tout cela doit permettre à un utilisateur de naviguer entre les textes. Mais cela permet aussi de répercuter les modifications d'une donnée sur celles qui lui sont liées. La cohérence est ainsi mieux gérée. Ministères Textes législatifs Circulaires Cnaf Commission de Suivi Législatif Suivi Législatif Administration Administration MODELISATION GENERALE Gestion des Prestations MAP Accueil Droits Potentiels 3615 grand public Documentation Aide à la décision Enseignement Assisté par Ordinateur Figure 3 : Modélisation des textes réglementaires aux Allocations Familiales [Chabbat, 1997] Dans un souci d'homogénéisation et afin de maintenir la cohérence plus facilement, la centralisation des diverses informations, notamment celles textuelles, semble indispensable. Cela nécessite une gestion de la cohérence très stricte, étant donné que tous les utilisateurs auront accès aux mêmes données. Une erreur pourrait entraîner de graves conséquences, les utilisateurs considérés étant dispersés dans la France entière. De plus, le système d'interrogation doit permettre l'interrogation par de nombreux utilisateurs en même temps, tout en conservant un temps de réponse jugé correct par les utilisateurs. Le problème qui se pose aux utilisateurs (c'est-à-dire aux employés des CAF) est d'avoir accès rapidement et de façon sûre (c'est-à-dire que les données consultées sont valides, et non pas erronées) à toutes les informations qui leur sont nécessaires dans leur prise de décision. Pour l'instant, il est bien souvent nécessaire de connaître plusieurs systèmes d'interrogation, 19 / 124

20 Problématique parfois un par type d'information. il est donc nécessaire de proposer un système, ou du moins une architecture d'un système d'interrogation qui permette aux utilisateurs de rechercher toutes les données dont ils ont besoin pour prendre leur décision, à travers une seule interface d'interrogation. Lorsque nous parlons d'utilisateurs, plusieurs types de personnes sont à prendre en compte. Tout d'abord, nous pouvons considérer les juristes de la CNAF chargés de rédiger une partie des textes internes à partir des textes externes à la CNAF (voir Chapitre Gestion de la cohérence). Les juristes sont experts dans le domaine juridique, mais ne le sont pas (en général), dans le domaine de l'informatique. Leur recherche sera donc précise sur le contenu et la logique de rédaction des textes réglementaires, mais peut-être moins sur la structure informatique des textes. D'autre part, nous devons considérer les concepteurs d'applications et d'architecture de systèmes (ou de bases de données). Ce type d'utilisateurs peut être considéré comme experts en informatique mais moins dans le domaine juridique. Leurs recherches seront donc plus précises sur la structure ou le type des données, mais peut-être moins sur leur contenu. Enfin, un troisième type d'utilisateurs est à prendre en compte : les employés des CAF. Parmi eux, nous considérons les techniciens-conseils, qui sont entre autres en contact avec le public des CAF, c'est-à-dire les allocataires. Ces personnes possèdent une connaissance générale des domaines informatiques et juridiques, mais ne sont pas, en principe, expertes dans l'un ou l'autre de ces domaines. Par conséquent, leurs recherches sont parfois plus précises dans le contenu, et d'autres sont plus précises sur la structure même des données, selon la personne qui recherche. En ce qui concerne notre étude, nous considérons deux principaux types d'utilisateurs : les concepteurs d'application d'un côté et les autres utilisateurs (juristes et employés CAF) de l'autre, bien souvent associés aux décideurs, étant donné que ce sont eux qui prennent des décisions à partir des données qu'ils ont recherchées. Mais, par un abus d'écriture, nous utilisons à la fois le terme "utilisateurs" et le terme "décideurs" pour les deux types d'utilisateurs que nous venons de présenter. Néanmoins, dans un premier temps, nous ne prendrons en compte que le décideur. Ce dernier recherche des informations afin de prendre une décision, quelle qu'elle soit. 20 / 124

21 Problématique 2. L'aide à la décision "La loi du 6 janvier 1978 tend à éviter tout automatisme dans la prise de décision. L'appréciation sur les comportements humains doit être laissée à l'homme et ne pas dépendre des seules conclusions de la machine. Ainsi, aucune décision impliquant une appréciation sur un comportement humain ne peut avoir pour seul fondement un traitement automatisé d'informations donnant une définition du profil ou de la personnalité de l'intéressé ( art. 2 ). Il n'est pas interdit de recourir à la méthode des profils qui consiste à classer des individus au regard de caractéristiques déterminées après des études statistiques. Mais cette méthode ne peut être utilisée que comme une aide à la décision c'est-à-dire constituer un élément d'information parmi d'autres, laissant toute sa liberté d'appréciation au décideur humain." Une des principales activités des CAF est de distribuer des prestations, et pour cela, de prendre des décisions (voir Partie 2 Chapitre 1, 2). Ces décisions sont prises à différents niveaux, en consultant diverses données. Un des problèmes liés à l'aide à la décision réside dans le fait d'avoir accès, à l'instant voulu, à toutes les informations nécessaires à une prise de décision. De plus, ces informations doivent être valides, dans le sens où leurs valeurs ne doivent pas être erronées. De plus, certaines données passent par différents états : chaque valeur est valide dans un intervalle de temps. Ces données sont dites versionnalisées. La date à laquelle un usager veut considérer la donnée à consulter est un paramètre discriminant. D'autre part, les données consultées ne sont pas toutes du même type, d'où l'utilisation de plusieurs systèmes d'interrogation, généralement, chacun spécialisé pour un type de données. Or, lors d'une prise de décision, il est important d'accéder non seulement rapidement aux données, mais aussi d'y accéder d'une façon conviviale. D'où la nécessité de proposer un système unique d'interrogation pour toutes les bases de données à consulter. Ainsi, un utilisateur, quel que soit son profil, pourra consulter les données qui lui sont nécessaires pour prendre sa décision. Un autre aspect est à considérer : certaines données utiles à la prise de décision peuvent ne pas être connues de l'utilisateur. En effet, comme nous l'avons dit précédemment, les données prises en compte dans cette étude sont liées les unes aux autres. Certaines peuvent provenir d'autres données, comme les règles de systèmes experts qui sont élaborées à partir du contenu 21 / 124

22 Problématique textuel des documents réglementaires. Dans ce cas, lorsqu'un utilisateur effectue une recherche, il peut demander à consulter deux types de données distincts, mais néanmoins liés par le biais d'un troisième type de données (concrètement, un texte réglementaire et un allocataire n'ont pas de lien direct, mais un texte réglementaire permet l'élaboration d'au moins une règle de système expert, laquelle sera appliquée sur les données d'un allocataire. Les règles de systèmes experts permettent donc de lier un texte réglementaire avec des allocataires). Il est important de fournir ces données "oubliées" à l'utilisateur. En effet, ce dernier doit avoir en sa possession toutes les données susceptibles de lui permettre de prendre sa décision, dans les meilleures conditions. Le système proposé doit permettre : un accès rapide aux informations recherchées, une restitution des informations demandées ainsi que des informations associées, utiles à la prise de décision, une interface unique, quel que soit le type des données recherchées. La prise de décision met en jeu de nombreuses données, de types divers. Une base de données est en général dédiée à un seul type de données : des données textuelles structurées selon, par exemple, le format XML, ou bien des données textuelles non structurées, des données factuelles, etc. Chacune de ces bases possède son propre système de gestion, son propre langage d'interrogation, et est utilisée par un certains nombres d'applications. Le système à élaborer doit donc prendre en compte le fait que ces bases existent, qu'elles ont un langage d'interrogation propre (SQL, langage propriétaire, etc.). Ces bases ne doivent pas être modifiées, pour ne pas altérer le fonctionnement des applications qui leur sont associées. De plus, le système doit pouvoir les interroger, à partir d'une seule requête, quel que soit leur langage d'interrogation. La requête initiale peut nécessiter une interrogation des bases de données selon un plan précis de décomposition de la requête. En effet, l'interrogation d'une base de données BD1 peut nécessiter au préalable une réponse d'une autre interrogation adressée à une base BD2, par exemple. Dans ce cas, le système doit pouvoir gérer le problème de l'absence de réponse de la base BD2. Il faut tenir compte aussi du fait que certaines bases à interroger sont déjà en exploitation. De même, d'autres bases sont en cours de conception, et ne seront mises en service qu'après la 22 / 124

23 Problématique réalisation du système d'accès. Le problème est alors de concevoir une architecture qui permette d'intégrer des bases de données existantes, tout en permettant l'ajout de nouvelles bases de données facilement. L'interrogation, à partir d'une seule requête, doit être assurée, ainsi que la récupération des données et leur présentation à l'utilisateur. Tout cela implique l'étude de l'accès à des bases de données hétérogènes ainsi que l'étude de l'échange de données. 23 / 124

24 Etat de l'art Chapitre 3 Etat de l'art 1. La structuration des documents 1.1. Introduction De tous temps, les documents ont constitué une formidable source d'information. Ils sont un support pour la mémorisation et la consultation des connaissances. L'informatique a permis, dans un premier temps, d'améliorer le stockage des divers documents à consulter, notamment par l'intermédiaire de Systèmes de Gestion de Bases de Données (SGBD). Grâce à ces systèmes, plusieurs utilisateurs peuvent consulter un même document électronique. La mise à jour des documents est facilitée. Par la suite, la récupération d'informations dans ces documents s'est trouvée améliorée, la recherche dans ce domaine étant très active. Les Systèmes de Recherche d'information (SRI) utilisent le contenu sémantique des documents pour rechercher une information. Actuellement, une autre dimension des documents est de plus en plus utilisée lors de la recherche d'informations : leur structuration. Le document n'est alors plus seulement un contenu textuel, tel que l'était un document papier, mais il contient aussi d'autres informations, sur sa structure, sa provenance, son élaboration. Toutes ces informations peuvent, elles aussi, être exploitées afin de retrouver un document pertinent pouvant ensuite être utilisé, notamment, pour une prise de décision. De nombreux éditeurs (par exemple Adobe FrameMaker, Microsoft Word, Xmetal, etc.) proposent aujourd'hui des environnements permettant de créer des documents structurés. Mais un autre aspect des documents électroniques est aussi à prendre en compte : l'aspect multimédia. De nos jours, les documents ne sont plus seulement textuels. Ils intègrent des images, des illustrations, des vidéos ainsi que du son. Il ne s'agit donc plus seulement de retrouver une information dans un contenu textuel. Il faut à présent prendre en compte tous les médias lors de la recherche d'une information. 24 / 124

25 Etat de l'art 1.2. Moyens Afin de représenter les documents structurés dans des environnements hétérogènes, certaines normes ont été développées : ODA (ISO 8613) [AFNOR, 1991], SGML (ISO 8879) [AFNOR, 1990], HyTime, et plus récemment XML [Michard, 1998] et ses standards associés. Ces normes permettent notamment de séparer la structure logique d'un document de sa structure physique. La structure logique d'un document permet de définir une hiérarchisation de l'information contenue dans le document. Un document va alors être constitué, par exemple, d'un titre, d'une ou plusieurs parties, elles-mêmes composées d'un titre et de sous-parties, etc. La structure physique, quant à elle, permet de définir la présentation du document. Celle-ci dépend du support de restitution. Par exemple, s'il s'agit d'une représentation dite "papier", la structure physique indiquera le format de la feuille (A3, A4, A5, ) ainsi que l'organisation des différentes entités logiques du document (telles parties avant telles autres, le titre de telle manière, la sous-partie de telle autre manière). S'il s'agit d'une représentation informatique, le support est déterminé par les fonctionnalités de la machine. En général, un document électronique est composé de pages, chacune pouvant posséder un en-tête et un bas de page, un corps de document, etc On peut remarquer que la structure logique du document est totalement indépendante du support, alors que la structure physique en est au contraire totalement dépendante. Par exemple, suivant le format papier considéré (A4 ou A5), le nombre de pages et les numéros des pages ne seront pas les mêmes pour un même document. La structure logique, elle, ne dépend pas du support de restitution. Il est donc possible de l'utiliser afin de rechercher une information. Outre le contenu textuel d'un document, la structure logique renseigne sur son organisation (les titres, les parties, sections, sous-parties, etc., chacune traitant d'un sujet précis, en général). Elle permet donc une recherche plus précise des informations, et permet ainsi d'augmenter le taux de réponses exactes aux requêtes utilisateurs. Ce besoin de recherche d'informations toujours plus précises est à associer au phénomène d'échange d'informations, notamment entre systèmes hétérogènes. Pour réaliser ces échanges, il est nécessaire d'avoir un langage de communication commun entre les systèmes. Il est donc primordial que les documents que l'on considère soient eux aussi dans un langage commun, d'où l'intérêt de normes de représentation pour les documents électroniques structurés. Ces normes, dont SGML fut la principale jusqu'à l'apparition de XML, fournissent une structure 25 / 124

26 Etat de l'art d'accueil aux documents qui sont alors reconnaissables par des systèmes hétérogènes. Grâce aux normes, les données sont organisées de façon homogène et utilisent un standard de représentation. La section suivante présente un peu plus en détail SGML et le nouveau standard XML SGML, HTML, XML SGML SGML est une norme de représentation des documents datant de Cette norme est basée sur le principe que tout document admet à la fois une structure logique qui définit son organisation hiérarchique et une structure physique qui détermine sa représentation. SGML 7 repose sur le balisage normalisé d éléments (appelés plus communément balises)constituants la structure logique d un document. Chaque document peut par exemple être classé selon sa structure logique, telle : roman, thèse, journal, compte-rendu, etc. La structure logique d un document est définie dans une DTD 8. Celle-ci permet de définir le nom des éléments à utiliser (par exemple titre, section, sous-section, auteur), leur imbrication, leur ordre d'apparition dans le document, etc. Pour être conforme à la norme SGML, un document doit être rédigé en conformité avec une DTD. La figure 1 montre un exemple de portion de document écrit selon SGML, la DTD n'étant pas fourni ici. <SUIVILEG> <FRONT> <GROUPE-TITRE> <TITRE-PRINCIPAL> <LIB> Conditions générales d'ouverture de droit </LIB> </TITRE-PRINCIPAL> <GROUPE-TITRE> </FRONT> </SUIVILEG> Figure 4 : Exemple de portion de document juridique rédigé selon SGML Un élément est typiquement composé de trois parties : 7 SGML : Standard Generalized Markup Language 8 Document Type Definition 26 / 124

27 Etat de l'art une balise de début, un contenu, une balise de fin. La balise de début est de la forme : <nom_d_element>, où nom_d_element est le nom de l'élément tel que définit dans la DTD. Le contenu peut être du texte, mais aussi d'autres éléments, selon la définition de la DTD. La balise de fin est de la forme : </nom_d_element>. On peut alors obtenir un élément de la forme : <auteur> <nom> Hugo </nom> <prenom> Victor </prenom> </auteur> Dans cet exemple, l'élément auteur est constitué de deux autres éléments : nom et prenom. Nom et prenom, quant à eux, sont constitués uniquement de texte. Les balises peuvent contenir des arguments, qui ne sont en général pas afficher par défaut dans la représentation physique (ce qui n'empêche pas leur affichage si nécessaire), mais qui permettent bien souvent d'effectuer une recherche plus rapide sur la structure du document. Par exemple, la date de création d'un document peut ne pas être utile dans la représentation physique bien que lors de la recherche de documents elle soit utilisée. Dans ce cas, une des solutions est de la renseignée dans un argument, par exemple avec la balise titre du document : <titre date_creation=" "> Un exemple avec SGML </titre> Chaque argument possède une et une seule valeur dans une balise. Il peut exister plusieurs arguments par balise. En revanche, SGML ne se préoccupe pas de l'aspect présentation physique du document. C'est au système de gérer celle-ci. De cette façon, il est plus facile d'échanger des documents, chaque système pouvant analyser et utiliser la DTD du document selon ses propres capacités. Néanmoins, une autre norme, DSSSL 9, a été établie afin de prendre en compte la présentation physique d'un document. Ce format permet : de formater les documents en vue de leur présentation physique, de transformer les documents, par exemple pour générer une table des matières, l'extraction de données en considérant le document SGML comme un base de données. 9 Document Style Semantics and Specification Language 27 / 124

28 Etat de l'art Un des principaux avantages de SGML est d'assurer la pérennité des documents, étant donné qu'il utilise un système de balisage universel. Il n'est donc pas soumis aux évolutions de versions des "programmes" propriétaires qui rendent les documents très rapidement obsolètes. Un autre avantage de SGML est d'assurer la conformité d'un document à un type de documents donnés, comme par exemple pour un rapport technique, ou pour un compte-rendu de réunion, etc. Tous les documents d'un même type auront donc la même structure logique, ce qui permet notamment une comparaison de documents et assure la conformité desdits documents à certaines spécifications HTML Parallèlement à SGML, nous pouvons citer la norme HTML 10, qui permet aussi de structurer un document mais ses possibilités et ses objectifs sont différents de ceux de SGML. En effet, HTML ne sépare pas la structure physique de la structure logique. De plus, il ne permet pas de définir une DTD, les balises à utiliser étant prédéfinies dans la norme. En revanche, un document HTML peut être visualisé sur le Web (via un navigateur, tel Internet Explorer ou Netscape, par exemple) alors qu'un document SGML nécessite un visualiseur spécifique (tel FrameMaker + SGML, par exemple). La figure 2 illustre un exemple de fichier au format HTML (ayant une extension ".html" ou ".htm") ainsi que sa visualisation via Internet Explorer 5. <html> <head> <title> Un exemple de document HTML </title> </head> <body> <p> Voici un petit exemple de document au format <b> html </b> </body> </html> 10 HyperText Markup Language 28 / 124

29 Etat de l'art Figure 5 : Fichier au format HTML et sa représentation graphique sous IE5 De plus, la norme SGML ne permet pas de définir de façon standard les liens entre documents ou à l'intérieur d'un même document. Une autre norme, HyTime, a été élaborée pour définir ces liens en association avec HTML. Le principal type de liens utilisés est le lien de référence, qui permet de naviguer d'un document à un autre, d'un simple clic de souris. Deux communautés se sont alors développées en parallèle : la communauté SGML (notamment ceux qui sont dans la grosse documentation, les livres, etc.) et la communauté HTML (notamment les internautes). La figure suivante illustre, de façon schématique, les relations existantes entre SGML et HTML, au début de leur création. 29 / 124

30 Etat de l'art SGML HyTime Doc 1 HTML Doc 2 Doc n doc_html 1 Liens interprétés par un logiciel de consulation, tel Netscape... doc_html m Figure 6 : illustration schématique des relations entre SGML et HTML XML Malgré ces deux standards différents, les évolutions de chacun ont fait naître le besoin de faire converger les deux communautés. Pour cela, un nouveau standard a été développé : XML 11. Il s'inspire à la fois de SGML et HTML, mais aussi de HyTime, DSSSL et bien d'autres. Il réunit certaines fonctionnalités des uns et des autres, afin de répondre aux besoins des utilisateurs, qu'ils soient pro-html ou pro-sgml. Ces besoins regroupent notamment la possibilité de définir des DTD, d'utiliser le net pour échanger (de façon plus simple qu'avec SGML) visualiser et manipuler des documents, etc. XML est donc né, avec à sa suite une panoplie de standards qui permettent d'enrichir ses fonctionnalités : XSL 12 (pour la présentation physique des documents), XSLT 13 (pour la manipulation des éléments d'un document avant sa présentation physique à l'utilisateur), XLL 14 (pour définir des liens intra ou inter documents). Certains de ces standards ont déjà été validés (tel XSLT, en novembre 1999, par exemple), alors que d'autres ne sont encore qu'à l'état de proposition (comme XML- Schemas, qui devrait à terme remplacer les actuelles DTD). XML est en fait un langage de description et de structuration de données. Il permet, tout comme SGML, de définir une structure logique à laquelle le document doit se conformer afin d'être valide. Néanmoins, il introduit une nouvelle notion, le "bien formé", pour un document. Cette notion permet d'utiliser un document sans sa DTD (contrairement à SGML), du moment que ses balises sont correctement imbriquées (par exemple, une balise <section> suivie d'une balise <titre> ne pourra être fermée qu'après avoir fermé la balise <titre>, sinon le document 11 extended Markup Language 12 extensible Style Language 13 extensible Style Language Transformation 14 extensible Linking Language 30 / 124

31 Etat de l'art n'est pas "bien formé"). Ainsi, un document créé conformément à sa DTD peut être échangé et manipulé sans avoir recours à cette DTD, ce qui simplifie à la fois les échanges et les traitements. Parmi les nombreux standards associés à XML, deux d'entre eux nous intéressent plus particulièrement : XSL et XLL. XSL permet de définir des feuilles de style, c'est-à-dire la façon dont le document va être présenté à l'utilisateur. Un sous-ensemble a été créé pour la transformation d'arbres de documents XML : XSLT. Ce dernier permet de manipuler les différents éléments d'un document (généralement représenté sous forme arborescente), afin d'en modifier l'organisation, pour ajouter un sous-arbre ou en cacher un autre, pour insérer de nouveaux éléments (par exemple la table des matières, les numéros des figures, etc.), etc. De son côté, XLL permet de définir (avec Xlink et Xpointer) les liens ainsi que leurs ancres, que ce soit à l'intérieur ou entre deux (ou plusieurs) documents distincts. Ces deux standards permettent donc de présenter un document, de le manipuler si nécessaire avant sa présentation finale afin, notamment, de l'adapter au profil de l'utilisateur, de naviguer entre les documents de la base lors d'une consultation, mais aussi de maintenir la cohérence entre les documents en utilisant entre autres les liens entre ceux-ci, par exemple, lors d'une mise à jour, pour déterminer quels sont les autres documents à mettre à jour. Un autre aspect de XML à envisager est celui de l'échange d'information. En effet, un des buts de XML est de permettre un échange de données plus facile qu'avec les moyens existants(l'edi 15, par exemple). De nombreux efforts sont réalisés dans ce sens. On peut citer l'effort du groupe OMG 16 avec sa proposition XMI 17. XML devient de plus en plus le successeur de SGML voire de HTML. En effet, il est de plus en plus utilisé à la fois pour structurer des documents (qui peuvent même contenir les données d'une base de données), pour échanger des données, mais aussi pour présenter des documents sur le Net, sans pour autant avoir à modifier le fichier source, bien souvent utilisé en interne avant d'être publié sur le net. Par rapport à SGML, XML permet de se détacher de la DTD dès que cela est possible, ce qui rend les traitements moins lourds. De plus, les standards associés à XML (notamment pour les liens et pour les feuilles de style) permettent d'augmenter ses fonctionnalités de manière significative. 15 Echange de Données Informatisé 16 Object Management Group 17 XML Metadata Interchange 31 / 124

32 Etat de l'art Face à HTML, XML permet de personnaliser les modèles de documents (via les DTD), et ainsi d'assurer la conformité des documents aux spécificités requises par exemple par un métier. De plus, les feuilles de style permettent de présenter un document en fonction de l'utilisateur, ce que HTML commençait seulement à autoriser avec sa version 4. XML peut donc facilement se substituer à HTML. Néanmoins, trop peu de navigateurs permettent pour l'instant de visualiser les documents XML avec leurs feuilles de style. Après IE5 de Microsoft, La prochaine version de Netscape, Mozilla, devrait enfin permettre de visualiser ces documents XML XMI XMI a été proposé en réponse à une demande de l'omg du pour un échange de modèles basé sur les flots. La proposition XMI a été adoptée officiellement en avril Dans sa proposition initiale, XMI spécifie un modèle d'échange d'information ouvert qui est destiné à donner aux développeurs, qui travaillent avec une technologie objet, la capacité d'échanger des données de programmation à travers Internet d'une façon standardisée. De ce fait, la compatibilité et la cohérence sont apportées aux applications créées dans des environnements de collaboration. En établissant un standard industriel pour stocker et partager des informations de programmation objet, les équipes de développement utilisant des outils variés peuvent tout de même collaborer sur des applications. Le standard proposé permet aux développeurs d'utiliser le web pour échanger des données entre outils, applications et entrepôts pour créer des applications distribuées, sûres, construites sur un environnement de développement en équipe. Ce standard combine les avantages du standard XML basé sur le web pour définir, valider et partager des formats de documents, tout en utilisant les avantages du langage UML 18, langage commun pour spécifier, visualiser, construire et documenter des modèles d'entreprise et des objets distribués. Le but principal de XMI est de permettre l'échange facile de métadonnées entre des outils de modélisation (basés sur UML) et entre outils et entrepôts de métadonnées (basés sur MOF 19 ) dans des environnements hétérogènes distribués. XMI intègre trois standards clés de l'industrie : 18 Unified Modeling Language 19 Meta Object Facility 32 / 124

33 Etat de l'art XML : extended Markup Language, un standard du W3C 20, UML : Unified Modeling Language, un standard de modélisation objet de OMG, MOF : Meta Object Facility, un standard de métamodélisation de OMG. L'intégration de ces trois standards dans XMI marie le meilleur des technologies de modélisation et de métadonnées du W3C et de OMG. XMI, concurremment avec MOF et UML, forme le noyau de l'architecture d'entrepôt de OMG, qui intègre des outils de conception et de modélisation orientés objet entre chacun d'eux, et avec une structure d'entrepôt extensible basée sur MOF. Cette architecture permet aux outils de partager des métadonnées via des programmes utilisant des interfaces COBRA spécifiées dans les standards MOF et UML, ou en utilisant des flots basés sur XML (ou des fichiers) contenant des spécifications de modélisation compatibles MOF ou UML. Ceci permet une très grande latitude pour les développeurs d'outils, d'entrepôts et de structures objets, et diminue la barrière d'entrée pour l'implémentation des standards de métadonnées de OMG. Les membre de OA & DTF OMG ont déjà commencé à étendre cette architecture afin de gérer des métadonnées de data warehousing dans l'initiative Common Warehouse Metadata Interchange (CWMI). La soumission de XMI consiste principalement en : 1. un ensemble de règles de production de DTD XML pour transformer des métamodèles basés sur MOF en DTD XML ; 2. un ensemble de règles de production de documents XML pour coder et transférer des métadonnées basées sur MOF ; 3. des principes de conception pour des DTD basées sur XMI ; 4. des DTD concrètes pour UML (voir figure ci-après) et MOF. 20 World Wide Web Consortium 33 / 124

34 Etat de l'art XMI Presentation Model~ XMI reference < name visibility ClassifierInState~ name ownedelement Class~ feature feature Figure 7 : DTD fournit par XMI pour UML 1.4. Conclusion L'utilisation d'un standard comme XML non seulement nous donne un aspect générique, mais permet aussi d'utiliser les nombreux standards qui lui sont associés, tels XSL, XLL, XMI, etc. De plus, de nombreux outils sont en développement ou sont déjà commercialisés (par exemple Xmetal). L'utilisation de XML n'implique donc pas nécessairement de grands investissements étant donné que ce standard devient de plus en plus usuel dans le monde informatique. 34 / 124

35 Etat de l'art 2. L'aide à la décision "Extraire du jus fade des données le nectar du sens" 2.1. Introduction Dans une entreprise, le nombre de données produites et consultées est sans cesse croissant. Ces données sont par la suite utilisées, que ce soit pour l'élaboration d'autres données ou bien pour prendre des décision, par exemple. Dans ce dernier cas, il est primordial de consulter toutes les données nécessaires à la prise de décision, à jour, non erronées. Prendre une décision, c'est suivre un raisonnement. Ce dernier peut être défini comme étant le processus mental qui consiste à transformer des informations données (appelées "ensemble de prémisses") afin d'en tirer une conclusion. Il est donc nécessaire, pour prendre une décision, de disposer de l'information uniquement utile, de la préparer et de la rendre disponible au moment où l'utilisateur en exprime le besoin, et cela dans un format compréhensible et utilisable. Bien que l'automatisation totale du processus de raisonnement et de prise de décision n'est pas possible, il reste néanmoins possible d'automatiser une partie du raisonnement. En effet, des systèmes peuvent être élaborés afin de faciliter l'accès aux données nécessaires à la prise de décision, sur la demande d'un utilisateur. Un système d'aide à la décision doit permettre : de récupérer toutes les données nécessaires à la prise de décision, de les stocker, de les traiter si nécessaire afin notamment de les uniformiser (par exemple pour éviter les doublons ou les erreurs), de les analyser, voire d'extraire de nouvelles informations afin de disposer de l'information utile. Il existe déjà de nombreux outils d'aide à la décision. Ils ont tous leurs avantages et leurs inconvénients. La section suivante présente quelques uns de ces outils. 35 / 124

36 Etat de l'art 2.2. Les outils d'aide à la décision Lorsque l'on parle d'outils d'aide à la décision, cela comprend : les infocentres, les tableaux de bord, les systèmes experts, les SIAD 21, des entrepôts de données [MI, 1997] [Franco, 1997] [L&S, 1997], outils de recherche opérationnelle, logique floue, Tous ces systèmes ont un même objectif : permettre de présenter et d'analyser des données nécessaires à une prise de décision. L'offre décisionnelle date des années 1970, et se caractérise à l'époque par des infocentres et des tableaux de bord [LS, 1997]. Mais les besoins des utilisateurs ont évolué au cours du temps, et dans de nombreux cas, les tableaux de bord se sont révélés insuffisants, étant donné leur coût élevé de développement, leur manque d'évolutivité et finalement le fait qu'ils soient inadaptés au besoin sans cesse changeant de l'utilisateur final. Néanmoins, ils sont toujours utilisés, grâce notamment à des améliorations comme le drill-down (fait de zoomer du niveau de détail le plus général au plus fin) ou encore le drill-across (analyser une même métrique sur des axes d'analyse différents). En 1990, William Inmon, cofondateur de Prism Solutions, introduit le terme de Data Warehouse. Ce concept tend à désigner un ensemble de méthodes, techniques et outils pour rassembler des données issues de sources multiples au sein d'un modèle cohérent, et leur donner un sens à des fins d'analyse. De nos jours, de nombreuses entreprises utilisent le principe de "data warehouse" pour stocker leurs données Le raisonnement Comme nous l'avons dit précédemment, le raisonnement qui conduit à une décision peut être vu comme une activité mentale qui consiste à transformer des informations données afin d'en tirer une conclusion. En logique, la conclusion est un état particulier et les prémisses (c'est-à-dire les informations de départ) sont aussi des états (des expressions logiques qui peuvent être soit vraies soit fausses). Les prémisses sont aussi appelées arguments. Du point de vue de la logique, un argument consiste soit en zéro soit en plusieurs prémisses, et en une conclusion. Un état peut être soit simple, soit constitué d'autres états. Si les prémisses d'un argument sont vraies, alors la conclusion de cet argument doit être vraie. 21 Systèmes Interactifs d'aide à la Décision 36 / 124

37 Etat de l'art Dans l'étude de la logique, on distingue la logique formelle et la logique informelle (ou semi-informelle). Dans la logique formelle (ou symbolique, ou mathématique), les arguments sont symbolisés grâce à un langage bien défini et peuvent être manipulés selon un ensemble strict de règles, indépendamment des interprétations possibles. Mais cette approche pose un problème de convivialité, en plus du problème de limitation (notamment pour exprimer le temps ou encore l'obligation). En effet, la notion logique est arcane, ce qui nécessite un entraînement intensif avant de comprendre les expressions formelles. Dans leur article, G.H. Hua et S.O. Kimbrough [Hua et Kimbrough, 1998] parlent de la représentation des arguments selon des graphes orientés. Les nœuds d'un tel graphe représentent les états et les arcs représentent certaines relations sémantiques entre les états (par exemple "supporte", "répond à", etc.). En plus de cela, Hua et Kimbrough considèrent deux types de liens hypermédia : les liens internes (entre des éléments du réseau d'argumentation) et les liens externes ('entre un élément du réseau d'argumentation et un élément en dehors de ce réseau). Un des problèmes est alors de construire automatiquement les liens hypertextes, sans l'aide de l'utilisateur. Le second problème réside dans la représentation graphique des arguments. Enfin, un dernier problème se pose pour représenter les inférences logiques, étant donné qu'un tel réseau n'est pas "logique". Hua et Kimbrough proposent donc d'utiliser les graphes logiques et les larges présomptions pour représenter les arguments. Cette méthode est suffisamment générale pour être appliquée à la plupart des systèmes d'aide à la décision existants. Néanmoins, lors d'une prise de décision, de nombreux types de données différents sont à prendre en compte. Par conséquent, la théorie de Hua et Kimbrough serait à reconsidérer afin de l'adapter, si possible, à la gestion de données hétérogènes. En effet, pour prendre une décision, un utilisateur utilise une certaine "logique", que l'on pourrait tenter de modéliser grâce à des graphes logiques Les principaux systèmes : théorie Il existe de nombreux systèmes qui ont pour but d'aider un utilisateur à prendre une décision. Chacun d'eux a des fonctionnalités particulières, et des caractéristiques précises. Les sections suivantes présentent quelques types de systèmes d'aide à la décision. 37 / 124

38 Etat de l'art LES INFOCENTRES Un infocentre est une collection de données orientées sujet, intégrées, volatiles, actuelles, organisées pour le support d'un processus décisionnel ponctuel. Un infocentre est alimenté par les valeurs du système de production. A chaque nouvelle alimentation, la nouvelle valeur remplace l'ancienne valeur. Du fait de cette alimentation, il est difficile de maintenir des agrégats, qui sont bien souvent calculé au moment de l'accès par l'utilisateur. Dans un infocentre, l'objectif est de prendre des décisions opérationnelles, basées sur des valeurs courantes, étant donné qu'il n'y a pas d'historique des valeurs. Ce concept a été inventé par IBM, mais ne s'est jamais imposé étant donné qu'il était mis en œuvre uniquement pour des spécialistes sur les mainframes (tout en étant dédié aux utilisateurs non informaticiens). Néanmoins il revient sur le marché LES SIAD Les Systèmes Interactifs d'aide à la Décision (SIAD) [Chabbat, 1997] ont pour but de rationaliser le processus décisionnel en effectuant l'intégration de multiples données, considérations et technologies. Le SIAD ne remplace pas le décideur mais il vient l'appuyer sur une base analytique et d'information. Il lui permet d'évaluer divers scénarios décisionnels, lesquels le conduiront vers une décision raisonnées et justifiable. Les données d'un SIAD sont organisées en une Base de Données gérée par un Système de Gestion de Bases de Données, doté d'un langage d'interrogation. De la même façon, les modèles, utilisés pour traiter l'information et donc gérer les scénarios, sont organisés en une Base de Modèles gérée par un Système de Gestion de Bases de Modèles qui possède souvent son propre langage appelé "langage de modélisation" (voir figure ci-dessous). 38 / 124

39 Etat de l'art Données Internes Données Externes Choix des modèles Base de Données Système de Gestion de Bases de Données Base de Modèles Système de Gestion de Base de Modèles Interface Utilisateur Figure 8 : architecture générale d'un SIAD LES SYSTÈMES EXPERTS Les premiers systèmes experts [Faltings, 1994], qui datent de plus de 20 ans, étaient à base de règles (par exemple : si alors). Ces systèmes ne permettaient pas de satisfaire à tous les besoins de l'époque, notamment : séparer les connaissances déclaratives de la procédure d'inférence afin de réutiliser les mêmes connaissances pour des tâches différentes ; avoir un système améliorant ses performances grâce à des techniques d'apprentissage. Les chercheurs en intelligence artificielle ont mis au point diverses techniques parmi lesquelles : les abstractions : afin de réduire la complexité d'un problème, on le formule à un niveau d'abstraction plus élevé. En contrepartie, le problème abstrait ne donnera pas accès à toutes les solutions du problème original. Le raisonnement à partir de cas : on construit des analogies entre des expériences précédentes et le problème actuel. Les deux principales composantes d'un moteur basé sur ce raisonnement sont l'indexation (pour retrouver les cas à prendre en compte pour le problème actuel) et l'adaptation (pour modifier un ou plusieurs cas 39 / 124

40 Etat de l'art afin de les rendre applicables au problème actuel). Le principal inconvénient d'un tel raisonnement est qu'il est très gourmand en ressources informatiques L'ENTREPÔT DE DONNÉES Les informations concernant l'entrepôt de données (ou encore Data Warehouse) sont nombreuses, et permettent d'avoir un bon aperçu de ce que l'on attend de l'aide à la décision. Cet outil est très répandu dans les grandes entreprises de nos jours. Objectif Un entrepôt de données a pour objectif principal de fournir rapidement et de façon fiable des informations utiles à la prise de décision [CERTA, 1996]. Pour cela, il faut restructurer des informations afin de les rendre plus facilement compréhensibles et utilisables. Il faut par conséquent extraire, transformer et agréger les données à traiter. La figure suivante illustre l'architecture d'un data warehouse. Info. Externes et Internes EIS, Requeteur Données Opérationnelles Extraction Transformation Data Warehouse Data Mining OLAP Tableurs Filtrage data mart Analyse Statistique méta données Dévpt GUI Notes Figure 9 : Architecture d'un data warehouse Les données en question proviennent de sources hétérogènes, c'est-à-dire des différentes bases de production de l'entreprise. Elles sont non volatiles, du fait que l'on conserve leur historique, ce qui permet de retrouver la valeur d'une donnée devenue obsolète depuis plusieurs mois déjà. De plus, les données sont organisées, coordonnées, intégrées et stockées 40 / 124

41 Etat de l'art afin de donner à l'utilisateur une vue intégrée. Enfin, la restitution des informations doit être rapide et elle doit se faire sous la forme souhaitée par l'utilisateur. Le data warehouse utilise le principe des métadonnées afin d'améliorer notamment ses performances. Les métadonnées Les métadonnées jouent un rôle important dans le data warehousing. Avant qu'un entrepôt de données puisse être accédé efficacement, il est nécessaire de comprendre quelle données est disponible dans l'entrepôt et où elle se situe. En plus de l'emplacement de la donnée dont les utilisateurs finaux ont besoin, la métadonnée peut contenir : un dictionnaire de données contenant les définitions des Bases de Données maintenues et les relations entre les éléments de données ; un flux de données constituant le mode d'emploi et la fréquence d'alimentation des données ; la transformation des données regroupant les transformations nécessaires quand la donnée est transportée ; le contrôle de versions correspondant au stockage des changements de la métadonnée ; les statistiques d'utilisation des données fournissant un profil des données dans l'entrepôt ; les informations d'alias : ce sont les noms d'alias pour un champ ; la sécurité pour connaître qui a l'autorisation d'accès à la donnée. La figure 7 illustre la façon dont les informations contenues dans une métadonnée peuvent être extraites. La donnée est extraite de la base de données périodiquement (ce qui, sur notre schéma, correspond à la fréquence d'extraction). Cette donnée est ensuite traitée puis stockée dans l'entrepôt de données. De plus, chaque utilisateur de l'entrepôt peut consulter les données selon des autorisations spécifiques à chaque type d'utilisateurs. Certaines données peuvent alors être cachées à des utilisateurs, alors que d'autres auront un accès total sur les données. 41 / 124

42 Etat de l'art Fréquence d'extraction Donnée dans le Data warehouse Base de Données donnée Transformation de la donnée versions Stat.d'utilisation Extraction Autorisation Figure 10 : illustration des informations contenues dans une métadonnée 2.5. Conclusion Dans le cadre de notre étude, le principe de data warehouse est très intéressant. En effet, il permet de stocker un grand nombre d'informations, non seulement sur les données ellesmêmes mais aussi sur les traitements qu'elles subissent. De plus, un entrepôt de données permet de stocker des données non volatiles et permet aussi de conserver leur évolution au cours du temps. Ces données peuvent être remaniées, et c'est d'ailleurs bien souvent le cas. En revanche, pour notre étude, les données considérées ne doivent pas être remaniées. Elles doivent être accessibles en temps réel, à jour, et dans leur format d'origine. Le principe de l'entrepôt est donc intéressant mais pas complet. C'est pourquoi nous nous en inspirons en l'adaptant aux besoins de l'étude. 42 / 124

43 Etat de l'art 3. Les systèmes de recherche d'information dans des bases de données hétérogènes 3.1. Généralités La recherche d'informations concerne tous les types de données. Le problème est bien souvent de trouver un système qui permette d'interroger plusieurs bases de données dont les données sont de types très différents (comme des données textuelles, des données images, etc.). Bien souvent, un système de recherche d'informations performant se concentre sur un type de données bien particulier (données textuelles non structurées, données alphanumériques, données sonores, etc.). Lorsqu'il faut prendre une décision, le décideur a besoin d'accéder à divers types de données, et bien souvent, il lui faut alors interroger plusieurs systèmes afin de réunir toutes les données qui lui sont nécessaires pour prendre sa décision. De plus en plus, des systèmes permettant l'accès à plusieurs types de données émergent. Ces systèmes permettent d'interroger plusieurs bases de données grâce à une seule requête, bien souvent selon un modèle prédéfini, afin de répondre rapidement à un utilisateur. Ces systèmes utilisent, généralement, des "vues" prédéfinies, c'est-à-dire une image d'une base de données à un instant donné, qui permet d'accéder aux informations de la base sans avoir à interroger celle-ci Architecture générale La création d'un système d'accès à des bases de données hétérogènes implique bien souvent la réutilisation de bases de données existantes. Le problème est alors de concevoir un système capable de retrouver une information quel que soit le type de la donnée recherchée. De plus, il faut connaître les bases de données à interroger afin de connaître leur langage d'interrogation et leur structure avant de les interroger. De nombreuses études ont déjà été réalisées sur le sujet. Certaines proposent d'utiliser des bases de données fédérées [Hainaut et al, 1999][Sheth et Larson, 1990]. 43 / 124

44 Etat de l'art Mais d'autres propositions s'appuient sur le principe des médiateurs / wrappers, afin de limiter les connaissances sur les bases à interroger ainsi que les modifications à réaliser sur les bases en question Les wrappers et médiateurs Afin de limiter les modifications directes des SGBD dédiés à chaque bases de données à interroger, de nombreuses architectures s'appuient sur le principe du wrapper [Wiederhold, 1992] [Wiederhold, 1995] [Vassalos et Papakonstantinou, 1999]. Un wrapper joue le rôle, de façon générale, d'un traducteur. Il traduit une requête donnée dans un langage A en une requête en langage B. Chaque wrapper est dédié à une seule base de données. Par exemple, on peut construire un wrapper afin de traduire une requête XML en une requête SQL, destinée à une base de données relationnelle. Un wrapper permet donc de dialoguer avec une base de données à partir d'un langage commun, comme par exemple XML. D'autre part, pour savoir quels wrappers interroger, on utilise des médiateurs (voir Figure 11). Un médiateur a pour rôle de diriger les requêtes vers les wrappers concernés. Il possède pour cela la connaissance nécessaire qui lui permet de savoir quel wrapper est rattaché à quelle base et comment l'atteindre. De nombreuses études ont été réalisées sur le principe médiateur/wrapper [Ludäscher et Gupta, 1999a] [Papakonstantinou et al, 1995] [Papakonstantinou et al, 1996]. Généralement, ces propositions considèrent des vues (matérielles ou virtuelles) de la base de données considérée et travaillent par matching entre la requête envoyée au wrapper et la vue de la base de données. Certaines études prennent aussi en compte le caractère structuré ou semi-structuré des données [Papakonstantinou et Vassalos, 1999] [Papakonstantinou et Velikhov, 1999]. 44 / 124

45 Etat de l'art Médiateur Médiateur question réponse Wrapper Wrapper Wrapper Base de données Base de données Base de données Figure 11 : Principe schématique des médiateurs et wrappers 3.4. Exemples de systèmes De nombreux systèmes utilisant le principe des médiateurs et des wrappers sont en cours de développement. Ils restent, pour l'instant, au stade universitaire, même si certaines entreprises utilisent déjà, dans leur développement, l'idée des wrappers, sans pour autant leur en donner le nom. Les sections qui suivent présentent quelques-uns de ces systèmes en cours de développement, dont nous nous sommes inspirés pour construire l'architecture de notre système WHIPS Le système WHIPS (Warehouse Information Prototype at Stanford ) [Labio et al, 1997] s'inspire du principe de data warehouse. Les sources des données de l'entrepôt peuvent être distribuées et hétérogènes Rappelons que deux composants principaux constituent un data warehouse : un composant d'intégration, qui collecte et maintient les vues matérialisées, et un composant de requêtes et d'analyse, qui a pour but de compléter l'information demandée par l'utilisateur final. Il est à noter que les vues matérialisées par le composant d'intégration dépendent fortement des besoins exprimés par l'utilisateur final. Le projet WHIPS se concentre sur la partie intégration de l'entrepôt. Une architecture a été développée ainsi qu'un prototype pour identifier les changements de données des sources 45 / 124

46 Etat de l'art hétérogènes, les transformer et les résumer selon les spécifications du data warehouse, et les intégrer de façon incrémentale dans le data warehouse. La modularité de leur architecture permet entre autres : d'ajouter et de supprimer des sources de données et des vues dynamiquement, de détecter automatiquement les changements dans les sources de données, d'avoir un data warehouse toujours cohérent avec les données des sources grâce à des algorithmes d'intégration. La Figure 12 illustre le principe de WHIPS, tandis que la Figure 13 présente le composant d'intégration d'un data warehouse, pour représenter l'architecture du système WHIPS. Gestionnaire de vues Intégrateur Application Client Moniteur Moniteur Moniteur Info Source Info Source Info Source Figure 12 : schématisation du processus du système WHIPS 46 / 124

47 Etat de l'art Administrateur Spécificateur de vue Data warehouse Intégrateur wrapper wrapper Gestionnaire de vues Gestionnaire de vues Stockage de métadonnées Processeur de requêtes Moniteur wrapper Moniteur wrapper wrapper Moniteur Source 1 Source 2 Source n Figure 13 : Architecture du système WHIPS pour la maintenance de l'entrepôt de données Le système WHIPS est composé de nombreux modules distincts, qui communiquent les uns avec les autres bien qu'ils soient, potentiellement, sur des machines différentes. Les données du data warehouse sont représentées selon le modèle relationnel : les vues sont définies dans ce modèle et l'entrepôt stocke les relations. En ce qui concerne les divers modules, le moniteur est responsable de la détection des modifications des données sources et de leur notification à l'intégrateur. les wrappers, quant à eux, traduisent des requêtes simples d'une représentation relationnelle interne en des requêtes dans le langage natif de la source. Par exemple, un wrapper de base de données relationnelle ne pourra traduire que des expressions relevant de l'algèbre relationnelle en SQL. L'utilisation d'un wrapper par source cache les détails d'interrogation (spécifique à la source) au processeur de requêtes et aux autres modules : tous les wrappers supportent la même interface de méthodes bien que leur code interne dépende de leur source. Le wrapper du data warehouse reçoit les définitions de vues et les modifications pour les données de vue dans un format (interne) canonique, et les traduit dans la syntaxe spécifique à la base de données de l'entrepôt. Le wrapper protège ainsi tous les autres modules dans le système WHIPS des 47 / 124

48 Etat de l'art détails de l'entrepôt. Toutes les modifications reçues par le wrapper de l'entrepôt dans un seul message sont appliquées à l'entrepôt en une seule transaction. Les vues sont définies dans un sous-ensemble de SQL. Lorsqu'une vue est définie, le descripteur de vue la traduit, ajoute des informations pertinentes (comme les attributs clés, les types d'attributs, etc.), puis l'envoie à l'intégrateur. Ce dernier a pour principal rôle de faciliter la maintenance des vues en calculant quelles modifications de sources ont besoin d'être propagées dans les vues. Il existe un module de gestion de vues, responsable du maintien de chaque vue. Le processeur de requêtes, quant à lui, reçoit les requêtes globales des gestionnaires de vues et pose les requêtes appropriées à chaque source aux wrappers afin qu'ils y répondent. Il passe ensuite les réponses aux gestionnaires de vues SQUIRREL Ce projet [Hull et Zhou, 1996] est en cours de développement à l'université du Colorado. Il fournit une structure pour l'intégration de données basée sur la notion de médiateur d'intégration. Ce médiateur d'intégration est un module actif qui supporte les vues intégrées sur des bases de données multiples. Un médiateur Squirrel consiste en un processeur de requêtes, un processeur de mise à jour incrémentale, un processeur d'attribut virtuel et un système de stockage pour stocker les vues matérialisées. Ces médiateurs sont générés à partir de spécifications de haut niveau. Dans un médiateur, une vue peut être pleinement matérialisée, partiellement matérialisée ou encore complètement virtuelle. Les requêtes qui sont envoyées au médiateur sont traitées par le processeur de requêtes en utilisant la vue matérialisée ou en accédant à la base de données source, si l'information nécessaire n'est pas stockée dans le médiateur. Le processeur de mise à jour maintient les vues matérialisées de façon incrémentale, en utilisant les mises à jour incrémentales des sources. Le processeur de mise à jour virtuel accède aux sources, si l'information pour répondre à la requête n'est pas disponible au niveau du médiateur. Une des caractéristiques clés de tels composants est leur aptitude à maintenir de façon incrémentale les vues intégrées en comptant sur les capacités actives des sources. L'architecture d'un médiateur Squirrel consiste en trois composants : un ensemble de règles actives, un modèle d'exécution pour ces règles, et un Plan de Décomposition de Vues (VDP). 48 / 124

49 Etat de l'art La notion de VDP est analogue à celle du plan de décomposition de requêtes dans l'optimisation de requêtes. Plus spécifiquement, le VDP spécifie les classes que le médiateur maintient, et fournit la structure de base pour supporter la maintenance incrémentale. La Figure 14 présente l'architecture d'un médiateur Squirrel. Requêtes Réponses Médiateur Squirrel Processeur de requêtes Processeur de mise à jour incrémentale Portion matérialisée de la vue et des données supportées File d'attente des mises à jour des sources Processeur d'attribution virtuel VDP Base de règles Mises à jour incrémentales polling de sources Collaborateur matérialisé de BDs Collaborateur hybride de BDs Collaborateur virtuel de BDs Figure 14 : Schématisation du système Squirrel Une extension de la structure de Squirrel dans laquelle à la fois les vues intégrées complètement virtuelles et les vues partiellement matérialisées sont supportées est présentée dans [Hull et Zhou, 1996]. La qualité des données est évaluée en définissant des propriétés formelles de cohérence et de fraîcheur pour les vues intégrées, et en montrant que les médiateurs de Squirrel générés automatiquement satisfont de telles propriétés, quand les sources et le réseau respectent quelques assomptions "naturelles". Enfin, une taxonomie de l'espace de solutions pour l'intégration des données est présentée, les situations mises en avant où soit une partie soit toute l'information intégrée est matérialisée. 49 / 124

50 Etat de l'art TSIMMIS TSIMMIS (The Stanford-IBM Manager of Multiple Information Source) [Garcia-Molina et al, 1997] [Hammer et al, 1997] [Li et al, 1998] [Chawathe et al, 1994] est un projet qui a pour objectif de produire des outils pour l'accès intégré à des sources d'information et des entrepôts multiples et divers. Chaque source d'information est équipée d'un wrapper (voir Figure 15) qui encapsule la source, en convertissant les objets de données considérés en un modèle de données commun. Dans TSIMMIS, un modèle de données orienté objet simple appelé Modèle d'echange d'objet (Object Exchange Model : OEM) est utilisé. Au-dessus des wrappers, TSIMMIS propose un autre type de composant : le médiateur. Chaque médiateur obtient les informations de un ou plusieurs wrappers ou d'autres médiateurs, traite ces informations en intégrant et en résolvant les conflits entre les fragments d'information des différentes sources, et fournit l'information résultante à l'utilisateur ou aux autres médiateurs à tour de rôle. Les médiateurs peuvent être conceptuellement vus comme des vues sur les données trouvées dans une ou plusieurs sources qui sont convenablement intégrées et traitées. Le médiateur est défini en termes de langage logique appelé MSL, qui est essentiellement un Datalog étendu pour supporter les objets OEM. Typiquement, les médiateurs réalisent des vues virtuelles puisqu'ils ne stockent pas les données localement. Cependant, il est possible qu'un médiateur matérialise la vue qu'il fournit. Quand un utilisateur pose une question au système, un médiateur spécifique est sélectionné. Un tel médiateur décompose la requête et propage les sous-requêtes résultantes aux niveaux inférieurs (soit des wrappers, soit des médiateurs). La réponse fournie par de tels niveaux est alors reconstruite en réalisant les étapes à la fois d'intégration et de traitement (en utilisant des techniques out-of-the-shelf). Le langage de requêtes de TSIMMIS est un SQLlike, adapté afin de traiter convenablement les objets OEM. L'ajout d'un nouvelle source d'information à TSIMMIS nécessite la construction d'un wrapper pour la source et de changer tous les médiateurs qui utilisent la nouvelle source. La recherche à l'intérieur du projet TSIMMIS combine des techniques pour générer automatiquement les wrappers et les médiateurs. 50 / 124

51 Etat de l'art User input Toolkit Application Source specific Query Translated Result Source Schema Templates Driver Parser Matcher Engine Native Wrapper Native Query Native Result Source Figure 15 : Schématisation du principe du système Tsimmis 3.5. Conclusion Après avoir étudié ces systèmes et aux vues de nos besoins, nous nous sommes inspirés de l'architecture des médiateurs / wrappers du système TSIMMIS. En revanche, le fait d'utiliser des vues ne nous semble pas intéressant dans notre cas. En effet, les questions posées par les utilisateurs ne sont généralement pas calquées sur un ou deux modèles prédéfinis. Toutes les requêtes sont imprévisibles, ce que nous prenons en compte dans le sens où nous permettons à l'utilisateur de poser sa requête à partir de termes du langage naturel. Par conséquent, l'utilisation de vues n'est pas retenue. De plus, afin de répondre de la façon la plus adéquate possible aux requêtes des utilisateurs, nous utilisons une base de connaissances, qui contient toute la connaissance nécessaire pour trouver toutes les réponses utiles à l'utilisateur selon la requête initiale posée. Nous détaillerons cette partie dans le chapitre sur le "système d'accès". 51 / 124

52 Un système d'accès à des bases de données hétérogènes Chapitre 4 Architecture d'un système d'accès à des bases de données hétérogènes : SABaDH 1. Un système d'accès à des bases de données hétérogènes 1.1. Rappel de la problématique Le but de notre projet est de permettre à un décideur d avoir accès à toutes les informations qui lui sont nécessaires pour sa prise de décision. Le profil d un décideur est variable, dans le sens où celui-ci peut être un expert du domaine de recherche (par exemple un juriste dans notre cas d étude), un expert des bases de données interrogées (par exemple un administrateur) ou bien un utilisateur non expert du domaine de recherche ni des bases de données. Les informations recherchées sont stockées dans des bases de données hétérogènes et réparties. Lors de l interrogation de ces bases, plusieurs problèmes sont à prendre en compte : le problème du volume de données : les données sont très nombreuses, et le volume des données à considérer dans le domaine de recherche ne cesse de croître ; le problème des données hétérogènes : les données de types différents sont stockées dans des bases de données distinctes, parfois sur des sites physiques différents et distants. Le problème des bases de données réparties se pose alors. De plus, il faut être capable de communiquer rapidement et de façon sûre avec chaque base de données afin de récupérer en réponse seulement (ou avec une marge d'erreur acceptable par l'utilisateur) les données pertinentes ; le problème de la représentation des données : l'utilisateur, dans bien des systèmes, doit connaître une partie de la représentation des données pour formuler sa requête. Permettre à un utilisateur de formuler sa requête sans qu'il sache comment sont représentées les données donne une liberté plus grande à l'utilisateur et permet d'être moins dépendant des bases de données. Il est donc nécessaire de réduire l'espace de recherche, par exemple par une sélection. Il faut aussi permettre l'interrogation des bases de données par l'utilisateur selon le langage naturel (ou pseudo-naturel), sans connaître la représentation des données. Celle-ci n'est connue que par le système, qui peut ensuite faire traduire la requête par un sous-élément en 52 / 124

53 Un système d'accès à des bases de données hétérogènes une sous-requête destinée à une base de données en particulier, et rédigée en un langage compréhensible par le SGBD gérant la base de données en question. Dans notre étude, nous nous intéressons en particulier au problème d'interrogation des bases de données. Il est à signaler qu en général, les prises de décision sont réalisées en collaboration avec d'autres collègues, chacun détenant une partie des données nécessaire à cette prise de décision. Mais de nos jours, une seule personne peut avoir accès à toutes les données qui lui sont nécessaires. Encore faut-il qu'il puisse les retrouver rapidement et facilement parmi toutes les données gérées par l'entreprise EXEMPLES DE PRISES DE DÉCISION Afin de mieux cerner le type de décision qui peut être prise en compte dans le cadre des allocations familiales, nous allons étudier trois exemples. Le premier concerne une analyse d'impact, le second traite des notifications de droits de paiement, et le dernier illustre une décision d'ouverture de nouvelle permanence Analyse d'impact Selon le contexte dans lequel il est utilisé, le terme texte réglementaire peut être appréhendé de différentes façons. Ainsi, les juristes établissent la distinction entre les textes législatifs et les textes réglementaires, alors que d autres personnes peuvent considérer qu un texte est un texte réglementaire à partir du moment où celui-ci exprime un ensemble de règles. Afin d éviter toute ambiguïté, il est primordial de fixer précisément le concept que recouvre, pour nous, cette expression. Nous nous appuierons sur la définition posée par B. Chabbat [Chabbat, 1997]: un texte réglementaire est, de manière générique, un texte exprimant une réglementation liée à la législation, en dehors de toute considération quant à leur valeur juridique. Les textes réglementaires possèdent des spécificités qui les distinguent des autres types de textes que l on a coutume d analyser et de gérer dans le domaine de la modélisation de documents.a partir de ces textes, la CNAF rédige un Suivi Législatif (texte interne à l institution), rédigé en termes moins spécialisés pour permettre à des non-juristes de comprendre plus facilement les lois, décrets et autres textes afin de les mettre en application. Avant de modifier un texte, il est bien souvent nécessaire de mesurer l'impact d'une éventuelle modification. En effet, cela peut entraîner un changement du nombre d'allocataires, 53 / 124

54 Un système d'accès à des bases de données hétérogènes ou bien un changement des allocations versées, Selon l'objectif voulu, le résultat de l'analyse entraîne la modification effective du texte ou bien l'annule. La Figure 16 illustre un exemple d'analyse d'impact. Le décret n du 2 février "Le montant mensuel du Revenu Minimum d'insertion mentionné à l'article 3 de la loi du 1er décembre 1988 modifiée susvisée est porté à 2253,02 F au 1er janvier en France métropolitaine" 1 Interrogation 2 Nombre de Textes? Nombre de fragments? Interrogation 3 4? Nombre de règles? Lesquelles? De quelle manière? N d étape dans l'exécution de l'analyse Nombre d'allocataires Profil de ces allocataires... Interrogation 5 6 résultat Textes réglementaires Règles de systèmes experts Données Allocataires Figure 16 : Illustration d'une analyse d'impact Dans l'exemple ci-dessus, le montant du Revenu Minimum d'insertion est modifié pour être porté à 2253,02 Francs, à partir du 1 er janvier. Pour connaître toutes les conséquences de la modification de la loi, il faut : rechercher tous les textes ayant un lien (de référence, de partage d'information, voir 3.1.b Les liens) avec la loi à modifier (étapes 1 et 2 du schéma), rechercher les règles, extraites de tous ces textes, qui sont susceptibles d'être modifiées elles aussi (étapes 3 et 4 du schéma), rechercher enfin les allocataires qui pourraient être affectés par la modification de cette loi à travers le versement d'une ou plusieurs allocations, dont le montant pourrait être révisé ou même dont l'allocation pourrait être supprimée (étapes 5 et 6 du schéma). Lorsqu une décision de ce type est en cause, le décideur ne sait pas, à priori, quelles bases interrogées, et notamment la base de règles. C est au système de déterminer quelles sont les bases à interroger, et dans quel ordre. Ici, le système doit être capable de savoir qu il lui faut 54 / 124

55 Un système d'accès à des bases de données hétérogènes interroger la base de textes en premier lieu, ensuite la base de règles (en réutilisant les résultats de la première interrogation), et enfin la base des allocataires (en réutilisant aussi les résultats de la seconde interrogation). Le système présente alors les résultats à l utilisateur, sans que celui-ci n ait connaissance de toutes les interrogations qui ont été réalisées Notification de Droit de Paiement Parmi les diverses bases que nous considérons dans notre projet, il en est une qui contient des informations sur les allocataires (que nous désignons comme la "Base Allocataires"). Cristal est un système qui permet de déterminer, en temps réel, les droits de ces allocataires. Il se peut que parfois, la révision des droits de l'allocataire entraîne des Notifications de Droit de Paiement (NDP), c'est-à-dire une lettre informant l'allocataire soit de ce qu'il doit rembourser à sa caisse d'allocations, soit ce que la caisse d'allocations familiales lui doit. Un système automatique est chargé d'envoyer ces notifications, mais il se peut que certaines incohérences (du point de vue de l'allocataire) existent. Notamment, deux notifications jugées "contradictoires" par l'allocataire (par exemple l'une demandant un remboursement à l'allocataire, et l'autre lui annonçant un virement), peuvent lui être envoyées, suite à diverses manipulations des informations relatives à l'allocataire. Dans ce cas, le contenu des notifications peut engendrer des confusions. Il est donc nécessaire, lors de la détection de ce genre d'incohérences, de prendre une décision : soit on conserve telles quelles toutes les notifications, car chacune apporte une information, non "contradictoire" avec une autre, soit on réunit toutes les notifications en une seule, qui est la synthèse de toutes les notifications à envoyer à cet allocataire, soit on décide de l'annulation pure et simple des notifications (toutes ou partie). La Figure 17 illustre le système actuel qui permet à un technicien de décider s'il faut conserver les deux NDP, s'il faut les réunir en une seule NDP, etc. 55 / 124

56 Un système d'accès à des bases de données hétérogènes NDP CRISTAL Destinataire de l'anomalie Liste des anomalies Format XES Interface Utilisateur + ACCESS SQ Notifications Word générées Consultation des NDP et corrections SQ Cristal Word Pilote de consultation des NDP SQ : Station Qualité XES : Format propriétaire Cristal Cristal : Système de gestion en temps réel NDP : Notification de Droit de Paiement Figure 17 : Présentation de l'architecture du système actuel de traitement des NDP LES NDP sont exportées dans un format propriétaires XES vers un programme qui ensuite permet la consultation des notifications en format Word. Le technicien peut alors consulter les trois écrans : celui de la station qualité, les notifications qu'il choisit, les informations relatives à l'allocataire à qui sont destinées les NDP traitées. Ce système nécessite de connaître à la fois le système Cristal pour les informations allocataires et le système de la station qualité, ainsi que Word, pour reprendre éventuellement le contenu d'une NDP. La figure ci-après illustre le processus de décision lors de la détection d'une incohérence entre deux notifications. 56 / 124

57 Un système d'accès à des bases de données hétérogènes résultats Nous avons étudié vos droits. Nous vous devons 576 F. NDP 1 Vous nous devez 1596 F, à nous rembourser le plus rapidement possible. NDP 2 NDP 1 NDP 2 Interrogation Cristal SID NDP : Notification de Droit de Paiement SID : Système d'information Décisionnel Textes réglementaires Décision fusion Cristal : Système de gestion en temps réel NDP 3 Aucun envoi Figure 18 : Illustration du traitement suite à des incohérences dans les NDP Lors d'une telle prise de décision, le système d'aide à la décision étudié (c'est-à-dire SABaDH, cf Chapitre ) peut fournir toutes les informations concernant l'allocataire traité, c'est-à-dire les textes appliqués, les décisions prises et les données de l'allocataire, sans que le décideur (ici, le technicien) n'ait pour autant à connaître les différents systèmes impliqués (Cristal, SID, la base de textes réglementaires ). 57 / 124

58 Un système d'accès à des bases de données hétérogènes Ouverture d'une nouvelle permanence Chaque caisse d'allocations familiales (CAF) a de nombreux dossiers à traiter. Parfois, afin entre autres de décharger sa CAF et d'améliorer le service auprès des allocataires, un directeur de CAF peut décider d'ouvrir une permanence qui prendra en charge, notamment, une partie des allocations pour une zone géographique donnée. Dans cette zone, le nombre d'allocataires percevant lesdites allocations est tel que la CAF est déchargée d'une grande partie du travail. Pour ouvrir cette permanence, il faut savoir, entre autres : quelles sont les allocations qui entraînent la plus grande charge de travail ; par quel(s) type(s) d'allocataire(s) ces allocations sont perçues, afin ensuite de déterminer (approximativement) où doit se situer la permanence afin que le plus grand nombre des allocataires concernés n'aillent plus directement à la CAF mais à la permanence ; si les fonds budgétaires permettent la construction et l'utilisation de cette nouvelle permanence, etc. Toutes les données à consulter sont différentes : elles sont stockées dans des bases différentes, certaines d'entre elles sont même externes à l'institution, comme les données fournies par l'insee 22 et permettant de déterminer le lieu géographique de résidence d'un allocataire. Il faut consulter non seulement des données hétérogènes, mais aussi des données externes, distantes. La Figure 19 illustre les différents types de données à consulter lors de la prise de décision de l'ouverture d'une nouvelle permanence. 22 INSEE : Institut National de la Statistique et des Etudes Economiques 58 / 124

59 Un système d'accès à des bases de données hétérogènes Interrogation Marchés publics Données Allocataires Thesaurus Données budgétaires Données INSEE Droit du travail DGI Situations génériques DII Stat. Assedic Système de gestion de données hétérogènes Utilisateur Décision DII : Dictionnaire d'information Institutionnel DGI : Direction Générale des Impôts INSEE : Institut National de la Statistique et des Etudes Économiques Figure 19 : illustration du processus de prise de décision pour l'ouverture d'une nouvelle permanence Le décideur doit consulter : les données allocataires, afin de déterminer quelles sont les allocations les plus allouées et nécessitant, par conséquent, le plus de travail ; les situations génériques pour déterminer le type d'allocataires qui reçoit ces allocations ; le thesaurus, afin de rechercher selon des mots génériques, et pas seulement sur certains mots, ou certaines allocations, etc ; le DII pour rechercher selon des termes génériques spécifiques à l'institution ; les données INSEE, afin de déterminer dans quelle région, à priori, le type d'allocataires concernés se situe ; les statistiques des Assedic afin de déterminer, d'une façon globale, la situation des types d'allocataires retenus ; le DGI pour connaître, approximativement, les revenus du type d'allocataires retenu ; les données budgétaires, pour savoir si la CAF a les moyens de construire une nouvelle permanence ; les marchés publics, pour savoir qui pourrait réaliser cette construction (ou pour trouver un local à louer) ; 59 / 124

60 Un système d'accès à des bases de données hétérogènes le droit du travail, pour recruter de nouveaux employés ou muter certains employés dans la nouvelle permanence. Cette liste n'est pas exhaustive, mais elle permet d'illustrer le nombre de données, diverses et variées, qu'il faut consulter, le fait que ces données puissent être externes à l'institution, et le fait qu'elles soient de natures très différentes. Il faut néanmoins préciser que les recherches effectuées sur les données externes à l'institution (comme celles de l'insee ou de la DGI) ne concernent qu'un regroupement type de personnes. En aucun cas les noms ou des données trop précises ne sont récoltées, et ce afin de préserver la liberté de chacun Caractéristiques du système Comme nous l'avons dit précédemment, puis illustré avec les quelques exemples précédents, une prise de décision nécessite l'accès et la consultation à des types variés de données, généralement stockés sur des sites distincts et distants. De plus, l'utilisateur (c'est-àdire le décideur) ne sait pas toujours à l'avance la totalité des données qu'il doit consulter pour sa prise de décision, ni l'emplacement de ces données. Un autre aspect de l'interrogation est à prendre en compte : la requête de recherche de données peut provenir d'un utilisateur (c'est-à-dire un décideur, bien que le profil de ce dernier puisse être multiple, par exemple un directeur, un technicien conseil, un juriste, etc.), ou bien qu'une application (dans le cas où notre système sert de relais entre les bases de données et une autre application). Dans le cadre de notre étude, nous nous intéressons dans un premier uniquement à l'utilisateur humain. Nous distinguons alors plusieurs profils d'utilisateur : un profil pour l'expert du domaine de recherche (par exemple les juristes), mais non expert en informatique ; un profil pour l'expert en informatique mais non expert du domaine de recherche (par exemple les concepteurs d'applications qui recherchent des informations en vue de créer une nouvelle base de données) ; enfin, un profil pour un utilisateur non expert du domaine de recherche ni en informatique, mais qui possède une culture générale, non précise (par exemple les techniciens conseil). Le système se doit d'être convivial, et dans ce but, la requête posée utilise le plus possible des termes du langage naturel, permettant ainsi à l'utilisateur (quel qu'il soit) de ne pas avoir à apprendre un nouveau langage d'interrogation. Le système utilise ensuite un thesaurus afin de 60 / 124

61 Un système d'accès à des bases de données hétérogènes généraliser la requête, ainsi qu'un dictionnaire d'information qui regroupe les termes les plus usités dans l'institution. Ce dernier s'apparente à un thesaurus mais n'utilise pas toutes les relations de celui-ci (on ne prend pas en compte les parents grammaticaux, mais plutôt les synonymes, les sigles, les définitions de termes, etc.). Enfin, il faut prendre en compte que l'utilisateur ne connaît pas forcément l'emplacement des données à rechercher. En effet, il sait que ces données existent, mais il ignore quelle base de données les stockent et où se situe cette base de données. De même, les liens pouvant exister entre les données ne sont généralement pas connus par l'utilisateur (par exemple le fait qu'une règle est générée à partir d'un ou plusieurs texte juridique n'est pas connu par l'utilisateur). Néanmoins, certains de ces liens peuvent être indispensables à la recherche de toute l'information utile et pertinente pour la prise de décision. C'est donc au système d'avoir cette connaissance afin de fournir à l'utilisateur les réponses les plus pertinentes. La cinématique suivante illustre un exemple de recherche en vue d'une prise de décision à l'aide du système d'accès. "Impact de la modification 'xxx' de la loi n ? " Système d accès aux bases de données Base de textes juridiques Base de règles Base de données allocataires Le décideur pose sa requête au système. Thesaurus Base de connaissances 61 / 124

62 Un système d'accès à des bases de données hétérogènes "Impact de la modification 'xxx' de la loi n ? " 0 Impact Modifier Loi n Allocation Système d accès aux bases de données Base de textes juridiques Base de règles Base de données allocataires Loi -> Base de textes juridiques -> Allocation Base liée à Base de règles par allocation dans prédicats Base de règles liée avec Base allocataires par allocation(s) perçue(s) 1 Le système analyse la requête afin de déterminer les données à rechercher. Pour cela, il utilise un thesaurus et une base de connaissances. Thesaurus Base de connaissances "Impact de la modification 'xxx' de la loi n ? " Système d accès aux bases de données Le système recherche ensuite les données dans les bases de 2 3 Loi -> APE 1 données concernées, et, dans notre exemple, commence par la 0 Base de Textes Juridiques. Il y Base de textes juridiques Base de règles Base de données allocataires recherche de l'allocation traitée par le texte recherché. Thesaurus Base de connaissances "Impact de la modification 'xxx' de la loi n ? " 0 Thesaurus Système d accès aux bases de données 2 3 Base de textes juridiques 4 5 Base de règles RMI -> prédicats gauche, API -> prédicats gauche, APJE -> prédicats gauche, CF -> prédicats gauche, Allocation différentielle -> prédicats gauche, AGED,... Base de données allocataires 1 Base de connaissances Il recherche ensuite, dans la base de règles, les différentes allocations liées à celle du texte recherché (c'est-à-dire l'allocation Parentale d'education : APE), afin de déterminer toutes les incidences d'une éventuelle modification du texte de loi. 62 / 124

63 Un système d'accès à des bases de données hétérogènes "Impact de la modification 'xxx' de la loi n ? " 0 Thesaurus Système d accès aux bases de données 2 3 Base de textes juridiques 4 5 Base de règles 6 7 Base de données allocataires Nombre des allocataires concernés par les différentes allocations trouvées en 5, selon lesdites allocations 1 Base de connaissances Le système recherche ensuite dans la base des allocataires tous ceux qui perçoivent une des allocations trouvées dans l'étape précédente. Il en récupère le nombre total, selon chaque allocation. "Impact de la modification 'xxx' de la loi n ? " Réponse fournie à l'utilisateur 8 Enfin, le système renvoie à l'utilisateur la réponse à sa requête. Système d accès aux bases de données Thesaurus Base de textes juridiques Base de règles Base de données allocataires Base de connaissances Nous pouvons dire que le système d'accès, que nous voulons générique, utilise en entrée une requête utilisateur pour fournir en sortie une réponse au format XML du côté utilisateur. Du côté des bases de données, le système envoie des sous-requêtes au format XML (pour conserver la généricité) et utilise des wrappers (voir ) pour interroger les bases de données. De plus, la connaissance qui lui est nécessaire pour comprendre la requête utilisateur afin de répondre de façon pertinente est contenue dans une base de connaissance. On obtient le schéma global et synthétique suivant : 63 / 124

64 Un système d'accès à des bases de données hétérogènes Requête utilisateur Réponse «XML» Système d accès Sous-requêtes «XML» Wrappers Bases de Données Base de connaissances Figure 20 : Schéma général des entrées/sorties du système d'accès Le système que nous avons développé permet : l'interrogation des bases de données de l'entreprise par différents types d'utilisateur, sans pour autant que l'utilisateur ait à connaître la structure des données recherchées; l'accès à des bases de données hétérogènes, à partir d'une unique requête utilisateur, en langage pseudo-naturel ; la visualisation de la réponse à la requête de façon compréhensible et conviviale. Nous avons vu précédemment qu'un des types utilisateur correspond aux administrateurs de bases de données. En effet, les concepteurs de bases de données peuvent avoir besoin de consulter les schémas des bases de données existantes afin de réutilisant autant que possible des parties de schéma déjà existant ou de réaliser des liens avec les bases de données existantes, etc. Le système doit par conséquent permettre de consulter les schémas, d'une façon uniforme afin de pouvoir ensuite les réutiliser, les comparer, etc. Nous utilisons pour cela XMI (cf. Chapitre ) et un dictionnaire d'informations afin d'homogénéiser les schémas des bases de données. Ceux-ci peuvent ensuite être présentés au format XML. Le système doit aussi connaître les liens entre données, entre bases de données, connaître l'emplacement exact des données à rechercher, etc. Toutes ces données complémentaires sont stockées dans une base de connaissances (cf Chapitre ). Celle-ci contient aussi les schémas des bases de données, selon un format homogène que nous détaillons plus tard. Notre système SABaDH (Système d'accès à des BAses de Données Hétérogènes pour l'aide à la décision) [Nicolle et al, 2000a] [Nicolle et al, 2000c] se compose des éléments suivants : 64 / 124

65 R = SRm Un système d'accès à des bases de données hétérogènes un analyseur de requêtes, qui permet au système de "comprendre" la requête de l'utilisateur avant son traitement, et ce en utilisant un thesaurus afin de "comprendre" les liaisons, synonymies et autres relations possibles entre les divers termes utilisés par l'utilisateur dans sa requête, un sous-requêteur, qui va être chargé de réaliser les diverses sous-requêtes, chacune destinée à une base de données en particulier, un aiguilleur, qui va dispatcher les sous-requêtes aux bases de données concernées, un rédacteur de réponse, qui va composer la réponse finale à partir notamment des réponses des bases de données. La Figure 21 présente le schéma général de notre système, avec ses principaux composants. Requête Utilisateur / Application Analyseur de de requêtes Thesaurus Réponse XML Rédacteur de de réponse réponse Base de Connaissances Module Module de de sous-requêtes Aiguilleur réponses X M L XML Système d'accès X M L X M L Wrapper Wrapper Wrapper SR 1 SR h SR m Base de données BD 1... Base de données BD h... Base de données BD m Figure 21 : Schéma général de notre système d'accès Notons que les wrappers, bien qu'externes à notre système d'accès, seront détaillés dans une prochaine section. En effet, le développement d'un wrapper est en général confié à l'administrateur de la base de données à relier au système. C'est lui qui connaît le mieux les données et leur structure ainsi que le langage de requêtes à utiliser pour cette base. Il est donc le plus approprié pour réaliser le wrapper. Néanmoins, une partie du wrapper est générique, 65 / 124

66 Un système d'accès à des bases de données hétérogènes quelle que soit la base de données considérée. C'est pourquoi nous détaillons cet élément en même temps que les autres éléments de notre système. La Figure 22 illustre quelques messages d'entrées / sorties traités lors de l'interrogation des bases de données en vue d'une aide à la décision (le cas de la recherche d'un schéma de bases de données ou d'une mise à jour de ces schémas n'est pas illustré sur le schéma). Requête Utilisateur Base de connaissances Analyseur de Requêtes Module de Sous-requêtes Sous-requêtes + requête initiale Filtre de décomposition Plan de séquencement Thesaurus Réponses Réponse finale Rédacteur de réponse Requête initiale Filtre de décomposition Plan de séquencement Aiguilleur Réponse Sous-requête Réponse Sous-requête Réponse Sous-requête Bd Wrapper Wrapper Bd Wrapper Bd Figure 22 : Schéma de notre système, avec les Entrées/sorties de chaque module 1.3. Composants du système d'accès Nous détaillons dans cette section les divers composants de notre système, leur rôle et éventuellement leur composition, ainsi que les messages qu'ils traitent, ainsi que les wrappers. En effet, l'architecture de ceux-ci est essentielle au bon fonctionnement de notre système. 66 / 124

67 Un système d'accès à des bases de données hétérogènes L'ANALYSEUR DE REQUÊTES La première étape du traitement d'une requête consiste comprendre cette requête, c'est-àdire à savoir ce que veut l'utilisateur. La requête initiale est rédigée dans un langage aussi proche que possible du langage naturel. Nous utilisons un "analyseur de requêtes" qui, à l'aide d'un thesaurus, analyse la requête afin de déterminer les données que l'utilisateur désire rechercher, et dans quel contexte. Il est alors possible de déterminer l'ordre dans lequel les données doivent être recherchées, ainsi que les liens entre les différents concepts trouvés. Par exemple, la requête "allocataires concernés par la loi XX-XXX", une fois analysée, permet de savoir que l'on recherche dans la base des allocataires et la base des textes juridiques, une loi étant un texte juridique. De plus, le fait que les allocataires soient "concernés par" permet de savoir que le résultat de la recherche dans la base des textes juridiques doit s'appliquer sur le résultat de la recherche dans la base allocataires. Le fait est qu'ici, l'analyseur ne possède pas la connaissance suffisante pour savoir qu'il faut aussi interroger la base de règles pour trouver en fait quelles allocations les textes juridiques trouvés permettent de calculer. Ensuite seulement on peut rechercher les allocataires concernés. Le résultat de l'analyse est par la suite envoyé au module suivant, c'est-à-dire au sousrequêteur. Exemple : Considérons la requête utilisateur suivante : "impact de la modification "du revenu net catégoriel pris en compte" de la loi n " L'analyseur de requête reçoit cette requête et l'analyse suivant le thesaurus à sa disposition. Il trouve le mot "impact", dont il déduit qu'il doit rechercher les liens entre l'objet de la requête et tout ce à quoi il peut être lié. Ensuite, il trouve "modification", ce qui correspond à un changement de la loi, quelque qu'il soit. Il doit donc considérer une mise à jour de l'objet de la requête. Il trouve enfin un objet qu'il connaît, "loi". Une loi est un texte juridique, et elle possède le numéro d'identification C'est l'objet de la requête. Il envoie donc au sousrequêteur ces informations au format XML. Celles-ci peuvent être de la forme : <rechercher> <objets> <condition> lies avec </condition> </objets> <objet recherche> <nom> loi </nom> <type> texte juridique </type> <identifiant> </identifiant> <condition> <chercher_chaine> 67 / 124

68 Un système d'accès à des bases de données hétérogènes "revenu net catégoriel" </chercher_chaine> </condition> </objet recherche> </rechercher> Ceci n'est qu'un exemple de formulation. La réalisation concrète n'ayant pas été réalisée, il ne s'agit pas ici d'une version définitive de l'analyse, mais seulement un aperçu. Outre les requêtes propres aux décideurs, il est possible de définir deux types de requêtes spécifiques, qui ne seront pas analysées par l'analyseur mais directement envoyées au sousrequêteur : la première permet à un concepteur de consulter un ou plusieurs schémas de base de données ; la seconde permet à un utilisateur (en général, l'administrateur) d'ordonner la mise à jour des schémas homogènes de bases de données. La Figure 23 représente les entrées / sorties de ce module. Requête Utilisateur Analyseur de Requêtes Résultat de l'analyse Vers module de sous-requêtes Thesaurus Figure 23 : Schéma des Entrées / Sorties de l'analyseur de requêtes LE SOUS-REQUÊTEUR Le sous-requêteur est un des principaux éléments du système d'accès. Il est aussi l'un des plus complexes. Son rôle est de décomposer la requête initiale afin d'élaborer les sousrequêtes à envoyer à chaque base de données qu'il faut interroger pour récupérer les données utiles à la prise de décision. 68 / 124

69 Un système d'accès à des bases de données hétérogènes Pour cela, il utilise le résultat préliminaire fourni par l'analyseur de requêtes, ainsi qu'une base de connaissances. Cette dernière contient toutes les informations nécessaires à la décomposition de la requête (voir ). Le sous-requêteur, à l'aide de cette base de connaissances, va déterminer : quelles bases de données interroger, quelles données doit-on y rechercher, quelles données "annexes" (c'est-à-dire non spécifiées par l'utilisateur mais qui ont un lien avec certaines données recherchées, et qui par conséquent pourraient être utiles au décideur) sont à rechercher et où les rechercher, si une sous-requête a besoin du résultat d'une autre sous-requête dans ses prédicats, dans quel ordre les sous-requêtes doivent être évaluées. Le sous-requêteur va alors élaborer : les diverses sous-requêtes (une par base de données à interroger) au format XML, un filtre de décomposition, qui définit comment la requête principale peut être reconstituée à partir des sous-requêtes élaborées, un plan de séquencement qui donne l'ordre dans lequel les sous-requêtes doivent être exécutées, et si une sous-requête a besoin d'un résultat d'une autre sousrequête dans ses critères de sélection, ce afin de réduire au mieux l'espace de recherche dans chaque base de données. Exemple : reprenons la requête utilisateur pris en exemple pour l'analyseur de requêtes. A partir de la première analyse reçue, le sous-requêteur va, à l'aide de la base de connaissances, déterminée : qu'un texte juridique (de type loi) est stocké dans la Base de Données Juridiques ; que la caractéristique d'un tel texte est une "allocation" ; qu'entre cette base et la Base de Règles, il existe un champ commun : "l'allocation" ; qu'entre la Base de règles et la Base d'allocataires, il existe un champ commun : "l'allocation". Par conséquent, les trois bases sont liées par le même champ : l'allocation. De plus, le fait de rechercher les liens entre l'objet de la requête (c'est-à-dire la loi) et les autres objets, implique d'interroger les trois bases, étant donné qu'une modification de la base de données juridiques peut entraîner une modification dans les autres bases au niveau des valeurs des champs. Il va donc élaborer les sous-requêtes destinées aux trois bases, sachant : qu'il lui faut le résultat de la base BDJ avant de lancer les autres requêtes, qu'il lui faut le résultat de la Base de Règles avant de lancer la requête sur la base des allocataires car dans la base de connaissances, il existe un lien qui permet de déterminer que les données de la base de règles s'appliquent sur les données de la base allocataire. Cette dépendance implique qu'une modification de la base de règles entraîne une modification dans la base des allocataires. De plus, il doit rechercher dans la base BDJ le texte de loi dont le numéro d'identifiant est et qui contient les mots "revenu net catégoriel pris en compte". Il pourra alors non seulement trouver l'allocation mis en 69 / 124

70 Un système d'accès à des bases de données hétérogènes cause, mais aussi les liens de ce fragment de texte avec d'autres données, qu'elles soient de type texte juridique ou autre. Il est sous-entendu que les liens entre les données structurées sont explicitement contenus dans une base ou du moins dans une table de la base BDJ. Sans cela, si les liens sont noyés dans la masse d'informations contenues dans la base, la recherche reste possible étant donné la base de connaissances, mais elle s'effectue moins rapidement. La figure suivante illustre les entrées/sorties de ce module. Requête initiale Résultat de l analyse Module de sous-requêtes Plan de séquencement Filtre de décomposition Sous-requêtes Vers l aiguilleur Base de connaissances Figure 24 : Schématisation des entrées/sorties du module de sous-requêtes 70 / 124

71 Un système d'accès à des bases de données hétérogènes FILTRE DE DÉCOMPOSITION Il permet de reconstituer la requête initiale à partir d'une combinaison des sous-requêtes élaborées par le sous-requêteur. On peut utiliser la convention suivante (non exhaustive) pour définir la façon dont les sous-requêtes s'imbriquent. SR1.SR3[..] (SR1).SR3[..] SR1.(SR3) [..] (SR1).(SR3) [..] SR1 + SR2 Jointure en conservant seulement les éléments de SR1 ayant un correspondant dans SR3 selon le champ [..] Il peut y avoir plusieurs champs à prendre en compte ; on garde alors les éléments qui ont des correspondants dans l'autre table selon tous les champs à prendre en compte (le OU n'est pas retenu) Jointure, comme précédemment, excepté que l'on conserve les éléments de SR1 qui n'ont pas de correspondant dans SR3 Jointure dont on conserve aussi les éléments de SR3 n'ayant pas de correspondant dans SR1 Jointure selon un élément mais on conserve malgré tout les éléments de SR1 et ceux de SR3 qui n'ont pas de correspondant dans l'autre table (on réunit en fait deux tables, sur leur totalité, selon un champ en particulier) On prend en compte tous les résultats de chaque sous-requête Le filtre de décomposition est utilisé par le rédacteur de réponse pour combiner les réponses des bases de données afin de répondre à la requête initiale PLAN DE SÉQUENCEMENT Le plan de séquencement permet à l'aiguilleur de savoir dans quel ordre il doit envoyer les sous-requêtes, et s'il doit attendre le résultat d'une sous-requête avant d'en envoyer une autre. Les conventions suivantes peuvent être utilisées afin de définir l'ordre des requêtes : 71 / 124

72 Un système d'accès à des bases de données hétérogènes SR1(SR2) SR1{SR2} SR1 - SR4 [..] (SR1,SR3) SR2 ; SR4 On utilise le résultat de la sous-requête SR2 comme prédicat (ou paramètre) de la sous-requête SR1 (par exemple dans la clause WHERE de SR1) On réalise la sous-requête SR1 pour chaque élément de réponse de SR2 On prend en compte les éléments de SR1 qui n'ont pas de correspondant dans SR4 selon le champ précisé entre crochets Cela signifie que l'on exécute les deux sous-requêtes SR1 et SR3 en parallèle Cela signifie que l'on exécute la sous-requête SR2 avant la sousrequête SR4 Si une sous-requête Sr i nécessite un résultat R n dans ses conditions de recherche, c'est à l'aiguilleur de réaliser le travail nécessaire avant d'envoyer la sous-requête en question. Il est évident qu'une telle dépendance implique un ordre de traitement : la sous-requête donnant le résultat R n doit impérativement être exécutée avant l'envoi de la sous-requête Sr i LA BASE DE CONNAISSANCES Rôle et contenu Le sous-requêteur nécessite une base de connaissances afin d'élaborer les sous-requêtes destinées aux bases de données à interroger. Cette base contient toutes les connaissances nécessaires sur les données consultables ainsi que sur les bases connectées au système. Elle permet notamment de déterminer: les données à rechercher dans les bases de données d'après la requête utilisateur et l'analyse préliminaire de l'analyseur de requêtes, la localisation des données à rechercher, quelles données complémentaires, non spécifiées par l'utilisateur, pourraient être utiles à ce dernier dans sa prise de décision. La base de connaissances doit donc non seulement permettre de connaître la base de données où se situe une donnée à rechercher mais aussi permettre de savoir quels sont les liens à la fois entre les diverses données d'une même base et les données de bases différentes. Pour cela, nous utilisons un schéma homogène pour chaque base de données. Chaque schéma 72 / 124

73 Un système d'accès à des bases de données hétérogènes homogène contient le schéma d'une base de données. Tous ces schémas peuvent ensuite être comparés afin de trouver les liens possibles entre les diverses bases de données à consulter. Mais ces schémas homogènes ont un autre rôle : ils permettent à des concepteurs d'applications ou de bases de données de consulter les schémas des bases existantes. Ils peuvent ainsi concevoir de nouvelles applications pour les bases existantes ou bien créer de nouvelles bases, en utilisant les données existantes dans d'autres bases, par exemple. Il est par conséquent nécessaire de présenter les différents schémas dans un format homogène, afin de permettre une comparaison aisée (voir ). La Figure 25 ci-dessous présente le modèle conceptuel de données de notre base de connaissances, selon le formalisme de UML. Règle de droit 0..n 1..n Est stockée dans 1 Provient de 0..n 0..n Données Textuelles Base de données Nom Emplacement stocke Données 0..n 1..n 1..n utilise 1 possède 1 TypeModèle Type Langage d'interrogation a 1 1..n Données Non Textuelles Schéma 1..n 1..n a 1..n compose 0..n Entité 1..n contient 1..n Élément Est composé de 0..n 1..n Association Données Structurées Langage de structuration Données non Structurées Format 0..n Données Multimédia Format Qualité Données Alphanumériques Type 1..n Image Dimension Son Vidéo s'applique sur Figure 25 : modèle de notre base de connaissances SABaDH permet de gérer des Bases de Données, possédant chacune un Schéma. Tous les schémas sont homogènes les uns par rapport aux autres (voir paragraphe suivant). Un schéma possède un Type de Modèle (relationnel, objet, ), et est composé d'entités (une ou 73 / 124

74 Un système d'accès à des bases de données hétérogènes plusieurs) ainsi que d'associations (une ou plusieurs). Chaque entité peut être composée d'autres entités, ou d'eléments (un ou plusieurs). Chaque base de données permet de stocker des Données. Celles-ci sont soit Textuelles, soit Non Textuelles. Les données textuelles regroupent les documents structurés (par exemple selon XML) et les documents non structurés (par exemple une note au format ".txt"), tandis que les données non textuelles comprennent les données Multimédia (vidéo, son, image) et les données Alphanumériques (comme par exemple les données factuelles sur les allocataires). En plus de ces données, nous considérons des Règles (de droit après une première étape puis des règles de systèmes experts), stockées elles aussi dans des "bases". Ces règles proviennent de données structurées (comme dans notre cas, de textes juridiques structurés selon XML), et s'appliquent sur des données alphanumériques (comme les données sur les allocataires, lors du calcul des droits de chacun) Schémas homogènes Les schémas homogènes ont deux principaux buts : permettre de comparer deux schémas de bases de données, permettre aux concepteurs d'applications et de bases de données de consulter les schémas des bases de données existantes. Lorsque l'on veut comparer deux schémas de bases de données, il est indispensable de disposer des schémas dans un format homogène. Il faut donc être capable de récupérer le schéma d'une base de données avant de l'homogénéiser et de le stocker dans la base de connaissances. Pour cela, nous nous inspirons de la proposition du groupe OMG au W3C, concernant l'échange de métadonnées XML : XMI. Cette proposition contient, dans son annexe A, une DTD permettant de traduire un schéma de base de données réalisé avec le formalisme UML en un document XML. Néanmoins, un tel schéma ne sera pas homogène avec les autres schémas de bases de données. En effet, chaque concepteur de bases de données a ses propres conventions, ses propres noms de données. Le schéma physique d'une base de données fournit donc le nom physique donné par le concepteur à une donnée. Lors de la traduction de ce schéma UML en XML, le nom physique de la donnée sera conservé. Or, une même donnée, selon le concepteur, aura un nom physique différent pour chaque base où elle intervient. Par conséquent, il est nécessaire d'homogénéiser les noms de chaque donnée. Pour cela, nous utilisons un Dictionnaire de Données (DD), propre à chaque institution (ou entreprise). Ce dictionnaire contient à la fois le nom générique d'une donnée et ses noms physiques dans les diverses bases de données où elle est stockée. 74 / 124

75 Un système d'accès à des bases de données hétérogènes La démarche de traduction d'un schéma de base de données UML en un schéma homogène est la suivante : 1. si le schéma n'est pas en UML, il est traduit dans ce formalisme avant tout autre traitement ; 2. on utilise la DTD fournie par XMI pour UML afin de traduire le schéma UML en XML ; 3. on utilise le Dictionnaire de Données (DD) pour homogénéiser le schéma et obtenir ainsi un schéma homogène à stocker dans la base de connaissances. La figure ci-après illustre ce mécanisme de traduction d'un schéma de base de données en schéma homogène. Nous faisons l'hypothèse que le schéma de la base de données est au format UML. Traducteur Homogénéisateur Schéma au format UML Schéma au format XML Schéma homogène Dico Figure 26 : schématisation du processus d'homogénéisation des schémas de bases de données La Figure 27 montre un exemple de traduction d'un schéma UML en XML. On obtient un fichier XML qui contient les informations portées par le schéma UML. C'est ce fichier XML qui va ensuite être homogénéiser. 75 / 124

76 Un système d'accès à des bases de données hétérogènes Données Structurées : Modèle Nom = Données Structurées Visibilité = public ownedelement Texte Juridique : Class Nom = Texte juridique ownedelement Document : Class Nom = Document feature Type : Attribute Nom = Type feature Alloc : Attribute Nom = Alloc <Modèle> <nom> Données Structurées </nom> <visibilité value="public"/> <ownedelement> <Class> <nom> Texte Juridique </nom> <ownedelement> <Class> <nom> Document </nom> <feature> <Attribut> <nom> Type </nom> </Attribut> </feature> <feature> <Attribut> <nom> Alloc </nom> </Attribut> </feature> </Class> </ownedelement> </Class> </ownedelement> </Modèle> Modèle UML Fichier XML Figure 27 : Exemple d'un schéma au format UML traduit en XML L'AIGUILLEUR Ce composant a principalement deux rôles : 1. il est chargé d'envoyer les sous-requêtes aux bases de données concernées et de récupérer les réponses de ces bases. Pour cela, l'aiguilleur peut avoir besoin de compléter les prédicats de recherche d'une sous-requête avec le résultat d'une autre sous-requête, afin de restreindre l'espace de recherche. 2. il maintient à jour les schémas des bases de données dans la base de connaissances Dispatching des sous-requêtes Un des rôles de l'aiguilleur est d'envoyer chaque sous-requête à la base de données concernée. Il reçoit pour cela, de la part du sous-requêteur : toutes les sous-requêtes, le plan de séquencement. 76 / 124

77 Un système d'accès à des bases de données hétérogènes Il utilise le plan de séquencement pour déterminer dans quel ordre envoyer les sousrequêtes et déterminer si une sous-requête nécessite le résultat d'une autre sous-requête dans ses prédicats de recherche. Toutes les sous-requêtes ne nécessitant pas de modifications et pouvant être traitées en parallèle sont envoyées en même temps aux bases de données concernées. Les sous-requêtes à compléter le sont par l'aiguilleur, à la réception du résultat attendu. L'ensemble des sous-requêtes et de leur réponse est envoyé au module suivant, après réception de la dernière réponse. Si une base de données ne répond pas, il existe un délai de réponse qui permet de déterminer une éventuelle absence de réponse. Dans ce cas, l'utilisateur est averti du problème et les réponses déjà obtenues sont envoyées au rédacteur de réponse. Ce dernier rédige la réponse finale, avec les réponses dont il dispose. La figure ci-après illustre les divers messages d'entrées / sorties du système en mode d'interrogation. Le problème de non réponse n'a pas été illustré sur le schéma. Termes du langage naturel Requête Utilisateur Base de connaissances Analyseur de Requêtes Module de Sous-requêtes Thesaurus Sous-requêtes Filtre de décomposition Plan de séquencement XML Réponses Réponse finale Rédacteur de réponse X M L Requête initiale Filtre de décomposition Plan de séquencement Aiguilleur XML En langage base de données XML Dico XML Sous-requête Réponse Sous-requête Réponse Sous-requête Réponse Bd Bd Bd Sgbd Sgbd Sgbd Sous-requête Sous-requête Sous-requête Réponse > Wrapper Réponse > Réponse > Wrapper Wrapper Figure 28 : Messages d'entrées/sorties en mode d'interrogation 77 / 124

78 Un système d'accès à des bases de données hétérogènes Mise à jour des schémas de bases de données Un autre rôle de l'aiguilleur consiste à maintenir à jour les schémas des bases de données dans la base de connaissances. Trois méthodes sont possibles pour cette mise à jour des schémas : 1. l'utilisateur demande par l'intermédiaire d'une requête prédéfinie la mise à jour des schémas de base de données. L'aiguilleur traite alors la requête, telle quelle en demandant aux wrappers les nouveaux schémas de base de données ; 2. l'aiguilleur, de façon automatique et périodique, demande aux wrappers, sur sa seule initiative, les nouveaux schémas de base de données; 3. un wrapper, suite à une mise à jour du schéma de la base de données à laquelle il est relié, envoie une requête de mise à jour à l'aiguilleur. La Figure 29 illustre les divers messages d'entrées / sorties du système lorsque l'aiguilleur prend l'initiative de la mise à jour des schémas. Requête Utilisateur Analyseur de Requêtes Thesaurus Base de connaissances Module de Sous-requêtes Réponse finale Rédacteur de réponse Aiguilleur Bd Bd Bd Sgbd Sgbd Sgbd Schéma XML Demande de MAJ Schéma XML Demande de MAJ Schéma XML Demande de MAJ Dico Demande de schéma Wrapper Wrapper Schéma UML Demande de schéma Wrapper Schéma UML Demande de schéma Schéma UML Figure 29 : Messages d'entrées / sorties en mode de mise à jour des schémas de bases de données 78 / 124

79 Un système d'accès à des bases de données hétérogènes Le wrapper reçoit de la part du SGBD auquel il est relié un schéma de base de données au format UML. Il le traduit alors au format XML et l'envoie à l'aiguilleur. Ce dernier homogénéise les divers schémas de base de données avant de les envoyer à la base de connaissances. Pour cela, il utilise le dictionnaire de données afin de remplacer les noms physiques des données par leur nom générique, entre autres choses LES WRAPPERS Les wrappers [Nicolle et al, 2000d] ne sont pas internes à notre système. Néanmoins, ils sont indispensables à son bon fonctionnement. Leur architecture est donc importante et doit se conformer à celle présentée à la Figure 30. requête réponse Requêteur Sous-requête Traducteur XML <--> L.BD Aiguilleur schéma Traducteur XML <-- UML Gestionnaire de schéma SGBD Wrapper BD Figure 30 : Composants internes d'un wrapper En mode d'interrogation d'une base de données, un wrapper est chargé de traduire la sousrequête XML qu'il reçoit en un langage compréhensible par le SGBD de la base de données auquel il est relié (par exemple SQL, langage propriétaire Progress ). Il utilise pour cela son module de "Traducteur XML Langage de Base de données". De la même façon, il traduit la réponse reçue du SGBD en XML avant de l'envoyer à l'aiguilleur. La figure ci-après présente le fonctionnement et les messages d'entrées / sorties d'un wrapper dans le mode d'interrogation de bases de données. Les composants n'intervenant pas dans le fonctionnement du wrapper sont grisés et les messages sont en pointillés. 79 / 124

80 Un système d'accès à des bases de données hétérogènes Base de Connaissances Sous-requête Réponse XML Requêteur Traducteur XML <--> L.BD Réponse Aiguilleur Traducteur XML <-- UML Gestionnaire de schéma SGBD Wrapper Dico Vers le rédacteur de réponse Réponses, plan de séquencement, filtre de décomposition, requête initiale Figure 31 : Fonctionnement d'un wrapper en mode d'interrogation de base de données Lors de l'interrogation d'une base de données, l'aiguilleur envoie au wrapper la sousrequête qui lui est destinée. C'est le requêteur qui est chargé de faire suivre la sous-requête au bon module, en l'occurrence ici au traducteur XML L.BD. Ce dernier va traduire la sous-requête en un langage compréhensible (SQL, par exemple, pour le relationnel) par la base de données à laquelle le wrapper est relié. La sous-requête est alors envoyée au SGBD chargée de la base de données à interroger. La réponse du SGBD est renvoyée au traducteur qui effectue l'opération inverse de traduction. C'est donc une réponse au format XML que le requêteur du wrapper reçoit. Il la fait suivre à l'aiguilleur qui peut alors la traiter. Le second rôle du wrapper intervient lorsque les schémas des bases de données doivent être mis à jour. Le wrapper récupère le schéma de sa base de données, au format UML, et le traduit en XML en utilisant pour cela la DTD pour UML fournie dans la proposition XMI de OMG. Il envoie ensuite le schéma au format XML (non homogénéisé) à l'aiguilleur. La figure ci-dessous illustre le fonctionnement d'un wrapper lors de la mise à jour d'un schéma de base de données. 80 / 124

81 Un système d'accès à des bases de données hétérogènes Base de Connaissances Demande de MAJ de schéma Requêteur Traducteur XML <--> L.BD Schéma homogène Aiguilleur Schéma en XML Traducteur XML <-- UML Gestionnaire de schéma SGBD Wrapper Dico Figure 32 : Fonctionnement d'un wrapper en mode de mise à jour des schémas de base de données Lors d'une demande de mise à jour, une requête type est envoyée par l'aiguilleur au wrapper. C'est le module requêteur qui reçoit toutes les requêtes. Lors de la réception de la requête type de mise à jour de schéma, le requêteur du wrapper l'envoie au gestionnaire de schéma. Tous les messages concernant le schéma de la base de données auquel le wrapper est relié passent par le gestionnaire de schéma. Ce dernier est chargé de récupérer le nouveau schéma (pour la mise à jour). Il l'envoie ensuite au module chargé de traduire le schéma en XML à l'aide de la DTD fournie dans XMI, le traducteur XML UML. L'aiguilleur va donc recevoir en retour le schéma XML de la base de données. Ce schéma contient notamment le nom de la base de données traitée ainsi que son emplacement, ajoutés par le wrapper. Il reste alors à l'aiguilleur à homogénéiser ce schéma à l'aide du Dictionnaire de Données (Dico, sur la figure). Il peut ensuite mettre à jour le schéma dans la Base de Connaissances. En ce qui concerne le Dictionnaire de Données, que nous appelons Dico pour le différencier de tout autre type de dictionnaire pouvant exister. Ce dico contient les renseignements concernant la donnée physique : son nom par rapport à son nom logique, ce dernier étant utilisé pour l'homogénéisation, les applications qui utilisent cette donnée sous ce nom physique. 81 / 124

82 Un système d'accès à des bases de données hétérogènes LE RÉDACTEUR DE RÉPONSE Le dernier élément de notre système est le rédacteur de réponse. Il est chargé d'associer les réponses obtenues afin de former une seule réponse, la réponse attendue par l'utilisateur à sa requête. Pour cela, il dispose : des réponses des bases de données interrogées, des sous-requêtes envoyées aux bases de données, du plan de séquencement, du filtre de décomposition, de la base de connaissances. Le plan de séquencement permet au rédacteur de positionner les réponses entre elles, et de réaliser ainsi les "jointures" ou omissions (si une réponse a été utilisée pour réaliser les prédicats de recherche d'une autre sous-requête, il n'est pas nécessaire qu'elle apparaisse dans la réponse finale). Le filtre de décomposition, quant à lui, permet de resituer chaque réponse dans son contexte. Enfin, la base de connaissances fournit les liens utilisés entre les données et les bases et permet ainsi de reconstituer une réponse finale cohérente et enrichie de la connaissance contenue dans la base de connaissances. Le rédacteur de réponse fournit à l'utilisateur une réponse au format XML, qui peut ensuite être soit affichée sur un écran (selon le profil de l'utilisateur, l'affichage peut varier, certaines données peuvent être mises en avant ou bien au contraire occultées), être imprimée, utilisée par une autre application 82 / 124

83 Un système d'accès à des bases de données hétérogènes Quelques Diagrammes de fonctionnement Nous présentons dans cette section quelques diagrammes de fonctionnement, réalisés à l'aide de RationalRose, selon le formalisme UML. Le diagramme de la Figure 33 illustre le mécanisme d'interrogation des bases de données via notre SABaDH, le diagramme de séquencement étant illustré dans la figure suivante. Figure 33: Diagramme de Collaboration (UML) de l'interrogation des Bases de données via SABaDH Chaque étape du processus d'interrogation est numérotée. Une étape peut se décomposer en plusieurs ou bien nécessiter l'appel d'une autre étape, comme c'est le cas lors de l'analyse du Prérésultat (étape 3) qui nécessite une demande d'information à la base de connaissances (étape 3.1). 83 / 124

84 Un système d'accès à des bases de données hétérogènes Figure 34 : Diagramme de Séquencement de l'interrogation des bases de données Ce schéma illustre de façon séquentielle le processus d'interrogation des bases de données. Nous pouvons remarquer que dans notre exemple, une transaction n'est terminée que lorsque la réponse est fournie à l'utilisateur. Il faut préciser que ceci n'est qu'une vue du processus. En réalité, le système gère de multiples demandes et il prend aussi en compte le fait qu'une des bases interrogées peut ne pas répondre. De même, les problèmes de transmission des données ne sont pas illustrés ici. Ce schéma n'est ici qu'à titre indicatif, pour clarifier la vue du processus d'interrogation. Il n'est en aucun cas fidèle à la mise en œuvre. 84 / 124

85 Gestion de la cohérence Chapitre 5 Gestion de la cohérence 1. Généralités Lors d'une prise de décision, un décideur consulte un grand nombre de données. Il est indispensable que celles-ci soient correctes, non obsolètes, et à jour. Pour cela, la gestion de la cohérence des données est primordiale. La section suivante traite le problème de la gestion de la cohérence dans une base de documents structurés. Cette base constitue une des bases que notre système doit permettre d'atteindre. D'autre part, notre système utilise une base de connaissances, qui contient le schéma de chaque base de données, structuré en XML. Par conséquent, étudier le maintien de la cohérence dans la base de documents structurés nous donnera une solution pour la gestion de la cohérence dans notre base de connaissances. 2. Gestion de la cohérence dans une base de documents structurés 2.1. La Base de Données Juridiques (BDJ) PRÉSENTATION DE BDJ Notre projet de système d'accès utilise les résultats d'un autre projet, celui de BDJ (Base de Données Juridiques) de la CNAF. Ce dernier a pour objectifs : de permettre une navigation organisée dans les textes juridiques (notamment pour l'aide à la prise de décision) ; de décentraliser la prise de décision (en mettant à disposition des CAF les outils de navigation) ; d'effectuer des études d'impact (en simulant des changements dans la réglementation) ; de gérer les informations réglementaires utilisées ou produites par la Direction des Prestations Familiales (DPF) de la CNAF 23 dans une base de données unique et centralisée. 23 Caisse Nationale des Allocations Familiales 85 / 124

86 Gestion de la cohérence Le projet Base de Données Juridiques est conduit avec la technologie SGML, choisie dans le cadre du projet de modélisation des textes réglementaires [Chabbat, 1997]. Par la suite, XML est utilisé pour structurer les documents. L'objectif principal du projet est de mettre à disposition des utilisateurs (CAF 24 et CNAF) des outils informatiques et des méthodes permettant de maîtriser de manière cohérente le processus de mise à jour des informations réglementaires et des fonctions qui y sont associées. Cet objectif nécessite de gérer les informations réglementaires utilisées ou produites par la DPF dans une base de données unique et centralisée, à la norme SGML. Cette base doit servir de source unique pour toutes les fonctions de l'institution utilisant ces informations. Les documents qui doivent être gérés sont dans un premier temps les documents internes de référence (circulaires CNAF, suivis législatifs, voir Figure 35 et Figure 36 pour connaître l'ensemble des textes considérés ainsi que leur hiérarchie). Le but est de pouvoir intégrer ensuite l'ensemble de la réglementation CAF (lois, décrets, Journal Officiel, Guide des textes réglementaires, Guide de l'allocation Logement, Code de la Sécurité Sociale, Jurisprudence et questions écrites, questions/réponses CAF et CNAF, notes de service CNAF, PV de Conseil d'administration, PV Assemblée Nationale, projets de lois, etc.) et de la réglementation externe qui lui est liée, en fonction des besoins Type de texte Constitution Loi Décret Circulaire ministérielle Textes de réf. interne Instructions techniques Règles de syst. expert Promulgué par Parlement Assemblée Nationale Conseil des ministres Ministère Organisation Niv. 1 Organisation Niv. 2 Organisation Niv. 3 Figure 35 : Hiérarchie des textes de droit La Figure 35 illustre la hiérarchie des textes considérés dans ce projet. Cette hiérarchie est pyramidale, la Constitution étant le texte prévalant sur tous les autres, ces derniers ne devant pas contredire les règles émises dans la Constitution. A la base de la pyramide, nous avons 24 Caisse des Allocations Familiales 86 / 124

87 Gestion de la cohérence ajouté les règles de systèmes experts. Celles-ci ne sont pas des textes à proprement parlé. Néanmoins, elles en sont extraites et peuvent être utilisées lors de la recherche d'information (voir Partie 3 Chapitre 1 2.1). C'est pourquoi nous les insérons dans cette pyramide de documents. Assemblée Nationale Ministères Textes Réglementaires CNAF Suivi Législatif Circulaires Cnaf Documentation Cristal CAFs Règles Cristal Réglementation Locale Notes de Service Exécution NDP Traitement Liste des Anomalies Figure 36 : Illustration des différents types de textes produits aux Allocations Familiales Les textes appelés textes réglementaires sont aussi nommés textes externes. Les autres textes présentés sur la Figure 36 sont dits textes internes. La base de données juridiques devra permettre de gérer la cohérence entre les fonctions suivantes : gestion des textes réglementaires : dans un premier temps, les textes considérés sont ceux réalisés par la Direction des Prestations Familiales (DPF) à la CNAF à partir des divers textes réglementaires émis par l'assemblée Nationale et le Ministère (lois, décrets, circulaires, etc.). Ces textes constituent le Suivi Législatif. consultation de ces textes, gestion des règles de systèmes experts, gestion de documents de formation ou d'enseignement Assisté par Ordinateur, gestion de documentation technique, communication externe, 87 / 124

88 Gestion de la cohérence etc. Le maintien de la cohérence dans une telle base nécessite entre autres de gérer les versions ainsi que les liens entre documents. En effet, l'évolution des textes traités est telle qu'il est indispensable de conserver les diverses versions de chaque texte. La prise d'une décision intervient bien souvent après une modification de textes, ceci étant donné le temps de traitement de chaque dossier et l'évolution rapide des textes en question. De plus, les documents juridiques sont liés les uns aux autres. L'évolution d'un texte (qui entraîne une nouvelle version par exemple) implique la vérification voire la modification de ces liens. Il est donc indispensable de savoir gérer conjointement les versions et les liens de chaque document afin de préserver la cohérence de la base de documents. Les sections suivantes présentent ces gestions GESTION DES VERSIONS ET DES LIENS Les documents Notre corpus documentaire est constitué, comme nous l'avons dit précédemment, de documents juridiques. Ces documents sont dits : externes s'ils émanent de l'assemblée Nationale, du Sénat, (lois, décrets, etc.) ; internes s'ils sont rédigés au sein des Caisses d'allocations Familiales (circulaires internes, etc.). Les documents juridiques internes sont élaborés à partir des textes externes et ont pour but, en général, de clarifier le contenu des textes externes, bien souvent difficiles à interpréter pour un non-expert du domaine juridique. Ces documents sont rédigés notamment par les juristes de la CNAF. Les documents juridiques évoluent au cours du temps, un nouveau document étant émis pour modifier un document déjà existant, ou pour promulguer de nouvelles conditions et directives. Les documents internes vont par conséquent évoluer en même temps que les documents externes, en fonction du temps. La figure ci-après présente un article du Code de la Sécurité Sociale ainsi qu'une circulaire interne à la CNAF dérivée de ce même article. 88 / 124

89 Gestion de la cohérence Article D Remplacé par le décret n du (22), modifié par les décrets n du (23), du , du (25), du , du , du (29), du (31) et du (34) Décrets n du et n du Sous réserve des dispositions des articles R à R et D , et des alinéas suivants du présent article, les ressources prises en considération s entendent du total des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu d après le barème des revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire de l impôt sur le revenu, ainsi que les revenus perçus hors de France ou versés par une organisation et après : a. la déduction au titre des créances alimentaires mentionnée au 2 du II de l article 156 du Code général des impôts ; b. l abattement mentionné à l article 157 bis du Code général des impôts en faveur des personnes âgées ou invalides ;... Circulaire CNAF Annexe, chap Détermination des ressources Les ressources servant au calcul de l allocation de logement telles que définies à l article D du Code de la Sécurité Sociale s entendent des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu, après imputation de certaines déductions. Par «revenus nets catégoriels» sont désignés, comme par le passé, les revenus propres à chaque catégorie professionnelle affectés des abattements et déductions afférentes à chacune de ces catégories. Par exemple : - les abattements de 10 et 20% pour les salariés, pensionnés ou retraités ; - les abattements supplémentaires propres à certaines professions ; - les abattements spécifiques aux revenus des non - salariés. Sont également pris en compte : - les revenus perçus hors de France ou versés par une organisation internationale quel que soit le lieu du domicile fiscal en année de référence ; - les revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire sur le revenu. Ces revenus sont majorés, le cas échéant, des reports des déficits constatés au cours d une année antérieure à l année de référence dont la déduction est admise par l Administration fiscale. Sont exclus du décompte des ressources les arrérages des rentes viagères constituées en faveur d une personne handicapée. Figure 37 : Texte externe (article D du Code de la Sécurité Sociale) et texte interne (circulaire CNAF) L'article D définit "les ressources prises en considération" lors d'un calcul d'allocation. La circulaire interne CNAF 42.94, quant à elle, reprend les termes de l'article en les précisant, afin de clarifier le contenu et lever les éventuelles ambiguïtés qui peuvent exister dans l'article. Elle peut aussi compléter le contenu d'un texte externe. Par la suite, chaque CAF peut, de façon individuelle, préciser le contenu d'un texte afin de lever toutes ambiguïtés qui pourraient persister dans un texte interne. Il est à noter que les textes externes sont naturellement flous, et ce notamment afin d'adapter les règles à chaque cas particulier si nécessaire. De plus, les documents en question sont structurés, non seulement de par leur contenu juridique (par définition très structuré à défaut d'être toujours très clair!) mais aussi de par leur rédaction. En effet, les textes considérés sont rédigés selon la norme SGML (le standard XML étant l'étape suivante dans la rédaction des textes). Il est alors possible de représenter un document sous une forme arborescente, où la racine représente la balise de début du document, les nœuds sont les balises à l'intérieur du document, et les feuilles contiennent le 89 / 124

90 Gestion de la cohérence contenu textuel du document. La figure ci-dessous illustre une représentation arborescente d'un article du Code de la Sécurité Sociale. <article> <titreart> Article D </titreart> <decr> </decr> <alin> <decr> </decr> <corpsal> Les ressources ci-dessus définies sont diminuées d'un abattement forfaitaire lorsque les deux conjoints ont exercé une activité professionnelle productrice de revenus au cours de l'année civile de référence. </corpsal> </alin> </article> Article D article Titreart decr alin decr corpsal Les ressources ci-dessus définies sont diminuées d'un abattement forfaitaire lorsque les deux conjoints ont exercé une activité professionnelle productrice de revenus au cours de l'année civile de référence. Figure 38 : Représentation arborescente de l'article D du Code de la Sécurité Sociale Selon cette représentation arborescente, nous pouvons dire qu'un document est en fait composé de "fragments" (la racine, les nœuds et les feuilles de l'arbre le représentant). Tous ces fragments sont organisés selon des liens de "composition" (ou encore lien de hiérarchie) qui permettent, lors de la lecture du document, de le reconstituer correctement. Dans notre exemple de la Figure 38, notre document est composé d'une racine, "article", elle-même composée de fragments ("Titreart", "decr", "alin") qui constituent des nœuds de l'arbre Document. Les feuilles de cet arbre contiennent le contenu textuel du document, c'està-dire "Article D ", " ", " ", "les ressources référence.". Par conséquent, lorsque nous devons gérer les versions de documents, nous devons aussi gérer des versions de fragments, comme l'explique la section suivante. 90 / 124

91 Gestion de la cohérence Les versions De façon générale, une version permet de modéliser l'évolution d'une entité du monde réel au cours du temps. De nombreuses recherches ont été réalisées dans ce domaine. On peut distinguer deux niveaux d'utilisation des versions [Tayar, 1995] : un niveau système, pour lequel les versions sont directement créées et utilisées par le système de gestion de Bases de Données ; un niveau application où ce sont les utilisateurs ou les programmes d'application qui sont responsables de l'opportunité de créer ou d'utiliser les versions. On distingue deux sortes de versions : 1. la version dérivée : elle est issue de la dernière version valide d'un objet et ne coexiste pas avec d'autres versions à un instant donné. 2. l'alternative : elle est issue d'une version (pas obligatoirement la dernière) d'un objet, et peut coexister avec d'autres alternatives à un instant donné. Pour gérer les versions, plusieurs principes ont été élaborés, dont celui des Versions de Bases de Données (VDB) [Cellary et Jomier, 1990][Gancarski, 1994]. Le principe des VDB est de séparer la notion de version logique d'objet (c'est-à-dire ce que perçoit l'utilisateur) de la notion de version physique d'objet (c'est-à-dire ce que gère réellement le système). A côté de cela, nous pouvons remarquer trois familles de travaux [Gancarski, 1994] : 1. la première (les serveurs de versions [Cellary et al, 1994]) est centrée sur le concept de version d'entités, qu'elle soit dérivée ou alternative. Il en résulte des limitations dans la représentation et la manipulation de contextes. Cette famille concerne principalement le domaine des Bases de Données Orientées Objet. 2. la deuxième famille regroupe les travaux dans lesquels l'apparition de versions d'entités et de contextes est liée à l'écoulement du temps. Contextes et versions d'entités sont aisément représentés et manipulés, mais l'utilisation du temps comme repère indique un ordre total entre les contextes et interdit (ou rend problématique) la possibilité d'alternatives. Ceci est le domaine des Bases de Données Temporelles [Anick et Flynn, 1992][Blanken, 1991][Dhouib Elloumi et al, 1998]. 3. la troisième famille regroupe des travaux, généralement issus du génie logiciel, qui sont centrés sur la manipulation de contextes en raison des nécessités spécifiques des applications. Cette spécificité induit un manque de généralité et par conséquent de formalisation [Reichenberger, 1989]. 91 / 124

92 Gestion de la cohérence D'un autre côté, nous pouvons citer les travaux concernant l'interrogation des Bases de Données intégrant des versions [Andonoff et al, 1997]. Les auteurs définissent un langage algébrique, un langage textuel VOQL et enfin un langage graphique VOGQL afin d'interroger les Bases de Données intégrant des versions. Dans notre contexte, les textes juridiques sont consultés en vue d'une prise de décision, par un expert juridique ou par un non-expert. De plus, leur contenu évolue au cours du temps. Prenons l'exemple d'un allocataire qui dépose un dossier de recours, c'est-à-dire qu'il demande que sa situation soit revue (et corrigée) sur les derniers mois ou les dernières années. Il considère pour cela qu'un erreur a été commise par la CAF dont il dépend lors de l'attribution d'une (ou plusieurs) allocation(s). Les textes à appliquer pour prendre la décision d'allouer ou non l'allocation en question sont ceux dont le contenu est valide au moment où la demande d'allocation est effective. Dans le cas d'un recours, la date de demande d'allocation est donnée par l'allocataire, à partir de l'instant où il considère qu'il aurait dû percevoir son allocation. Cette date peut se situer plusieurs mois voire plusieurs années en arrière. Dans ce cas, les textes à consulter ont pu évoluer et les termes d'attribution ont donc pu changer. Néanmoins, il faut pouvoir consulter les textes qui étaient en vigueur au moment de la demande. Il est donc indispensable de conserver toutes les versions d'un document afin de permettre à un décideur de consulter le bon contenu d'un document pour sa prise de décision. Cela entraîne donc une gestion de versions de documents. La figure ci-après montre trois versions d'un article du Code de la Sécurité Sociale. Les passages modifiés sont signalés (dans le contenu textuel) en gras. 92 / 124

93 Gestion de la cohérence Article D ( ) Sous réserve des dispositions des articles R à R et D , et des alinéas suivants du présent article, les ressources prises en considération s entendent du total des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu d après le barème et après : a. la déduction au titre des créances alimentaires mentionnée au 2 du II de l article 156 du Code général des impôts ; b. l abattement mentionné à l article 157 bis du Code général des impôts en faveur des personnes âgées ou invalides ; c. une déduction représentative des frais de garde des enfants à charge, dont le montant maximum est fixé par arrêté du ministre chargé de la sécurité sociale.... Article D (D du 21 juin 1990) Sous réserve des dispositions des articles R à R et D , et des alinéas suivants du présent article, les ressources prises en considération s entendent du total des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu d après le barème des revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire de l impôt sur le revenu, ainsi que les revenus perçus hors de France ou versés par une organisation internationale et après : a. la déduction au titre des créances alimentaires mentionnée au 2 du II de l article 156 du Code général des impôts ; b. l abattement mentionné à l article 157 bis du Code général des impôts en faveur des personnes âgées ou invalides ; c. une déduction représentative des frais de garde des enfants à charge, dont le montant maximum est fixé par arrêté du ministre chargé de la sécurité sociale.... Article D (D du 30 janvier 1997)... Sous réserve des dispositions des articles R à R et D , et des alinéas suivants du présent article, les ressources prises en considération s entendent du total des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu d après le barème des revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire de l impôt sur le revenu, ainsi que les revenus perçus hors de France ou versés par une organisation et après : a. la déduction au titre des créances alimentaires mentionnée au 2 du II de l article 156 du Code général des impôts ; b. l abattement mentionné à l article 157 bis du Code général des impôts pour les personnes nées avant le 1er janvier 1931 ou invalides quel que soit leur âge ; c. une déduction représentative des frais de garde des enfants à charge, dont le montant maximum est fixé par arrêté du ministre chargé de la sécurité sociale. Figure 39 : Exemple de versions pour l'article D du Code de la Sécurité Sociale Dans notre exemple, la version initiale du document est celle de l'article D au Cette version détermine comment calculer les ressources à prendre en compte lors du calcul d'une allocation. Le 21 juin 1990, un décret, le D , est émis afin de modifier le contenu textuel de l'article D On obtient alors une nouvelle version de cet article, en date du Ensuite, le 30 janvier 1997, un nouveau décret, le D 97-84, modifie à nouveau l'article D On obtient alors une troisième version de l'article. Au 31 janvier 1997, il existe donc 3 versions distinctes de l'article D : la première est valide du au ; la seconde est valide du au ; le troisième et dernière est valide à partir du Lors d'une prise de décision impliquant cet article, le décideur devra prendre en compte la version valide à la date considérée, selon les intervalles donnés ci-dessus. 93 / 124

94 Gestion de la cohérence Formalisation des documents Il est possible de formaliser la représentation d'un document afin de le manipuler comme une donnée quelconque. Nous proposons la formalisation suivante, que nous enrichirons au fur et à mesure de notre présentation, notamment avec la formalisation des liens. Nous considérons un ensemble de documents composés de fragments : D : Document = <{f 1, f 2,..., f n },v d > Document auquel un fragment est rattaché f : Fragment = <t,v f,v d,d,{f fils } cont> Fragment de document f fils : Fragment Fragment fils d'un autre fragment t : chaîne de caractères Type caractéristique du fragment (par exemple : Titre) v f : Version = <num,d v > Version de fragment num : N numéro de la version d v : Date date de création de la version v d : Version = <num,d v > Version de Document à partir de laquelle la version de fragment en question doit être prise en compte num : N numéro de la version d v : Date date de création de la version f fils : Fragment Ensemble des fragments fils du fragment considéré cont Contenu textuel du fragment Nous considérons qu'un Document est constitué d'un ensemble de fragments. Certaines caractéristiques, comme un résumé ou un sigle caractéristique, ne sont rattachées qu'au document lui-même, et non pas à tous les fragments. C'est pourquoi nous considérons une entité Document et une entité Fragment. Néanmoins, un Document peut être vu comme un Fragment particulier, étant donné qu'il correspond à l'élément racine d'un texte. Un Fragment possède : un type (par exemple Titre, sous-section, etc.) qui permet ensuite de réaliser des recherches selon la structure du document ; une version, contenant à la fois un numéro de version et la date à laquelle cette version a été créée ; 94 / 124

95 Gestion de la cohérence une version de document, afin de savoir à partir de quelle version du document cette version de fragment doit être considérée. Il est possible de ne prendre en compte que les dates de version, les numéros de version pouvant se déduire facilement des dates de création. d'une liste de fragments fils ou bien d'un contenu textuel. La liste de fragments fils permet de connaître les fragments dont celui considéré est le père hiérarchiquement parlant, et le contenu textuel marque un élément feuille de l'arbre Document qui, comme son nom l'indique, présente une partie du contenu textuel du Document. Nous pouvons distinguer deux sortes de fragments : les fragments ayant un contenu textuel, qui forment les feuilles d'un arbre Document, les fragments nœuds de l'arbre Document, qui n'ont pas de contenu textuel. Une création de version commence toujours, dans notre étude, par la création d'une nouvelle version d'une feuille de l'arbre. Cette création est ensuite propagée jusqu'à la racine de l'arbre, entraînant ainsi la création d'une nouvelle version pour le document lui-même Les liens Les documents que nous considérons sont liés les uns aux autres, par différents types de liens. Par exemple, en ce qui concerne les textes juridiques externes, pour modifier un texte existant, il est impératif de promulguer un nouveau texte. Ce dernier comporte par conséquent une référence au texte qu'il doit modifier ou compléter. Cela constitue un lien de référence. De même, un texte interne à la CNAF permet de clarifier le contenu d'un texte externe. Par conséquent, il a non seulement une référence au texte externe dont il est issu, mais aussi des portions de texte identiques (totalement ou partiellement) à des portions du texte original. Deux textes externes peuvent aussi avoir des portions de texte en commun. Cela constitue un lien de partage d'information[chabbat, 1997]. La figure ci-dessous illustre ces deux types de liens (référence et partage d'information). 95 / 124

96 Gestion de la cohérence Lien de référence Article D Remplacé par le décret n du (22), modifié par les décrets n du (23), du , du (25), du , du , du (29), du (31) et du (34) Décrets n du et n du Sous réserve des dispositions des articles R à R et D , et des alinéas suivants du présent article, les ressources prises en considération s entendent du total des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu d après le barème des revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire de l impôt sur le revenu, ainsi que les revenus perçus hors de France ou versés par une organisation et après : a. la déduction au titre des créances alimentaires mentionnée au 2 du II de l article 156 du Code général des impôts ; b. l abattement mentionné à l article 157 bis du Code général des impôts en faveur des personnes âgées ou invalides ; Lien de partage d information Circulaire CNAF Annexe, chap Détermination des ressources Les ressources servant au calcul de l allocation de logement telles que définies à l article D du Code de la Sécurité Sociale s entendent des revenus nets catégoriels retenus pour l établissement de l impôt sur le revenu, après imputation de certaines déductions. Par «revenus nets catégoriels» sont désignés, comme par le passé, les revenus propres à chaque catégorie professionnelle affectés des abattements et déductions afférentes à chacune de ces catégories. Par exemple : - les abattements de 10 et 20% pour les salariés, pensionnés ou retraités ; - les abattements supplémentaires propres à certaines professions ; - les abattements spécifiques aux revenus des non - salariés. Sont également pris en compte : - les revenus perçus hors de France ou versés par une organisation internationale quel que soit le lieu du domicile fiscal en année de référence ; - les revenus taxés à un taux proportionnel ou soumis à un prélèvement libératoire sur le revenu. Ces revenus sont majorés, le cas échéant, des reports des déficits constatés au cours d une année antérieure à l année de référence dont la déduction est admise par l Administration fiscale. Sont exclus du décompte des ressources les arrérages des rentes viagères constituées en faveur d une personne handicapée. Figure 40 : illustration des liens de référence et de partage d'information La circulaire CNAF fait référence à l'article D grâce aux termes "définies à l'article D ". Elle reprend aussi une partie du contenu de cet article avec les termes "s'entendent des revenus nets catégoriels sur le revenu". Cela constitue un lien de partage d'information intégral, étant donné que chaque mots de l'article D est repris tel quel dans la circulaire CNAF. Nous allons considérer, au cours de notre étude, les trois types de liens suivants : les liens de référence, les liens de partage d'information (partiel ou intégral), les liens de composition. Il est évident que de nombreux autres types de liens sont possibles. Néanmoins, les types que nous considérons ici sont ceux les plus couramment rencontrés dans les documents que nous traitons. Voyons à présent un peu plus en détail ces liens. 96 / 124

97 Gestion de la cohérence 4.1. LIEN DE RÉFÉRENCE Un lien de référence est unidirectionnel. Cela signifie qu'il possède un sens (de A vers B), et que ses ancres peuvent être nommées "source" (pour A) et "cible" (pour B). Si l'on reprend l'exemple de la Figure 40, le lien de référence illustré va de la circulaire (source) vers l'article (cible). Ce type de lien est en général introduit par des expressions réservées, comme par exemple "voir chap. 5", "cf. l'article 2", "comme exposé dans ". Le nombre d'expressions est hélas trop important pour permettre une détection automatique des liens de référence. Il semble donc plus prudent de demander l'intervention de l'utilisateur afin de mettre en évidence ces liens LIEN DE PARTAGE D'INFORMATION Un lien de partage d'information permet de mettre en évidence que deux portions de textes contiennent la même information, que ce soit partiellement ou totalement. Si l'information est totalement identique dans une portion et dans l'autre, le partage d'information est dit intégral. Dans le cas contraire, le partage d'information est dit partiel et on utilise alors un coefficient de similarité pour définir en quelle proportion l'information est reprise [Chabbat, 1997]. Ce type de lien est bidirectionnel en cas de partage d'information intégral (c'est-à-dire que chaque ancre est à la fois source et cible du lien). Dans le cas d'un partage d'information partiel, le lien est unidirectionnel étant donné le degré de similarité. Ce type de lien requiert l'intervention de l'utilisateur afin d'identifier les portions de texte partageant une même information LIEN DE COMPOSITION Ce type de lien permet d'organiser des fragments afin de reconstituer, par la suite, un document, suivant la DTD à laquelle il est conforme. Ces liens sont unidirectionnels et sont établis par le système, suivant la DTD du type de document qu'il traite. 97 / 124

98 Gestion de la cohérence 4.4. MODÉLISATION DES LIENS Lors de la modélisation des documents, une autre modélisation a dû être étudiée : celle des liens. En effet, afin d'avoir une gestion cohérente et complète de la base, il est nécessaire de modéliser aussi bien les liens que les documents. Pour cela, nous utilisons le standard XLL (extensible Link Language : juillet 1997). XLL est basé sur la norme ISO (Technologies de l'information : langage de structuration hypermédia / événementiel) mieux connue sous le nom de HyTime, utilisé par SGML. XLL doit permettre, entre autres, des liens bidirectionnels, des liens vers des cibles sur Internet non balisées au préalable, des liens gérés dans un fichier externe à l'instance de documents et même des attributs sur des liens qui permettront de définir le type de lien (lien vers une définition, lien extérieur, etc.). Un lien XML est un élément quelconque dont le nom et le modèle de contenu sont librement choisis par un auteur de document ou de DTD. Le nom d'un élément est totalement arbitraire. Il existe différents types de liens : des liens simples ou étendus, des liens inclus ou exclus. Un lien simple n'a qu'une cible alors qu'un lien étendu peut en avoir un nombre quelconque. Un lien peut aussi être soit inclus, c'est-à-dire que la ressource dans laquelle il est défini est considérée comme étant l'origine du lien, soit exclu, lorsque la ressource origine est différente de celle dans laquelle le lien est défini. Modélisation des liens de référence Il existe deux catégories de liens de référence : les liens intra-document et les liens interdocuments. Dans le cadre du projet BDJ, nous considérons que les liens de référence peuvent porter sur n'importe quel fragment de document, de l'élément racine à la chaîne de caractères d'un élément feuille. Modélisation des liens de partage d'information Ce type de liens servent essentiellement à maintenir la cohérence de la base. En effet, lors de la modification d'un texte réglementaire, il est important de pouvoir déterminer l'impact de cette modification non seulement sur les textes externes mais aussi sur les textes internes. Ces liens possèdent un attribut de similarité (noté s)[chabbat, 1997] qui permet de déterminer la part d'information récupérée d'un document, voire d'un fragment de document à un autre. C'est 98 / 124

99 Gestion de la cohérence donc à l'aide de cet attribut que l'on distingue les liens de partage d'information. Du point de vue de la modélisation, nous devons alors séparer les liens de partage d'information en deux catégories : les liens intégraux (s = 1), et les liens de partage partiels (0 < s < 1) Les versions et les liens Les documents que nous considérons sont donc évolutifs, liés les uns aux autres, et leur évolution dépend du temps. Afin de restituer un ensemble de documents cohérents à un utilisateur, il est donc nécessaire de conserver l'historique des documents (par le biais des versions) ainsi que celui des liens (en les versionnalisant). Avant de regarder en détail ce qu'implique cette gestion simultanée des versions et des liens pour les documents structurés, nous introduisons la notion de contexte juridique estampillé [Nicolle et al, 2000b] [Nicolle et al, 2000e] CONTEXTE JURIDIQUE ESTAMPILLÉ Définition d'un CJE Un contexte juridique estampillé est un ensemble de documents valides cohérent juridiquement parlant, à une date donnée. La validité des documents s'entend selon leur validité juridique, c'est-à-dire que leur contenu est applicable à la date considérée. La figure ci-après illustre un exemple de Contexte Juridique Estampillé, selon le temps. L'exemple ne prend en compte qu'un seul document, mais en réalité, un CJE peut contenir plusieurs documents, chacun dans une version donnée. Ce CJE permet de consulter un ensemble de documents cohérents. 99 / 124

100 Gestion de la cohérence Contexte juridique estampillé Document, version 2 f1v0 f5v0 f2v1 f3v2 f4v2 Version 2 du document f1v0 f2v1 f3v2 f4v2 f5v0 f1v0 f5v0 f2v1 f3v1 f4v1 Version 1 du document Document, version 1 f1v0 f2v1 f3v1 f4v1 f5v0 f5v0 f1v0 f2v0 f3v0 f4v0 Version 0 du document Document, version 0 f1v0 f2v0 f3v0 Nouvelle version de fragment f4v0 f5v0 Figure 41 : Exemple de contextes juridiques estampillés pour un document Dans notre exemple, nous considérons un document D en version 0 comme point de départ. Ce document est constitué de 5 fragments, tous en version 0. Ensuite, le document évolue : le fragment 2 passe en version 1 ; le fragment 4 passe en version 1 lui aussi. Etant donné que le fragment 4 a pour parent le fragment 3, l'évolution de version de f4 entraîne l'évolution de version de son parent f3. De même pour la suite, le passage en version 2 de f4 entraîne à nouveau la création d'une nouvelle version pour f3. On obtient alors trois contextes différents, à l'intérieur desquels le document est constitué d'un ensemble cohérent de versions de fragments. Notre exemple ne prend en compte qu'un seul document, pour ne pas surcharger le schéma, mais en réalité, un contexte contient un ensemble de documents. Leur évolution entraîne l'apparition d'un nouveau contexte. Un contexte juridique estampillé (CJE) va donc permettre à un utilisateur de consulter un ensemble de documents dont la valeur juridique, à la date demandée, est (ou était, si l'utilisateur a demandé une version antérieure des textes) applicable. Il s'agit donc de retrouver des versions de documents et de leurs liens à une date donnée, afin de fournir à l'utilisateur un ensemble de versions cohérentes entre elles. 100 / 124

101 Gestion de la cohérence Un CJE est un ensemble de documents à une date donnée, donc il est un ensemble de versions de documents, donc un ensemble de versions de fragments, à une date précise Exemple de manipulation de CJE Prenons l'exemple d'un dossier allocataire. Un allocataire dépose une demande d'allocations le 15 septembre Le traitement du dossier n'est pas immédiat, et entre le jour de dépôt du dossier et le jour du traitement du dossier, il peut se passer plusieurs jours voire plusieurs semaines. La législation a donc pu évoluer. Lorsque le décideur va consulter les textes juridiques, il est donc important qu'il se place dans le contexte juridique qui était valide au moment du dépôt du dossier. Il va donc demander à consulter les textes valides au Le système va donc rechercher les textes valides à cette date. Les versions postérieures à cette date ne seront pas prises en compte, les liens non plus. La figure ci-après illustre la recherche d'une version d'un document à une date donnée. Document recherché Version recherchée Autres Documents Recherche de l'article D au liens hiérarchiques 1 Récupération du document recherché, avec toutes les versions Récupération de la version valide 2 Résultat intermédiaire Résultat final Figure 42 : illustration d'une recherche d'un document précis à une date précise La première étape consiste à repérer le document recherché, et de récupérer tous les fragments qui le constituent, avec toutes leurs versions. Ensuite, le système regarde pour 101 / 124

102 Gestion de la cohérence chaque fragment quelle version est valide pour la date demandée (c'est-à-dire dans notre exemple le ). On obtient au final le document recherché, dans une version valide à la date demandée. En réalité, bien souvent, le décideur recherche un ensemble de mots qui vont lui permettre de retrouver un texte en particulier. La figure suivante illustre une telle recherche. Recherche des mots ", les ressources prises en considération" dans l'article D au contexte général 1 document recherché fragment recherché 2 3 version du version du version du version du version du Résultat final recherche de la version valide au Figure 43 : illustration d'une recherche de version de fragment de document à une date donnée Dans cet exemple, le système commence par rechercher le document correspondant à l'article D Ensuite, il recherche, dans ce document, le (ou les) fragment(s) contenant les mots "les ressources prises en considération". Il récupère ainsi un ensemble de versions pour chaque fragment trouvé. Il sélectionne alors la version valide à la date demandée, c'est-àdire ici valide au La version retenue est celle du , étant donné que la suivante, celle du est postérieure à la date recherchée. Il n'y a donc pas eu, pour ce texte et dans notre exemple, de modifications du texte entre le 10 septembre 1997 et le 28 juin / 124

103 Gestion de la cohérence Formalisation d'un contexte Si l'on reprend la formalisation précédemment énoncée pour les documents (cf.formalisation des documents p.94), nous pouvons la compléter avec la formalisation suivante d'un contexte juridique estampillé à une date donnée. CJE date = {d i f i / d vi date et (d vi+1 > date ou non existante)} Un contexte juridique estampillé peut donc être défini comme étant un ensemble de documents ou de fragments, dont la version a une date de création inférieure ou égale à la date demandée alors que la version suivante desdits fragments ou documents a une date de création supérieure à la date demandée (si elle existe) CARACTÉRISTIQUES D'UN LIEN VERSIONNALISÉ Caractéristiques générales Un lien a, par définition, les caractéristiques suivantes : un identifiant, un type (dans notre cas, le type sera "référence", "partage d'information", "composition") une référence à son ancre "source", une référence à son ancre "cible", un paramètre de similarité en cas de lien de partage d'information, une date de création. Ces informations permettent d'utiliser par la suite un lien, à partir d'une date donnée (celle de sa création), entre deux fragments de documents. Ces fragments peuvent appartenir à un même document (lien intra document) ou bien à deux documents distincts (lien inter documents). Dans la suite de notre discours, nous différencierons les deux ancres d'un lien en appelant l'une "source" et l'autre "cible". Il est entendu que pour un lien de partage d'information intégral, la source et la cible du lien sont totalement interchangeables, le lien étant par définition bidirectionnel. Dans le cas d'un lien de référence, le fragment contenant la référence sera appelé source tandis que le fragment référencé sera appelé cible. Enfin, pour le lien de partage d'information partiel, la source et la cible sont définies selon le degré de similarité affecté au lien par l'utilisateur. 103 / 124

104 Gestion de la cohérence Caractéristiques de versionnalisation Lorsque l'on introduit la notion de version avec les liens, il nous faut prendre en compte le fait qu'à une date donnée, un lien va relier deux versions : celle de sa source et celle de sa cible. A une autre date, les numéros de versions des fragments ancres peuvent être différents. Néanmoins, une même version peut être utilisée à plusieurs dates différentes, avec des fragments associés de versions différentes, suivant l'évolution de ce dernier fragment. De plus, un lien peut être momentanément invalidé. Il faut par conséquent être capable d'indiquer au système (ainsi qu'à l'utilisateur) qu'il est impossible d'utiliser le lien à telle date. C'est pourquoi nous ajoutons la propriété suivante à la description d'un lien : une liste de triplets : (date, v num_source, v num_cible ) date correspond à la date à partir de laquelle le couple qui suit doit être utilisé v num_source correspond au numéro de la version de l'ancre source à considérer lors de l'utilisation du lien v num_cible correspond au numéro de la version de l'ancre cible à considérer lors de l'utilisation du lien Formalisation des liens versionnalisés Si l'on considère la formalisation précédemment émise, nous pouvons la compléter par celle des liens versionnalisés. l : Liens = <t,dc,s,c,vv> lien t : {référence, partage d'information, composition} type du lien dc : Date date de création du lien s : Fragment "source" du lien c : Fragment "cible" du lien vv = {(date vv, num s, num c )} ensemble des versions valides des ancres date vv : Date date de début de prise en compte du couple de versions des ancres associé num s : N numéro de la version de l'ancre "source" à prendre en compte num c : N numéro de la version de l'ancre "cible" à prendre en compte Si num s et num c sont à 0, cela signifie que le lien est invalide à partir de la date associée à ce couple de versions d'ancres. 104 / 124

105 Gestion de la cohérence Nous pouvons donc approfondir la définition d'un contexte, qui devient la suivante : CJE date = {d i f i / d vi date et (d vi+1 > date OU non existante)} & {l i / date vvi date et (datevvi+1 > date OU non existante)} Incidences des mises à jour La modification d'un document entraîne, généralement, la création d'une nouvelle version. Comme nous l'avons vu précédemment, cela implique la vérification voire la modification des liens associés aux fragments mis en cause dans la modification AJOUT D'UN FRAGMENT Lors de l'ajout d'un fragment, les premiers liens à mettre en place sont les liens de composition. En effet, avant tout autre liaison, le fragment doit être rattaché à un fragment (excepté s'il s'agit de la racine!), devenant ainsi partie de document. L'ajout d'un fragment dans un document entraîne évidemment la création d'une nouvelle version pour ce document, ainsi que pour les fragments parents de celui ajouté. Les autres types de liens peuvent ensuite être ajoutés. Il faut souligner que pour qu'un lien soit créé, les deux fragments mis en cause doivent déjà exister dans la base, sinon, il y a une incohérence MODIFICATION DU CONTENU D'UN FRAGMENT FEUILLE Lorsque le contenu textuel d'un document est à modifier, c'est un des fragments feuilles dudit document qui est à modifier. Une nouvelle version de ce fragment est alors créée. Cette création est propagée jusqu'à la racine du document, entraînant une nouvelle version du document lui-même. Les différents liens qui ont pour ancre le fragment modifié doivent être contrôlés et éventuellement invalidés. 105 / 124

106 Gestion de la cohérence 4.3. SUPPRESSION D'UN FRAGMENT Il est possible qu'un fragment soit à supprimer d'un document. Cette suppression ne peut être que logique, et non pas physique, étant donné la gestion de versions. La suppression d'un fragment entraîne donc la création d'une nouvelle version pour tous les fragments pères ainsi que pour le document auquel appartient le fragment à supprimer. Dans cette nouvelle version, le fragment supprimé n'apparaît plus, et tous les liens pour lesquels il était ancre sont invalidés. 3. Gestion de la cohérence dans le système d'accès Notre système d'accès permet d'accéder à plusieurs types de bases de données. Celles-ci ont leur propre gestion de cohérence, mais il est aussi indispensable que notre système ait la sienne, notamment pour la base de connaissances et le dictionnaire qui sont tous deux des bases de données structurées La base de connaissances Notre base de connaissances est structurée selon le modèle présenté en 4.3. Par conséquent, nous utilisons la gestion de la cohérence présentée en 2 de ce chapitre. Notre base de connaissances, à l'heure actuelle, ne gère pas les versions de schémas de bases de données. Pour le système, le schéma d'une base de données, enregistré dans la base de connaissances, est celui qui permet d'interroger la base en question à l'instant où la requête est posée. En effet, nous prenons comme hypothèse que les bases à interroger n'ont qu'une seule version de schéma valide. Si une base conserve les versions des données qu'elle gère, cela ne doit pas affecter son schéma, sinon, pour notre système, c'est qu'il existe deux bases distinctes. Les versions antérieures des schémas des bases de données peuvent éventuellement servir aux administrateurs de bases de données. En effet, il faut rappeler que notre système permet non seulement d'interroger des bases en vue d'une prise de décision en fonction de leur contenu, mais il permet aussi de consulter leur schémas en vue de la création d'une nouvelle base ou de la modification d'une base existante. Par conséquent, la gestion des versions présentée précédemment pourrait être utile lorsque les versions des schémas de bases de données seront gérées par notre système. Néanmoins, certains liens peuvent exister entre deux schémas. Ces liens doivent être vérifiés à chaque modification de schéma. La gestion des liens que nous avons évoqué dans le 106 / 124

107 Gestion de la cohérence 2.2. de ce chapitre est donc utilisée pour maintenir la cohérence des liens entre schémas lors de la modification d'un des schémas de base de données. La gestion simultanée des versions et des liens sera ensuite utilisée lorsque les versions de schémas seront intégrées à notre système Le Dictionnaire Le dictionnaire de données utilisé par notre système regroupe l'ensemble des informations sur les noms des données manipulées : le nom logique, les noms physiques et leur utilisation dans les diverses applications. Il est évident que lorsqu'un schéma de base de données est modifié, les noms physiques des données peuvent être modifiés. Le dictionnaire de données doit alors être mis à jour. C'est en effet grâce à lui que les schémas des bases de données peuvent être homogénéisés, en permettant de remplacer le nom physique d'une donnée par son nom logique. Un des moyens pour maintenir le dictionnaire à jour est de réaliser des liens entre les noms contenus dans le dictionnaire et les wrappers. Lorsqu'une base de données est modifiée (par exemple un nom de données), le SGBD de la base "informe" le wrapper, qui va alors déclencher la mise à jour du dictionnaire. Ainsi, le dictionnaire sera toujours à jour, et l'homogénéisation sera correcte. Il est à noter que pour l'instant, le dictionnaire ne prend pas en compte les versions de base de données. Par conséquent, lorsqu'un nom ou qu'un attribut d'une donnée est modifié, le nouveau nom remplace l'ancien, lequel est perdu. Ce choix s'explique par le fait que l'homogénéisation d'un schéma est réalisée sur le schéma valide à l'instant de la demande. Les données du dictionnaire sont structurées selon le formalisme XML. C'est pourquoi nous utilisons la gestion des liens que nous avons présentée précédemment. De même que pour la base de connaissances, lorsque les versions des schémas des bases de données seront intégrés à notre système, nous utiliserons la gestion simultanée des liens et des versions que nous avons présenté pour maintenir la cohérence à l'intérieur de notre dictionnaire. 107 / 124

108 Prototypage - Réalisation Chapitre 6 Prototypage Réalisation Dans cette partie, nous allons présenter les deux réalisations concrètes qui ont été réalisées sur une partie de notre étude. La première consiste en l'interrogation d'une base de documents structurés via une interface WEB, selon un formalisme proche du langage naturel. La seconde réalisation concerne les wrappers, avec l'implémentation d'un wrapper permettant l'interrogation d'une base dans son langage propriétaire et la récupération de la réponse au format XML. 1. Interrogation d'une base de documents structurés 1.1. Introduction Le développement de ce prototype a été réalisé avec le logiciel BASIS, qui permet de gérer des bases de données structurées via une interface WEB, une interface sous Windows et une interface sous UNIX. La création de la base est réalisée sous UNIX par l'administrateur. Par la suite, l'insertion des données est réalisée soit avec l'interface sous Windows, soit avec l'interface WEB, pour plus de convivialité par rapport à l'interface UNIX. L'objectif principal de ce prototype est de valider les choix concernant l'interrogation de bases de documents structurés selon un langage proche du langage naturel par un utilisateur non informaticien et non expert du domaine d'interrogation Présentation de Basis Les fonctionnalités auxquelles nous nous intéressons dans ce prototype sont les suivantes : stocker tous les ensembles documentaires de la branche famille (Code de la Sécurité Sociale, Guide complet des prestations familiales, Guide des textes réglementaires,...), consulter un élément documentaire (ELS), rechercher un élément documentaire, mettre à jour en cascade des éléments réglementaires, c'est-à-dire répercuter une modification par rapport à la hiérarchie des éléments, 108 / 124

109 Prototypage - Réalisation retrouver l'ensemble des éléments documentaires qui sont issus d'un texte réglementaire (c'est-à-dire connaître la liste des textes à modifier suite à une évolution législative), rechercher un document par des informations issues du profil du document, faciliter la maintenance coordonnée des objets réglementaires, pour les liens explicites et implicites (par exemple, les liens de partage d'information), naviguer entre les divers documents lors de la consultation, contrôler la cohérence entre les objets par la gestion des versions, et de l'accès aux versions antérieures d'un élément documentaire. L'outil Basis a été choisi parce qu'il était le seul à intégrer déjà plusieurs de ces fonctionnalités (indexation, thesaurus, recherche en texte intégral, gestion de documents SGML...). Les principaux outils et langages que nous avons utilisés s'articulent de la façon suivante : Basis Desktop TCP/IP Winsocket Noyau BasisPlus Base de Données BasisPlus HTML JavaScript Navigateur Web HTTP TCP/IP Basis WebServer Serveur Web OpenApi / C Figure 44 : Articulation des divers outils BASIS BASISPLUS Il s'agit d'un système de gestion de bases de données relationnelles. Il permet le stockage des documents structurés et fournit des utilitaires de maintenance de la base. Le processus d'indexation en texte intégral est automatisé, et élimine les mots 'vides' contenus dans les documents. De plus, il est possible d'associer une Base Thesaurus à la base de documents en décrivant les relations entre les concepts. L'utilisation de cette Base Thesaurus est automatique. 109 / 124

110 Prototypage - Réalisation BASISDESKTOP Il s'agit d'une interface graphique sous Windows, qui permet aux utilisateurs de rechercher, visualiser et mettre à jour interactivement les données de la base BASISWEBSERVER Cet outil permet de réaliser l'interfaçage entre un serveur Web et une base de données BasisPlus. Il sert d'intermédiaire entre l'interface HTML et la base de documents et permet d'accéder et de publier les informations contenues dans la base. Il est aussi possible d'insérer un enregistrement dans la base à partir de l'interface Web Résultats La plupart des fonctionnalités prévues lors de l'analyse des besoins ont pu être implémentées, avec des simplifications plus ou moins importantes comme nous le verrons plus tard. Le prototype permet donc : de saisir des requêtes en langage naturel, de paramétrer des requêtes selon certains critères, comme par exemple le type du document recherché, exécuter les requêtes utilisant le mécanisme d'indexation en texte intégral, et complété par le thesaurus, utiliser des caractères génériques dans le texte des requêtes, afficher la liste des éléments documentaires résultats d'une recherche, avec conservation du contexte de l'information, visualiser les textes réglementaires, ou éléments documentaires résultats d'une requête, naviguer entre les textes de la base de données, grâce aux liens de référence. 110 / 124

111 Prototypage - Réalisation 1.4. Le prototype L'interface graphique sous le web est présentée à la figure ci-après. Saisie de la requête Résultats de la recherche ou liste de documents Zone de paramétrage de la recherche Fonction de zoom sur le texte réglementaire Sommaire du texte réglementaire Le texte réglementaire Figure 45 : interface graphique du prototype Basis 2. Traduction de requêtes XML en langage propriétaire Base de données Ce prototype concerne la traduction d'une requête XML en langage propriétaire Progress Version 8. Il a été réalisé par M. B. Collardey, du CNEDI. Pour ce prototype, nous considérons une base de données Progress, en version 8, et une interface graphique d'interrogation, intégrant un visualiseur Internet Explorer, et des champs de saisie pour la requête. 111 / 124

112 Prototypage - Réalisation La requête XML est de la forme : <request> <tables> <table> Personne <fields> <field> Prenom </field> <field> Nom </field> </fields> </table> </tables> <where> Personne.Nom="Dupont" </where> </request> La base de données Progress (base de données relationnelle) n'est pas manipulée directement avec du SQL, mais en réalisant des requêtes dites dynamiques en Progress, qui permettent de traduire le XML en langage Progress, interprétable par Progress. Ceci est rendu possible grâce aux caractéristiques de Progress, qui permet l'élaboration de ces "briques" de traduction. Le résultat de la base, rédigé en langage Progress, est traduit par les "briques Progress" en XML et retourné à l'interface graphique qui l'affiche dans la partie "navigateur" de l'interface. Le résultat est alors présenté selon la feuille de style correspondante à l'utilisateur. Si aucune feuille de style n'est disponible, le résultat apparaît sous forme arborescente avec Internet Explorer 5. Ce prototype a été par la suite intégré à une application plus générale, qui permet aux allocataires de consulter leur situation. Avant de mettre en place ce "wrapper", l'accès aux informations contenues dans la base Progress était inaccessible aux allocataires. A présent, ces informations sont accessibles, de façon transparente pour l'utilisateur. L'accès est rapide et 112 / 124

113 Prototypage - Réalisation convivial, la présentation des données pouvant être paramétrée par les feuilles de style lors de la présentation de la réponse au format XML. 113 / 124

114 Conclusion Chapitre 7 Conclusion La problématique à l'origine de notre travail était de permettre à un décideur d'accéder à plusieurs bases de données, hétérogènes réparties, dans le cadre de l'aide à la décision. Nous avons donc proposé une architecture pour un système d'accès à des bases de données hétérogènes. Ce système est basé sur le principe de médiateur / wrappers. L'accès aux différentes bases de données affranchit l'expert ou l'utilisateur de la connaissance des SGBD sous-jacents. Le système proposé est souple car il facilite la prise en compte d'une nouvelle base de données (mise à jour du dictionnaire de données et de la base de connaissances, et ajout d'un wrapper) tout en conservant l'existant, c'est-à-dire les bases de données et leur système de gestion. De plus, l'architecture proposée est générique, notamment grâce à l'utilisation du langage XML. Celui-ci est utilisé pour les messages internes du système, ainsi que pour les messages sortant (en direction des wrappers ou vers l'utilisateur pour la réponse finale). Le système peut ainsi être adapté à n'importe quelle architecture existante sans trop de modifications. Afin d'améliorer ses performances, le système proposé utilise une base de connaissances qui lui permet de connaître, notamment, les schémas des bases de données cibles. Il peut ainsi déterminer les liens existants entre ces bases, et pas seulement les liens intra-base. Notre système SABaDH peut ainsi répondre plus précisément à l'utilisateur, en l'occurrence un décideur, afin de lui fournir le maximum de données sur le sujet demandé. Les schémas de base de données stockés sont structurés, au format XML. Rappelons que cette base de connaissances est spécifique au contexte des Allocations Familiales. Lorsque le système est utilisé dans un autre contexte, la base de connaissances doit être remise à jour. Elle est spécifique à son environnement d'utilisation. D'autre part, nous utilisons un dictionnaire de données, qui nous permet d'homogénéiser les schémas des bases de données stockés dans la base de connaissances. C'est grâce à cette homogénéisation, basée sur XMI, que la comparaison entre les schémas est possible. Elle permet aussi de présenter les schémas à des concepteurs de base de données ou d'applications selon un format homogène. Le contenu de ce dictionnaire dépend du domaine d'application. Néanmoins, sa structure reste la même, ce qui ne diminue pas la généricité de notre système. 114 / 124

115 Conclusion Pour maintenir la cohérence dans le dictionnaire de données et dans la base de connaissances, nous nous sommes intéressés au maintien de la cohérence dans l'une des bases de données considérées dans notre étude : la base de documents juridiques. Les documents de cette base sont structurés selon le format XML, tout comme notre base de connaissances et notre dictionnaire. Chaque texte possède plusieurs versions, valides selon une date, et des liens avec d'autres documents et à l'intérieur d'eux-mêmes. Nous avons donc étudié la gestion simultanée des versions et des liens pour des documents structurés en vu de maintenir la cohérence dans la base. Cette gestion est réutilisée pour le maintien de la cohérence dans la base de connaissances et le dictionnaire de données. Dans le cadre de cette étude, nous avons proposé la notion de Contexte Juridique Estampillé qui permet de définir les caractéristiques des versions et des liens d'un document structuré. Nous avons aussi proposé une formalisation afin de définir précisément les caractéristiques d'un document versionnalisé ainsi que ses liens. Il est à noter que la représentation des liens s'appuie sur la définition des liens XML, c'est-à-dire Xlink et Xpointer. Suite à notre étude et proposition, de nombreuses perspectives peuvent être évoquées. D'une part, l'aspect échange de données est à approfondir. En effet, nous n'avons considéré que les relations Utilisateur Système et Wrapper Système. Il serait intéressant que le système d'accès puisse s'interfacer avec d'autres systèmes ou applications. Dans ce cas, les requêtes en entrée du système pourraient être rédigées d'une façon différente, dans le sens où XML pourrait être utilisé directement dans la rédaction de la requête initiale, et non plus seulement après la première analyse. Il en est de même pour les wrappers qui peuvent correspondrent à d'autres systèmes d'interrogation. L'étude des impacts sur l'architecture est ainsi nécessaire. L'uniformisation de la base de connaissances, du dictionnaire de données et du thesaurus constitue une piste de recherche dans le but de limiter le nombre de mises à jour nécessaires lors de la modification d'une base ou de l'ajout d'une nouvelle base. En effet, lors de la modification de la structure d'une base de données, il est nécessaire de mettre à jour à la fois la base de connaissances et le dictionnaire de données ainsi que la ré-écriture du wrapper associé. Dans ce travail, nous n'avons considéré que des bases de documents (structurés ou non), des bases de règles et des bases de données factuelles. L'intérêt de prendre en compte les 115 / 124

116 Conclusion autres types de médias, et notamment les images, les vidéos est manifeste. Cela entraînera inévitablement des modifications dans le processus d'analyse des requêtes et dans l'élaboration des sous-requêtes. Enfin, un prototype complet est à réaliser afin de valider (ou invalider, ou améliorer) les choix proposés dans ce rapport. 116 / 124

117 Bibliographie Bibliographie AFNOR, 1990 AFNOR, Traitement de l'information. Systèmes bureautiques - Langage normalisé de balisage généralisé (SGML). AFNOR NF EN 28879, Paris : AFNOR, 1990, 177 p AFNOR, 1991 AFNOR, Traitement de l'information - Bureautique - Architecture des documents de bureau (ODA) et format d'échange- Partie 2 : structure des documents, Norme NF ISO , décembre 1991, Applications des TI en bureautique, 212 p. Andonoff et al, 1997 Andonoff E., Hubert G., Le Parc A., Interrogation de Bases de données intégrant des versions, Congrès Inforsid'97, Toulouse, juin 1997, pp Anick et Flynn, 1992 Anick P.G., Flynn R.A., Versionning a full-text information retrieval system, in Proc. 15th SIGIR, Copenhagen, Denmark, Juin 1992, pp Blanken, 1991 Blanken H., Implementing version support for complex objects, Data and Knowledge Engineering, 1991, vol. 6, n 1, pp.1-26 Cellary et al, 1994 Cellary W., Vossen G., Jomier G., Multiversion object constellations : a new approach to support a designer's database work, Engineering with womputers 1994, vol.10, n 4, pp Cellary et Jomier, 1990 Cellary W., Jomier G., Consistency of versions in object-oriented databases, in Proc. 16th Very Large data bases 16 th Int. Conf., Brisbane (Australia), 1990, pp / 124

118 Bibliographie CERTA, 1996 Entrepôt de données ou data warehouse, [on line] Revue de presse du CERTA, mai-juin 1996, Disponible sur : Chabbat, 1997 Chabbat B., Modélisation multiparadigme de textes réglementaires, thèse de l'insa de Lyon, France, 1997, 391 p Chawathe et al, 1994 S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J. Ullman, J. Widom, The TSIMMIS Project : Integration of heterogeneous information sources, Proceedings of 100th Anniversary Meeting of the Information Processing Society of Japan, 1994, oct, Tokyo, Japan, pp Dhouib Elloumi et al, 1998 Dhouib Elloumi S., Bouziz R., Moalla M., Contrôle de concurrence multiversion dans les Bases de Données Temporelles, BDA'98, Tunisie, octobre 1998, pages Faltings, 1994 Boi Faltings, Intelligence Artificielle, au-delà des systèmes experts, [on line] LIA-EPFL, Disponible sur : Franco, 1997 Jean-Michel Franco, Le data warehouse : le data mining, Paris : Eyrolles, 1997, 203p. Gancarski, 1994 Gançarski S., Versions et Bases de Données : modèle formel, supports de langage et d interface utilisateur, Ph. D. thesis, Paris-Sud University, Centre d Orsay, France, 1994, 188p. Garcia-Molina et al, 1997 H. Garcia-Molina, Y. Papakonstantinou, D. Quass, A. Rajaraman, Y. Sagiv, J. Ullman, V. Vassalos, J. Windom, The TSIMMIS Approach to Mediation : Data Models and Languages, Journal of Intelligent Information Systems, 1997, vol. 8, n 2, pp / 124

119 Bibliographie Hainaut et al, 1999 Hainaut J.-L., Thiran P., Hick J.-M., Bodart S., Deflorenne A., Methodology and Case Tools for the developement of Federated Databases, International Journal of Cooperative Information Systems, 1999, Vol. 8, N 2-3, pp , Hammer et al, 1997 J. Hammer, H. Garcia-Molina,, S. Nestorov, R. Yerneni, M. Breuing; V. Vassalos, Template-Based Wrappers in the TSIMMIS System, SIGMOD Record, 1997; vol. 26; N 2, pp Hua et Kimbrough, 1998 Gary H. Hua, Steven Kimbrough, On Hypermedia-based argumentation. Decision Support Systems 1998, vol.22, n 3, pp Hull et Zhou, 1996 R.Hull, G.Zhou, A framework for supporting Data Integration Using the materialised and virtual approaches. SIGMOD Record. 1996, vol 25, n 2, pp L&S, 1997 Data warehouse : une décision stratégique, [on line]"logiciels & Systèmes", septembre-octobre 1997, Hors Série "Technologies Nouvelles", Disponible sur : Labio et al, 1997 W. Labio, Y. Zhuge, J. L. Wiener, H. Gupta, H. Garcia-Molina, J. Widom, The WHIPS prototype for data warehouse creation and maintenance, SIGMOD Record, 1997, vol.26, n 2, pp Li et al, 1998 C. Li, R. Yerneni, V. Vassalos, H. Garcia-Molina, Y. Papakonstantinou, J. Ullman, M. Valiveti, Capability Based Mediation in TSIMMIS. SIGMOD Record, 1998, vol.27, n 2, pp LS, 1997 Logiciels & Systèmes, [on line] septembre-octobre 1997, Hors série "Technologies Nouvelles" : Data Warehouse : une décision stratégique, Disponible sur : Ludäscher et Gupta, 1999a Ludäscher B., Gupta A., Modeling Interactive Web Sources for Information Mediation. Lecture Notes in Computer Science, 1999,n 1727, pp / 124

120 Bibliographie MI, 1997 Data Warehouse, [on line] Le Monde Informatique, n 711 du 28 février 1997, Disponible sur : Michard, 1998 Michard A., XML : Langage et Applications. Paris : Eyrolles, 1998, 361 p. Nicolle et al, 2000a Nicolle C., Amghar Y., Pinon J.-M., Système d'accès à des bases de données hétérogènes dans le cadre de l'aide à la décision, Conférence Inforsid'2000, Lyon, France, mai 2000, pp Nicolle et al, 2000b Nicolle C., Amghar Y., Pinon J.-M., Gestion simultanée des liens et des versions dans le contexte des documents structurés, Conférence CIDE'2000, Lyon, France, juillet 2000, pp Nicolle et al, 2000c Nicolle C., Amghar Y., Pinon J.-M., Interrogation System Architecture of heterogeneous data for decision making, Conférence Internationale RIAO'2000, Paris, France, avril 2000 pp Nicolle et al, 2000d Nicolle C., Amghar Y., Pinon J.-M., Wrapper-oriented access system to heterogeneous data, including legal texts, 7 th Conférence Internationale RETIS'2001, Lyon, France, 4-6 juillet 2001, pp Nicolle et al, 2000e Nicolle C., Alvarez A., Amghar Y., Managing Versions and Links for structured legacy documents, International Symposium on Information Systems and Engineering, ISE'2001, June 25-28, 2001, Monte Carlo Resort, Las Vegas, Nevada, USA. Papakonstantinou et al, 1995 Y. Papakonstantinou, A. Gupta, H. Garcia-Molina, J. Ullman, A Query translation scheme for rapid implementation of wrappers, 4 th International Conference on Deductive and Object-Oriented Databases, 1995, Singapor. Lecture Notes in Computer Science, 1995, n 1013, pp Papakonstantinou et al, 1996 Y. Papakonstantinou, S. Abiteboul, H. Garcia-Molina, Object Fusion in Mediator Systems, Very Large data bases, 22 nd Conference, Bombay, India, September 1996, pp / 124

121 Bibliographie Papakonstantinou et Vassalos, 1999 Y. Papakonstantinou, V. Vassalos, Query rewriting for semistructured data. SIGMOD Record. 1999, vol 28, n 2, pp Papakonstantinou et Velikhov, 1999 Y. Papakonstantinou, P. Velikhov, Enhancing Semistructured Data Mediators with Document Type Definitions, 15 th International Conference on Data Engineering (ICDE99), Sydney, 1999, pp Reichenberger, 1989 Reichenberger C., Orthogonal version management. Proceedings of the 2nd International Workshop on Software Configuration Management, Princeton (USA), 1989, pp Sheth et Larson, 1990 Sheth A.P., Larson J.A., Federated Database System for Managing Distributed, Heterogeneous, and Autonomous Databases, ACM Computing Surveys, vol. 22, n 3, ACM Press, 1990, pp Tayar, 1995 Tayar N., Gestion des versions pour la construction incrémentale et partagée de bases de connaissances, Thèse de doctorat, Université Joseph Fourier, Grenoble I, soutenue le 21 septembre 1995, 137 p. Vassalos et Papakonstantinou, 1999 V. Vassalos, Y. Papakonstantinou, Describing and using query capabilities, of heterogeneous sources Proceedings of 23 rd International Conference on Very Large Data Bases, Athens, Greece, August 25-29, 1997, pp ISBN Wiederhold, 1992 G. Wiederhold, Mediators in the Architecture of Future Information Systems, Computer, 1992,vol 25, n 3, pp 38 à 49 Wiederhold, 1995 G. Wiederhold, Modeling and system maintenance, Lecture notes in computer science, 1995, no. 102, pp / 124

122 Sigle Signification Principaux sigles utilisés dans ce document BDJ CAF CJE CNAF CNEDI CSS DGI DII DPF DSSSL DTD HOLAP HTML INSEE MDD MOF MOLAP NDP ODA OEM OLAP OMG PV ROLAP Base de Données Juridique Caisse d'allocations Familiales Contexte Juridique Estampillé Caisse Nationale des Allocations Familiales Centre National d'etudes et de Développements Informatiques Cascading Style Sheets Direction Générale des Impôts Dictionnaire d'information Institutionnel Direction des Prestations Familiales Document Style Semantics and Specification Language Document Type Definition Hybrid OLAP HyperText Markup Language Institut National de la Statistique et des Etudes Economiques MultiDimensional Database Meta Object Facility Multidimensional OLAP Notification de Droit de Paiement Office Document Architecture Object Exchange Model On Line Analytical Processing Object Management Group Procès Verbal Relational OLAP 122 / 124

123 Sigle Signification SGBD SGML SIAD ( IDSS) SMIF SQL TSIMMIS UML VDB VDP Système de Gestion de Bases de Données Standard Generalized Markup Language Système Interactif d'aide à la Décision Stream - Based Interchange Format Structured Query Language The Stanford-IBM Manager of Multiple Information Source Unified Modeling Language Versionning DataBase View Decomposition Plan VOQL VOGQL W3C WHIPS XLL XMI XML XSL XSLT World Wide Web Consortium WareHouse Information Prototype at Stanford extensible Linking Language XML Metadata Interchange extensible Markup Language extensible Style Language extensible Style Language Transformation 123 / 124

124 Architecture de Système d'accès à des bases de données hétérogènes pour l'aide à la décision De tous temps, lors d'une prise de décision, le décideur a dû faire face au problème d'accès à toutes les données qui lui sont nécessaires pour prendre une décision juste. De nos jours, de nombreux systèmes proposent une aide à cette prise de décision. Mais il est encore difficile, pour le décideur, de savoir où trouver les informations voulues. De plus, il peut ne pas connaître la nature de toutes les données qui lui sont utiles dans sa prise de décision. C'est pourquoi nous proposons une architecture de système d'accès qui permet au décideur de poser une requête en langage proche du langage naturel, sans avoir besoin de préciser où rechercher les données en question. Le système sait où trouver les informations, et peut même fournir au décideur des informations liées à celles qu'il voulait, ces informations étant utiles à la prise de décision (complétant ainsi la recherche de l'utilisateur tout en fournissant des réponses pertinentes). Le système pallie ainsi à certaines éventuelles lacunes du décideur dans le domaine de recherche. Notre système utilise le principe des wrappers, ainsi que XML comme langage interne, langage de requêtes et de réponse. Deux prototypes ont été réalisés au cours de la thèse, un sur la recherche dans une base de textes juridiques, un autre sur l'interrogation en XML d'une base Progress avec réponse en XML. Mots clefs : bases données hétérogènes, système accès, XML, médiateur, wrapper, aide à la décision, structure donnée, base connaissance Architecture of Access system of heterogeneous database for decision making Since all time, for decision making, decider had to be faced with access problem of all needed data to take the better decision. Nowadays, most systems provide help for this decision making. But it's always difficult to know where the decider can find relevant data. Furthermore, decider can't know type of all data which he need to make his decision. That's why we propose an architecture of an access system which allows decider ask his request in language like natural language, without more detail about their location. Our system can find this data, and provides all information in relation with searched data, these information being relevant. Our system can alleviate some deficiency about search domain. Our system uses wrapper principle, and XML as internal language and request and answer language. Two prototype have been realised, one about search in legal texts base, the other about XML interrogation of Progress base with answer in XML. Key words : heterogeneous data, access system, XML, wrapper, mediator, knowledge base, decision making, structured data. Informatique et Information pour la Société Documents Multimédia, Images et Systèmes d'information Communicants LISI - INSA de Lyon Bâtiment Blaise Pascal 20 av Albert Einstein Villeurbanne Cedex 124 / 124