Vous êtes sur la page 1sur 23

Le projet logiciel E.C.D.

Sagitta :
Un état des lieux
Olivier Raynaud1
Research Report LIMOS/RR-06-05
22 mai 2006

1
raynaud@isima.fr
Abstract

Le projet logiciel E.C.D.Sagitta se présente comme la compilation de modules


logiciels dédiés à l’extraction de connaissances à partir de données. A ce jour
nous disposons d’un module d’extraction (le module ”Extracteur” qui est out-
ils de type E.T.L.), d’un module de navigation dans les règles d’association (le
module ”A.R.F.” pour association rules finder) et d’un module de recherche
de symétries dans les items d’une collections d’enregistrements (le module
”clone miner”). La connaissance de certaines forment de symétrie dans les
données permet de calculer une représentation de ces données sous une forme
moins volumineuse.
Au fil du texte qui suit nous définissons le contexte de réalisation du pro-
jet logiciel. Nous pensons ici en particulier aux motivations et aux objectifs
attendus de cet effort de développement. Pour cela nous rappelons en in-
troduction les grands principes sous jacents au processus E.C.D. Ensuite,
puisque par nature un processus E.C.D. incorpore une technique de fouille,
nous décrivons dans la section 2 la technique du panier de la ménagère.
Nous rappelons à cette occasion que les objets mathématiques sous jacents
à cette technique sont le coeur de metier de notre équipe de recherche. La
troisième section est consacrée à la description de deux approches originales
proposées par notre équipe pour appréhender le problème de l’extraction des
connaissances. Enfin nous décrivons le projet logiciel, dans sa version finale
souhaitée et dans sa version actuelle.
Keywords: Extraction des connaissances, fouille de données, projet logiciel,
théorie des treillis

1
1 Introduction
Les progrès de la technologie informatique dans l’acquisition et le trans-
port de données permettent aux acteurs économiques de disposer à ce jour de
quantités de données souvent gigantesques. Ces progrès ont eu pour conséquence
une transformation profonde de leurs modes de fonctionnement. Certains au-
teurs parlent de révolution des services ([7, 24]).
A titre d’exemple : les entreprises ont stocké et accumulé les données
résultant de leurs activités opérationnelles tout au long des dernières années.
Elles gardaient à l’esprit leur exploitation future. En effet, une connaissance
approfondie des modes de consommation et des profils clients doit permettre
de mieux cerner ses besoins et de lui proposer des services plus adaptés. On
parle alors de services personnalisés. Pourtant une autre analyse pourrait être
faite. La connaissance acquise permet aussi de dégager les grandes tendances
du comportement à la consommation. Cette connaissance assure de proposer
des produits normalisés pour le plus grand nombre. Charge alors aux services
marketing de préparer les consommateurs à cette normalisation.

Fig. 1 – Croissance des capacités du parc informatique. Les capacités de


stockage sont données en milliers de tera octets. Cette figure est extraite de
[8].

La figure 1 montre que partout dans le monde se sont constitués des


gisements considérables d’informations potentielles mais que ces informa-
tions restent néanmoins très difficiles à extraire et à représenter. En effet
les capacités de stockage et de traitement de l’information sont sans com-
mune mesure. Ainsi la réalisation d’un processus efficace d’extraction des

2
connaissances à partir des données (processus E.C.D.) constitue un chal-
lenge incontournable pour la gestion des grandes masses de données.
Les solutions matérielles retenues par les entreprises pour répondre à ce
problème s’appuient sur plusieurs principes.
En 1995 Smith ([22]) propose une stratification de l’information en fonc-
tion de la nature de son utilisation : opérationnelle, tactique ou stratégique.
Les entreprises distinguent ainsi aujourd’hui les besoins opérationnels du
quotidien des besoins décisionnels pour le moyen et long terme. Le second
principe est alors intuitif, il consiste à séparer physiquement les données
d’ordre opérationnel des données informationnelles qui seront archivées et
conservée dans des entrepôts (data wharehouse). R. Godin dans [11] ca-
ractérise ces dernières ; Elles sont par exemple orientées sujet (on retrouve
ici le découpage en domaines ou métiers, cher à la modélisation d’un S.I.),
intégrée (les données sont formatées en fonction de leur provenance), et pour
finir temporelles (c’est à dire de nature historique). Cette séparation physique
des données permet de mettre en place des applications logicielles adaptées
aux différents besoins ou à la nature des données. Ainsi pour le traitement
opérationnel les entreprises se munissent d’outils assurant les transactions
en ligne (outils OLTP, ERP). Pour les données orientées décisionnel elles
s’équipent d’outils d’analyse (par exemple les outils OLAP pour l’analyse
multidimensionnelle) ou de prospection (progiciel de fouille de données comme
SAS Enterprise Miner, Intelligent Miner, Alice, Clémentine ...).

Fig. 2 – Architecture de stockage et de traitement des données. Cette figure


est extraite de [11].

En représententant l’architecture la plus répendue au sein des grandes

