Le document traite de la conception d'un datawarehouse, en abordant les étapes clés telles que la définition des besoins, la modélisation dimensionnelle et les performances. Il explique les caractéristiques des datawarehouses, leur fonctionnement par rapport aux bases de données opérationnelles (OLTP versus OLAP) et les meilleures pratiques pour optimiser les performances. Enfin, il souligne l'importance de la lisibilité des données et des tables de fait dans l'analyse et la prise de décision.

1. Conception du datawarehouse

2. Introduction les projets de Business Intelligence Le processus général 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. Le DataWarehouse

4. Le DataWarehouse DataWarehouse = Entrepôt de données Base de données spécialisée Réceptacle de l’ensemble des données de l’entreprise => grosses quantités de données Objectif : permettre à une organisation de prendre des décisions basées sur les informations disponibles Les informations proviennent des systèmes opérationnels de l’organisation et parfois de données externes à l’organisation Les données sont non volatiles : elles sont mises à jour uniquement par des flux d’alimentation exécutés périodiquement

5. Le DataWarehouse Caractéristiques du DataWarehouse Lisibilité pour l’utilisateur final Les données doivent être simples à comprendre, mais permettre plusieurs analyses différentes selon des critères différents (dimensions) 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 Performances Temps d’exécution d’une requête / d’un rapport ne doit pas dépasser 30 secondes 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 => Trouver le juste milieu entre les performances à l’exécution et la maintenabilité du système

6. Le DataWarehouse Caractéristiques du DataWarehouse Les données sont généralement stockées dans une base de données relationnelle Mais la structure des tables est adaptée à la navigation dans les données (dimensions, hiérarchies) Un gros effort est fourni sur l’aspect Performances Optimisation des tables, des indexes et du matériel (mémoire, processeur, disques)

7. Le DataWarehouse OLTP vs OLAP 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. Le DataWarehouse Il n’est pas recommandé de faire des analyses multidimensionnelles dans une base de données de production (OLTP) 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 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) Les requêtes ne doivent pas pénaliser les performances du système de production => Alimentation d’une base de données (quelquefois sur une machine) dédiée à l’analyse multidimensionnelle

9. Conception dimensionnelle

10. Sommaire Le DataWarehouse Conception dimensionnelle Structure du DataWarehouse

11. Conception dimensionnelle Conception dimensionnelle 1 dimension = 1 table de dimension 1 ensemble d’indicateurs = 1 table de faits => Schéma « en étoile » 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. Conception dimensionnelle Conception des dimensions hiérarchiques Dénormalisation complète des tables de dimension => duplication des données (pas grave car peu de volume dans les tables de dimension) => meilleures performances car moins de jointures Normalisation partielle 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. Conception dimensionnelle La dimension Temps La plus utilisée et la plus importante en terme de performances 90 % des requêtes sont filtrées sur le temps ou affichent/comparent des données temporelles La table Temps doit permettre de facilement gérer : L'ensemble de la hiérarchie Temps (jour, … , année) La période courante, Les x périodes précédentes, suivantes L'affichage, le tri de l'ensemble de la hiérarchie Temps Les données de la table Temps sont remises à jour chaque jour 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 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. Conception dimensionnelle La dimension Temps 13 mois glissants … where cpt_mois between -12 and 0 Années A-1, A et A+1 … where cpt_annee in (-1, 0, 1) Tri par mois … order by cpt_mois ou … order by id_mois Somme des ventes par trimestre .... sum(vente) group by id_trimestre 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') 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. Conception dimensionnelle Conception des tables de fait Les données de détail le plus fin sont stockées dans les tables de fait Les agrégations (somme, moyenne, …) sont en général calculées Les comptages utilisent des colonnes dédiées Si problèmes de performance => tables d'agrégations 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. Conception dimensionnelle Les clés des tables de dimension (et donc de fait) Les clés sont des clés techniques (bigint, NUMBER, ...) Éviter les clés ayant un sens fonctionnel => mauvaises performances si de type texte => pbms de mise à jour si le contenu évolue É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 Id : number matricule : varchar nom prenom ... Personne

17. Conception dimensionnelle 2 points de conception Un attribut ne peut exister que dans une et une seule dimension, alors qu’un fait peut figurer dans plusieurs tables de faits 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

18. Structure du DataWarehouse

19. Structure du datawarehouse Datawarehouse vs Datamarts Plusieurs niveaux de détail / d'agrégation des données Données élémentaires : copie quasi conforme (mais contrôlées et nettoyées) des données de production => « staging area » (zone de transit) Données agrégées au niveau de détail requis par l'analyse Données agrégées à un niveau supérieur pour des contraintes de performances 2 choix techniques possibles (non exclusif) Base relationnelle Base multi-dimensionnelle (Cubes) staging area Le datawarehouse regroupe l'ensemble de ces bases / objets staging area datamart finances datamart RH datamart logistique Alimentation

20. Structure du datawarehouse Base de données relationnelle vs multi-dimensionnelle 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 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

21. Structure du datawarehouse Optimisation des performances 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 » Répartition sur plusieurs disques Données sur 1 disque Indexes sur 1 disque 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 … … 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 .... .... ...) Ville id nom_ville departement region pays

22. Des questions ? Des questions ? http://www.6it.fr [email_address] 06.24.91.02.03 04.84.25.17.94