Vous êtes sur la page 1sur 17

Système d'accès à des bases de données hétérogènes dans le cadre

de l'aide à la décision
C. Nicolle1,2 Y. Amghar1 J.-M. Pinon1
1 2
INSA de Lyon CNEDI –CNAF
INSA de Lyon – 20 av. Albert Einstein – 69 621 Villeurbanne Cedex
CNEDI – CNAF – Tour du Crédit Lyonnais – 129 rue Servient – 69 326 Lyon Cedex 03
cnicolle@lisisun1.insa-lyon.fr, amghar@ifhpserv.insa-lyon.fr, pinon@if.insa-lyon.fr
Catégorie : Chercheur
Résumé
L'aide à la décision est un domaine de recherche très actif, et ce depuis de nombreuses années déjà. Les
décideurs sont, de nos jours, face à un nombre croissant de données, de plus en plus hétérogènes. Il est donc difficile
pour le décideur, dans une entreprise, de retrouver les données qui lui sont nécessaires pour sa prise de décision.
C'est dans ce contexte que se situe notre étude. Nous proposons dans cet article un système d'accès à des bases de
données hétérogènes. Ce système permet d'une part d'affranchir les décideurs de la connaissance des structures de
représentation des données lors de la formulation de leurs requêtes et d'autre part de connaître la cartographie
d'ensemble du système d'information. Nous introduisons la notion de "schéma pivot" qui homogénéise les schémas
des diverses bases de données afin d'améliorer les connaissances sur ces bases lors de la recherche d'informations.
Une base de connaissances est notamment utilisée pour fournir une vue d'ensemble sur les données recherchées. Un
thesaurus permet de compléter la recherche et autorise ainsi le décideur à formuler une requête en utilisant des
termes du langage naturel. Un décideur peut ainsi rechercher des données parmi des bases de données hétérogènes
sans pour autant connaître l'emplacement de ces données ainsi que leur format de stockage. Les divers liens
existants entre les bases de données sont exploités afin de retrouver les données les plus pertinentes et éliminer ainsi
le risque de bruit dans les réponses. Ces réponses sont par la suite réunies avant d'être présentées au décideur. Le
langage XML est utilisé comme langage de description interne, ainsi que pour décrire les requêtes et pour restituer
la réponse avant de la présenter au décideur. L'utilisation de XML et d'une base de connaissances qui peut être
extériorisée rend notre système d'accès très générique et réutilisable.
Mots clés : bases de données hétérogènes, interrogation de bases de données, XML, aide à la décision
Abstract
Decision Support System has, for several years, been a very active domain of research. The deciders of today are
faced with an ever increasing flow of data, which is becoming more and more diverse. It is therefore difficult, in a
company, for the decision taker to find the data which is necessary for him to make decisions. It is in this context
that is placed our study. We propose in this article, a system to access different databases. This system will permit
deciders to formulate requests without having to know the structure of their data and allow them to have an
overview of their information system. We introduce the notion of "pivot schema" which gives uniformity to the
schemas of different databases with the objective of improving, when researching, the understanding of the data. A
knowledge base is also used to allow a global view of the researched data. A thesaurus is used to allow the decider
to formulate his requests using natural language. A decider will therefore be able to research data using different
databases, without having to know the emplacement or structure of the data. The different links that exist between
the databases are used so as to find the data the most pertinent and help to eliminate the risk of noise in the answers.
These answers are united before being presented to the decider. The language XML is used not only as an internal
description language but as well for describe requests and for the restitution of the answers before showing them to
the decider. The use of XML and the knowledge base, which can be exteriorised, makes our system very generic and
reusable.
Keywords : heterogeneous databases, databases querying, XML, decision support system

