Entreposage de Données et Aide à la Décision

Slides:



Advertisements
Présentations similaires
Module Systèmes d’exploitation
Advertisements

Optimisation des requêtes
Classification et prédiction
SQL - Subtilités.
Fonctionnalités des SGBD
Directeur de Thèse : Pr. Witold Litwin
Algèbre relationnelle
Plan de formation Chapitre 1 : Présentation de SAP
R. Saint-Paul, G. Raschia and N. Mouaddib IRIN, Nantes (France)
SGBDR : LA GESTION DES VUES
Traitement Co-Séquentiel: Appariment et Fusion de Plusieurs Listes
Initiation au système d’information et aux bases de données
Les requêtes La Requête est une méthode pour afficher les enregistrements qui répondent à des conditions spécifiques. La requête est donc un filtre.
Les contraintes d’integrité
Initiation au système d’information et aux bases de données
Développement d’applications web
Contrôles d'accès aux données
Introduction : Compilation et Traduction
IAS 16 « Immobilisations corporelles »
Principes de persistance dans les applications orienté objet
Chap 4 Les bases de données et le modèle relationnel
1 Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14.
Gestion de Fichiers Arbres B.
L’utilisation des bases de données
Sections sélectionnées du Chapitre 11
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 Procédures stockées CPI-SQLServer.
Courbes de Bézier.
1 SQL: Requêtes, Programmation et Triggers Chapitre 5, Sections
1 Evaluation des Operations Relationnelles Chapitre 14, Section 14.4.
Gestion de Fichiers Indexes basés sur les structures d’arbres binaires et indexes à niveaux multiples.
1 Évaluation des Requêtes: Survol Chapitre Objectifs Catalogue Préliminaires: Techniques de base pour traiter des requêtes Chemin daccès Correspondance.
1 SQL: Requêtes, Programmation et Triggers Chapitre 5, Sections 15.5.
SQL: Contraintes et Triggers
Algèbre Relationnelle
Optimisation des Requêtes Relationnelles
1 Évaluation des Requêtes: Survol Chapitre Objectifs Catalogue Préliminaires: Techniques de base pour traiter des requêtes Chemin daccès Correspondance.
1 SQL: Requêtes, Programmation et Triggers Chapitre 5, Sections
1 Survol du Stockage et de lIndexage Chapitre 8. 2 Objectifs Stockage persistant Organisation des fichiers Fichiers de données Fichiers dindexes Operations.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Évaluation des Requêtes: Survol Chapitre 12.
Universté de la Manouba
Cours de Base de Données & Langage SQL
Cours N°2 Base de Données & Langage SQL
PROGRAMMATION INFORMATIQUE DINGÉNIERIE II PRO-1024.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 SQL: Requêtes, Programmation et Triggers Chapitre 5, Sections
Les Algorithmes de Tri Introduction Tri par Sélection
Michel Tollenaere SQL et relationnel ENSGI Cours MSI 2A Relationnel et SQL version 1.4 du 25 septembre 2007 (ajout jointures) 1 Modèle relationnel Historique.
Programmation linéaire en nombres entiers : les méthodes de troncature
EPID-CPI-ISAIP Philippe Bancquart - mise à jour 24/02/ page 1 SQL jointure PHILIPPE BANCQUART.
Bases de données phénotypique et ontologie
Marc Bouissou, Guillaume Torrente, EDF
Algèbre Relationnelle : Implémentation
Traduction des opérations sous MySQL
JDBC L'API JDBC est utilisée pour utilisée pour intéragir avec une base de données.
Objectifs A la fin de ce chapitre, vous pourrez : présenter l'utilisation d'opérations de chargement de données par chemin direct décrire l'utilisation.
Bases de données fédéréEs hétérogènes
Programmation linéaire en nombres entiers
Surveiller et résoudre le conflit de verrouillage
SIO SI2 : Support Réseau des Accès Utilisateurs
Module 13 : Implémentation de déclencheurs. Vue d'ensemble Présentation des déclencheurs Définition de déclencheurs Exemples de déclencheurs Performances.
1 J. PHILIPP d'après G. Gardarin SGBDR : la gestion des vues l 1. Contexte l 2. Vues externes l 3. Interrogation des vues l 4. Mises à jour des vues l.
21/04/2015© Robert Godin. Tous droits réservés.1 6Gestion des contraintes d’intégrité en SQL n Contrainte d'intégrité statique – respectée pour chacun.
1 Survol du Stockage et de l’Indexage Chapitre 8.
1 Entreposage de Données et Aide à la Décision Chapitre 25, 25.1 – 25.7.
Structures de données avancées : Arbres B+ avec expansion partielle D. E ZEGOUR Institut National d ’Informatique.
Les bases de données Séance 8 Jointures.
NIVEAU LOGIQUE Vues. Fenêtre dynamique sur la base Ses données proviennent d'autres tables ou d'autres vues.
Op é rateurs ensemblistes Module 4. 2 La clause GROUP BY La clause GROUP BY est nécessaire dès que l'on utilise des fonctions de calculs statistiques.
Les vues, indexes, séquences.  Qu’est ce qu’une vue 1. Une vue est une vision partielle ou particulière des données d'une ou plusieurs tables de la base.
1 Initiation aux bases de données et à la programmation événementielle VBA sous ACCESS Cours N° 4 Support de cours rédigé par Bernard COFFIN Université.
1 Les bases de données Séance 5 -- Le Langage de Définition de Données ou la manœuvre de la structure de la base -- Le Langage de Manœuvre de Données.
Transcription de la présentation:

Entreposage de Données et Aide à la Décision Chapitre 23, 23.8—28.10 The slides for this text are organized into chapters. This lecture covers the material from Chapter 25 on views. It is most appropriate for a second course, or for an in-depth applications oriented course.

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

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.

Requêtes sur les Vues: Modification des Vues (Evaluer sur Demande) 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 Vue SELECT R.category, R.state, SUM(R.sales) FROM RegionalSales R GROUP BY R.category, R.state Requête 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 Requête modifiée

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) FROM RegionalSales R WHERE R.category=“Laptop” GROUP BY R.state SELECT R.state, SUM(R.sales) FROM RegionalSales R WHERE R. state=“Wisconsin” 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.

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.

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?)

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.

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 sous-jacentes.

‘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.

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.

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.

Maintenance des Vues: Problématiques (Suite) Langage de définition des vue? Requêtes conjonctive (règles) commandes SQL appropriées Duplicatas Agrégats Récusions

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).

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.

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.

Maintenance des Vues d’Entrepôts view(sno) :- r1(sno, pno), r2(pno, cost) 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. Problème: Il peut y avoir des changements aux sources entre les Etapes 1 et 3!

Subtilités de la Maintenance des Vues 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é

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.