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.