3
entreprises, la figure 2 résume clairement ces principes.
L’objet de notre étude concerne la mise en place d’un dispositif de pros-
pection. Pour cela nous devons définir clairement ce processus de prospection
ou processus E.C.D.
Frawley et Piatesky-Shapiro définissent précisément le concept de fouille.
Il s’agit ici de l’extraction d’informations originales, auparavant inconnues et
potentiellement utiles, à partir de données. Citons aussi la définition proposée
par M.J.A. Berry : l’exploration et l’analyse par des moyens automatiques
(ou semi automatiques) d’un large volume de données afin de découvrir des
tendances ou des règles.
Dans la suite de ce texte nous ferons la distinction entre techniques de
fouille de données (”data-mining”), qui sont multiples (statistiques, réseaux
de neurones, inférence inductive...) et le processus logiciel (processus E.C.D.)
assez complexe qui permet de répondre aux définitions de Frawley et Berry
(La figure 3 illustre un exemple de processus). Ce processus commence par le
nettoyage et la récupération des données sous un format adapté aux étapes
suivantes. L’ensemble des outils logiciels assurant ces fonctionnalités sont ap-
pelés outils E.T.L. (pour extraction, transformation et loading). Le processus
se poursuit alors par l’étape de fouille proprement dite. Son déroulement
dépend très largement de la technique de fouille employée. L’application
E.C.D. doit ensuite permettre la visualisation des résultats sous forme de
graphiques ou de tableaux de bord. Ces fonctionnalités sont appelées outils
de visualisation et outils de reporting. Pour les auteurs de [7] le processus
E.C.D. doit se poursuivre par la réalisation d’un bilan d’efficacité (plusieurs
méthodes de comparaison sont proposées). Les résultats de ce bilan sont alors
compilés dans la masse d’informations dont dispose l’entreprise pour le do-
maine concerné (les auteurs justifient ainsi la notion de ”cercle vertueux” de
l’extraction des connaissances à partir des données).
Nous avons évoqué jusqu’à présent les notions de données, d’information
et de connaissance sans les définir. Pour combler cette lacune nous nous
appuyerons sur les travaux de Devlin ([4]). Il définit les données comme un
ensemble de signes dont la manipulation est régie par une syntaxe. Il décrit
alors l’information comme un ensemble composé de données et du sens qu’on
leur accorde. La question de savoir si la présence de l’homme est indipensable
pour dégager ce sens est alors posée. En informatique on parle aussi parfois
d’information pour évoquer les règles ou le schéma comportemental d’un
ensemble de données. Il s’agit bien souvent d’un abus de langage et nous
utiliserons le terme de meta-données (ce qu’elles sont) pour les caractériser.
Enfin, pour Devlin, la connaissance rapproche l’information et la capacité
d’agir à partir de cette information.

4
Fig. 3 – Un processus E.C.D. qui distingue bien l’action de fouille (”data-
mining”) de l’ensemble du processus. Cette figure est extraite de [23].

La figure 4 résume ces définitions.

Fig. 4 – Définitions emboitées des notions de données, d’information et de


connaissance

Nous avons retenu ces définitions pour deux raisons en particulier. La


première parce qu’elles rejoignent la notion de cercle vertueux qui impose
une action et une mesure de son efficacité en fin de cycle E.C.D. La seconde
parce qu’elles positionnent l’homme avec sa force de proposition et sa capacité
d’interprétation, au coeur du processus. Ainsi une technique de fouille de
données n’a de sens que si elle répond à une problématique posée par un
groupe d’individus et est compatible avec leurs méthodes de travail. La fouille
de données doit s’adapter aux besoins et non pas l’inverse.
Pour résumer cette introduction : nous avons justifié les besoins logiciels
en comparant les croissances des puissances de traitement et des capacités
de stockage des outils informatiques. Nous avons ensuite décrit l’architecture

5
de stockage et de traitement retenue par les entreprises pour répondre aux
besoins opérationnels d’un coté et décisionnels de l’autre. Enfin nous avons
défini l’extraction des connaissances en terme de processus logiciel (appelé
processus E.C.D.) et avons insisté pour positionner l’homme au coeur de ce
processus.
Ce texte se poursuit par quatre sections. La premiere est consacrée à
une technique particulière de fouille (l’étude du panier de la ménagère) et à
l’outil mathématique majeur utilisé par cette technique (l’analyse formelle
de concepts). Ensuite la deuxième section décrit deux outils innovants de
fouille de données (la navigation et la recherche de clones) proposées par
notre équipe de recherche. Nous évoquerons dans la section suivante les be-
soins de notre équipe pour assurer les validation théorique et pratique de ses
travaux. Enfin, la dernière porte sur une description synthétique du projet
”E.C.D.Sagitta”.

2 Techniques de fouille de données


En introduction de ce texte nous avons parlé du processus E.C.D. sans
évoquer les différentes techniques de fouille proprement dites. Pour compléter
notre étude, nous consacrons donc cette section à une technique particulière
dite de l’étude du panier de la ménagère (correspondant à la recherche des
règles d’association dans une base de données de transactions).

2.1 La recherche des règles d’association


Les magasins de grande distribution stockent dans des tables les achats
effectués par leurs clients. Une table se présente alors comme une liste de
transactions, ou de paniers. Et chaque transaction est décrite par l’ensemble
des items (les produits achetés) sélectionnés par le client.
La recherche des règles d’association a été introduite à l’origine par Agra-
wal et al dans [1]. Une règle d’association est une expression de la forme
X → Y où X (l’antécédent) et Y (le conséquent) sont des ensembles d’items.
Le sens d’une règle est intuitif : si un panier contient les items de X alors il
contient probablement les items de Y .
Pour Devlin la connaissance se compose de l’information et de la capacité
d’agir à partir de cette information. Cette idée d’associer l’information et
l’action est soutenue par M.J.A. Berry ([7]) : ”la fouille de données prend en
entrée des données et des opportunités commerciales et produit des résultats