1 / 17
1 Introduction
L'aide à la décision est un domaine très vaste. De nos jours, le nombre de données
consultables est considérable et ne cesse d'augmenter. Les types des données considérés sont très
variés (données factuelles, textuelles structurées ou non, image, son, etc.). Le décideur est face à
un grand nombre de données à consulter avant de prendre une décision.
Les caisses d'allocation familiales dans laquelle se déroule ce projet gèrent un volume
important de données hétérogènes : textes réglementaires ou juridiques (structurés selon SGML
ou XML), données atomiques ou complexes (concernant les allocataires), données multimédia
(image, son,…), ce qui nécessite différents systèmes de stockage, de manipulation et
d'interrogation. En outre, les applications qui accèdent à ces différentes données sont souvent
cloisonnées et les inter-relations entre données hétérogènes sont rarement prises en compte. Au-
delà des traitements classiques dont font l'objet ces informations, il est souvent indispensable aux
décideurs de l'entreprise de réaliser des corrélations sur les différentes données issues des
systèmes différents dans le but d'aider aux prises de décisions. Pour cela, ils peuvent être amenés
à formuler des requêtes qui ne s'adressent pas à une base unique mais font intervenir une
sémantique d'ensemble sur les données de l'entreprise. Sur un autre plan, l'écriture de nouvelles
applications nécessitent de connaître la cartographie des informations au sein des architectures
informatiques afin de réutiliser des données existantes et éviter de créer inutilement de nouveaux
schémas de bases de données.
C'est dans cette problématique générale que s'inscrit ce projet dont l'objectif est de réaliser un
système d'interrogation de données hétérogènes pour l'aide à la décision.
La contribution de notre travail consiste en la mise en place d'un système d'interrogation qui,
d'une part, affranchit les décideurs de la connaissance des structures de représentation des
données lors de la formulation de leurs requêtes, et d'autre part permet aux administrateurs des
données de connaître la cartographie d'ensemble du système d'information. Cette cartographie
concerne aussi bien la dimension "donnée" que "application" (procédures, fonctions, etc.). Dans
ce travail, nous nous appuyons sur les deux requêtes types suivantes : (1) Quels sont les textes
qui s'appliquent aux allocataires célibataires ? et (2) Quelles sont les applications qui utilisent les
ressources de l'allocataire comme élément de calcul et comment sont décrites ces ressources dans
la base de données ? Le premier type de requête fait intervenir les liens qui peuvent exister entre
des données de bases et de structures différentes, et le second type de requête montre l'intérêt
qu'il y a à connaître l'utilisation et la description d'une donnée à travers l'ensemble du système
d'information en vue de son extension.
De nombreuses études ont déjà été réalisées dans le domaine de la recherche d'information
notamment dans des bases de données hétérogènes [AHME,1991, AKOK,1997, CARE,1994, CHRI,1997,
FLES,1998...]. Il en ressort que l'utilisation de médiateurs et de wrappers [WIED,1992, WIED,1995]
semble la plus adaptée à la recherche d'information dans des bases de données hétérogènes.
Nous nous inspirons donc de la technique des wrappers et des médiateurs afin de proposer un
système d'accès aux bases de données hétérogènes grâce auquel un décideur pourra interroger
toutes les bases de données susceptibles de l'aider dans sa décision.

2 / 17
2 Contexte d'étude
Notre étude se situe dans le cadre des caisses d'allocations familiales. Différents types de
décisions sont pris s'appuyant sur des données très hétérogènes. Par exemple, pour décider de
l'ouverture ou non d'une nouvelle permanence, un directeur de CAF consultera les données
relatives aux allocataires (par exemple pour connaître les allocations les plus versées et
entraînant donc un surcroît de travail), à l'insee (par exemple pour connaître la répartition des
allocataires sur le territoire), au budget (pour savoir si les fonds nécessaires à la construction
éventuelle de la permanence sont disponibles), aux marchés publics (pour la construction de la
permanence)… Un technicien conseil, quant à lui, aura parfois besoin de consulter à la fois des
données relatives à l'allocataire et les textes relatifs aux allocations auxquelles prétend
l'allocataire. Toutes ces données hétérogènes sont généralement stockées dans des bases de
données différentes. Néanmoins, pour consulter ces données, le décideur ne doit pas
nécessairement connaître l'emplacement exact des données, ni leur format de stockage. De plus,
certaines données utiles à la prise de décision sont en fait élaborées à partir de données brutes
(par exemple par corrélation entre diverses données). Le décideur peut ne pas savoir exactement
les données qui lui seraient utiles à sa prise de décision. Bien souvent, il ne recherche que par
mot clé. Il est donc nécessaire de lui fournir les différentes données relatives à ce mot clé (par
exemple "ressources" fait aussi bien référence au "salaire" perçu par un allocataire qu'aux autres
types de revenus).
Plus précisément, il s'agit d'organiser la description des données afin de rendre transparent les
structures internes et permettre des formulations de requêtes proches du langage naturel. Les
données manipulées par le CNEDI de Lyon concernent :
• les textes juridiques structurés selon la norme SGML. Ces textes s'appliquent au
contexte des allocations familiales et sont constitués de lois, de décrets, de
circulaires, etc.
• les données sur les allocataires permettant de gérer des propriétés simples ou non
comme le nom, la situation familiale, les ressources, le nombre d'enfants, le revenu
imposable, etc. Le schéma de représentation de ces données est un schéma
relationnel.
• les règles d'attribution de prestations qui sont exprimées sous forme de règles de
production de la forme "si prédicat alors allocation A validée". Ces règles sont
extraites (manuellement) des textes juridiques par des spécialistes du droit.
Le CNEDI dispose, entre autres, d'une application centrée sur un système expert permettant
de calculer en temps réel les prestations d'un allocataire en exécutant l'ensemble des règles
appropriées au cas considéré.

3 Etat de l'art
La recherche d'information dans des bases de données hétérogènes est un sujet de recherche
très actif depuis de nombreuses années déjà [AHME,1991, CHRI,1997, FLES,1998, FOUR,1998,
GUPT,1989, HULL,1996]. Dans les années 90, les bases de données fédérées [LITW,1990, SHET,1990,
SU,1996, THOM,1990, WIED,1992] ont été proposées pour intégrer des bases de données existantes
tout en limitant le degré de complexité de cette intégration, et pour conserver une part
d'autonomie aux bases de données existantes. Mais un des principaux inconvénients des bases de
données fédérées est que le flux d'information n'est pas réellement coordonné, ce qui peut
entraîner une dispersion de l'information.

