Projet BI - 2 - Conception base de données

14 201 vues

Publié le

Publié dans : Technologie
0 commentaire
19 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
14 201
Sur SlideShare
0
Issues des intégrations
0
Intégrations
168
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
19
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Projet BI - 2 - Conception base de données

  1. 1. Conception du datawarehouse
  2. 2. Introduction les projets de Business Intelligence <ul><li>Le processus général </li></ul>Conception Définition des besoins Définition de l’architecture technique Choix des outils Définition des indicateurs Modélisation dimensionnelle Définition des rapports / tableaux de bord Installation et paramétrage des outils Conception du modèle physique Création des « univers » Développement des rapports / tableaux de bord Déploiement Formation développement des alimentations
  3. 3. Le DataWarehouse
  4. 4. Le DataWarehouse <ul><li>DataWarehouse = Entrepôt de données </li></ul><ul><ul><li>Base de données spécialisée </li></ul></ul><ul><ul><li>Réceptacle de l’ensemble des données de l’entreprise => grosses quantités de données </li></ul></ul><ul><ul><li>Objectif : permettre à une organisation de prendre des décisions basées sur les informations disponibles </li></ul></ul><ul><ul><li>Les informations proviennent des systèmes opérationnels de l’organisation et parfois de données externes à l’organisation </li></ul></ul><ul><ul><li>Les données sont non volatiles : elles sont mises à jour uniquement par des flux d’alimentation exécutés périodiquement </li></ul></ul>
  5. 5. Le DataWarehouse <ul><li>Caractéristiques du DataWarehouse </li></ul><ul><ul><li>Lisibilité pour l’utilisateur final </li></ul></ul><ul><ul><ul><li>Les données doivent être simples à comprendre, mais permettre plusieurs analyses différentes selon des critères différents (dimensions) </li></ul></ul></ul><ul><ul><ul><li>Plus le modèle est lisible (intuitif) pour les utilisateurs, moins sera long (coûteux) de définir une surcouche pour le rendre compréhensible </li></ul></ul></ul><ul><ul><li>Performances </li></ul></ul><ul><ul><ul><li>Temps d’exécution d’une requête / d’un rapport ne doit pas dépasser 30 secondes </li></ul></ul></ul><ul><ul><ul><li>Il est généralement nécessaire de créer des agrégations de données et/ou des redondances => impact sur les performances au moment de l’alimentation des données => cela complique l’administration du système </li></ul></ul></ul><ul><li>=> Trouver le juste milieu entre les performances à l’exécution et la maintenabilité du système </li></ul>
  6. 6. Le DataWarehouse <ul><li>Caractéristiques du DataWarehouse </li></ul><ul><ul><li>Les données sont généralement stockées dans une base de données relationnelle </li></ul></ul><ul><ul><li>Mais la structure des tables est adaptée à la navigation dans les données (dimensions, hiérarchies) </li></ul></ul><ul><ul><li>Un gros effort est fourni sur l’aspect Performances Optimisation des tables, des indexes et du matériel (mémoire, processeur, disques) </li></ul></ul>
  7. 7. Le DataWarehouse <ul><li>OLTP vs OLAP </li></ul>OLTP On Line Transactional Processing OLAP On Line Analytical Processing Données mises à jour en continu par les utilisateurs => Sécurisation des mises à jour et de la cohérence des données Données en lecture seulement Mises à jour 1 fois par programme Beaucoup d’utilisateurs concurrents « Peu » d’utilisateurs (managers, Directions) Un seul objet traité à la fois Beaucoup d’objets manipulés Mêmes requêtes simples utilisées un grand nombre de fois Requêtes complexes souvent différentes Tables nombreuses, normalisées Peu de tables, de grande taille et dénormalisées Beaucoup de calculs d’agrégation
  8. 8. Le DataWarehouse <ul><li>Il n’est pas recommandé de faire des analyses multidimensionnelles dans une base de données de production (OLTP) </li></ul><ul><ul><li>Les données d’une base de production sont par nature très volatiles => on charge dans le datawarehouse un ensemble de données cohérentes et validées </li></ul></ul><ul><ul><li>Les données d’une base de production ne sont pas organisées pour des requêtes OLAP (nombreuses tables et jointures sur un volume de données très important) </li></ul></ul><ul><ul><li>Les requêtes ne doivent pas pénaliser les performances du système de production </li></ul></ul><ul><li>=> Alimentation d’une base de données (quelquefois sur une machine) dédiée à l’analyse multidimensionnelle </li></ul>
  9. 9. Conception dimensionnelle
  10. 10. Sommaire <ul><li>Le DataWarehouse </li></ul><ul><li>Conception dimensionnelle </li></ul><ul><li>Structure du DataWarehouse </li></ul>
  11. 11. Conception dimensionnelle <ul><li>Conception dimensionnelle </li></ul><ul><ul><li>1 dimension = 1 table de dimension </li></ul></ul><ul><ul><li>1 ensemble d’indicateurs = 1 table de faits </li></ul></ul><ul><li>=> Schéma « en étoile » </li></ul>id td1 id td2 id td3 id td4 indicateur 1 indicateur 2 .... Table de fait id libelle .... Table de dimension 2 Table de dimension 4 Table de dimension 1 Table de dimension 3 id libelle .... id libelle .... id libelle ....
  12. 12. Conception dimensionnelle <ul><li>Conception des dimensions hiérarchiques </li></ul><ul><ul><li>Dénormalisation complète des tables de dimension </li></ul></ul><ul><ul><li>=> duplication des données (pas grave car peu de volume dans les tables de dimension) => meilleures performances car moins de jointures </li></ul></ul><ul><ul><li>Normalisation partielle </li></ul></ul>Ville id nom_ville departement region pays Ville id nom_ville id_departement departement id nom_ departement id_region Region id nom_region pays id nom_ville departement region pays 1 Avignon 84 PACA France 2 Cavaillon 84 PACA France 3 Marseille 13 PACA France
  13. 13. Conception dimensionnelle <ul><li>La dimension Temps </li></ul><ul><ul><li>La plus utilisée et la plus importante en terme de performances </li></ul></ul><ul><ul><li>90 % des requêtes sont filtrées sur le temps ou affichent/comparent des données temporelles </li></ul></ul><ul><ul><li>La table Temps doit permettre de facilement gérer : </li></ul></ul><ul><ul><ul><li>L'ensemble de la hiérarchie Temps (jour, … , année) </li></ul></ul></ul><ul><ul><ul><li>La période courante, Les x périodes précédentes, suivantes </li></ul></ul></ul><ul><ul><ul><li>L'affichage, le tri de l'ensemble de la hiérarchie Temps </li></ul></ul></ul><ul><ul><li>Les données de la table Temps sont remises à jour chaque jour </li></ul></ul><ul><ul><li>Si besoin de descendre plus dans le détail que la journée, créer une autre table dédiée, pour ne pas dégrader les performances </li></ul></ul>id_date : date num_jour_annee : entier num_jour_semaine : entier num_jour_mois : entier id_semaine : entier cpt_semaine : entier num_semaine : entier id_mois : entier cpt_mois : entier num_mois : entier id_trimestre: entier … … … Temps 25/09/2009 268 5 25 200939 0 (semaine courante) 39 200909 0 (mois courant) 9 200903 … … …
  14. 14. Conception dimensionnelle <ul><li>La dimension Temps </li></ul><ul><ul><li>13 mois glissants … where cpt_mois between -12 and 0 </li></ul></ul><ul><ul><li>Années A-1, A et A+1 … where cpt_annee in (-1, 0, 1) </li></ul></ul><ul><ul><li>Tri par mois … order by cpt_mois ou … order by id_mois </li></ul></ul><ul><ul><li>Somme des ventes par trimestre .... sum(vente) group by id_trimestre </li></ul></ul><ul><ul><li>Performances : select .... from temps T inner join table_fait F on T.id_date = F.id_date where T.cpt_mois in (-1, 0) select … from table_fait F where to_char(F.id_date,'MM') = to_char(add_months(now, -1),'MM') or to_char(F.id_date,'MM') = to_char(add_months(now, 0),'MM') </li></ul></ul>Récupère 60 lignes dans la table Temps puis utilise l'index sur la table de fait Pas d'utilisation d'index Parcoure la table entière
  15. 15. Conception dimensionnelle <ul><li>Conception des tables de fait </li></ul><ul><ul><li>Les données de détail le plus fin sont stockées dans les tables de fait </li></ul></ul><ul><ul><li>Les agrégations (somme, moyenne, …) sont en général calculées </li></ul></ul><ul><ul><li>Les comptages utilisent des colonnes dédiées </li></ul></ul><ul><ul><li>Si problèmes de performance => tables d'agrégations </li></ul></ul>id date id produit nb_unites prix_vente nb_retours .... Table de fait id_date .... id_mois Temps id mois id produit nb_unites total_ventes .... Table de fait agrégée
  16. 16. Conception dimensionnelle <ul><li>Les clés des tables de dimension (et donc de fait) </li></ul><ul><ul><li>Les clés sont des clés techniques (bigint, NUMBER, ...) </li></ul></ul><ul><ul><li>Éviter les clés ayant un sens fonctionnel => mauvaises performances si de type texte => pbms de mise à jour si le contenu évolue </li></ul></ul><ul><ul><li>Éviter les clés du système de production => les clés du système de production ne sont pas toujours stables dans le temps (réutilisation de clés) => il peut y avoir plusieurs sources donc plusieurs clés dont les valeurs peuvent se chevaucher </li></ul></ul>Id : number matricule : varchar nom prenom ... Personne
  17. 17. Conception dimensionnelle <ul><li>2 points de conception </li></ul><ul><ul><li>Un attribut ne peut exister que dans une et une seule dimension, alors qu’un fait peut figurer dans plusieurs tables de faits </li></ul></ul><ul><ul><li>Si une dimension semble apparaître a plusieurs endroits, cela signifie probablement qu’elle joue plusieurs rôles. Nommez ces rôles et traitez les comme des dimensions différentes </li></ul></ul>
  18. 18. Structure du DataWarehouse
  19. 19. Structure du datawarehouse <ul><li>Datawarehouse vs Datamarts </li></ul><ul><ul><li>Plusieurs niveaux de détail / d'agrégation des données </li></ul></ul><ul><ul><ul><li>Données élémentaires : copie quasi conforme (mais contrôlées et nettoyées) des données de production => « staging area » (zone de transit) </li></ul></ul></ul><ul><ul><ul><li>Données agrégées au niveau de détail requis par l'analyse </li></ul></ul></ul><ul><ul><ul><li>Données agrégées à un niveau supérieur pour des contraintes de performances </li></ul></ul></ul><ul><ul><li>2 choix techniques possibles (non exclusif) </li></ul></ul><ul><ul><ul><li>Base relationnelle </li></ul></ul></ul><ul><ul><ul><li>Base multi-dimensionnelle (Cubes) </li></ul></ul></ul>staging area <ul><ul><li>Le datawarehouse regroupe l'ensemble de ces bases / objets </li></ul></ul>staging area datamart finances datamart RH datamart logistique Alimentation
  20. 20. Structure du datawarehouse <ul><li>Base de données relationnelle vs multi-dimensionnelle </li></ul><ul><ul><li>La base multi-dimensionnelle stocke les valeurs sur l'ensemble des dimensions, à tous les niveaux d'agrégation peu d'informations dans les dimensions => accès très rapide => optimisé pour la navigation dans les hiérarchies et pour les comparaisons temporelles => structure plus rigide </li></ul></ul><ul><ul><li>La base relationnelle est plus souple, elle permet de stocker autant d'informations que nécessaire => plus souple (requêtes / agrégations à la demande) => si volume très important => pbms de performances </li></ul></ul>
  21. 21. Structure du datawarehouse <ul><li>Optimisation des performances </li></ul><ul><ul><li>Indexes sur l'ensemble des clés (tables de fait et tables de dimensions) mais aussi sur les données « critères d'agrégation » </li></ul></ul><ul><ul><li>Répartition sur plusieurs disques </li></ul></ul><ul><ul><ul><li>Données sur 1 disque </li></ul></ul></ul><ul><ul><ul><li>Indexes sur 1 disque </li></ul></ul></ul><ul><ul><ul><li>Grosses tables de fait réparties sur plusieurs disques, en fonction des dimensions (souvent en fonction de l'axe temps) Janvier => disque 1 Février => disque 2 … … </li></ul></ul></ul><ul><ul><li>Création de « vues matérialisées » (snapshots) pour les agrégations supplémentaires Avantages des vues et stockage sur disque Rafraichies à la demande ou de manière automatique CREATE MATERIALIZED VIEW FAIT_VENTES_MOIS AS (SELECT .... .... ...) </li></ul></ul>Ville id nom_ville departement region pays
  22. 22. Des questions ? Des questions ? http://www.6it.fr [email_address] 06.24.91.02.03 04.84.25.17.94

×