6
concrets pour générer des actions”. Ainsi Agrawal et al dans [1] listent un en-
semble de questions auxquelles pourra répondre la recherche de règles d’asso-
ciation et surtout le type d’actions commerciales qu’elles pourront entrainer.

Extrait modifié de [1] :


– Trouver les règles avec ”boisson gazeuse” comme conséquent ; (Com-
ment mieux vendre la ”boisson gazeuse” ? )
– Trouver les règles avec ”biscuit” comme antécédent ; (Sur quels produits
aura un impact l’arrêt des vente de ”biscuits” ? )
– Trouver les règles avec ”saucisse” comme antécédent et ”moutarde”
comme conséquent ; (Quels produits accompagnent l’achat de ”saucisses”
lorsque celui-ci s’agrémente de ”moutarde)
– Trouver les règles concernant des produits provenant de rayonnages
distincts ; (Exsite-t-il des liens de cause à effet entre les ventes et les
rangements dans les rayonnages ? )
– Trouver les k ”meilleures règles” contenant ”soda” comme conséquent ;
Ce qu’il faut retenir de cette liste : tout d’abord les actions commerciales
évoquées s’expriment toujours sous la forme de questions, les informations
recueillies par le processus E.C.D. fournira donc des éléments supplémentaires
pour y répondre mais ne décrit pas les actions à mener elles mêmes ; ensuite
la dernière question exprime l’existence de critères qualitatifs d’une règle.
Bien que de nombreux critères aient été défini dans [13], nous ne retiendrons
dans le cadre de cette étude que le support d’une règle (la proportion des
enregistrements de la base concernés par la règle) qui reflète sa pertinence, et
la confiance d’une règle (la proportion des enregistrements qui la respecte)
qui indique sa justesse.
Nous pouvons résumer la problèmatique soulevée précédemment comme
suit :

Problème 1 (La recherche des règles d’association)


Entrée : une relation binaire (extraite de la table à traiter) ;
Sortie : un ensemble de règles d’association respectant des contraintes (les
contraintes fixent le contenu des règles, leur support et leur confiance) ;

Précédemment nous avons défini une règle d’association comme une ex-
pression de la forme X → Y où X et Y sont des ensembles d’items. Dans
[20, 25] les auteurs ramènent le problème de la recherche de telles règles à
celui de la recherche des concepts de la relation binaire servant d’entrée au
problème 1 (autrement dit la table de transactions). Un concept peut être
vu comme un panier type. C’est à dire qu’il n’existe pas forcement, dans la

7
table, des transactions correspondant exactement à ce panier, mais que ce
panier représente un ensemble de transactions en rassemblant ce qui leur est
commun.

2.2 Fondements mathématiques


La notion de concept comme représentation de la connaissance provient
de la modélisation du monde réel supposé être constitué d’objets ou d’in-
dividus disposant de propriétés ou d’attributs. La description d’un concept
résume les propriétés partagées par un ensemble d’objets. La structure qui
regroupe et décrit l’ensemble des concepts issus d’une base de données est
connue sous le nom de treillis de Galois de la relation binaire objet-propriété.
Cette correspondance de Galois a été proposée à la fin des années 60 ([3]) et
reste aujourd’hui l’outil majeur dans l’étude des données constituées d’ob-
jets décrits par des propriétés ([21]). Le spectre des applications est large. Il
couvre la classification conceptuelle, l’analyse formelle de concepts (utilisée
pour la recherche des règles d’association), les bases de données relationnelles
et objets ou la théorie des implications ([5, 6]).
D’une façon générale le nombre de concepts d’une relation binaire croit
de façon exponentielle avec la taille de cette relation. Notons que des auteurs
ont montré que ce n’était pas toujours le cas d’un point de vue pratique
([25]). Malgrès tout, tout effort visant à reduire la taille de cette relation
assure une meilleure efficacité des algorithmes de calcul des concepts.
Notre équipe de recherche s’est spécialisée depuis longtemps dans l’étude
des propriétés des ensembles ordonnés et des treillis. Ainsi, notre travail
consiste souvent à déterminer, pour une strucure discrête donnée et plus
particulièrement pour un treillis, une représentation simple et ayant une al-
gorithmique efficace (reconstruction, génénration, test de comparabilité...).
A ce jour, notre vision est clairevoyante dans les domaines de l’algorithmique
combinatoire, de l’algorithmique de génération des treillis, mais auusi dans
les domaines de la théorie et de la représentation des treillis et du codage des
ordres partiels.
Néammoins, dans le contexte d’une recherche internationale compétitive
et exigeante, une diffusion large de nos résultats est dépendante d’une vérification
expérimentale de qualité.

8
2.3 Besoins logiciels dans un cadre de recherche scien-
tifique
Notre intuition est que cette validation doit suivre deux axes (cf. figure
5) :
1. la programmation d’applications legères permettant la génération, la
gestion, la visualisation des objets étudiés, mais aussi la vérification de
leurs propriétés ; Nous parlerons alors de validation théorique.
2. l’adéquation de l’utilisation de ces objets dans le cadre de l’analyse des
bases de données ou de la fouille de données. Nous parlerons ici de
validation pratique.

