Troisième partie Entrepôt de données 23 Chapitre 8 Architecture d’un entrepôt de données 8.1 8.1.1 Systèmes décisionnels Comparaison avec un système transactionnel Un système transactionnel est une base de données tournée vers la saisie, le stockage, la mise à jours et l’intégrité des données. Ces systèmes permettent de gérer les transactions quotidiennes d’une ou de plusieurs applications particulières (réservation, commande, gestion de stock, ...). Les données sont détaillée, et la notion d’archivage est quasiment absente. L’activité est caractérisée par un nombre important de requêtes simples d’interrogation et de modification. On parle de base OLTP (On-Line Transaction Processing). Un système décisionnel permet d’agréger des données internes ou externes et de les transformer en information apportant une aide à la décision. Un système décisionnel n’est mis à jour qu’à un moment choisi lors de l’import de donnée. Son activité principal est de répondre à des interrogations complexes et ouvertes. C’est l’utilisateur qui doit pouvoir formuler simplement ses questions en fonction de ses besoin. La prévision des interrogations est imprévisible car elle dépend de l’utilisateur et des réponses aux autres interrogations. Par exemple, si un produit s’est peu vendu une année par rapport à la précédente, le responsable marketing va vouloir comprendre pourquoi en effectuant des analyses suivants plusieurs axes : Ventes par région, par magasin, par mois, par profil de client, ... Il faut donc que le système décisionnel lui permette d’explorer toutes mes données suivant les recherches qu’il a à mener, afin d’apporter une aide à la décision (par exemple faire une promotion ciblée pour les clients d’un certain age, d’une certaine région, ...). On parle dans ce car de base OLAP (On-Line Analytical Processing). Le support d’une activité OLAP nécessite la construction d’un Datawarehouse. 8.1.2 Datawarehouse Définition Un datawarehouse est une collection de données orientées sujets, intégrées, non volatiles et historisées, organisées pour le support du processus d’aide à la décision. ( Bill Inmon, 1994). Il s’agit donc d’une base de données alimentée par les systèmes de production (souvent des bases OLTP), après nettoyage et uniformisation de leur données. La figure 8.1 montre les différents aspect du datawarehouse. Caractéristiques des données décisionnelles Orientées sujet Les données sont organisées autours des sujets majeurs de l’entreprise, elles présentent une vue synthétique des informations pertinentes pour les décideurs, dans la perspective d’une aide à la décision et non de la gestion quotidienne de opérations. Intégrées Elles sont construites en intégrant plusieurs sources de données hétérogènes (fichiers, base de données relationnelles, ...) issues de l’entreprise ou de sources externes. L’uniformisation de ces données est une part importante dans la construction du datawarehouse. Historisées Un référentiel temps est systématiquement mis en place pour les données. La mise à jours des données n’existe pas, mais il y aura un stockage de l’historique des valeurs des données. 24 CHAPITRE 8. ARCHITECTURE D’UN ENTREPÔT DE DONNÉES Figure 8.1 – Architecture d’un datawarehouse Non Volatiles En conséquence de l’historisation des données, une requête effectuée à deux instants différents mais portant sur la même période devra toujours donner le même résultat. 8.2 Datamart 8.2.1 Définition Le DataMart est issu d’un flux de données provenant du DataWarehouse. Contrairement à ce dernier qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée fonctionnellement. (Bill Inmon) Le DataMart est un sous-ensemble du DataWarehouse, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise constitue le DataWarehouse. (Ralph Kimball) 8.2.2 Caractéristiques Un datamart est orienté vers un sujet unique, et contient des données fortement agrégées pour lesquelles le datawarehouse joue le rôle d’historique. Il est organisé de façon multidimensionnel dont une est généralement le temps. 25 Chapitre 9 Conception d’un entrepôt de données Un entrepôt de données ne s’achète pas, il se construit. (Bill Inmon) 9.1 9.1.1 Modélisation Représentation multidimensionnelle Un datawarehouse est basé sur une modélisation multidimensionnelle qui représente les données dans un cube à plusieurs dimensions. Dimension ...). Une dimension est un attribut ou un ensemble d’attribut (temps, localisation, produit, client, Granularité Une dimension possède une granularité qui correspond au niveau de détail de la dimension. Par exemple : Dimension Temps Années/Trimestre/Mois/Jours Dimension Géographique Pays/Région/Province/Ville Fait Les cellules du cube contiennent des valeurs agrégées appelées faits (chiffre d’affaire, Coût, nombre d’unité, ...) Figure 9.1 – Représentation Multidimensionnelle des données 9.1.2 Phases de réalisations La construction d’un Datawarehouse doit suivre trois étapes dépendantes les une des autres. L’étude préalable doit permettre — de définir les objectifs et le contenu du datawarehouse en fonction des besoins des décideurs 26 CHAPITRE 9. CONCEPTION D’UN ENTREPÔT DE DONNÉES — d’établir la liste des données nécessaire pour alimenter le datawarehouse : Dans les bases de production Dans des sources externes à identifier Cette étude préalable permettra d’établir la liste des dimensions (et de leur granularité) ainsi que les faits qui devront être exposé dans le datawarehouse. Modélisation conceptuelle La modélisation d’un datawarehouse est basé sur une modélisation conceptuelle permettant de représenter les cubes. On distinguera dans le modèle obtenu deux types de tables : Tables de dimensions Chaque dimension répertoriée lors de l’étude préalable produit une table appelée table de dimension dans le modèle conceptuel Table de Fait A chaque cube est associé une table de faits qui contient les mesures, et les clés de chacune des dimensions associée au cube. Il existe deux modélisation courante permettant d’effectuer une telle modélisation. Modèle en Étoiles Chaque cube est associé à une table de faits dont la clé est composée de toutes les clés des tables de dimensions qui lui sont associées. Les autres champs de la table de fait sont les mesures du cube. Dans les tables de dimensions, on retrouve la clé de la dimension, des informations complémentaire et un champ par niveau de la dimension (notion de granularité). Figure 9.2 – Modèle en étoiles Modèle en Flocons Le modèle flocon est un dérivé du modèle étoile qui normalise les tables de dimensions suivant leur granularité. Dans un modèle flocon, les différents niveaux de la dimension seront normalisé dans des tables. Figure 9.3 – Modèle en flocons 27 9.1. MODÉLISATION alimentation L’alimentation est l’opération permettant de transférer les données depuis le système opérationnel vers le datawarehouse. Typiquement cette opération est appelée ETL (Extract Transform Loading) et doit donc se charger de trois opérations distinctes. Extraction L’extraction des données consiste à extraire les données depuis les différentes sources, de façon périodique, sans perturber les systèmes de production, et en effectuant un marquage des données transférées. Transformation La transformation consiste à homogénéiser les données des différentes sources (nom des attributs, types de données, ...), et à nettoyer ces données (données manquantes, valeur incohérentes, ...). Chargement Une fois nettoyées et uniformisées, les données peuvent être copiées vers les différentes tables du datawarehouse. L’alimentation des données est sans doute la phase la plus complexe du datawarehouse car elle nécessite beaucoup de manipulation. Plusieurs logiciels d’ETL existent pour faciliter cette tâche. 28