Bases de Données OLAP. Chapitre 2 Architecture. La Perspective d Oiseau. Perspective Détaillée ... Hiver 2011/2012

Transcription

1 Bases de Données OLAP Hiver 2011/2012 Melanie Herschel Université Paris Sud, Groupe Bases de Données, LRI Chapitre 2 Architecture Composantes d un DW ETC 2 La Perspective d Oiseau Système DW Sources de hétérogènes. L entrepôt de collecte les des sources et stocke cellesci dans les relations. vues partielles sur DW Data Data Data Mart 1 Mart 2 Mart 3 Différentes vues () sur ces relations de l entrepôt de sont mises à disposition à des applications. Oracle DB2 XML sources de 3 Perspective Détaillée Data-Warehouse-System Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Basisrelationen DB2 Oracle Analyse de XML détaillées Méta agrégées Mise à disposition de dispositives consolées D après Wolfgang Lehner, Datenbanktechnologie für Data Warehouse Systeme, dpunkt.verlag, 2003 Consolation de Procuration de & (staging area) 4

2 Data-Warehouse-System Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Basisrelationen Data-Warehouse-System Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Basisrelationen Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Data-Warehouse-System Basisrelationen Systèmes de source Systèmes et fichiers fournissant les intéressantes pour les analyses. Souvent, ces systèmes sont hétérogènes (voir classification du transparent suivant) Mise à disposition de ce au DW Push: La source génère elle-même les à extraire pour le DW Pull: Le DW met en marche l accès Chaque source doit être traitée indivuellement 5 Hétérogénéité Hétérogénéité syntactique structurelle sémantique hardware software interfaces modèle conflits de noms entité conflits de bande passante système HTLM processeur d exploitation SQL mémoire centrale protocoles XQuery sécurité relationnel OO attribut vs. valeur concepts différentes valeurs relation vs. valeur synonymes représentations manquantes nom d attributs normalisation emboitage homonymes du même objet unités contradictions 6 Systèmes de source Source 1 Produit P1 p_ nom prix type 1 Matrix 9,99 Blue Ray 2 Der Pate $US12,45 DVD 3 Dirty Dancing 7,50 Veo Source 2 Produit P2 ent description dvd veo blueray P1 The Matrix non non oui P2 The Godfather oui non non P3 Moulin Rouge non non oui Vente p_!p1.p_ panier_ nombre date /1/ /1/ /2/ /3/2011 Stock s p_ent!p2.ent stock dernier_restockage 1 P P P P Pour les deux systèmes de source décrit ci-dessus, quels types d hétérogénéité reconnaissez-vous? 7 Procuration et de Objectif: Intégration des extraites les es pertinentes (en provenance des sources de ) sont amenées physiquement dans la sphère de contrôle du DW (load time). Nettoyage et ajustement des () Vérification d une qualité de suffisante. Réunion de es pour obtenir une vue globale. Les résultats intermédiaires sont stockés temporairement. Le domaine de procuration de et de est souvent nommé staging area. 8