Fig. 5 – Le rôle d’une application dans un schéma de validation

2.3.1 Validation théorique


Nous l’avons évoqué, les travaux de notre équipe porte sur la génération, la
reconnaissance et la définition d’objets combinatoires complexes issus d’une
relation binaire. L’algorithmique associée porte sur des objets basiques (les
inf-irréductibles ou les sup-irréductibles) du treillis de Galois de la relation.
Pour implémenter cette algorithmique nous devons disposer d’une boite à
outils (ou collection de fonctions) qui manipulent ces objets basiques. Nous
pourrons alors appliquer ces algorithmes à des ensembles de benchmarks
reconnus et vérifier expérimentalement la justesse des résultats. Dans un
second temps nous pourrons réaliser des statistiques ou des comparaisons
avec d’autres méthodes.
La figure 6 résume ce processus et mentionne plus précisément la nature
des objets combinatoires étudiés.
Pour mettre en place un tel processus nous devons respecter un certain
nombre de recommandations. Tout d’abord définir un format de stockage

9
Fig. 6 – Protocole de validation théorique

d’une relation et donc disposer d’une application qui transforme les fichiers
benchmarks dans ce format (cf. figure 7). Ensuite, nous devons mettre à dis-
position un environnement de développement rapide et pour cela documenter
très précisément la collection de fonctions disponibles. Enfin, pour préparer
au mieux nos solutions algorithmiques à un futur passage à l’échelle (tout
relatif), les fonctions de notre collection devront picorer dans les fichiers
formatés et ne surtout pas les charger en mémoire.

Fig. 7 – Schéma de discrétisation de benchmarks

2.3.2 Validation pratique


La validation dite pratique consiste à mesurer l’adéquation des méthodes
innovantes que nous proposons (cf. section 3) au processus E.C.D. Comme
nous l’avons précisé en introduction, un processus E.C.D. doit positionner
l’analyste au coeur de son déroulement. En ce sens l’utilisation de benchmarks
pour mesurer l’efficacité de nos méthodes n’est pas toujours adaptée. Notre
intention est donc de proposer à l’analyste un ensemble d’outils, déjà connus
et/ou innovants, qui lui permettent de réaliser le processus sur ses données
propres. Enfin la proximité de l’analyste nous permettra de répondre à une
autre exigence mentionnée en introduction : une technique de fouille doit
répondre à un type de question précis. Avec l’analyste, nous serons à même
de définir clairement ces questions.
Pour résumer nos besoins, nous devons disposer d’une application qui
assure la récupération de benchmarks, leur discrétisation et leur formatage

10
Fig. 8 – Schéma de validation pratique. Les outils innovants mentionnés font
l’objet d’une description complète dans la section 3 de ce document.

(format XML). Nous devons disposer d’une bibliothèque de fonctions (large-


ment documentée) qui permette la gestion d’une relation (sous format XML)
et la génération de ses objets basiques (inf. et sup-irréductibles). Du coté ana-
lyste nous devons disposer d’une application qui assure les premières tâches
du processus E.C.D. (nettoyage, discrétisation, affinage, formatage) et l’accès
à des techniques innovantes de fouille. Nous devrons aussi assurer la confi-
dentialité de ses données.
Dans cette section nous avons décrit une technique de fouille (l’étude
du panier de la ménagère) et montré que cette technique repose sur la
problèmatique de la génération du treillis des concepts issus d’une relation
binaire. Nous avons rappelé à cette occasion que cette problématique consti-
tue le coeur de métier de notre équipe de recherche. Nous avons finalement
évoqué la nécessité de disposer d’outils logiciels pour assurer les validations
théorique et pratique de nos travaux.
Plusieurs fois au cours des pages précédentes des outils originaux par-
ticipants au processus E.C.D. ont été mentionnés. La section suivante est
consacrée à une description plus détaillée de ces outils.

3 Approche proposée par notre équipe


Au cours des dernières années notre équipe a orienté ses efforts dans
l’étude des stuctures discrètes ordonnées et des systèmes implicationnels. Ci-
tons par exemple l’énumération des éléments du treillis de Galois ([9, 19]),
la reconnaissance de règles appartenant à des bases d’implications données
([16]), la recherche interactive des règles d’association ([16, 17]) ou la re-
cherche de similitudes dans le comportement des attributs d’une table ([10,
15]). Notre attention se porte donc sur l’étude des structures mais aussi sur
les algorithmes sous jacents. Peut-on répondre à des requêtes concernant les

11
objets étudiés en temps raisonnable (polynomial) ? Ces différents travaux
sont dans la droite ligne des résultats obtenus par les membres de l’équipe
en des temps plus anciens ([14, 18]).
Ces travaux nous permettent aujourd’hui de proposer deux outils inno-
vants de fouille de données. Le premier, appelé navigation, s’appuie sur la
technique de la recherche des règles d’association. Le second, appelé recherche
de clones, nous permet de réduire le volume des données à traiter, de vali-
der des choix de discrétisation ou de réaliser des tâches de classification. Les
techniques de classification étant un des pilliers essentiels de la fouille de
données.