3 / 17
Durant ces dernières années, des systèmes basés sur les médiateurs [WIED,1992] ont été étudiés
et réalisés. On peut citer Information Manifold (de AT&T) [LEVY,1996] et TSIMMIS (de
l'université de Stanford) [CHAW,1994, GARC,1997] comme deux exemples d'implémentation de
médiateurs. On peut définir l'architecture basée sur les médiateurs comme une architecture à
deux niveaux : un niveau de médiateurs, et un niveau de wrappers. Un wrapper est un traducteur
qui, dédié à une base de données en particulier, traduit les informations venant du médiateur en
un langage compréhensible par la base de données à laquelle il est attaché, et inversement. Un
médiateur, quant à lui, est chargé d'interroger une ou plusieurs bases de données, et est donc relié
à un ou plusieurs wrappers (voire des médiateurs).
Comme nous l'avons dit précédemment, nous nous intéressons aux données hétérogènes. Bien
que les médiateurs et les wrappers permettent une intégration des données hétérogènes, le
dialogue entre les médiateurs et les wrappers se doit d'être neutre et générique. Etant donné que
nous devons considérer des textes structurés en XML, il nous a semblé logique d'utiliser ce
langage (ainsi que divers autres langages qui lui sont associés) pour dialoguer entre les
médiateurs et les wrappers. Nous verrons ultérieurement l'intérêt d'utiliser XML dans notre
étude.

3.1. Les médiateurs et wrappers


Lorsque l'on interroge différentes bases de données, plusieurs problèmes sont à prendre en
compte dont les suivants :
• La disparité des types de données,
• La différence entre les langages d'interrogation des divers systèmes,
• L'hétérogénéité des schémas de données.
Lorsqu'un utilisateur émet une requête vers un système d'accès central, ce système d'accès
doit déterminer vers quelle(s) base(s) envoyer la requête, et doit aussi être capable de modifier la
requête si nécessaire avant de l'envoyer à une base. Cette requête doit arriver au système gérant
la base de données dans un langage compréhensible par ce système.
Le rôle du médiateur est "d'aiguiller" la requête vers la bonne base de données. Le wrapper est
ensuite chargé de traduire la requête dans le langage compréhensible par le système gérant la
base de données en question. Le wrapper récupère ensuite la réponse du système et la renvoie au
médiateur après l'avoir traduite dans le langage connu du médiateur.
Un médiateur peut donc "dialoguer" avec plusieurs wrappers (qui, de plus, peuvent aussi être
interrogés par différents médiateurs). Un wrapper sera en revanche dédié à une seule base de
données.

4 / 17
Médiateur Médiateur

n
tio

se
on
es
qu

rép
Wrapper Wrapper Wrapper

Base de Base de Base de


données données données

Figure 3-1 : Illustration de médiateurs et wrappers

3.2. XML
Etant donné la croissance incessante du volume d'informations échangées, que ce soit à
l'intérieur d'une entreprise ou entre entreprise, il est indispensable d'avoir un standard permettant
d'échanger ces informations. XML1 [MICH,1999, XML,1998], étant un standard qui répond à cette
préoccupation, permet de structurer les données selon un modèle (encore appelé DTD :
Document Type Definition) pour attacher une certaine sémantique aux informations.
Dans le cadre de notre étude, nous utilisons XML comme support pour la description des
requêtes et comme format d'échange, que ce soit entre les différents éléments de notre système
d'accès ou entre notre système d'accès et les wrappers (voir le paragraphe "Un système d'accès
générique"). Cela permet d'envoyer une même requête à différentes bases de données sans
connaître le langage d'interrogation cible. En utilisant XML, le même langage est conservé à la
fois pour les requêtes, pour la réponse fournie à l'utilisateur et pour les schémas de bases de
données. Aucune traduction en format propriétaire n'est utile.
Dans le cadre de notre étude, et plus particulièrement, en ce qui concerne l'échange de
données et la représentation de schéma, une autre proposition, basée sur XML, sera également
utilisée. Il s'agit de XMI, que nous détaillons ci-après.

3.3. XMI
Le groupe OMG2 a proposé XMI (XML Metadata Interchange), afin de spécifier un modèle
d'échange d'informations ouvert, destiné à donner aux développeurs utilisant une technologie
objet, la capacité d'échanger des données de programmation à travers Internet d'une façon
standardisée. XMI intègre trois standards clés de l'industrie :
• XML : eXtensible Markup Language, un standard du W3C,
• UML : Unified Modeling Language, un standard de modélisation de OMG,
• MOF : Meta Object Facility, un standard d'entrepôt de métadonnées et de
modélisation de OMG.

1
eXtended Markup Language
2
Object Management Group

5 / 17
La soumission XMI de OMG consiste principalement en :
1. un ensemble de règles de production de DTD XML pour transformer des méta-
modè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 et MOF.
Dans notre cas, nous allons utiliser la DTD UML fournie par XMI afin de traduire un schéma
de base de données réalisé en UML au format XML. Par la suite, ce schéma est traduit en un
format homogène que nous appelons "schéma pivot" et que nous présentons ultérieurement.

4 Un système d'accès générique


Afin d'aider le décideur dans sa consultation de données hétérogènes lors d'une prise de
décision, notre projet vise à réaliser un système d'accès permettant à un utilisateur d'accéder à
toutes les bases de données de l'entreprise via un seul système d'accès, et de les interroger via un
langage uniforme et simple, sans avoir besoin de connaître l'emplacement des données qu'il
recherche ni les données précises qu'il recherche. En effet, certaines informations sont utiles dans
leur forme brute, sans traitement ni manipulation quelconque, alors que d'autres informations
peuvent provenir de données traitées ou dérivées, qui ne sont pas forcément connues de
l'utilisateur. L'accès aux données est entièrement à la charge du système, ce qui ne nécessite pas
l'intervention de l'utilisateur pour préciser la localisation des données.
Notre système s'inspire de la méthode qui utilise les médiateurs et les wrappers. Le schéma de
la figure 4-1 illustre le principe du système d'accès, tandis que la figure 4-2 illustre les différents
composants de ce système.

Sous-requêtes
Requête utilisateur Système «XML» Bases de
Wrappers
... ... Données
Réponse «XML» d ’accès

Base de
connaissances

Figure 4-1 : Système d'accès aux bases de données hétérogènes

Le système reçoit en entrée une requête utilisateur, traite la requête en élaborant des sous-
requêtes destinées à chaque base de données contenant les informations recherchées. Le système
récupère ensuite les réponses de chaque base de données et les combine afin d'élaborer la
réponse finale.

6 / 17
Requête
Analyseur de
Sous-requêteur
requêtes

R = SR1 @ SR2 @...@ SRn


SR 1
Wrapper BD1
thesaurus Base de
Connaissance X
Réponse M
XML L
SR 2
Wrapper BD2
Aiguilleur .
X
M .
Rédacteur de réponses .
L
réponse XML SR n
Wrapper BDn

Figure 4-2 : Système d'accès - détail

Le système d'interrogation que nous préconisons est constitué de quatre composants


principaux.

4.1. L'analyseur de requêtes


Ce composant a pour but, comme son nom l'indique, d'analyser la requête de l'utilisateur afin
d'en extraire non seulement les données à rechercher mais également le contexte dans lequel
elles sont recherchées. Il utilise pour cela un thesaurus, la requête utilisant des termes du langage
naturel. Ce thesaurus lui permet de mettre en évidence les différentes données recherchées
(données des allocataires, textes juridiques…) et de donner les liens existants entre ces diverses
données ("allocataires concernés par la loi…"). Il envoie le résultat de son analyse au sous-
requêteur.

4.2. Le sous-requêteur
Ce composant utilise la requête initiale, les informations provenant de l'analyseur de requêtes
ainsi qu'une base de connaissances afin de décomposer la requête initiale en sous-requêtes,
chacune destinée à une base de données. La base de connaissances permet au sous-requêteur de
déterminer l'emplacement des données recherchées (qui sera utilisé par la suite par l'aiguilleur
pour envoyer la sous-requête à la bonne base de données), les différents liens existants entre les
bases de données, notamment afin de réaliser par la suite des jointures (par exemple) sur les
réponses fournies par les bases de données. Cela est possible notamment grâce aux schémas
homogènes des bases de données (voir § 4.5.1).
Le sous-requêteur établit donc non seulement les sous-requêtes destinées aux bases de
données mais aussi un plan de séquencement et un filtre de décomposition de requête. Le
plan de séquencement permet à l'aiguilleur de savoir quand et dans quel ordre envoyer les
diverses sous-requêtes. Cela permet de récupérer une réponse afin de restreindre le domaine de
recherche d'une autre sous-requête. Le filtre permettra, après récupération des réponses, de
combiner les différentes réponses d'après la requête émise par l'utilisateur. La réponse
correspondra ainsi à la question posée, et ne sera pas un ensemble d'informations désordonnées.

7 / 17
4.3. L'aiguilleur
Ce composant a pour rôle d'envoyer les diverses sous-requêtes à la bonne base de données,
selon le plan de séquencement qu'il reçoit du sous-requêteur. Si une sous-requête a besoin d'une
réponse provenant d'une autre base de données avant d'être envoyée, c'est l'aiguilleur qui est
chargé de compléter la sous-requête en fonction de la réponse en question.
Il récupère ainsi toutes les réponses et les fait parvenir, ainsi que le plan de séquencement, le
filtre de décomposition et les différentes sous-requêtes, au rédacteur de réponses.
L'aiguilleur et le sous-requêteur forment, pour le système d'accès, le médiateur. Ce dernier a
donc un rôle plus étendu que dans TSIMMIS, puisqu'il est chargé d'élaborer des sous-requêtes et
de les dispatcher en ordre et en temps voulus.

4.4. Le rédacteur de réponses


Il est chargé de fournir une réponse à l'utilisateur. Pour cela, il utilise le filtre de
décomposition de requêtes pour reconstituer une réponse correspondant à la requête posée, c'est-
à-dire en tenant compte du contexte d'interrogation. La réponse, comme tous les échanges
d'information à l'intérieur du système d'accès, est codée en XML. Cela permet, lors de la
présentation de la réponse, de pouvoir envoyer la réponse à différents supports (écran,
imprimante, autre application…). De plus, on peut afficher les informations en fonction de
l'utilisateur, ce qui permet d'envoyer la même réponse, sous différentes formes, à plusieurs types
d'utilisateurs.

4.5. La base de connaissances


L'élément central de tout ce système est en fait la Base de Connaissances. Cette base de
connaissances a plusieurs rôles :
• connaître la base de données de stockage de la donnée recherchée,
• connaître les liens entre les diverses données dans une même base,
• connaître les liens entre des données de bases différentes (par exemple pour
connaître les éventuels "champs" nécessaires aux jointures inter-bases)
Pour remplir les deux derniers rôles, un schéma pivot de représentation des schémas des bases
de données est utilisé. Ce schéma pivot permet d'homogénéiser les divers schémas pour
comparer notamment les schémas entre eux. De plus, les concepteurs d'applications ou de bases
de données peuvent avoir besoin de connaître les schémas des différentes bases avant de
concevoir une nouvelle application ou une nouvelle base de données. Il est donc nécessaire de
leur présenter les schémas des bases de données, selon un format homogène, afin de faire
apparaître les relations intra et inter-bases. L'intérêt de stocker au format XML est :
• de travailler avec un format standard,
• d'utiliser la proposition XMI pour élaborer un schéma pivot à partir de modèle
UML,
• de présenter les schémas sous diverses formes, selon les besoins du concepteur,
• de comparer aisément les schémas tout en conservant une sémantique commune
mais explicite.

8 / 17
4.5.1. Schéma pivot

Pour pouvoir comparer deux schémas de base de données, il est nécessaire d'avoir une
représentation homogène de ces schémas. Nous nous sommes inspirés de XMI3 pour élaborer
notre schéma pivot, décrivant de façon homogène les schémas des bases de données. Ce schéma
pivot est écrit en XML, et a les caractéristiques suivantes :
• la balise <Modèle> permet de donner le type du modèle : relationnel ou objet,
• la balise <Entité> représente soit une Table (pour un modèle relationnel), soit une
Classe (pour un modèle objet), et la balise <Elément> permet de définir une colonne
(en relationnel) ou un attribut (en orienté objet),
• la balise <Relation> permet de définir les relations existant entre deux entités.
Les "Eléments" sont toujours à l'intérieur d'une "Entité". Les balises <Elément> seront donc
toujours imbriquées à l'intérieur des balises <Entité> </Entité>.
Le corps du document ainsi constitué est découpé en deux parties :
• la première contient les déclarations des entités et éléments,
• la seconde contient les déclarations de relations.
La balise relation a les caractéristiques suivantes :
• la sous-balise "ancre1", qui définit la première ancre (entité) de la relation,
• la sous-balise "ancre2" qui définit la seconde ancre (entité) de la relation,
• la sous-balise "type" qui définit le type de la relation (héritage, partage d'information,
etc.),
• une liste d'attribut pour cette sous-balise constituée d'une liste de couples
(nom,valeur), permet par exemple de connaître le degré de similitude pour un lien de
partage d'information,
• la sous-balise "nom" qui permet de nommer la relation,
• l'attribut "orienté" de cette sous-balise permet de définir que la relation est orientée.
Dans ce cas, l'ancre1 correspond à la source de la relation (par exemple pour une
relation d'héritage, l'ancre1 correspondra à la classe fille) et l'ancre2 correspond à la
cible de la relation (pour la relation d'héritage, l'ancre2 sera la classe mère).
La traduction du schéma de la base de données vers le format XML est assurée par les
wrappers, en s'appuyant sur une DTD connue par tous ces derniers et remise à jour si nécessaire
par le "médiateur", c'est-à-dire par l'aiguilleur.
Nous utilisons de plus un Dictionnaire Institutionnel afin d’homogénéiser les différentes
balises de chaque schéma après les avoir traduit de UML vers XML. Ce dictionnaire regroupe
les différents termes utilisés dans toutes les applications pour chaque donnée manipulée. Par
exemple, un nom de personne peut, dans une application, être identifié par le terme « nom »
alors que dans une autre, il sera identifié par « nom_personne ». Le dictionnaire nous permet
d’utiliser un seul terme pour ce concept (par exemple, « nom_personne »).