3 Procuration et de des en provenance des sources 1 et 2 Au niveau du Produits_intégrés P Nouvel attribut nom prix monnaie type nom = description 1 The Matrix 9,99 EUR Blue Ray prix divisé en prix + monnaie 2 The Godfather 12,45 USD DVD Représentation du type suivant source 1 Au niveau des 3 Dirty Dancing 7,50 EUR Veo Valeurs générées pour 4 Moulin Rouge NULL NULL Blue Ray Identité des films vérifiée Titres anglais seulement Prix ne contient plus de symbole pour la monnaie Vente Monnaie déduite du prix spécifié dans la source 1!P. panier_ nombre date type intégré des deux sources /1/2010 Au niveau du Source 1 seul procureur pour les ventes réutilisé (sauf ) /1/2010 Au niveau des /3/2011 Valeurs de générées en fonction de produits_intégrés. Tuple insignifiant (nombre = 0) filtré Stock s!p. stock dernier_restockage /4/ /3/ /1/ /2/2010 Au niveau du Source 2 seul procureur pour les stocks réutilisé (sauf ) Au niveau des Valeurs de générées en fonction de produits_intégrés. Format de date est adapté (même format à travers toutes les relations) Valeurs interdites (stock < 0) corrigées 9 Consolation de Base de consolées Réalise un stockage de toutes les de détail à travers toutes l organisation, indépendamment de l application. Ainsi, elle donne une vue d ensemble des processus et de l état d une organisation, qui sont stockés dans le cadre de l entrepôt de. Objectif: Actualisation de la base de consolée dans le DW Addition de fraichement intégrées à la base de du DW (refresh time) Schéma Généralement développé suivant les règles du développement de s relationnels (normalisation, évitement de redondance). Souvent le résultat d un processus d intégration de appliqué aux sources. 10 Consolation de Intégration de Soient un ensemble de sources de Qi et leurs s respectifs Si, alors trouve un S = Si, où désigne une union sémantique. L intégration de est difficile à cause de l hétérogénéité, en particulier de la sémantique des éléments du. Que stocke la relation KVMU? Que stocke l attribut Produit.ANS? Que stocke l attribut Nom? (Titre d un film, nom d un acteur, ) Comment se décompose le prix? (TVA, monnaie, réductions, ) L intégration de n est pas automatisée jusqu à présent, mais facilitée (semi-automatique) par des outils interactifs. Domaine de recherche actif: entification de correspondances sémantiques entre les attributs de différents s (schema matching) (par exemple nom = description). 11 Consolation de Beispiel: Normalisiertes Schema Exemple d un normalisé d une base de consolée year year customer name cust_class discount customer_ productg_ discount line_item order_ product_ amount single_price productgroup name product productgroup_ month Month year_ day day month_ session cust_ day_ time order session_ supply_ total_amount supply_station region_ region name order_status order_ supply_ Ulf Leser: DWH und DM, Sommersemester 2007 status 28 12

4 Mise à Disposition des Données Problèmes de la base de consolées Beaucoup de tables, confus Beaucoup de jointures sont nécessaires pour (presque) toutes les requêtes, optimisation difficile Les jointures divertissent du but analytique - on préfère opérer avec des notions des processus à analyser. Solution: Modélisation multimensionnelle de la base de dispositive. 13 Mise à Disposition des Données Base de dispositive La base de dispositive stocke les dans un format dépendant de l'application et optimisé pour les requêtes analytiques prévues. Objectif de la mise à disposition des : Mise à jour de la base de dispositive, basée sur la base de consolées. La conception du est guée par l application à laquelle il est dédié (star/snowflake-schema) Le degré du détail des est également adapté à l'application. Différents niveaux de détail ( plus ou moins agrégées) sont possible et engendrent de la redondance, explicitement désirée dans ce contexte. 14 Mise à Disposition des Données Multimensionales Schema Exemple d un étoile (star schema) customer name cust_class time day month year line_item order_ product_ amount single_price discount_rate product name product_group supply region Plus Technische de détails Informationen techniques (session) raus (Session) Ne Nur stocke abgeschlossene que des commandes Bestellungen complètement aufnehmen (Orderstatus) traitées (orderstatus) Données Zusammenfassen condensées (discount_rate) Dénormalisation Denormalisieren (partout) (überall) Concentration Konzentration sur auf les Businessobjekte objets et processus und -prozesse importants Ulf Leser: DWH und DM, Sommersemester Analyse de Le domaine de l analyse des comprend tous les systèmes et bases de destinés à l interaction entre un utilisateur / une application et les dispositives. Ce sont des vues spécialisées, nommées data marts, sur la base de dispositive. Elles sont dédiées à des applications spécifques. Vue dans des bases de classiques: requêtes sauvegardées, mais exécutées lors de chaque utilisation. Un accès répétitif au dispositives est trop couteux à cause du large volume de. Pour cette raison, les vues utilisées par un DW sont des vues matérialisées, stockant le résultat de la requête déclarant la vue. Problèmes intéressants: Mise à jour des vues matérialisées (view maintenance) Choix des vues matérialiséés utilisées lors de l'exécution d une requête pouvant utiliser une ou plusieurs vues pour éviter le calcul de résultats intermédiaires (view selection) 16