3.1 La navigation
3.1.1 Les solutions standards
La plupart des méthodes proposées pour résoudre le problème 1 consistent
en une démarche itérative composée :
1. d’une étape de génération (potentiellement exponentielle) d’un ensemble
de règles ;
2. d’une étape de parcours de cet ensemble pour trouver la/les règle/s
intéressante/s ;
3. d’une étape d’analyse et d’affinage qui relance le processus ;
Ces méthodes permettent un parcours des règles une fois que l’ensemble
des règles a été généré. La phase d’affinage permet d’appliquer des contraintes.
On peut restreindre l’espace de recherche en augmentant les seuils de sup-
port et de confiance ([2], [12]) ou en spécifiant que les règles recherchées
contiennent tel item. La seule interaction avec l’utilisateur consiste en l’évaluation
des contraintes. Le temps de calcul nécessaire à la réalisation de l’étape de
génération est un obstacle crucial à l’interactivité entre l’utilisateur et le pro-
giciel alors même que le processus E.C.D. est hautement centré sur l’humain,
sa connaissance du domaine, son intuition et sa capacité d’interprétation.
Pour répondre à cet inconvénient majeur nous proposons une méthode
originale de navigation ”à priori” dans l’espace des règles.

3.1.2 Découverte interactive des règles d’association


Notre méthode de navigation est un processus interactif qui permet de
générer les règles à la demande. L’analyste se voit proposer un ensemble res-
treint (polynomial) de règles dites générales dont les parties droites corres-
pondent à chaque item. Il a ensuite la possibilité de demander une réduction

12
de la partie gauche d’une règle afin d’affiner ce qui est vraiment nécessaire
pour produire la partie droite. A chaque étape du processus le nombre de
calculs est restreint, ceci assure de garder le contact avec l’utilisateur. Au fur
et à mesure on voit donc se construire un arbre de règles dont les branches
peuvent être élaguées ou développées. Bien que cet arbre soit composé de
règles exactes (de confiance 1), l’utilisateur pourra, pour une règle donnée,
extraire des règles de qualité dégradée (pour le support et la confiance). En-
fin l’outil est capable de semi-automatiser la réduction d’une règle générale
à la demande de l’utilisateur. L’outil permettra aussi de vérifier si la règle
choisie appartient à une base spécifique (base réduite à gauche, etc). Les
résultats mathématiques sous-jacents à ces fonctionnalités ont fait l’objet de
publications récentes [17, 16].

3.2 La recherche de Clones


Dans [15] les auteurs définissent, de manière formelle, une relation d’équivalence
sur l’ensemble des items décrivant une relation binaire. Ces classes sont ap-
pelés classes d’items clones. Deux items sont clones si leur présence est inter-
changeable dans l’ensemble des concepts de la relation. Ainsi l’ensemble des
paniers types où l’un des items clones apparait peut être déduit de l’ensemble
des paniers types où le second item est présent. Et ceci en un nombre linéaire
de calculs. En représentant chaque classe d’items clones par un seul item on
réduit le contexte et ainsi l’espace de recherche des règles.

3.2.1 Sémantique associée aux clones


Comment interpréter le fait que deux items, qui permettent de décrire un
ensemble de transactions, sont interchageables ? Aujourd’hui notre réponse
n’est que partielle. Afin de faciliter la discussion nous proposons quatre
exemples :
1. Un grand nombre de paniers types contiennent les mêmes produits à
ceci près que certains d’entre eux inclus des chaises de jardin alors que
les autres incorporent un banc de jardin ;
2. Le comportement accidentogène des conducteurs ayant moins de 10 ans
de pratique de la conduite est le même pour les tranches d’ages de 18
à 23 ans et de 23 à 27 ans.
3. La répartition du pouvoir d’achat sur les biens de comsommation ou
de services est le même pour les seniors que pour les juniors.

13
4. Pour chaque panier type contenant un article vestimentaire de telle
marque, il existe le même panier type, sans cet article, mais avec un
article de quincaillerie.
Les quatre assertions précédentes sont supposées être des interprétations
possibles faites à partir d’un ensemble de règles. Notons que ces règles ne
sont pas exclusivement issues de bases de transactions. Nous avons élargi le
champs d’étude au domaine de l’assurance et au domaine socio-économique.
Pour ces domaines on ne parle plus d’items et de transactions mais d’attributs
et d’enregistrements. Pour être adaptées à la recherche des règles d’associa-
tion les données doivent alors subir un traitement appelé discrétisation. Une
discrétisation consiste à découper en tranches les attributs dit continus qui
décrivent les enregistrements de la table. Autrement dit la discrétisation de
l’attribut âge consiste par exemple à regrouper dans une même classe d’âge
tous les personnes de 18 à 23 ans et toutes les personnes de 23 à 27 ans.
Les attributs clones dans les 4 cas étudiés sont :chaises/banc de jardin,
tranches [18,23]/[23,27], tranche junior/senior, marque vestimentaire/quincaillerie.
Notre intuition est que la sémantique est sensiblement différente pour chacun
de ces cas.
Le cas deux est clairement relatif à une discrétisation non adaptée, en
effet il aurait fallut ne pas découper en deux la tranche [18-27] puisque l’âge
n’a aucune influence sur l’ensemble des règles. Le cas trois est le même si ce
n’est que les intervalles (junior, sénior) ne sont pas contigüs. Le cas 1 reflète
le problème de la hiérarchie dans les niveaux de description des articles du
magasin. Si une telle classe de clones existe c’est que le niveau de description
n’était pas ou peu adapté. Enfin, le cas 4, très mystérieux, résiste à toute
analyse à ce jour.
En plus de permettre une réduction d’un contexte, les clones se présentent
donc comme un moyen de vérification ou un critère d’évaluation de la qua-
lité d’une procédure de discrétisation, de classification ou de description
hiérarchique d’un ensemble d’objets.

