Vers un système d’ED manipulant données et traitements
1.4 Validation : simulation de l’optimisation de l’ED
1.4 Validation : simulation de l’optimisation de l’ED
Nous montrons dans cette section l’intérêt de la persistance des besoins dans la structure d’un ED par un ensemble d’expérimentations simulant la tâche d’optimisation.
1.4.1 Motivations de l’expérimentation
Les expérimentations menées ont pour but de montrer que l’utilisation des besoins va au-delà des phases de définitions des besoins et de modélisation conceptuelle. Nous montrons que les besoins des utilisateurs peuvent être utilisés pour simuler différentes tâches du cycle de vie de l’ED comme la tâche d’optimisation. La diversité des modèles de données et des architectures de déploiements du cycle de conception des ED rend nécessaire cette simulation dès les premières phases de conception. Nous menons des expérimentations afin de comparer le résultat et le coût d’une optimisation dirigée par les besoins (obtenus dès le début de la conception de l’ED), et d’une optimisation dirigée par les requêtes des utilisateurs (obtenues après la conception de l’ED et son exploitation par les utilisateurs). Cette comparaison nous permet de montrer si une simulation de cette tâche de conception est possible à partir des besoins des utilisateurs. Nous rappelons la règle 80-20 énoncée par R.Elmasri dans [55] qui s’applique à ce contexte de simulation : 80% de la charge de travail utilisée lors la conception physique de la base de données, est représentée par 20% des transactions identifiées. Les expérimentations que nous menons ont trois principaux objectifs :
1. Vérifier si une simulation des phases de conception de l’ED à partir des besoins des utili-sateurs est possible.
2. Renforcer les liens entre les différentes phases de conception de l’ED afin de faciliter la communication entre les acteurs (administrateur, concepteur, éditeur, etc) intervenant tout au long du cycle de conception.
3. Apporter un nouveau modèle économique dans la conception des ED. En effet, nous avons remarqué que dans le contexte actuel, le rôle du concepteur physique diminue au point d’être parfois remplacé par des outils d’administration automatiques. Cependant, la robustesse de ces outils est souvent remise en cause [54]. Avec ce nouveau modèle illustré en figure 1.30, il est préférable d’exploiter la ressource humaine encore disponible le concepteur en le faisant interagir avec le système sur les différents niveaux de conception de l’ED. Nous tentons ici de fournir ce lien "humain" entre la conception logique et la conception physique.
Nous présentons dans ce qui suit l’intérêt de la persistance des besoins pour la tâche d’opti-misation.
1.4.2 Persistance des besoins pour l’optimisation de l’ED
1.4.2.1 Présentation de l’expérimentation
Les différentes tâches d’optimisation d’un ED s’effectuent habituellement au niveau physique et reposent sur les principales entrées suivantes : le schéma de l’ED, une charge de requêtes fré-quentes, un ensemble de contraintes données (espace de stockage, coût de mise à jour, etc), les caractéristiques du SGBD et l’architecture de déploiement (centralisé, distribué, etc). L’ensemble
Figure 1.30 – Rôles des acteurs dans l’architecture ANSI/SPARC
de ces entrées peut être fourni après l’analyse des besoins des utilisateurs. Toutes les contraintes (comme l’espace de stockage et le coût de mise à jour) et les caractéristiques du SGBD sont col-lectées auprès des acteurs du système sous forme de besoins non fonctionnels. Le schéma de l’ED est défini à partir des entités et des propriétés identifiées après analyse des besoins. La charge de requêtes correspond aux traitements que devra assurer l’ED, qui sont également obtenus à partir des besoins des utilisateurs. Nous rappelons que cette charge de requêtes n’est habituellement obtenue qu’une fois l’ED spécifié au niveau physique ensuite exploitée par les utilisateurs finaux de l’ED pendant une certaine période de temps. Durant cette période sensible où les statistiques et requêtes fréquentes de l’ED ne sont pas disponibles, nous proposons d’exploiter les besoins des utilisateurs pour simuler le processus d’optimisation.
Nous proposons deux cas d’étude : le problème de sélection des index et celui de la fragmen-tation horizontale et nous reformulons ces problèmes en prenant comme entrée les besoins des utilisateurs.
1.4.2.2 Persistance des besoins pour la définition des index
Nous commençons par formaliser le problème de sélection d’index en exploitant les besoins des utilisateurs définis sous forme de buts. Les index représentent une technique d’optimisation de requêtes très efficace et très répandue dans le contexte des ED. Ils permettent de réduire le coût d’exécution des requêtes en minimisant le volume de données à exploiter dans les calculs. Un problème classique de sélection d’index se formalise comme suit. Etant donné :
– I = I1, ..., In un ensemble d’index candidats (obtenus à partir des prédicats de sélection des requêtes).
– Q = Q1, ..., Qm un ensemble de requêtes.
1.4. Validation : simulation de l’optimisation de l’ED
Il faut alors trouver une configuration d’index Config telle que : – Le coût d’exécution des requêtes soit minimal.
– L’espace alloué pour le stockage de ces index ne dépasse pas S.
Nous adaptons ce problème en exploitant les besoins des utilisateurs au lieu des requêtes des utilisateurs de la manière suivante (figure 1.31) :
– I = I1, ..., In un ensemble d’index candidats (obtenus à partir des besoins). – B = B1, ..., Bm un ensemble de besoins.
– S la taille de l’espace de stockage allouée pour les index. Il faut alors trouver une configuration d’index Config telle que :
– Le coût d’exécution des requêtes soit minimal.
– L’espace alloué pour le stockage de ces index ne dépasse pas S.
Plusieurs travaux ont proposé des algorithmes pour répondre au problème de sélection d’in-dex. Nous optons pour l’algorithme défini par Bouchakri et al. dans [27], proposé dans les cadre des travaux menés au laboratoire LIAS. Pour faciliter l’exploitation des besoins des utilisateurs par le modèle de coût utilisé par l’algorithme, nous traduisons les besoins spécifiés en requêtes SQL. Rappelons qu’une requête SQL correspond à la définition d’un but décrit selon la syntaxe SQL. La traduction des besoins se fait en deux étapes :
– Structuration des besoins décrits en langue naturelle dans la spécification du banc d’essai SSB selon le modèle de but que nous avons défini.
– Traduction des buts obtenus en requêtes SQL. Cette traduction correspond à une trans-formation Model To Text dans l’ingénierie dirigée par les modèles (IDM). Cette étape est réalisée à l’aide de modèles de génération fournies par le plugin Accelio disponible sous l’environnement Eclipse. Accelio fournit un générateur de code permettant de transformer des modèles vers du code respectant une syntaxe définie, dans le cadre d’une Architec-ture Dirigée par les Modèles (MDA). Ce processus repose sur la définition d’un algorithme précisant les règles de transformation définies ci-dessous appliquées sur chaque but :
SELECT (les propriétés des classes "Métrique" dans le modèle de but) As (Résultat) FROM (l’ensemble des classes spécifiant l’instance du but)
WHERE (les propriétés des classes "Critère" dans le modèle de but et leurs valeurs. Les jointures entre les tables Fait et Dimension utilisées sont rajoutées)
Les expérimentations sont effectuées sur le schéma logique obtenu. L’ensemble des besoins décisionnels (13 besoins) spécifiés dans la spécification du banc d’essai SSB sont exploités. Les expérimentations ont donné les résultats résumés dans le tableau 1.2.
Ce tableau présente les index générés et le taux d’optimisation du coût d’exécution de chaque besoin. Ces résultats sont confrontés aux index et coût d’optimisation obtenus à partir de la charge de requêtes finales (fournies au niveau de la spécification du banc d’essai SSB). Ces résultats confirment que les index proposés par les besoins couvrent les index proposés par les requêtes du banc d’essai. Les coûts d’optimisation sont également assez similaires. Ceci s’explique par le fait que les requêtes issues des besoins sont similaires aux requêtes du banc d’essai (sans les clauses group by et order by que nous n’avons pas pu générer).
s_région s_région 3.5 d_year, d_yearmonth, s_region, p_category 90.2 d_year, d_yearmonth, s_region, p_category 90.2 4 d_year, d_yearmonth, c_region, s_region, p_category 91.7 d_year, d_yearmonth, c_region, s_region, p_category 91.7 4.5 d_year, d_yearmonth, c_region, s_region, p_mfgr, p_category 92 d_year, d_yearmonth, c_region, s_region, p_mfgr, p_category 91.9 5 d_year, d_yearmonth, c_region, s_region, s_nation, p_category 92.7 d_year, d_yearmonth, c_region, s_region, s_nation, p_category 92.6
Table1.2 – Index générés et taux d’optimisation du coût d’exécution des besoins Vs des requêtes
1.4. Validation : simulation de l’optimisation de l’ED
1.4.2.3 Persistance des besoins pour la fragmentation horizontale
Nous avons effectué une expérimentation similaire pour simuler le processus de fragmentation horizontale (FH) en utilisant les besoins des utilisateurs. La FH est une technique d’optimisa-tion qui consiste à répartir les tuples d’une table en plusieurs sous ensembles disjoints appelés fragments horizontaux. On distingue deux types de FH : (1) FH primaire définie sur une table de dimension en fonction de ses propres attributs, et (2) FH dérivée définie sur la table des faits en fonction des dimensions fragmentées.
Le problème de FH prend en entrée un ensemble de dimensions et une table de fait, une charge de requêtes et une contrainte de maintenance. Il retourne en sortie un schéma de partitionnement pour l’ensemble des tables qui réduit au mieux le coût de la charge. Le problème de FH est formalisé comme suit [15] :
Ayant les entrées suivantes :
– Un ensemble de table de dimension D=D1,D2,..Dd et une table de fait – Une charge de requête Q=Q1,Q2,..Qm
– W = seuil de fragments (fixé par l’administrateur) l’algorithme de FH doit alors fournir en sortie :
– Un ensemble D’ inclus ou égal à D des tables de dimension fragmentées – Un ensemble de N fragments de faits F1,F2,..Fn
Avec comme objectif de :
– Réduire le temps de réponse de Q – N<=W
Nous adaptons le problème de FH en remplaçant la charge de requêtes par l’ensemble des besoins. Ainsi la formalisation devient comme suit : ayant les entrées suivantes :
– Un ensemble de table de dimension D=D1,D2,..Dd et une table de fait – Un ensemble de besoin B=B1,B2,..Bm
– W = seuil de fragments (fixé par l’administrateur) l’algorithme de FH doit alors fournir en sortie :
– Un ensemble D’ inclus ou égal D des tables de dimension fragmentées – Un ensemble de N fragments de faits F1,F2,..Fn
Avec comme objectif de :
– Réduire le temps de réponse de Q – N<=W
Pour répondre à ce problème, nous utilisons l’algorithme de résolution de FH défini dans [15], qui a été proposé dans le cadre des travaux menés au laboratoire LIAS. Nous avons comparé les résultats de l’optimisation effectuée en utilisant la charge de requêtes réelles du banc d’essai SSB et les requêtes que nous avons traduits à partir des besoins. Les résultats de ces expérimentations sont illustrés dans la figure 1.32 et montrent que les besoins apportent un gain en performance supérieur de 15% comparé aux requêtes. Cette amélioration s’explique par l’absence des clauses Group By. Ces résultats sont prometteurs dans le sens où nous montrons que les besoins per-mettent de fournir une simulation de l’optimisation par FH pratiquement équivalente à une FH effectuée lors de la phase physique.
Figure1.32 – Fragmentation horizontale de l’ED à partir des besoins
1.5 Conclusion
Après avoir montré la convergence des méthodes de conception d’ED actuelles vers des ap-proches dirigées par les besoins et où la sémantique du modèle est de plus en plus considérée ; nous avons proposé dans ce chapitre une méthode de conception ontologique du schéma de l’ED permettant la persistance des besoins des utilisateurs dans une structure d’ED sémantique. Nos contributions dans ce chapitre concrétisent le premier objectif énoncé dans l’introduction géné-rale, qui est de consolider le cycle de conception de l’ED par une représentation persistante des besoins.
Pour ce faire, nous avons fourni un modèle de besoins défini selon une approche orientée but, les étapes de la méthode de conception du schéma de l’ED (conceptuel, logique et phy-sique), et le mécanisme permettant de faire persister les besoins dans la structure de l’ED. La méthode proposée prend en entrée une ontologie de domaine partagée par les sources de don-nées. Les besoins collectés auprès des utilisateurs sont projetés sur l’ontologie afin d’identifier les concepts et propriétés pertinentes à représenter dans l’ED, et l’ensemble des traitements que devra effectuer l’ED. Une ontologie locale à l’ED est ainsi définie par extraction de toutes les classes et propriétés intervenant dans la définition des besoins. Cette ontologie est annotée par les concepts multidimensionnels. Les mécanismes de raisonnement de l’ontologie sont exploités afin de valider le modèle de l’ED, et d’inférer de nouvelles structures multidimensionnelles. Le modèle de l’ontologie OED est ensuite traduit en un modèle relationnel selon différentes représen-tations (horizontale, binaire et verticale) par l’application d’un ensemble de règles permettant la traduction des constructeurs de l’ontologie vers les constructeurs d’un modèle relationnel. Nous avons validé notre proposition par l’implémentation du schéma de l’ED dans une structure de BDBO de type I (Oracle) et de type III (OntoDB), dont les métaschémas ontologiques ont été étendus par le modèle des besoins. Nous avons également démontré de manière informelle en-suite via des expérimentations l’impact de la persistance des besoins sur le cycle de vie de l’ED. Les expérimentations conduites ont montré l’intérêt de la persistance des besoins sur la tâche d’optimisation de l’entrepôt, plus particulièrement sur les problèmes de sélection d’index et de fragmentation horizontale.
Le prochain chapitre porte sur notre deuxième proposition, qui consiste à consolider le cycle de conception de l’ED en revisitant l’ordre d’exécution de la phase ETL. Nous complétons notre
1.5. Conclusion
méthode de conception ontologique présentée dans ce chapitre, pour une approche permettant la conception du schéma de l’ED et son alimentation par les données issues des sources.