5 Analyse de Exemples de vues possibles customer_class_per_product customer_class product_name product_class count Class 1 The Matrix Blue Ray 5000 Class 2 The Matrix Blue Ray 2000 Class 1 Dirty Dancing Veo 1000 Class 2 Dirty Dancing Veo 6000 product_sales_per_region region product_name product_class income Europe The Matrix Blue Ray North America The Matrix Blue Ray Asia The Matrix Blue Ray Europe The Godfather DVD Quelles autres requêtes pourraient être traitées en réutilisant ces vues? 17 Méta- Objectifs Suivre et comprendre les processus Eviter de fausses interprétations Décrire les aspects techniques du DW Exigences envers la gestion de méta- Mise à disposition des informations importantes en garantissant leur intégralité et actualité. Accès flexible à travers des interfaces expressifs Gestion de versions et de configurations Support des fonctions techniques et professionnelles et des utilisateurs [Prof. Rahm, Universität Leipzig, Cours Data Warehouses] 18 Méta- Formes de réalisation Méta- spécifiques aux outils utilisés. Méta- suivent un modèle plus généralement applicable et extensible (modèle de méta-) Il existe une multitude de modèles de méta- propriétaires Effort de standardisation, par exemple le Common Warehouse Metamodel (CWM) du Object Management Group (OMG) Souvent, l intégration et l'échange entre différents systèmes de gestion de méta- sont necessaires. [Prof. Rahm, Universität Leipzig, cours Data Warehouses] 19 Types de méta- Application des s, scheduling Règles de, de nettoyage Schémas des BD, des fichiers statistiques sur la qualité de Schéma du DW (tables, attributs) conceptionnel (multimensionnel) Description de la sémantique des entités, dimensions, Vocabulaire d entreprise rapports, requêtes infos sources (DBMS, IP, URL) autorisations (noms, mots de passe) types d'accès, statistiques Profils d utilisateurs, droits, rôles Composantes d un DW (discutées dans ce cours) [Prof. Rahm, Universität Leipzig, cours Data Warehouses] 20

6 Types de méta- Méta- techniques Information produite lors de la construction et du fonctionnement du DW. Information recueillie lors du fonctionnement du DW, décrivant quelle est appliquée à quel instant et quel était le résultat (erreur, succès, ) Exemples de méta- techniques Données d accès (protocole, utilisateur, mot de passe, ) Description de correspondances tiques (schema matching) Programme de standardisation des adresses Description du processus de complet 21 Types de méta- Méta- orientées vers le processus Description comment interpréter les stockées du point de vue du processus réel de l entreprise. La spécification de la sémantique se fait avec un langage assez expressif pouvant exprimer des assertions concernant les. Exemple du secteur bancaire 22 Chapitre 2 Architecture Composantes d un DW ETC 23 L architecture discutée est le cadre maximal. Cela veut dire qu une solution de DW n implémente pas nécessairement toutes les s discutées. Une configuration spécifique dépend du scénario d application. La distribution physique des (serveur central vs. système distribué) peut varier. Les configurations varient également selon le temps de stockage des ( matérialisées et permanentes vs. virtuelles et permanentes). 24