3.2.2 Les items clones dans un processus E.C.D.


Notre intention est d’utiliser la technique des clones pour les deux problémes
suivants :
Réduction des volumes de données à traiter Comme nous l’avons
mentionné, en représentant chaque classe d’items clones par un seul
item on réduit le contexte et ainsi l’espace de recherche des règles.
L’utilisation de cette technique peut s’inscrire dans une phase de pré-
processing, succédant à la phase de discrétisation, visant à réduire la

14
taille d’un contexte avant l’application d’une technique de fouille. Une
phase de post-processing est alors nécessaire pour reconstruire les règles
à partir de la définition des classes de clones. Ceci afin de préparer les
données à la phase de visualisation. Il est à noter que la reconstruction
peut être effectuée à la demande.
Outil d’évaluation qualitative d’une phase de discrétisation Dans
une application logicielle dédiée à la discrétisation nous proposerons une
fonctionnalité d’évaluation d’une discrétisation donnée. En déterminant
les classes d’items clones nous seront à même de repérer des cas simi-
laires aux cas 2 et 3. C’est à dire des cas où les classes d’items clones
sont issus de la discrétisation d’un même item. Nous proposerons alors
le regroupement de tels ou tels intervalles de valeurs.

3.2.3 Difficultés algorithmiques


L’expérience montrera sûrement que le nombre de clones d’une relation
est limité. Notre recherche ne doit donc pas se restreindre aux classes exactes
de clones. Nous avons proposé une première notion de distance entre attributs
(si cette distance est nulle les attributs sont clones) malheureusement sont
évaluation reste délicate puisque elle nécessite de devoir compter un ensemble
de règles. Ce qui n’est pas le cas pour déterminer les classes exactes.
Le calcul d’une approximation de cette distance a fait l’objet d’un pro-
jet étudiant et d’une implémentation. Le logiciel est disponible à l’adresse
suivante :
http ://www.isima.fr/raynaud/Software/Clone/download.htm.

3.2.4 Conclusion
Nous avons présenté dans cette section deux outils innovants de fouille
de données que sont la navigation et la recherche de clones. La navigation
est originale car elle se présente comme un outil interactif de recherche de
règles alors que cette technique de fouille est classée comme non dirigée dans
la littérature. La recherche de clones nous permet quand à elle de réduire le
volume de la relation et ainsi de rendre plus efficace les traitements de fouille,
quels qu’ils soient.
Enfin, ces deux outils s’appliquent sur des relations binaires et imposent
donc un traitement de discrétisation des données étudiées. Nous pensons que
la qualité des résultats produits par ces outils est très dépendante de cette
phase de discrétisation. Nous avons montré que la recherche de clones peut
être adaptée à l’évaluation de la qualité d’une discrétisation.

15
4 Le projet E.C.D.Sagitta
L’objectif de notre projet logiciel est le développement d’un ensemble
d’applications (ou de modules) appelé ”E.C.D.Sagitta” répondant aux be-
soins exprimés.
Cette section est composée de deux sous-sections. Dans un premier temps
nous donnons l’architecture modulaire retenue par notre équipe. Le développement
de ces modules et de leurs fonctionnalités sont donc des objectifs à atteindre.
Dans un second temps nous décrivons les développements déja effectués.

4.1 Une architecture modulaire adaptée


1. Le module Extracteur : l’étude des besoins a montré la nécessité
d’une application (outils E.T.L.) assurant le nettoyage, la discrétisation
(ou le calcul des agrées) et le formatage X.M.L. des données. Ce mo-
dule doit s’installer sur le poste utilisateur et donner accès aux bases
de données locales hébergant les données brutes ou les benchmarks.
Cet outil installé localement assurera la confidentialité des données.
Ce module sera utilisé indifféremment par les analystes qui préparent
leurs données ou par les chercheurs qui formatent les benchmarks en
vue de valider leurs travaux. Ces derniers auront le choix d’extraire des
benchmarks une relation discrétisée pour évaluer des outils de fouille,
ou d’extraire les agrées pour tester des outils d’analyse de base de
données. Ce module répond aux besoins de la figure 7.
2. Le centre de calcul : il réalise les calculs lourds à partir des fichiers
formatés fournis en entrée. Ce centre à disposition des programmeurs
se présentera sous la forme d’une liste précise de fonctions qu’il sait
calculer (la boite à outils). Il sera clairement documenté.
3. Le serveur : le dernier module est constitué du serveur qui assure
l’interface entre les utilisateurs et le centre de calcul. Il donne accès
aux outils innovants de fouille ou d’analyse de données. Il assure aussi
la gestion d’un espace disque permettant le stockage des fichiers nor-
malisés, et d’enregistrer les travaux en cours. Les utilisateurs inscrits
ont accès à ces services par l’intermédiaire d’un client léger (navigateur
Web).

La figure 9 résume l’architecture matérielle et logicielle retenue.

16
Fig. 9 – Architecture modulaire

4.2 Les développements déjà effectués


