Après avoir défini toutes les dimensions, le concepteur procède à la définition du Fait et ses composants. D’abord, il doit préciser le nom du Fait et sélectionner les dimensions liées. Le système vérifie les données numériques qui sont reliées au niveau le plus bas d’au moins une dimension (nous rappelons la possibilité d’avoir des données numériques manquantes issues du croisement des différentes sources d’où l’absence de données numériques reliées à des niveaux de base de certaines dimensions) et propose les données structurelles, non- utilisées dans l’identification des dimensions, comme nom de mesure. Pour chaque dimen- sion et pour chaque mesure, le concepteur peut définir pour chaque paramètre de chaque hiérarchie différentes fonctions d’agrégation selon la proposition de [Hassan, 2014]. Au ni- veau du graphe, les noeuds des données numériques sont supprimés et le nouveau noeud de Fait avec ses mesures est créé. Le noeud Fait est également relié aux dimensions selon le formalisme graphique du modèle conceptuel de [Teste, 2009].
Fait et la requête pour son alimentation. A ce stade, le système gère automatiquement le problème des données numériques redondantes pour les mêmes instances de di- mensions en utilisant la technique de vote. Par ailleurs, les données numériques man- quantes de certaines instances de dimensions seront des valeurs nulles dans la table de Fait.
– Pour non-matérialiser, le système génère un nouveau noeud structurel avec le label du Fait et lui attribue l’annotation a qb : dataset. Il rajoute l’annotation a qb : MeasureProperty pour les données structurelles identifiées comme mesures. Chaque fonction d’agrégation peut avoir les annotations qb4o : Avg, qb4o : Min, qb4o : Max, qb4o : Count, qb4o : Count ou qb4o : sum. Une fonction d’agrégation doit se défi- nir comme une propriété entre un composant de la dimension (paramètre, attribut ou hiérarchie) et entre la mesure. Enfin, un nouveau noeud pour la constellation est créé avec l’annotation a qb : dataStructureDe f intion. Le lien entre le Fait et la constellation est établi par l’annotation Nom_Fait qb : structure Nom_Constellation. Pour chaque dimension reliée au Fait, le système rajoute l’annotation Nom_Constellation qb : Component Nom_Dimension. Comme nous considérons que les concepteurs ne sont pas forcément des experts dans la conception multidimensionnelle, le système doit au préalable implémenter les règles de vérification d’additivité (sous forme d’assertions OWL-DL) proposées par [Prat et al., 2012] .
Exemple 15. La Figure IV.11 montre une itération intermédiaire dans la création de Fait pour l’exemple de motivation.
Figure IV.11 — Exemple d’itération dans la création de Fait
Afin de matérialiser, le système génère la requête de création du schéma de la table de fait comme suit :
CREATE TABLE StatistiquesMedicales ( id_fact_stats DECIMAL,
id_dim_temps DECIMAL, Dépenses DECIMAL,
VolumeSoinConsommé DECIMAL,
CONSTRAINT pk_statMed PRIMARY KEY (id_fact_stats),
CONSTRAINT fk_soin FOREIGN KEY (id_dim_soin) REFERENCES Soin(id_dim_soin), CONSTRAINT fk_temps FOREIGN KEY (id_dim_temps) REFERENCES Temps(id_dim_temps), )
Le système produit aussi une requête d’alimentation de la table de fait dont le résultat est illustré dans la Figure IV.12.
Figure IV.12 — Exemple de table de Fait avec les tables de dimensions
Afin de non-matérialiser, le système produit les annotations suivantes dans le graphe RDF. StatistiquesMedicales a qb : dataset Depenses a qb : MeasureProperty
VolumeSoinConsomme a qb : MeasureProperty ConstelStatMed a qb : DataStructureDe f inition qb : component Temps
qb : component Soins
StatistiquesMedicales qb : structure ConstelStatMed
4
Conclusion
Nous avons présenté dans ce chapitre la dernière étape de notre démarche d’entrepo- sage d’Open Data. Nous rappelons que les deux premières étapes de notre démarche ont
étape est de permettre l’exploitation analytique de ces données intégrées. L’exploitation ana- lytique dans les systèmes décisionnels est réalisée par des opérations OLAP. Ces opérations nécessitent l’organisation des données selon un schéma multidimensionnel. Pour cela, cette dernière étape est consacrée à la transformation des données ouvertes intégrées en données multidimensionnelles (c’est-à-dire décrites par un schéma multidimensionnel). Dans la lit- térature, il y a deux approches pour la matérialisation des données multidimensionnelles. Certaines approches conçoivent un schéma multidimensionnel puis matérialisent les don- nées dans un entrepôt. D’autres approches décrivent les données par des vocabulaires mul- tidimensionnels et les interrogent directement sans matérialisation. Étant donné que notre approche s’adresse à une large audience (contexte self-service BI), nous supportons les deux approches. Pour cela, nous avons proposé un processus progressif composé de deux vues :
– Une vue utilisateur dans laquelle l’utilisateur définit progressivement, à un ni- veau conceptuel, les composants multidimensionnels (dimensions et faits) à partir du graphe intégré. Ce graphe se transforme progressivement en un schéma mul- tidimensionnel selon le formalisme graphique du modèle conceptuel proposé par [Ravat et al., 2007b].
– Une vue système dans laquelle le système s’occupe de la matérialisation ou de la non- matérialisation des données d’une façon complètement transparente à l’utilisateur. Le système demanderait juste au début du processus le choix de l’utilisateur concernant la matérialisation.
– Pour matérialiser les données, le système opère pour générer un entrepôt de don- nées selon la démarche R-OLAP classique. Pour cela, le système génère progressi- vement les scripts sql pour le schéma de création et d’alimentation de l’entrepôt de données. Il est possible alors d’interroger l’entrepôt de données avec des opérations OLAP.
– Pour non-matérialiser les données, le système produit automatiquement des anno- tations multidimensionnelles dans un graphe RDF équivalent au graphe intégré visualisé par le concepteur. Les annotations mutlidimensionnelles utilisées appar- tiennent au vocabulaire QB4OLAP [Etcheverry et al., 2014]. Nous avons choisi ce vo- cabulaire multidimensionnel puisqu’il est plus complet que d’autres vocabulaires, en instance QB2. Il est possible d’interroger directement le graphe RDF annoté avec
des opérations OLAP-SPARQL [Etcheverry et al., 2014]. L’usage des graphes géné- riques nous a permis d’aboutir à une démarche ETQ [Abello et al., 2015].
Ces propositions ont été publiées dans le cadre de la conférence nationale EDA’13 [Berro et al., 2013] et la conférence internationale ICEIS’15 [Berro et al., 2015a].
Dans le chapitre suivant, nous décrivons le prototype implémenté pour la validation de notre démarche. Puis, nous présentons les résultats des expérimentations effectuées sur nos propositions.
V
Prototype et évaluations
N
OUS abordons dans ce dernier chapitre deux volets concernant la validation de notre démarche d’entreposage. Dans le premier volet, nous décrivons les différents modules du prototype qui ont été développés pour notre démarche ETL. Dans le deuxième volet, nous illustrons les résultats d’évaluations de nos algorithmes de détection des données ta- bulaires ainsi que les résultats d’évaluation de la qualité et de la performance du programme linéaire d’intégration de données.1
Introduction
L’ouverture des données tabulaires statistiques par des organismes publics constitue de nouvelles sources pour alimenter les systèmes de prise de décision. Néanmoins, ces données posent plusieurs problèmes : hétérogénéité, manque de structure, qualité, etc. Elles néces- sitent alors des solutions pour les croiser et les analyser de manière simple et rapide.
Figure V.1 — Une démarche d’entreposage des données ouvertes tabulaires statistiques
Nous répondons à ces besoins en proposant une démarche ETL basée sur les graphes. Cette démarche est constituée de trois phases, Extraction- Transformation- Loading ; elles sont illustrées dans la Figure V.1. La première phase consiste à la détection et la reconnais- sance des données tabulaires. La deuxième phase consiste à l’intégration des graphes de
données ouvertes et la troisième phase consiste à la définition de schémas multidimension- nels à partir du graphe intégré. L’utilisation des graphes dans cette démarche permet une plus grande généricité de nos travaux.
Les phases de cette démarche ont été détaillées dans les chapitres 2, 3 et 4 de ce manus- crit. Le but de ce chapitre est d’illustrer le prototype développé pour valider notre démarche et évaluer celle-ci.
Ce chapitre s’articule en deux sections : prototype et évaluations. Dans la section pro- totype, nous décrivons les trois modules qui ont été implémentés pour les trois étapes de notre démarche. Nous nous appuyons sur un scénario d’étude pour présenter ces modules. Dans la section évaluations, nous présentons d’abord les résultats du module de détection des données tabulaires puis nous détaillons les résultats d’évaluation de la qualité de l’ap- pariement par paire sur des bancs d’essais de référence. Nous finissons avec les résultats d’évaluation de la performance de l’appariement holistique pour les graphes de notre scé- nario d’étude.
2
Prototype
Dans cette section, nous décrivons le prototype que nous avons développé pour valider notre approche ETL. Nous présentons un scénario d’étude, dans la sous-section 2.1, pour illustrer le fonctionnement de notre prototype. Ensuite, nous présentons l’architecture fonc- tionnelle de ce prototype dans la sous-section 2.2. Enfin, nous détaillons les trois modules de notre prototype dans les sous-sections 2.3, 2.4 et 2.5.