7 Exemple 1 - manque des consolées outils d analyse data mining tableur requête analyse data marts mise à disposition détaillées agrégées dispositives procuration & sources 25 Exemple 2 - manque de l étape de outils d analyse analyse mise à disposition procuration & data mining tableur dispositives data marts détaillées requête agrégées Operational data store (ODS) d après Inmon Collection non durable / non persistée de intégrées et orientées vers un thème précis. Sert à soutenir le besoin de actuelles, fonctionnelles et intégrées et de vue d ensemble d une unité d organisation. Operational data store 26 Exemple 3 - Serveur DW monolithique data marts Serveur DW méta détaillées agrégées dispositives Sources 27 Exemple 4 - système distribué data marts sur machines indivuelles data marts serveur de dépôt méta détaillées agrégées dispositives Server DW Server dédié à la Sources Oracle XML 28

8 Exemple 5 - intégration matérialisée et vues virtuelles data mining tableur requête temporaire / virtuel persisté / materialisé méta data marts détaillées qgrégées dispositives 29 Exemple 6 - intégration virtuelle temporaire / virtuel persisté / materialisé data mining tableur requête consolées! Les sont stockées par les sources.! Les sources sont autonomes (à un certain degré).! Sont transférées uniquement les nécessaires au calcul de la réponse à la requête posée.! La et l intégration sont faites en ligne, c.a.d. lors de l'exécution d une requête.! Les requêtes sont posées de manière déclarative envers un global (correspondant ici au consolé) et sont exécutées de manière distribuée.! Pas de historique! Deux principales architectures! Architecture à 5 couches pour des systèmes BD fédérés! Architecture mediator-wrapper 30 Architecture à 5 couches [SL90]! Application: Systèmes de gestion de BD distribués et fédérés! Par exemple BD catalogue et BD images permettant un accès commun.! Par exemple DW constitué de plusieurs domaines partiels de l entreprise.! Sources semi-autonomes:! forte autonomie,! mais le désir de coopération avec d autres systèmes existe! fédération! L utilisation de méta- facilite le traitement de requêtes. externe 1 d export de fédéré externe 2 d export de 31 Architecture à 5 couches [SL90]! Schéma! correspond au logique des sources.! Schéma de fédéré! modèle de canonique (modèle de du fédéré) d export d export! passage d un modèle à l autre par des mappings! résout le problème d hétérogénéité du modèle de.! Schéma d export! sous-ensemble du de! gère les droits d accès externe 1 de externe 2 de 32

9 Architecture à 5 couches [SL90]! Schéma fédéré! intègre les s d export! connait la distribution des externe 1! noms alternatifs:! d import!!!! global d entreprise unifié médiateur externe 2 fédéré d export de d export de 33 Architecture à 5 couches [SL90]! Schéma externe! le fédéré peut ëtre très grand " simplification par différents s d export, nommés s externes à ce niveau! simplifie le problème de l évolution de! peut définir des conditions d intégrité supplémentaires! implémente des droits d accès externe 1 externe 2 fédéré d export de d export de 34 Architecture Mediator-Wrapper! Application sources hétérogènes sources très autonomes, qui ne savent souvent pas de leur intégration application 1 application 2 pas de dépôt de méta-! Mediator (médiateur) mediator! développé à partir des applications envisagées, et non par l intégration des s source.! servant à l intégration wrapper1! wrapper (enveloppe)! sert d intermédiaire entre les sources et le médiateur! résout l hétérogénéité (i) des interfaces, (ii) des modèles de et (iii)sémantique wrapper3 wrapper2 source 1 source 2 Chapitre 2 Architecture Composantes d un DW ETC 36 source 3 35