3
Voir Etat de l'art, paragraphe 3.3

9 / 17
Le passage d’un schéma de base de données au schéma pivot nécessite plusieurs étapes :
• il faut tout d’abord que le schéma de la base de données soit au format UML (si ce
n’est pas le cas, il est nécessaire de le traduire en UML) ;
• ensuite, on utilise la DTD pour UML fournie par XMI afin de traduire le schéma de la
base en XML ;
• on homogénéise ensuite le schéma grâce au dictionnaire institutionnel et on obtient
donc le schéma pivot de la base de données considérée.
Ces étapes sont répétées pour chaque base de données.
4.5.2. Modèle de la base de connaissances

Nous proposons un modèle de base de connaissances en vue d'identifier les informations


nécessaires à l'interrogation des différentes bases de données. Le schéma ci-après illustre le
modèle de cette base de connaissances.

Base de 1..1 possède > 1..1


Schéma
données 1..n
1..n de 1..1
mposé 1..n de

est com
1..n <est co sé
s " 1..1 po
dan m
est stockée

e co

posé d
cké Type Modèle 1..n st
dans

t st o 0..n <e
" es Entité

e>
1..n
1..n
1..n 1..n
est composée de
0..n
Relation
1..n
Règle Données 1..n
1..n pr
ov Elément
ien
td
e
1..n Non Textuelles
0..n utilisent
Textuelles 0..n
Multimédia

