LUCIFER : Un système de détection de conflits dans les

Transcription

LUCIFER : Un système de détection de conflits dans les
LUCIFER : Un système de détection de conflits dans les
requêtes flexibles
Olivier Pivert, Grégory Smits, Allel Hadjali, Hélène Jaudoin
IRISA 6, rue de Kerampont - BP 80518 22305 Lannion cedex
{pivert | smits | hadjali | jaudoin}@irisa.fr, http://www.irisa.fr/pilgrim
Résumé. Le prototype de recherche présenté dans cet article est une implémentation d’une approche coopérative décrite dans Pivert et al. (2011). Cette approche aborde le problème des requêtes floues de type conjonctif retournant un
ensemble vide ou insatisfaisant de réponses. L’approche implémentée identifie
les sous-requêtes minimales à l’origine de l’échec ou de la non satisfaction.
1
Introduction
L’approche coopérative présentée dans Pivert et al. (2011) s’inscrit dans le contexte des
requêtes floues et aborde le problème des requêtes conjonctives retournant un ensemble vide
ou peu satisfaisant de réponses. Les requêtes floues constituent une des approches permettant
la prise en compte des préférences utilisateurs lors de l’interrogation de bases de données. En
ce sens, la théorie des ensembles flous, modèle sur lequel est basée cette représentation particulière des préférences, offre un cadre méthodologique riche et particulièrement adapté pour
la représentation de concepts issus de la langue naturelle (par exemple : ‘récent’, ‘élevé’, etc.).
Ainsi, un langage, nommé SQLf, a été développé afin de permettre l’expression de requêtes
floues dont la syntaxe et la sémantique sont décrites dans Bosc and Pivert (1995). Une requête
SQLf retourne une relation floue où chaque tuple est associé à un degré pris dans l’intervalle
unité reflétant sa satisfaction vis-à-vis des prédicats spécifiés dans la requête.
Bien que la prise en compte de préférences dans les requêtes introduit une forme de relaxation, le problème des réponses vides reste posé et peut, dans ce contexte, être étendu aux
ensembles de résultats peu satisfaisants. La section 2 rappelle l’approche de Pivert et al. (2011)
permettant de générer des explications pour ces situations d’échec ou de médiocre satisfaction.
La section 3 introduit le prototype de recherche qui implémente cette approche et présente une
série d’expérimentations discutant les performances de l’approche (Sec. 4).
2
Explication Graduelle des Échecs ou des Insatisfactions
L’explication d’une requête floue conjonctive, retournant un ensemble vide ou peu satisfaisant de réponses, repose sur l’identification des sous-requêtes responsables de la vacuité ou
du caractère peu satisfaisant des résultats. Ainsi, pour une requête floue conjonctive visant à
rechercher des annonces de véhicules récents, de faible consommation, à prix très réduit et
ayant un faible kilométrage, l’approche considérée pourrait expliquer l’échec (total ou partiel)
LUCIFER
de la recherche de la façon suivante : i) aucune voiture ne satisfait ‘année récente et prix très
réduit et faible kilométrage’ ; ii) aucune voiture ne satisfait le critère ‘consommation faible’
avec un degré supérieur à 0.6. Ces explications permettent d’aider l’utilisateur à reconsidérer
sa requête afin d’obtenir un ensemble non vide de résultats ou bien des résultats plus satisfaisants. Le premier type d’explications indique qu’afin d’obtenir des résultats, l’utilisateur
doit réviser la conjonction ‘année récente et prix très réduit et faible kilométrage’. Le second
type d’explication, caractérisant l’échec graduel (i.e., absence de réponses hautement satisfaisantes), indique également que sans réviser la sémantique du prédicat ‘consommation faible’,
l’utilisateur ne peut espérer de résultats satisfaisant pleinement sa requête.
Le processus d’identification des sous-requêtes à l’origine de l’échec ou de la faible satisfaction de la requête initiale repose sur une première étape de résumé de la base de données
interrogée. La construction de ce résumé nécessite un seul parcours du jeu de données au cours
duquel des cardinalités floues sont construites, cf. Pivert et al. (2011). Une cardinalité floue,
représentée formellement de la façon suivante : FQ = α1 /c1 + α2 /c2 + ... + αn /cn , indique
que c1 tuples de la base satisfont entièrement Q, c2 avec un degré de α2 , etc. Une échelle
normalisée prédéfinie S : α1 = 1 > α2 > ... > αn détermine les degrés de satisfaction
à considérer. Des cardinalités floues sont construites et maintenues pour chaque conjonction
pouvant être construite à partir des prédicats spécifiés dans la requête initiale. Ainsi, si une
requête comporte p prédicats, 2p − 1 cardinalités floues seront construites dans le pire des cas.
À l’aide de ces cardinalités floues, un algorithme inspiré d’APriori (Agrawal et al.
(1993)) permettant d’identifier efficacement les GMFSs (Gradual Minimal Failling Subqueries) de la requête considérée, est mis en oeuvre. Ces GMFSs fournissent des explications
relatives à l’échec ou à la faible satisfaction de la requête. L’algorithme construit de manière
incrémentale des sous-requêtes candidates en partant des requêtes atomiques jusqu’à la requête à expliquer, et vérifie à l’aide des cardinalités floues si elles échouent. Ces tests sont
effectués pour chaque degré de satisfaction présent dans l’échelle S. Pour éviter l’exploration
de toutes les conjonctions possibles pour chaque degré de satisfaction, l’algorithme exploite
le fait qu’une sous-requête qui échoue pour un certain degré αi , échouera également pour tout
degré αj où j ≥ i. Ainsi, si une sous-requête SQ échoue pour un degré αi alors aucune
conjonction de prédicats contenant SQ comme sous-requête ne sera étudiée. Cette réduction
de l’espace de recherche nécessite de vérifier au préalable la condition de minimalité de SQ,
c’est-à-dire qu’aucune sous-requête de SQ n’échoue également.
3
Le Prototype LUCIFER
Un prototype nommé LUCIFER 1 implémente cette approche coopérative afin d’expliquer
les situations d’échec pouvant survenir lors de l’interrogation d’une base de données contenant
50000 annonces de véhicules d’occasion. L’accès à cette base de données se fait au travers
d’une vue formée du résultat de la jointure de différentes tables. Cette vue a le schéma suivant : {idads, make, year, mileage, price, length, height, nbSeats, consumption, co2emission,
acceleration}. Pour des raisons de simplicité, un vocabulaire commun d’interrogation comprenant 59 prédicats flous a été défini sur les dix derniers attributs de la vue.
1. Pour Leveraging Unveiled Conflicts In FlexiblE Requests. Ce prototype est accessible à partir de l’URL suivante
http://sul3.irisa.univ-rennes1.fr:8080/Prototypes/lucifer/
O. Pivert et al.
L’implémentation a été réalisée sous forme d’une interface Web (en langage PHP) proposant un cadre de formulation de requêtes floues conjonctives (Fig. 1) et un cadre d’affichage
des résultats ou des explications en cas d’échec ou de médiocre satisfaction (Fig. 2). Le système de gestion de base de données choisi est PostgreSQL et les serveurs Web et PostgreSQL
sont installés sur une machine dotée d’un Intel Core 2 Duo 2,53Ghz, 4GO de DR3 1067 MHz
fonctionnant sous Linux Debian 6.
F IG . 2 – Explications via des
GMFSs
F IG . 1 – Interface d’interrogation
Expérimentations
Temps
d'exécution
Cardinalités
floues
10
Nb. tuples
F IG . 3 – Taille du résumé
6
4
50000
45000
40000
35000
30000
25000
20000
15000
5000
10000
0
1000
2
0
50000
45000
40000
35000
30000
20000
15000
Temps en seconde
8
10000
0
3500
3000
2500
2000
1500
1000
500
0
5000
Mémoire utilisée en KO.
Matrice
binaire
25000
4
NB. tuples
F IG . 4 – Temps de traitement
Nous avons mené une série d’expérimentations pour étudier l’impact de la taille de la
requête et celle de la base de données cible sur les performances de l’approche. La figure 3
illustre l’évolution de la taille du résumé en fonction du nombre de prédicats présents dans la
requête et met ce résultat en perspective par rapport à un résumé basé sur une matrice binaire
comme préconisé par Jannach (2006). La figure 4 représente l’évolution du temps de traitement
nécessaire à la génération des explications en fonction de la taille de la base de données. Ces
temps de traitement moyens ont été observés sur 20 requêtes composées de 8 prédicats. Il
est également intéressant de souligner que l’explication concernant une requête de 8 prédicats
pour une base de 50000 tuples à l’aide d’une approche naïve, où toutes les sous-requêtes sont
LUCIFER
exécutées (McSherry (2004)), nécessite 340 secondes. Cette information met clairement en
avant l’efficacité d’un unique parcours de la base de données.
5
Interprétation et Conclusion
Les expérimentations menées à l’aide de ce prototype confirment les résultats avancés dans
Pivert et al. (2011), c’est-à-dire que la complexité de l’algorithme d’explication de la vacuité
ou de la pauvreté de l’ensemble des résultats est linéaire en fonction de la taille du jeu de données. Cependant, il convient de noter que l’approche n’est exploitable que pour des contextes
applicatifs où le nombre de prédicats exprimés dans les requêtes est raisonnable (≤ 10), ce
qui correspond tout de même à une grande partie des cas d’application réels. Finalement, nous
avons pu constater que grâce aux corrélations entre attributs ainsi qu’à la présence de conjonctions de prédicats retournant un ensemble vide de résultats, la taille du résumé construit est très
raisonnable et surtout converge rapidement vers une taille maximale en raison d’un nombre limité de combinaisons possibles de propriétés. Ceci permet d’envisager une utilisation même
pour de larges bases de données. En perspective, nous travaillons actuellement sur une implantation écrite en C et avec un calcul en parallèle des cardinalités floues, ce qui réduira encore
les temps de traitement. Ce prototype sera également complété par une stratégie de réparation automatique de requête basée sur la relaxation des prédicats à l’origine de l’échec et par
l’application de propositions quantifiées à la place de la conjonction.
Références
Agrawal, R., Imielinski, T., and Swami, A. N. (1993). Mining association rules between sets
of items in large databases. In Proc. of SIGMOD’93, pages 207–216.
Bosc, P. and Pivert, O. (1995). SQLf : a relational database language for fuzzy querying. IEEE
Transactions on Fuzzy Systems, 3(1) :1–17.
Jannach, D. (2006). Techniques for fast query relaxation in content-based recommender systems. In Proc. of KI’06, pages 49–63.
McSherry, D. (2004). Incremental relaxation of unsuccessful queries. In Proc. of ECCBR’04,
pages 331–345.
Pivert, O., Smits, G., Hadjali, A., and Jaudoin, H. (2011). Efficient detection of minimal failing
subqueries in a fuzzy querying context. In In Proc. of ADBIS’11.
Summary
The research prototype presented in this paper is an implementation of the cooperative
approach detailed in Pivert et al. (2011). This approach deals with the problem of conjunctive
fuzzy queries that yield an empty or poorly satisfactory answer set. The implemented approach
efficiently retrieves the minimal failing subqueries of the initial query.