Requêtes OLAP sur une base de données XML native - Cercle ...

More documents

Recommendations

Info

2.3 Le modèle multidimensionnel 6 2.3.1 Notions Un sujet est défini par un ensemble de mesures et un ensemble de dimensions. Par exemple, les mesures d’une vente peuvent être son numéro, son prix et sa quantité : ce sont les valeurs numériques que l’on veut comparer. Les dimensions seraient la date, le type de produit et la région : ce sont les points de vue depuis lesquels les mesures peuvent être observées. Une dimension est une liste d’éléments organisés de façon hiérarchique. La granularité d’une dimension est son nombre de niveaux hiérarchiques. Par exemple, pour le temps, nous pourrions avoir la hiérarchie suivante : année, semestre, trimestre, mois, semaine, jour, soit six niveaux. Les axes de dimensions doivent fournir des règles de calculs d’agrégat pour chaque mesure. Par exemple, le nombre de ventes du premier trimestre est la somme du nombre de ventes de janvier, février et mars. Les dimensions sont stockées dans des tables de dimensions qui contiennent les niveaux hiérarchiques des dimensions ainsi que les formules à appliquer sur les données numériques (les faits) pour passer d’un niveau à un autre. Certains cas spéciaux sont à gérer si les dimensions sont organisées en hiérarchies multiples : les magasins d’une entreprise peuvent être organisées par ville, par province, par secteur ou par région de vente. Une région de vente peut regrouper certaines villes de provinces différentes. Elzbieta Malinowski et Esteban Zimányi ont fait une étude complète des différents types de hiérarchies de dimensions dans [3]. Un fait représente la valeur d’une mesure, mesurée ou calculée, selon un membre de chacune des dimensions. Par exemple, « 10000 » est un fait qui exprime la valeur de la mesure « coût des travaux » pour le membre « 2002 » du niveau « année » de la dimension « temps » et le membre « Bruxelles » du niveau « ville » de la dimension « géographie ». Les mesures sont stockées dans des tables de faits qui contiennent les valeurs des mesures et les clés vers les tables de dimensions. Dimension Temps PK jour semaine mois trimestre année Dimension Produit PK id_produit nom_produit id_categorie nom_categorie id_famille nom_famille Fait Vente PK id_vente nombre montant FK1 id_produit FK2 jour FK3 id_vendeur FK4 id_magasin Dimensions Vendeurs PK id_vendeur nom_vendeur groupe departement Dimension Géographie PK id_magasin nom_magasin commune region pays Fig. 2.2 – Modélisation d’un entrepôt à l’aide d’un schéma en étoile. A titre d’illustration, observons le schéma relationnel de la figure 2.2. La table placée au centre représente les faits et leurs mesures respectives : nombre et montant. Les quatre tables gravitant
2.3 Le modèle multidimensionnel 7 autour de la table des faits représentent les dimensions : temps, géographie, produit et vendeur. Chaque table de dimension contient les différents niveaux de la hiérarchie de dimension. Pour la dimension géographique, représentée figure 2.3, nous avons 4 niveaux de granularité : le magasin, sa commune, sa région et son pays. Il s’agit ici d’une hiérarchie de dimension symétrique, c’est à dire qu’un magasin n’est inclus dans une seule commune, une commune dans une seule région et ainsi de suite. Géographie Magasins Communes Régions Pays Fig. 2.3 – Hiérarchie symétrique d’une dimension géographique. Ces différents mécanismes nous permettront de placer les données dans des matrices multidimensionnelles appelées cubes. Un exemple d’un tel cube est présenté à la figure 2.4 Ces cubes sont parfois appelés hyper-cubes s’il y a plus de 3 dimensions. Les données pourront être interrogées directement et facilement sur n’importe quelle combinaison de dimensions, sans utiliser de requêtes trop complexes. Passer d’une hiérarchie de dimension à une autre est réalisée facilement dans un cube de données par la technique de pivot, de rotation. Par cette technique, le cube peut être pivoté pour afficher différentes orientations des axes. Par exemple, on peut pivoter un cube pour afficher les régions en lignes, les trimestres en colonnes et les produits dans la troisième dimension. Cette technique est équivalente à avoir une table de vente par région pour chaque produit, où chaque table affiche les ventes par trimestre et par région du produit. clavier 2003 2004 2005 souris écran 120 230 210 132 198 256 145 259 237 Bruxelles Wallonie Flandre 78 176 142 137 258 232 Régions 276 187 245 196 Produits Fig. 2.4 – Représentation d’un cube de données. Les opérations slice et dice permettent respectivement d’extraire une tranche du cube et un sous-cube selon des prédicats sur les dimensions. Ces opérations sont illustrées respectivement aux figures 2.5 et 2.6. Années
Page 1 and 2: Faculté des Sciences Département
Page 3 and 4: TABLE DES MATIÈRES iii Table des m
Page 5 and 6: TABLE DES MATIÈRES v 5 Les bases d
Page 7 and 8: Chapitre 1 Introduction Le but de c
Page 9 and 10: Chapitre 2 Les entrepôts de donné
Page 11: 2.3 Le modèle multidimensionnel 5
Page 15 and 16: 2.3 Le modèle multidimensionnel 9
Page 17 and 18: 2.5 Analyse des données 11 F. Codd
Page 19 and 20: Chapitre 3 Les documents XML Ce cha
Page 21 and 22: 3.3 Motivations 15 9. Les documents
Page 23 and 24: 3.4 Le document XML 17 présenter.
Page 25 and 26: 3.5 Les DTD et les Schémas XML 19
Page 27 and 28: 3.5 Les DTD et les Schémas XML 21
Page 29 and 30: 3.6 Modélisation des documents XML
Page 31 and 32: 3.6 Modélisation des documents XML
Page 33 and 34: Chapitre 4 Les langages d’interro
Page 35 and 36: 4.2 XPath 29 sont peut être pas é
Page 37 and 38: 4.3 XQuery 31 4.3 XQuery 4.3.1 Intr
Page 39 and 40: 4.3 XQuery 33 A titre d’illustrat
Page 41 and 42: 4.3 XQuery 35 4.3.7 Limitations De
Page 43 and 44: 4.4 Autres langages d’interrogati
Page 45 and 46: 4.5 Conclusions 39 ou à produire d
Page 47 and 48: 5.2 Types de bases de données XML
Page 49 and 50: 5.3 Bases de données XML natives 4
Page 63 and 64:
5.3 Bases de données XML natives 5
Page 65 and 66:
5.4 eXist, une base de données XML
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
5.5 Conclusions 69 intéressant de
Page 77 and 78:
6.2 Systèmes d’analyse (OLAP) 71
Page 79 and 80:
6.2 Systèmes d’analyse (OLAP) 73
Page 81 and 82:
6.3 Besoins d’un système OLAP ba
Page 83 and 84:
6.4 Le test TPC-H 77 existait des s
Page 85 and 86:
6.4 Le test TPC-H 79 Requête simpl
Page 87 and 88:
6.4 Le test TPC-H 81 précédemment
Page 89 and 90:
6.5 Conclusions 83 6.5 Conclusions
Page 91 and 92:
7.1 Base de données source 85 < co
Page 93 and 94:
7.2 Requêtes d’analyse 87 SELECT
Page 95 and 96:
7.3 Groupements en XQuery 89 Ces de
Page 97 and 98:
7.4 Scénario d’évaluation 91 d
Page 99 and 100:
7.4 Scénario d’évaluation 93 po
Page 101 and 102:
7.4 Scénario d’évaluation 95
Page 103 and 104:
7.6 Conclusions 97 Temps (ms) 80000
Page 105 and 106:
7.6 Conclusions 99 T(eXist)/T(scrip
Page 107 and 108:
8.2 Travaux Futurs 101 Cet opérate
Page 109 and 110:
BIBLIOGRAPHIE 103 [19] J. Clark and
Page 111:
BIBLIOGRAPHIE 105 [58] D. Florescu
show all

Requêtes OLAP sur une base de données XML native - Cercle ...

Create successful ePaper yourself

Delete template?

Save as template?