10 Perspective Détaillée Data-Warehouse-System Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Basisrelationen Analyse de Méta détaillées agrégées dispositives Mise à disposition de consolées Consolation de D après Wolfgang Lehner, Datenbanktechnologie für Data Warehouse Systeme, dpunkt.verlag, 2003 Procuration de & (staging area) 37 Procuration de Données et Rappel L objectif est d intégrer les sources es (plus précisément, les stockées dans les systèmes de source). Ces intégrées sont placées physiquement dans la sphère de contrôle du DW et y sont ainsi stockées de manière permanente. Trois étapes cruciales ont lieu dans le domaine de procuration de et de (la staging area) et sont regroupées dans le processus extraction--chargement (ETC). Processus extraction--chargement (ETC) Extraction: Approvisionnement des importantes des systèmes de source. : des source afin de respecter le et le format de la base de donnée cible (dans le cadre général défini, le de la BD consolée) Chargement: Import et stockage des dans la BD cible. 38 Extraction Exigences de performance rigoureuses Les outils d analyse requièrent les à temps. Les outils d analyse ont souvent besoin de actuelles. L activité des systèmes opératoires ne doit pas être diminuée, ou cette diminution doit être minimale.! Variation du volume de extraites.! Variation du degré de coopération des sources à délivrer leurs. Sources hétérogènes (lors de l extraction, l'hétérogénéité syntactique est surmontée principalement).! Variation des moyens d accès aux sources de. 39 Extraction - Volume des extraites Deux principales possibilités: Extraction des changements: Que les parties des ayant été modifiées depuis la dernière procédure d extraction sont transmises au système DW. Modifications peuvent être des insertions de tuples (insert), des effacements de tuples (delete). Des modifications de tuples existants (update) sont typiquement implémentés par une suite insert+delete. Copie intégrale des source (snapshot) S utilise lorsque le nombre de changements indivuels est trop important ou si l extraction des changements n est pas possible due à des raisons techniques. Conflit d intérêt: Extraction de cohérentes vs. restriction du fonctionnement opératif causé par l accès exclusif des, nécessaire durant l extraction. " Méthodes de snapshot spécialisés [AdLi80] à la création de copies logiques de BDs. 40

11 Extraction - degré de coopération des sources Degré de coopération des sources, du plus au moins élevé. 1.Sources réplicatives Coopération très étroite entre la source et le domaine d entréé des du DW. Utilisation de techniques de réplication pour propager des changements de de manière synchrone au DW. 2.Sources actives Des changements de sont propagés par la source au DW en toute indépendance. Utilisation de déclencheurs (trigger) dans les BD sources. 3.Sources snapshot La source livre un snapshot qui représente un état cohérent, mais pas nécessairement actuel des source. Les changements de source (reflétés dans le snapshot) peuvent être extrait du snapshot sans perturber le système opérationnel. 41 Extraction - degré de coopération des sources 4.Sources exportatrices Une alternative au snapshot (copie logique d une BD) est la création d un database dump (copie physique d une BD) pouvant être exporté. 5.Sources délivrant un protocole des changements Le protocole est analysé par le DW afin d en déduire les changements devant être reflétés dans le DW. 6.Sources non-coopératives Système clos, ne permettant pas de solution élégante pour donner accès aux stockées à d autres applications. Logiciels spécialisés (adaptateurs) ou programmation de logiciels indivuels. 42 Extraction - interfaces d accès au sources Accès via fenêtre de dialogue Pour des systèmes clos, le seul moyen de communication est la fenêtre de dialogue. L extraction des se fait par simulation d un dialogue adapté. Accès au niveau application Systèmes opérationnels ayant des interfaces vers l extérieur. L extraction des se fait par programmation contre l interfqce dédié à l échange de. Accès au niveau BD Possibilité d accès direct au système de stockage des sources (par exemple un système der gestion BD). Pour l extraction sont utilisés des protocoles standardisés / spécifiques aux systèmes (par exemple ODBC pour C/C++, JDBC pour Java) 43 Extraction - interfaces d accès au sources (ctd) Accès au niveau protocoles d activités Pas d accès au niveau d application ou BD Mais accès au protocoles d activités des sources Utilisation d extracteurs spéciaux (log file sniffer), déduisant les changements des sources. Export et Import Le DW ne peut accéder directement a quelconque information du système source. Mais le système source exporte les en un format prédéfini. Le DW peut alors importer cet export de la source. 44

12 Production de cohérentes et inégrées Démarche non-répétitive à faire lors de la création du DW: création du consolé Einmaliger Schritt: Entwurf des Schemas der konsolierten Datenbasis "intégration de s Démarche répétitive à refaire à chaque extraction de : de source vers le cible ( de la BD consolée). " Intégration de 45 - intégration de s Définition voir poly 11, détails pas discutés dans ce cours Exigences envers le intégré: Intégralité (completeness) tous les objets / toutes les informations décrits dans les s sources sont reflétés dans le intégré. Exactitude (correctness) La sémantique des sources est préservée. Cependant, comme les intégrées (par exemple de l attribut prix) doivent toutes avoir la même sémantique (par exemle sans TVA), la sémantique des sources doit pouvoir être transformée et compréhensible. Minimalité (minimality) Pas de redondance des objets représentés dans le global. Compréhensibilité (comprehensibility) Schéma doit être facilement compréhensible et modifiable intégration de Tâche la plus importante: assurer la qualité des intégrées. Techniques détaillées discutées ulérieurement. 5 étapes de nettoyage de : 1. Décomposition des source en éléments (elementizing) Par exemple adresse " rue, numéro, code postal, ville 2. Adaptation des éléments à un format standard (standardizing) Par exemple adoption d un même format pour les dates (jj/mm/aaaa), «1ST AVE» " «First» Avenue. 3. Vérification de la plausibilité de (verification) Par exemple le conflit entre code postal = «91400» et ville = «Paris» est entifié et résolu 47 - intégration de (ctd) 4. Alignement des (matching) Par exemple vérification de l existence d un produit (tuple provenant d une source) dans la BD intégrée. Si un produit y existe déjà, sa représentation intégrée est adaptée. 5. Formation de groupes (householding) Vérification de l appartenance de nouveau tuples à un groupe de tuples de la BD intégrée intéressant au niveau application (bénéfique lors des analyses). Par exemple, formation / élargissement du groupe «type de consommateur». 48

13 Data-Warehouse-System Teilsichten über DW Data Data Data Mart 1 Mart 2 Mart 3 Basisrelationen Chargement Objectif: Ajout efficace des transformées au DW. Techniques Basées SQL Interface standard: embedded SQL, JDBC, Opération / extension propriétaire: Array Insert Consération et activation de toutes les méthodes BD: déclencheurs, actualisation d indexes, concurrence, Chargement de masse (bulk load): Extension spécifique d un système BD dédiée au chargement de larges volumes de. Utilisation d interfaces d application: nécessaire chez certains vendeurs (SAP) [Prof. Ulf Leser, HU Berlin, cours Data Warehouse, SS 2007] 49 Chargement - chargement de masse Pour de large volumes de, le chargement de masse (bulk load) est souvent le seul interface de chargement assez performant. Processus critique s applique en général à une seule table à la fois bloque la table entière désactive les contraintes d intégrité (CI), les déclencheurs, l actualisation d indexes! suivant un chargement de masse, CI sont vérifiées et les indexes actualisés! les déclencheurs ne sont pas executés UPDATE ou INSERT? (UPSERT!) Performance du chargement de masse est souvent le facteur limitant [Prof. Ulf Leser, HU Berlin, cours Data Warehouse, SS 2007] 50 Récapitulatif Perspective Détaillée Architecture / s d un DW Configuration dépend de l application Composantes implémentées varient Systèmes distribués Intégration matérialisée vs. virtuelle Processus ETC Extraction des source détaillées agrégées Méta dispositives consolées D après Wolfgang Lehner, Datenbanktechnologie für Data Warehouse Systeme, dpunkt.verlag, 2003 des dans le et format cible Chargement des transformées dans la BD cible. Analyse de Mise à disposition de Consolation de Procuration de & (staging area) 4 51