ENTREPÔTS DE DONNÉES ILHAM MOUNIR LPMI ESTS A.U : 2021-2022 1 1) Objectifs Tra
ENTREPÔTS DE DONNÉES ILHAM MOUNIR LPMI ESTS A.U : 2021-2022 1 1) Objectifs Transformer un système d’information qui avait une vocation de production en un SI décisionnel c’est une Transformation des données de production en informations stratégiques Exemple de requêtes décisionnelles : Catégorie socioprofessionnelle des meilleurs clients de chaque région Evolution de la part de marché d’un produit particulier Nombre d'employé de l'entreprise par classe d'âge, par sexe, par grade Quel est le profil des employés les plus performants? 2 Chapitre I : Introduction 3 Chapitre I : Introduction Quel est le profil des employés les plus performants? Pourquoi et comment le chiffre d’affaire a baissé? A combien s’élèvent mes ventes journalières par produit et par région? 1) Objectifs Gestion et visualisation des données doit être rapide et intuitive. -> visualisation multidimensionnelle des données: 4 Chapitre I : Introduction 1) Objectifs Pour cela, il est nécessaire de retrouver et d’analyser rapidement les données provenant de diverses sources. DW offre une vision transversale des données de l'entreprise intégration de différentes BDs Les données doivent être : Extraites Groupées ensembles et organisées Corrélées Transformées (résumé, agrégation) 5 Chapitre I : Introduction Chapitre I : Introduction 2) Définition d’un entrepôt de données Ensemble de données destinées aux "décideurs" souvent une copie des données de production avec une valeur ajoutée (agrégation, historique) Intégrées historiées Ensemble d'outils permettant de regrouper les données de nettoyer, d'intégrer les données, ... de faire des requêtes, rapports, analyses de faire du datamining faire l'administration du warehouse 6 Chapitre I : Introduction Fonctions des entrepôts Récupérer des données existantes dans différentes BD sources Stocker les données (historiées) Mettre à disposition les données pour : Interrogation Visualisation Analyse 7 Chapitre I : Introduction Architecture 8 Chapitre I : Introduction 3) Pourquoi ne pas utiliser un SGBD? SGBD et DW : ont des objectifs différents et font des traitements différents stockent des données différentes font l'objet de requêtes différentes -> SGBD et DW ont besoin d'une organisation différente des données -> SGBD et DW doivent être physiquement séparés. 9 Chapitre I : Introduction SGBD: Objectifs et traitements Les SGBD sont des systèmes dont le mode de travail est transactionnel (OLTP On-Line Transaction Processing). Permet d'insérer, modifier, interroger des informations rapidement, efficacement, en sécurité. Deux objectifs principaux : Sélectionner, ajouter, mettre à jour et supprimer des tuples Ces opérations doivent pouvoir être effectuées très rapidement, et par de nombreux utilisateurs simultanément. 10 Chapitre I : Introduction DW: Objectifs et traitements Les datawarehouses sont des systèmes conçus pour l’aide à la prise de décision. (Mode de travail: OLAP On-Line Analytical Processing) La plupart du temps sont utilisés en lecture (utilisateurs) Les objectifs principaux sont regrouper, organiser des informations provenant de sources diverses, les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier, retrouver et analyser l’information facilement et rapidement. 11 Chapitre I : Introduction Données différentes D’après BILL Inmon : “Un DW est une collection de données orientées sujet, intégrées, non volatiles, historiées, organisées pour la prise de décision.” Orientées sujet: thèmes par activités majeures ; Intégrées: divers sources de données ; Non volatiles: ne pas supprimer les données du DW ; Historiées: trace des données, suivre l’évolution des indicateurs. 12 Chapitre I : Introduction Orientées sujet 13 BD DW Chapitre I : Introduction Données intégrées Techniques d'intégration des données Techniques de nettoyage: Cohérence entre les différentes sources des noms, unités de mesures, etc 14 Chapitre I : Introduction Données non volatiles 15 Chapitre I : Introduction Les données Volume très important Données dispersées, souvent difficiles d’accès Peu ou mal intégrées Complexes Non structurées pour les applications décisionnelles 16 Chapitre I : Introduction Requêtes BD-OLTP représentent les données sous forme aplatie: relation, données normalisées 17 Chapitre I : Introduction Requêtes OLTP: Requêtes simples "qui, quoi " par ex. les ventes de X. jointures: les ventes de X à quel prix de quel fournisseur, OLAP: besoin de données agrégées, synthétisées nombre de ventes par vendeur, par région, par mois, nombre de ventes par vendeur, par fournisseur, par mois, … SQL: Possibilité d'agréger les données (group by) mais très coûteux (parcourir toutes les tables) et il faut recalculer à chaque utilisation Sur plusieurs tables (ex : somme des ventes par fournisseur), nécessité de faire des jointures souvent coûteuses 18 Chapitre I : Introduction Différences BD – DW 19 Chapitre I : Introduction Nécessité d'une structure multidimensionnelle Les BD relationnelles ne sont pas adaptées à l'OLAP car : Pas les mêmes objectifs Pas les mêmes données: Les données nécessaires à l'OLAP sont multidimensionnelles (i.e. ventes par vendeur, par date, par ville…). Les tables en représentent une vue aplatie. Pas les mêmes traitements et requêtes: Non seulement perte de performances mais aussi nécessité pour les utilisateurs de savoir comment trouver les liens entre les tables pour recréer la vue multidimensionnelle. Il est donc nécessaire de disposer d'une structure de stockage adaptée à l'OLAP , i.e. permettant de représenter les données dans plusieurs dimensions, manipuler les données facilement et efficacement. 20 Chapitre I : Introduction 21 Séparation BD et DW Les DW vont être physiquement séparés des BD, pour des raisons de: Performance : systèmes de production ne sont pas organisés pour pouvoir répondre efficacement aux requêtes des systèmes d’aide à la décision. Même les requêtes simples peuvent dégrader sérieusement les performances. Données différentes: ◼Données historiées : aide à la décision nécessite des données sur une longue durée, non conservée dans les BD ◼Données agrégées ◼Qualité des données : sources différentes qui utilisent souvent des noms, formats, codes et mesures différents devant être uniformisés Chapitre I : Introduction 22 DW-OLAP représentation des données sous forme multidimensionnelle : ‘Cube’ Chapitre I : Introduction 23 Cube: représentation des données sous forme multidimensionnelle Chapitre II: Modélisation des données décisionnelles 24 Utilisation de concepts pour : o Optimiser la restitution de données selon les axes métiers de l’entreprise o Gérer et visualiser les données de manière rapide et intuitive o Retrouver et analyser rapidement les données à partir de diverses sources o Intégrer plusieurs bases dedonnées o Extraire, grouper, organiser, corréler et transformer les données Deux types de modélisations: Entité-Relation et Multidimensionnelle Modèles de Données 25 Plan du Chapitre 26 ➢Modélisation Entité-Relation ➢Modélisation Multidimensionnelle ➢Conception des Data Warehouses : Etapes et Exemple ➢Modèles d’un Data Warehouse ➢Aspects Fondamentaux de la Modélisation Multidimensionnelle I) Modélisation Entité-Relation 27 Modèle permettant d’éclairer les relations microscopiques entre les données o Supprimer la redondance desdonnées o Simplifier le traitement destransactions o Aider le concepteur dans la répartition des propriétés entre les entités Principes o Notion d’identifiant o Dépendance fonctionnelle o Décomposition o Formes normales Normalisation dans les BDRs 28 Forme normale : o Type de relation particulier entre lesentités o Permet d’éviter les anomalies transactionnelles dues à une mauvaise modélisation des données o Permet de vérifier la robustesse de la conception des modèles de données pour éviter les problèmes de redondance et de mise à jour du contexte Dans le modèle OLTP , il existe en principe 6 formes normales o Elles s’emboitent les unes dans les autres o Le respect d’une FN de niveau supérieur implique le respect des FN des niveaux inférieurs o On va présenter les 3 premières (les plus utilisées) Première Forme Normale (1FN) 29 Produit Fournisseur Téléviseur Vidéo SA, Hitek LTD Produit Fournisseur Téléviseur Vidéo SA Téléviseur Hitek LTD Relation dont tous les attributs : o Contiennent une valeur scalaire (les valeurs ne peuvent pas être divisées en plusieurs sous-valeurs dépendant également individuellement de la clé primaire) o Contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul attribut). o Sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge). Problème Solution Deuxième Forme Normale (2FN) 30 Les attributs d'une relation sont divisés en deux groupes: o Le premier groupe est composé de la clé (une ou plusieurs). o Le deuxième groupe est composé des autres attributs (éventuellement vides). Tout attribut du deuxième groupe ne peut dépendre que d'un sous-ensemble (strict) d'attribut(s) du premier groupe. o « Un attribut non clé ne dépend pas que d'une partie de la clé » Pdt Fournisseur Adresse Fournisseur Télé Vidéo SA 13 rue Midi Ecran Vidéo SA 13 rue Midi Télé Hitek LTD 25 rue Bond Produit Fournisseur Télé Vidéo SA Ecran Vidéo SA Télé Hitek LTD Fournisseur Adresse Vidéo SA 13 rue Midi Hitek LTD 25 rue Bond Problème Solution Troisième Forme Normale (3FN) 31 Fournisse Ur Adresse Ville Pays Vidéo SA 13 rue Midi Paris France Hitek LTD 25 rue Bond London England Fournisse ur Adresse Ville Vidéo SA 13 rue Midi Paris Hitek LTD 25 rue Bond London Les attributs d'une relation sont divisés en deux groupes: o Le premier groupe est composé de la clé (une ou plusieurs). o Le deuxième groupe est composé des autres attributs (éventuellement vides). Tout attribut du deuxième groupe ne peut pas dépendre que d'un sous-ensemble (strict) d'attribut(s) du deuxième groupe. o « Un attribut non clé ne dépend pas d'un ou plusieurs attributs ne participant pas à la clé ». Problème Solution uploads/Management/cours-entrepotdonnees-slides.pdf
Documents similaires










-
30
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Jul 12, 2021
- Catégorie Management
- Langue French
- Taille du fichier 1.9367MB