A ce jour notre effort de développement s’est porté :

– sur le module d’extraction indispensable à la gestion des benchmarks


et aux formatage X.M.L. des données ;
– sur l’architecture du serveur (gestion des services d’espace disque
aux utilisateurs) et la mise en place du premier service de technique
innovante de fouille (la navigation interactive).
– sur quelques fonctions du centre de calcul programmées en C++
(avec utilisation des S.T.L.) ;

4.2.1 Le module ”Extracteur”


Le module ”Extracteur” assure tout d’abord le branchement sur des bases
de données Oracle et MySql. Ensuite il permet d’exécuter une discrétisation
des données sélectionnées suivant différentes méthodes (adaptées à divers
contextes). Enfin ”Extracteur” exporte les données obtenues sous un format
X.M.L. qui servira de format d’entrée pour les modules suivants. Puisque
”Extracteur” se branche directement sur une base de données, la discrétisation
peut se faire sur une vue/table dont le contenu a déjà fait l’objet d’une
vérification ou d’une sélection des lignes ou des colonnes. A terme ”Extrac-
teur” proposera tout de même un service de nettoyage.
A noter que si les données ne sont pas disponibles dans une base (comme
les benchmarks du Web, ou dans le cas de données dispersées) nous devons
passer par la réalisation d’un script SQL de création d’une table qui sera
hébergée sous les S.G.B.D. Oracle ou MySql (cf. figure 10).

Cette phase d’extraction et de transformation est primordiale pour assu-


rer la qualité de la suite du processus. Notre objectif n’est pas d’implémenter
toutes les techniques de discrétisation proposées par les progiciels (SAS, Alice
...), mais de pouvoir tester des méthodes originales ou des méthodes pro-

17
Fig. 10 – Processus d’extraction des données

posées, imaginées par les analystes utilisateurs. Pour cela l’originalité de


ce module tient dans la possibilité d’insérer à ”Extracteur” des ”plug-in”
implémentant de nouvelles méthodes. Un ”plug-in” se présentera sous la
forme d’une classe java (des classes exemples seront à disposition pour la
consultation). L’analyste se confrontera alors uniquement aux aspects algo-
rithmiques de ses besoins et non pas sur les aspects techniques ou d’implémentation.

La figure 11 est une capture d’écran du prototype opérationnel disponible


pour téléchargement à l’adresse : w3.isima.fr/raynaud/Software/Extracteur/extracteur.htm

Fig. 11 – Capture d’écran de ”Extracteur” (d’autres captures d’écran sont


disponibles à l’adresse w3.isima.fr/raynaud/Software/Extracteur)

4.2.2 Le serveur
Pour répondre aux besoins exprimés dans la section précédente nous avons
retenu un serveur TomCat produisant des pages HTML par l’intérmédiaire de

18
Servlets (issue de pages JSP). Le serveur a pour rôle de répondre aux requêtes
exprimées par les utilisateurs grace à un client leger de type navigateur.
Le serveur TomCat est physiquement hébergé par notre équipe et assure
la cohésion entre différents modules :
– un serveur de base de données pour la gestion des droits et des comptes
utilisateurs ;
– un espace disque personnalisé qui sert au stockage de fichiers de travail
et des sources de données sous un format X.M.L. ;
– un centre de calcul (serveur XML-RPC) qui assure l’exécution des al-
gorithmes sur les données stockées dans les espaces disque.
Le langage et l’environnement de développement choisi est donc Java
(J2EE). La figure 12 résume l’architecture retenue pour le serveur.

Fig. 12 – Architecture du serveur

4.2.3 Le centre de calcul


Le centre de calcul se présente sous la forme d’une interface de fonc-
tions (ou API). Ces fonctions ont été développées en C++ (avec utilisation
de S.T.L.) et compilées. Grâce au logiciel Swig nous produisons à partir
du fichier compilé un programme Python appelable par le serveur XML-
RPC. Actuellement l’interface est composée de 3 fonctions nécessaires pour
l’exécution de la recherche interactive de règles d’association.

5 Conclusion
Adam Smith, dans la société des nations, décrit tous les avantages inhérents
à une économie de marché. Citons le dynamisme économique, les libertés
d’entreprendre, la croissance des richesses ou l’autorégulation des prix as-
surée par la loi de l’offre et de la demande. Il précise néammoins le contexte

19
idéal à cette économie : un contexte à information compléte dans lequel cha-
cun est libre de choisir ou d’agir.
Disposer de l’information est donc un atout crucial pour consommer, ache-
ter ou investir intelligemment sur le marché. Pour cette raison les problèmes
liés à la gestion des grandes masses de données, à la recherche d’informa-
tion ou de connaissances dans les entrepôts de données sont des problèmes
sensibles. Les acteurs économiques veulent disposer d’une information fiable
pour axer leurs stratégies sur le moyen et long terme. Nous pouvons peut
être trouver ici une explication du boum survenu ces dernières années dans
les domaines de l’informatique liés à ces problèmatiques.

L’économie n’est pas le seul domaine pour lequel l’information est sen-
sible. L’état, pour rationaliser son administration ou assurer la sécurité (dans
tous ces aspects opérationnels) est insatiable en informations. Rationaliser
consiste souvent à créer des gains de productivité par l’automatisation d’un
grand nombre de tâches. L’outil informatique est l’outil idéal pour mettre
en place cette automatisation. Nous pensons néammoins que la fouille de
données à ceci de particulier qu’elle assiste des prises de décision parfois
délicates et lourdes de conséquences. Pour cette raison le décideur doit pou-
voir comprendre et retracer le cheminement de l’analyse automatique de l’ou-
til informatique et savoir limiter sa portée.