Image Son Vidéo


Structurées Non Structurées
Alphanumériques
s'applique sur > 1..n

Figure 4-3 : modèle de la base de connaissances

Le rôle de la base de connaissances est, comme nous l'avons dit précédemment, d'avoir une
vue d'ensemble sur les données recherchées. Elle permet notamment :
• de savoir où sont situées les données recherchées,
• quels sont les liens existants à l'intérieur d'une base de données (notamment grâce à
l'élément "Relation"),
• quels sont les liens existants entre les bases de données étant donné que l'on peut
connaître les champs communs à deux bases de données,
• les liens existants entre les règles et les textes dont elles sont extraites.

10 / 17
5 Exemple

5.1. Exemple de contenu de deux des bases considérées


5.1.1. La base de données juridiques

Un texte juridique est structuré selon la norme XML. La figure ci-dessous montre le début
d’un texte juridique au format XML.

<SUIVILEG>
<FRONT><GROUPE - TITRE>
<TITRE - PRINCIPAL>
<LIB> Conditions Générales d’Ouvertures de Droit </LIB>
</TITRE - PRINCIPAL>
</GROUPE - TITRE>

</FRONT>

</SUIVILEG>

5.1.2. La base de règles

Les règles sont extraites des textes juridiques afin de déterminer quels sont les droits de
chaque allocataire. Voici un exemple de règles extraites d’un texte juridique
4
.

Age_ok(prestation, mois_traité, date_naissance)


Si calcul_age(date_naissance,mois_traité,age)
et param_limite_age(prestation, limite_inf, limite_sup)
et limite_inf ≤ age
et age < limite_sup

Dans l’exemple suivant, nous considérerons que les règles sont au format Prolog, avec une
partie gauche contenant les prédicats à vérifier afin que la partie droite de la règle soit validée.

5.2. Exemple de traitement d’une requête


Comme nous l'avons dit précédemment, nous utilisons à la fois une base de connaissances et
un thesaurus. La base de connaissances permet d'approfondir notre connaissance des diverses
bases de données gérées alors que le thesaurus permet notamment d'analyser une requête
formulée à partir de termes du langage naturel. Un décideur pourra par exemple poser une
requête de la forme : "allocataires concernés par la loi n°94-629".
Prenons l'exemple d'un décideur qui cherche à connaître l'impact d'une éventuelle modification de la
loi n° 94-629. Il formule sa requête de la façon suivante :
"impact d'une modification de la loi n° 94-629 ?"
La Figure 5-1 illustre les différentes étapes de la recherche.

4
Voir Thèse de Bertrand Chabbat [CHAB, 1997]

11 / 17
Le système d'accès, grâce au thesaurus, va pouvoir déterminer qu'il faut rechercher tout ce qui est en
rapport avec la loi n°94-629 ( étape 0 sur la figure).
Dans un premier temps, on recherche les divers liens existants entre un texte juridique de type "loi" et
les autres bases (étape 1). On trouve, grâce à la base de connaissances et notamment les schémas
pivots des bases, qu'il existe un lien entre la base de textes juridiques et la base de règles. En effet, il
existe un champ « Allocation » pour les deux bases :
• chaque texte juridique concerne une allocation,
• une règle possède des prédicats dont certains concernent les allocations perçues (rappelons
que le fait de percevoir une allocation peut entraîner la non-perception d’une autre allocation,
comme par exemple la perception de l’APE qui entraîne l’invalidation du Complément
Familial).
Par la suite, le lien entre la base de règles et la base des données allocataires est identifié. En effet,
les règles permettent de déterminer quelle(s) allocation(s) doit percevoir l’allocataire.
On connaît ainsi non seulement les liens entre bases mais aussi les "champs" qui permettent de
mettre en relation ces différentes bases.
Une fois cela déterminé, on peut déterminer le plan de séquencement et le filtre de découpage afin
d'élaborer les diverses sous-requêtes à poser aux bases (ici, 3 bases sont à interroger : la base de textes
juridiques, la base de règles et la base de données allocataires). On recherche alors la loi en question
(étape 2), ce qui nous donne l'information suivante (étape 3) : le texte concerne l'Allocation Parentale
d'Education, c'est-à-dire l'APE. On recherche alors dans la base de règles toutes les règles (étape 4) qui
ont :
• dans les prédicats gauches, l'APE associée à une autre allocation (c'est-à-dire à d'autres
prédicats), ce qui nous donnera les différentes allocations impactées par la modification de la
gestion de l'APE (par exemple, le fait de percevoir l'APE invalide le versement du Complément
Familial),
• pour terme validé (c'est-à-dire la partie droite de la règle) l'APE (par exemple, si un allocataire
perçoit l'APJE, il ne peut pas percevoir l'APE).
On obtient en retour (étape 5) toutes les allocations qui sont mises en cause (directement, comme
l'APE, ou indirectement, comme l'APJE) par la modification de la loi.
Par la suite, on recherche tous les allocataires percevant l'APE ou une allocation résultat de la
recherche sur la base de règles (étape 6). Les réponses (étape 7) sont ensuite envoyées au système
d'accès qui va former la réponse finale avant de la fournir à l'utilisateur (étape 8).

12 / 17
"Impact d'une modification Réponse fournie
de la loi n°94-629 ? " à l'utilisateur
8
XML

Système d’accès aux bases de données

2 3 4 5 6 7

0 1

Base de Base de
Base de
textes données
règles
juridiques allocataires

Base de
Thesaurus
connaissances

Figure 5-1 : Illustration des diverses étapes d'une recherche d'information sur un exemple

Suite aux réponses données après l'interrogation de la base de règles, deux traitements sont
possibles :
1. soit on recherche les textes associés aux diverses allocations trouvées afin de donner à
l'utilisateur directement l'impact de la modification de la loi sur les autres textes, puis on
recherche les allocations mises en cause, etc, jusqu'à ne plus avoir de modifications. Mais
cela risque d'être long et inutile pour le décideur ;
2. soit on permet à l'utilisateur, une fois la réponse finale fournie, d'effectuer une recherche
simplement en cliquant sur une des allocations concernées, et en effectuant alors la
recherche suivante : "impact de la modification du texte traitant de telle allocation".
Nous avons choisi d'opter pour la seconde solution. Nous fournissons ainsi uniquement la
réponse concernant la requête initiale, mais nous donnons aussi la possibilité au décideur
d'approfondir sa recherche simplement.

6 Conclusion
Il est important (et même indispensable) d'avoir à sa disposition toutes les données utiles à
une bonne prise de décision. Aujourd'hui, les données à consulter sont non seulement
nombreuses mais aussi hétérogènes. Dans cet article, nous avons proposé un système
d'interrogation qui permet d'interroger toutes les bases de données d'une entreprise à partir d'un
système d'accès simple, et grâce à une requête écrite en langage dit naturel. Le système d'accès
s'inspire des médiateurs et des wrappers pour réaliser la liaison avec les bases de données. De
plus, nous utilisons le langage XML pour manipuler les requêtes et les réponses en interne dans
le système d'accès, ainsi que pour interroger les diverses bases de données. Nous avons aussi
proposé un schéma de base de connaissances qui utilise notamment la notion de "schéma pivot".
Ce schéma pivot permet de représenter les schémas des différentes bases de données de façon

13 / 17
uniforme. Il est ensuite possible d'exploiter les connaissances contenues dans les schémas de
bases de données (par exemple les relations entre bases de données).
Un prototype est en cours afin de valider nos choix technologiques et notre modèle. Nous
utiliserons pour cela deux bases de données : une pour des données allocataires, et une autre pour
les textes juridiques. Le principal but du prototype est de vérifier qu'une requête est correctement
découpée en sous-requêtes, grâce à la base de connaissances. Il doit aussi permettre de vérifier le
bon acheminement des sous-requêtes ainsi que la bonne récupération des réponses. L'affichage
des réponses n'est pas notre préoccupation centrale.
Par la suite, la problématique actuelle sera étendue aux règles de systèmes experts. Une
nouvelle étude permettra d'intégrer ce nouveau type de "données" à notre proposition. Un
prototype sera élaboré afin de valider les choix réalisés au cours de l'étude.

14 / 17
Bibliographie

[AHME,1991] R. Ahmed et al, The Pegasus heterogeneous multidatabase system,


IEEE Computer, 24:19-27, 1991

[AKOK,1997] Jacky Akoka, Nicolas Prat, Modélisation logique des données dans les
systèmes multidimensionnels d'aide à la décision : la méthode MAP,
Revue des systèmes de décision, vol.6 - n°2/1997

[CARE,1994] M.J. Carey et al, Towards heterogeneous multimedia information


systems : the Garlic approach, Technical Report RJ 9911, IBM
Almaden Research Center, 1994

[CHAB,1997] B. Chabbat, Modélisation multiparadigme de textes réglementaires,


thèse soutenue le 8 décembre 1997 à l'INSA de Lyon, France

[CHAW,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
IPSJ Conference, pp 7-18, Tokyo, Japan, October 1994

[CHRI,1997] Claude CHRISMENT, Taoufiq DKAKI, Bernard DOUSSET, Josiane


MOTH Extraction et synthèse de connaissances à partir de bases de
données hétérogènes. Ingénierie des Systèmes d'Information. Volume 5 -
n°3/1997, pages 367 à 400

[FLES,1998] Flesca S., Palopoli L., Saccà D., Ursino D., An architecture for
accessing a large number of autonomous, heterogeneous databases,
Networking and Information Systems Journal, Volume 1 – n° 4-5/1998,
pages 495 à 518

[FOUR,1998] Fourel F., Modélisation, indexation et recherche de documents


structurés, Thèse de IMAG, 05 février 1998

[GARC,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

[GUPT,1989] A. Gupta, Integration of Information Systems : Bridging


Heterogeneous Databases, IEEE Press, 1989

[HAMM,1997] J. Hammer, H. Garcia-Molina,, S. Nestorov, R. Yerneni, M. Breuing;


V. Vassalos, Template-Based Wrappers in the TSIMMIS System, In
Proceedings of the Twenty-Sixth SIGMOD International Conference on
Management of Data, Tucson, Arizona, May 1997

15 / 17
[HUA,1998] Gary H. Hua, Steven Kimbrough, On Hypermedia-based
argumentation decision support systems, ELSEVIER Science

[HULL,1996] R.Hull, G.Zhou, A framework for supporting Data Integration Using


the materialised and virtual approaches, in Proceedings of the ACM
SIGMOD International Conference of the Management of Data, pp 481-
492, june 1996

[LEVY,1996] Levy A, Rajaraman A., Ordille J., Querying heterogeneous data


sources using source description, Proceedings of the 22nd Very Large
Data Bases (VLDB) Conference, pp 251-262, 1996

[LI,1998] C. Li, R. Yerneni, V. Vassalos, H. Garcia-Molina, Y. Papakonstantinou,


J. Ullman, M. Valiveti, Capability Based Mediation in TSIMMIS,
Sigmod 98 Demo, Seattle, June 1998

[LITW,1990] W. Litwin, L. Mark, N. Roussopoulos, Interoperability of multiple


autonomous databases, ACM Computing Surveys, 22:267-293, 1990

[MARE,1996] Maret P. Poullet L., Pinon J.-M., Des modèles conceptuels pour
capitaliser la connaissance au sein d'une organisation, Ingénierie des
Systèmes d'Information, Volume 4 – n°4/1996, pages 491 à 540

[MICH,1999] Michard A., XML : langage et applications, Editions Eyrolles, 1999,


code ISBN : 2-212-09052-8

[MI,1996] Décisionnel, Quinze outils OLAP passés à la loupe, Le Monde


Informatique, n°673 du 12 avril 1996, http://www.lmi.fr/673/673p18.html

[PAPA,1995] Y. Papakonstantinou, A. Gupta, H. Garcia-Molina, J. Ullman, A Query


translation scheme for rapid implementation of wrappers,
International Conference on Deductive and Object-Oriented Databases,
1995

[PAPA,1996] Y. Papakonstantinou, S. Abiteboul, H. Garcia-Molina, Object Fusion in


Mediator Systems, VLDB Conference, Bombay, India, September 1996

[PAPA,1999] Y. Papakonstantinou, P. Velikhov, Enhancing Semistructured Data


Mediators with Document Type Definitions, International Conference
on Data Engineering (ICDE99), 1999

[SHET,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, pp183-236, 1990

[SMAD,1995] Smadhi S., Marciano J.-P., Hocine A., Une méthode de découverte de
connaissances dans les bases de données : une approche par les objets

16 / 17
symboliques, Actes du XIIIème congrès d'Inforsid, pages 315 à 327, 30
mai-2 juin 1995, Grenoble, France

[SU,1996] Su S.Y.W. et al, NCL : A Common Language for Achieving Rule-


Based Interoperability Among Heterogeneous Systems, Journal of
Intelligent Information Systems : Integrating Artificial Intelligence and
Database Technologies, vol.6, n°2-3, Kluwer Academic Publishers, pp
171-198, 1996

[THOM,1990] G. Thomas et al., Heterogeneous distributed database systems for


production use, ACM Computing Surveys, 22:237-266, 1990

[WIED,1992] G. Wiederhold, Mediators in the architecture of future information


systems, The IEEE Computer Magazine, March 1992, pp 38 à 49

[WIED,1995] G. Wiederhold, Modeling and system maintenance, Keynote


presentation at the ER-OO Conference, Brisbane Australia, December
1995

[XML,1998] XML, Site du W3C : http://www.w3.org/TR/REC-xml

17 / 17

Vous aimerez peut-être aussi