Entreposage de données
publicité
Entreposage de Données et Aide à la Décision Chapitre 23, 23.8—28.10 1 Objectifs Entreposage de données: OLAP vs OLTP Modèle de données multidimensionnelles Requêtes OLAP Design des données multidimensionnelles Techniques d’implémentation Vues et aide à la décision Matérialisation des vues Gestion et maintien des vues matérialisées 2 Vues et Aide à La Décision Les requêtes OLAP sont typiquement des requêtes d’agrégats. Du prétraitement est essentiel pour des temps de réponse interactifs. Le CUBE est en fait une collection de requêtes d’agrégat et du prétraitement est important à ce sujet: le challenge majeur est de trouver ce qui doit être prétraité étant donné un espace limité disponible pour stocker le résultat du prétraitement. Un entrepôt de données peut être conçu comme une collection de table reproduite de manière asynchrone et comme des vues mises à jour périodiquement. Cela a attiré un intérêt renouvelé dans la maintenance des vues. 3 Requêtes sur les Vues: Modification des Vues (Evaluer sur Demande) Vue CREATE VIEW RegionalSales(category,sales,state) AS SELECT P.category, S.sales, L.state FROM Products P, Sales S, Locations L WHERE P.pid=S.pid AND S.locid=L.locid Requête SELECT R.category, R.state, SUM(R.sales) FROM RegionalSales R GROUP BY R.category, R.state Requête modifiée SELECT R.category, R.state, SUM(R.sales) FROM (SELECT P.category, S.sales, L.state FROM Products P, Sales S, Locations L WHERE P.pid=S.pid AND S.locid=L.locid) AS R GROUP BY R.category, R.state 4 Requêtes sur les Vues: Matérialisation des Vues (Prétraitement) Supposez que nous prétraitons RegionalSales et stockons le résultat avec un index B+ groupé sur [category,state,sales]. La requête de la page précédente peut être traitée au moyen d’un scannage de l’index (‘ index-only scan’). SELECT R.state, SUM(R.sales) SELECT R.state, SUM(R.sales) FROM RegionalSales R FROM RegionalSales R WHERE R.category=“Laptop” WHERE R. state=“Wisconsin” GROUP BY R.state GROUP BY R.category Utiliser l’index B+ sur la vue Matérialisée:localiser la 1ère Feuille qui satisfait la clause WHERE et scanner à partir de là L’index sera peu utile (car un scannage de tout le niveau des feuilles de l’arbre B+ est nécessaire. 5 Vues Matérialisées Une vue dont les tuples sont stockées dans une base de données est dite matérialisée. Fournit un accès rapide (agit comme une mémoire cache). Besoin de maintainir la vue au fur et à mesure que la les tables sous-jacentes changent. Idéalement des algorithmes de maintenance incrémentale sont souhaitables. Concepts proches: entreposage, OLAP, maintien asynchrone des bases de données distribuées, évaluation contraintes d’intégrité et évaluation des triggers. 6 Matérialisation des Vues: Problématiques Quelles vues matérialiser et quels indexes construire sur ces vues? Etant donnée une requête et un ensemble de vues matérialisées, peut-on utiliser ces vues pour donner une réponse à cette requête? Quelle fréquence utiliser pour rafraichir les vues matérialisées afin de le rendre consistantes avec les tables sous-jacentes? Comment effectuer le rafraichissement de manière incrémentale?) 7 Maintenance des Vues Deux étapes: Propagation: Calculer les changements aux vues lorsque celles-ci changent. Rafraichissement: Appliquer les changements aux tables matérialisées. Une police de maintenance détermine quand rafraichir les vues. Maintenance immédiate: La vue est synchronisée avec les tables sous-jacentes au moment de transaction qui modifie cette table sous-jacentes. • La vue matérialisée sera toujours consistante. • Les modifications sont ralenties. Maintenance différée: La vue est synchronisée plutard dans une transaction séparée. • La vue devient inconsistante. • Plusieurs vues peuvent être facilement maintenues sans que les modifications soient ralenties. 8 Maintenance Différée Trois variantes: Paresseuse: retarder le rafraichissement jusqu’à la prochaine requête sur la vue et rafraichir juste avant de répondre à la requête. Périodique (‘Snapshot’): Rafraichir périodiquement. Les requêtes sont traitées en utilisant des versions périmées de la vues (Cette variante est largement utilisée, spécialement pour des reproductions asynchrones dans les bases de données distribuées et dans les application d’entreposage de données). Basée sur les événements: p.ex. rafraichir après un nombre fixe de changements aux tables sousjacentes. 9 ‘Snapshots’ dans Oracle 7 Une copie instantanée (‘snapshot’) est une matérialisation locale d’une vue stockée sur un site original. Rafraichissement périodique par reconstruction de la vue dans son entièreté. Rafraichissement rapide incrémental pour des instantanées simples: • chaque ligne dans la vue est basée sur une seule ligne dans une seule table sous-jacente • aucun DISTINCT, GROUP BY • aucune opération d’agrégat; aune sous-requête, aucun join ni opération ensembliste Les changements sur le site original sont journalisés par un trigger afin de supporter les copies instantanées. 10 Maintenance des Vues: Problématiques expensive_parts(pno) :- parts(pno, cost), cost > 1000 Quelles infos sont disponibles? (Relations de base, vues matérialisées, contraintes d’intégrité). Supposez que le tuple parts(p5,5000) est inséré: Seule la vue matérialisée est disponible: Nous ne pourrons pas dire si p5 est à insérer dans la vue ou pas tant que seule la vue est disponible. La table Parts est disponible: Ajouter p5 à la vue s’il n’y a pas déjà un tuple p5 de Parts dont le coût est plus grand que 1000. • (Parts pourrait ne pas être disponible si la vue est dans un entrepôt!) Si nous savons que pno est la clé de Parts: Nous pouvons inférer que p5 n’est pas déjà dans la vue et devons donc l’y insérer. 11 Maintenance des Vues: Problématiques (Suite) expensive_parts(pno) :- parts(pno, cost), cost > 1000 Quels changements doivent être propagés? (Insertions, effacements et modifications). Supposez que le tuple parts(p1,3000) est effacé: Seule la vue matérialisée est disponible : Si p1 est dans la vue, il n’y a pas moyen de dire si p1 devrait être effacé ou pas. • Si nous maintenons un compte (‘count’ -- #dérivations) pour chaque tuple de la vue, nous pouvons dire si p1 devrait être effacé ou pas (décrémenter le compte et effacer si le compte est = 0). La table Parts est disponible : S’il n’y a pas déjà un tuple p1 de Parts dont le coût est plus grand que 1000, effacer p1 de la vue. Si nous savons que pno est la clé de Parts : Nous pouvons inférer que p1 est déjà dans la vue et devons donc l’en effacer. 12 Maintenance Incrémentale: Insertions utilisant une Règle View(X,Y) :- Rel1(X,Z), Rel2(Z,Y) Etape 0: Maintenir un compteur de dérivation pour chaque tuple de la vue. Etape 1: Calculer les ensembles de tuples delta1 et delta2 correspondants aux relations Rel1 et Rel2 (delta1 et delta2 sont les ensembles de tuples insérés dans Rel1 et Rel2, respectivement). Etape 2: Calculer l’ensemble delta_new des tuples inserés dans la vue View(X,Y). Important: les duplicatas ne sont pas effacés (maintenir un compteur de dérivation pour chaque nouveau tuple). Etape 3: Rafraîchir View(X,Y) en effectuant une union des multi ensembles delta_new et (I.e. mettre à jour les compteurs de dérivation des tuples existants et ajouter les tuples de delta_new qui n’étaient pas dans View). 14 Maintenance Incrémentale: Effacement utilisant une Règle View(X,Y) :- Rel1(X,Z), Rel2(Z,Y) Etapes 0 - 2: Similaire aux insertions. Etape 3: Rafraichir la vue stockée en effectuant une différence des multi ensembles à la place de l’union. Pour mettre à jour les compteur de dérivation des tuples existants, nous devons soustraire les compteurs de dérivation des nouveau tuples de ceux des tuples existants. 15 Maintenance Incrémentale: Algorithmes Généraux Utilisant une Multitude de Règles L’algorithme à compteur peut être généralisé aux vues définies par une multitude de règles de dérivations. Il peut aussi être généralisé aux requêtes SQL avec duplicatas, négation et agrégats. 16 Maintenance des Vues d’Entrepôts view(sno) :- r1(sno, pno), r2(pno, cost) Problème: Il peut y avoir des changements aux sources entre les Etapes 1 et 3! Principal changement: Les vues sont dans un entrepôt de données et les tables sources sont autre part ailleurs (SGBS opérationnels, al DBMS, sources propriétaires, …). L’entrepôt est notifié de tout changement au niveau des tables sources (p.ex. lorsque un tuple est ajouté à r2) L’entrepôt peut nécessiter une information additionnelle au sujet des tables sources pour traiter un changement (p.ex. qu’est ce qui est dans r1 à l’instant ?) La source répond avec l’info additionnelle et l’entrepôt rafraichit la vue de manière incrémentale. 17 view(sno) :- r1(sno, pno), r2(pno, cost) Subtilités de la Maintenance des Vues Initialement: r1(1,2), r2 est vide Exécution de insert r2(2,3) à la source r2; notification de l’entrepôt L’entrepôt enverra la requête d’info additionnelle ?r1(sno,2) à r1 Check pour trouver quel sno insérer dans la vue Exécution de insert r1(4,2) à la source; notification de l’entrepôt L’entrepôt enverra la requête d’info additionnelle ?r2(2,cost) à r2 Check pour voir si nous avons besoin d’incrémenter le compteur de dérivation de view(4) Les sources r1 et r2 retourneront sno=1, sno=4 à l’entrepôt; ces valeurs iront dans la vue avec 1 comme valeur du compteur de chacune de ces valeurs. La source reçoit la seconde requête et y répond positivement et incrémente ainsi le compteur de view(4). Ce résultat est faux! Car le compteur correct pour view(4) est 1! D’où la nécessité d’algorithmes sophistiqués pour la maintenance des vues dans un environnement distribué 18 Résumé L’aide à la décision suppose la création de larges dépôts de données consolidées appelés entrepôts de données (‘data warehouses’). Les entrepôts de données sont utilisés au moyen de techniques d’analyse sophistiquées: requêtes SQL complexes et requêtes OLAP pour données multidimensionnelles. De nouvelles techniques sont utilisées pour le design des bases de données, l’indexage et les requêtes interactives. Les entrepôts de données sont des vues matérialisées qui exigent une maintenance au fur et à mesure que les sources de données changent. 19