Enfin, la soif de savoir qui caractèrise l’homme n’est pas toujours justifiée
par un but précis (compétitivité, sécurité ...). Elle correspond aussi souvent à
une démarche inconsciente qui nous pousse à comprendre l’univers qui nous
entoure. La fouille ou l’analyse de données de masse sont devenus des outils
indispensables aux métiers de la recherche. Par exemple ils ont permis aux
biologistes de mettre en place une nouvelle classification phylogénétique du
vivant.
Au XVIIIième siècle Voltaire évoque cette soif de comprendre, il raconte
aussi l’orgueil des hommes qui raisonnent. Cet orgueil qui persuade les indi-
vidus de la démesure de leur destin. Pour répondre aux hommes, l’écrivain
les confronte à Micromégas, un géant voyageur venu sur Terre par hasard
dont le savoir est immense. En les quittant il leur laissera quelques bribes
de ce savoir. Des pages blanches. Afin de tenir compte de cet avertissement
nous avons retenu le nom de ”E.C.D.Sagitta” pour notre projet. En effet ”Sa-
gitta”, la flêche, est synonyme d’acuité et de rapidité, ce que l’on souhaite à
nos algorithmes. Ce mot est aussi la racine du mot ”sagesse”, celle que l’on
doit conserver dans le cadre d’une quête difficile.

20
Références
[1] R. Agrawal, T. Imielinski, and A. Swami. Mining association rules bet-
ween sets of items in large databases. In ACM SIGMOD’93. Washington,
USA, 1993.
[2] R. Agrawal and R. Srikant. Fast algorithm for mining association rules.
In 20th International Conference of Very Large DataBasis (VLDB),
pages 487–499. Santiago, Chile, September, 1994.
[3] M. Barbut and B. Monjardet. Ordre et classification. Hachette, 1970.
[4] K. Devlin. Turning Information into Knowledge. InfoSens, 1997.
[5] V. Duquenne. Latticial structure in data analysis. Theoritical Computer
Science, 217 :407–436, 1999.
[6] V. Duquenne and J-L. Guigues. Famille minimale d’implications in-
formatives résultant d’un tableau de données binaires. Mathématiques
Sciences Humaines, 24, 1986.
[7] M.J.A. Berry et G. Linoff. Data-Mining, Techniques appliquées au mar-
keting, à ?la vente et aux services clients. InterEditions, 1997.
[8] R. Lefebure et G. Venturi. Data-Mining, Gestion de la relation client,
Personnalisation de site Web. Eyrolles, seconde edition, 2001.
[9] A. Gely. A generic algorithm for generating closed sets of a binary
relation. In ICFCA’05, 2005.
[10] A. Gely, R. Medina, L. Nourine, and Y. Renaud. Uncovering and redu-
cing hidden combinatorics in guigues-duquenne covers. In ICFCA’05,
2005.
[11] R. Godin. Les entrepôts de données et l’analyse de données. Version
béta edition, 2002.
[12] J. Hipp, U. Guentzer, and G. Nakhaeizadeh. Algorithms for association
rules mining - a general survey and comparison. SIGKDD Exploration,
2(1) :58–64, 2000.
[13] M. Halkidi M. Vazirgiannis and D. Gunopulos. Uncertainty Handling
and Quality Assessment in Data-Mining. Springer, 2003.
[14] R. Medina and L. Nourine. Algorithme efficace de génération des idéaux
d’un ensemble ordonné.
[15] R. Medina and L. Nourine. Clone items : a pre-processing information
for knowledge discovery. submitted.
[16] R. Medina, L. Nourine, and O. Raynaud. Interactive association rules
discovery. In 4th International Conference, ICFCA, pages 177–190, 2006.

21
[17] R. Medina, C. Noyer, and O. Raynaud. Efficient algorithms for clone
items detection. In CLA’05, pages 70–81, 2005.
[18] L. Nourine and O. Raynaud. A fast algorithm for building lattices.
Information Processing Letters, volume 71 :199–204, 1999.
[19] L. Nourine and O. Raynaud. A fast incremental algorithm for building
lattices. Journal of Experimental and Theoritical Artificial Intelligence,
14 :217–227, 2002.
[20] N. Pasquier, Y. Bastide, R. Taouil, and L. Lakhal. Efficient mining of
association rules using closed itemset lattices. Information Systems, 24,
1 :P. 25–46, 1999.
[21] R.Wille. Why can concept lattices support knowledge discovery in da-
tabase. Journal of experimental and theoritical artificial intelligence,
volume 14 :81–92, 2002.
[22] D. Smith. System engineering for healthcare professionals. Cardiff ins-
titute of higher education, 1995.
[23] G. Piatesky-Shapiro U. Fayyade and P. Smyth. From data-mining to
knowledge discovery in data base. AAAI97, 1997.
[24] I. Watson. Applying case-based reasonning : Techniques for Enterprise
Systems. Morgan Kaufmann, 1997.
[25] M. Zaki. Generating non redundant association rules. October, 2000.

22

Vous aimerez peut-être aussi