Le concept de Data Warehouse a été formalisé pour la première fois en 1990.

Transcription

1 1 - LE DATA WAREHOUSE PRESENTATION Le concept de Data Warehouse a été formalisé pour la première fois en L idée de constituer une base de données orientée sujet, intégrée, contenant des informations datées, non volatiles et exclusivement destinées aux processus d aide à la décision fut dans un premier temps accueillie avec une certaine perplexité. Beaucoup n y voyaient que l'habillage d un concept déjà ancien : l infocentre. Mais l économie actuelle en a décidé autrement. Les entreprises sont confrontées à une concurrence de plus en plus forte, des clients de plus en plus exigeants, dans un contexte organisationnel de plus en plus complexe et mouvant. Pour faire face aux nouveaux enjeux économiques, l entreprise doit anticiper. L anticipation ne peut être efficace qu en s appuyant sur de l information pertinente. Cette information est à la portée de toute entreprise qui dispose d un capital de données gérées par ses systèmes opérationnels et qui peut en acquérir d autres auprès de fournisseurs externes. Mais actuellement, les données sont surabondantes, non organisées dans une perspective décisionnelle et éparpillées dans de multiples systèmes hétérogènes. Pourtant, les données représentent une mine d informations. Il devient fondamental de rassembler et d homogénéiser les données afin de permettre d analyser les indicateurs pertinents pour faciliter les prises de décisions. Pour répondre à ces besoins, le nouveau rôle de l informatique est de définir et d intégrer une architecture qui serve de fondation aux applications décisionnelles : le Data Warehouse. Le nouveau rôle de l informatique est de définir et d intégrer une architecture qui serve de fondation aux applications décisionnelles : le Data Warehouse.

2

3 1.2 - POURQUOI UN DATA WAREHOUSE LA PROBLEMATIQUE DES ENTREPRISES L entreprise construit un système décisionnel pour améliorer sa performance. Elle doit décider et anticiper en fonction de l information disponible et capitaliser sur ses expériences. Depuis plusieurs dizaines d années, une importante masse d informations est stockée sous forme informatique dans les entreprises. Les systèmes d information sont destinés à garder la trace d événements de manière fiable et intègre. Ils automatisent de plus en plus les processus opérationnels. Parallèlement, les entreprises réalisent la valeur du capital d information dont elles disposent. Au delà de ce que l informatique leur apporte en terme fonctionnel, elles prennent conscience de ce qu elle pourrait apporter en terme de contenu informationnel. Considérer le système d information sous cet angle en tant que levier pour accroître leur compétitivité et leur réactivité n est pas nouveau. Par contre, étant donné l environnement concurrentiel actuel, cela devient une question de survie. L informatique a un rôle à jouer, en permettant à l entreprise de devenir plus entreprenante et d avoir une meilleur connaissance de ses clients, de sa compétitivité ou de son environnement. Il est intéressant de calculer les retours sur investissement rendus publics. Ils se calculent rarement en terme de baisse de coûts, mais en terme de gains. Par exemple, ils permettent un meilleur suivi des ventes, une meilleure compréhension des habitudes d achats des clients, d une adaptation des produits à une clientèle mieux ciblée. A ce titre, le Data Warehouse doit être rapproché de tous les concepts visant à établir une synergie entre le système d information et sa stratégie.

4 LA REALITE DES SYSTEMES D INFORMATIONS A première vue, les systèmes opérationnels seraient des mines d or informationnelles. En fait, il n en est rien. Les données contenues dans ces systèmes sont : Eparpillées : il existe souvent de multiples systèmes, conçus pour être efficace pour les fonctions sur lesquelles ils sont spécialisés. Peu structurées pour l analyse : la plupart des systèmes informatiques actuels ont pour objet de conserver en mémoire l information, et sont structurés dans ce but. Focalisées pour améliorer le quotidien : toutes les améliorations technologiques se sont focalisées pour améliorer cette capacité en terme de volume, qualité, rapidité d accès. Il manque très souvent la capacité à nous donner les moyens de tirer parti de cette mémoire pour prendre des décisions. Utilisées pour des fonctions critiques : la majorité des systèmes existants est conçue dans le but unique de nous servir avec des temps de réponse corrects. Le Tableau 1 présente les différences entre les données opérationnelles et décisionnelles. Données opérationnelles Orientées application, détaillées, précises au moment de l accès Mise à jour interactive possible de la part des utilisateurs Accédées de façon unitaires par une personne à la fois Cohérence atomique Haute disponibilité en continu Données décisionnelles Orientée activité (thème, sujet), condensées, représentes des données historiques Pas de mise à jour interactive de la part des utilisateurs Utilisées par l ensemble des analystes, gérées par sous-ensemble Cohérence globale Exigence différente, haute disponibilité ponctuelle Peuvent être redondantes Structure flexible Uniques (pas de redondance en théorie) Structure statique, contenu variable Petite quantité de données utilisées par un Grande quantité de données utilisée par

5 traitement les traitements Réalisation des opérations au jour le jour Cycle de vie différent Forte probabilité d accès Faible probabilité d accès Utilisées de façon répétitive Utilisée de façon aléatoire Tableau 1 : différences entre données du système de production et données décisionnelles

6 S il existe effectivement des informations importantes, il n en est pas moins nécessaire de construire une structure pour les héberger, les organiser et les restituer à des fins d analyse. Cette structure est le Data Warehouse ou entrepôt de données. Ce n est pas une usine à produire l information, mais plutôt un moyen de la mettre à disposition des utilisateurs de manière efficace et organisée. La mise en œuvre du Data Warehouse est un processus complexe. L objectif à atteindre est de recomposer les données disponibles pour en donner : une vision intégrée et transversale aux différentes fonctions de l entreprise, une vision métier au travers de différents axes d analyse, une vision agrégée ou détaillée suivant le besoin des utilisateurs. Le Data Warehouse permet la mise en place d un outil décisionnel s appuyant sur les informations pertinentes pour l entreprise, centrées sur le métier utilisateur LES OBJECTIFS Toutes les données qu elles proviennent du système de production de l entreprise ou qu elles soient achetées vont devoir être organisées, coordonnées, intégrées et stockées, pour donner à l utilisateur une vue intégrée et orientée métier. Systèmes externes Systèmes hétérogènes de production IBM BULL EXTRACTION PREPARATION CHARGEMENT HP STOCKAGE ACCES, VISUALISATION IDENTIFIER POINT FOCAL

7 Tableau 2 : le data warehouse, point focal de l'informatique décisionnelle Source : EDS-Prométhéus Cette figure illustre l objectif d un Data Warehouse, sorte de point focal stockant en un endroit unique toute l information utile provenant des systèmes de production et des sources externes. Avant d être chargée dans le Data Warehouse, l information doit être extraite, nettoyée et préparée. Puis, elle est intégrée et mise en forme de manière compréhensible par être comprise par l utilisateur DEFINITION De nombreuses définitions ont été proposées, soit académiques, soit par des éditeurs d outils, de bases de données ou par des constructeurs, cherchant à orienter ces définitions dans un sens mettant en valeur leur produit. La définition la plus appropriée est : Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d un processus d aide à la décision. Orientées sujet Le Data Warehouse est organisé autour des sujets majeurs de l entreprise, contrairement aux données des systèmes de production. Ceux-ci sont généralement organisés par processus fonctionnels. Les données sont structurées par thème. L intérêt de cette organisation est de disposer de l ensemble des informations utiles sur un sujet le plus souvent transversal aux structures fonctionnelles et organisationnelles de l entreprise. Cette orientation sujet va également permettre de développer son système décisionnel via une approche par itérations successives, sujet après sujet.

8 L intégration dans une structure unique est indispensable car les informations communes à plusieurs sujets ne doivent pas être dupliquées. Dans la pratique, une structure supplémentaire appelée Data Mart (magasin de données) peut être créée pour supporter l orientation sujet.

9 Données intégrées Un Data Warehouse est un projet d entreprise. Par exemple dans la distribution, le même indicateur de chiffre d affaires intéressera autant les forces de vente que le département financier ou les acheteurs. Pour y parvenir, les données doivent êtres intégrées. Avant d être intégrées dans le Data Warehouse, les données doivent êtres mises en forme et unifiées afin d avoir un état cohérent. Par exemple, la consolidation de l ensemble des informations concernant un client donné est nécessaire pour donner une vue homogène de ce client. Une donnée doit avoir une description et un codage unique. Cette phase d intégration est très complexe et représente 60 à 90 % de la charge totale d un projet. Données historisées Dans un système de production ; la donnée est mise à jour à chaque nouvelle transaction. Dans un Data Warehouse, la donnée ne doit jamais être mise à jour. Un référentiel temps doit être associé à la donnée afin d être capable d identifier une valeur particulière dans le temps. Données non volatiles La non volatilité des données est en quelque sorte une conséquence de l historisation. Une même requête effectuée à quelques mois d intervalle en précisant la date de référence de l information recherchée donnera le même résultat. Le Tableau 3 ci-après présente les principales différences entre le système de production et le data warehouse : Critère Système de production Data Warehouse Niveau de détail des Très détaillé Synthétique, parfois détaillé informations utilisateurs Utilisateurs Une ou quelques fonctions de l entreprise Plusieurs fonctions de l entreprise Données figées Non évolution en temps réel Oui archivage Historique Non Oui Opérations sur les données Ajout/mise à jour/ consultation Consultation uniquement

10 Tableau 3 : différences entre système de production et data warehouse LES CONCEPTS DE BASE LA STRUCTURE Un Data Warehouse se structure en quatre classes de données, organisées selon un axe historique et un axe synthétique. Données fortement agrégées Données agrégées Niveau de synthèse Méta Données Données détaillées Données détaillées historisées Niveau d'historique Tableau 4 : structure d'un data warehouse Source : EDS-Prométhéus Les données détaillées Elles reflètent les événements les plus récents. Les intégrations régulières des données issues des systèmes de production vont habituellement être réalisées à ce niveau. Les volumes à traiter sont plus importants que ceux gérés en transactionnel.

11 Attention : le niveau de détail géré dans le Data Warehouse n est pas forcément identique au niveau de détail géré dans les systèmes opérationnels. La donnée insérée dans le Data Warehouse peut être déjà une agrégation ou une simplification d informations tirées du système de production. Exemple : l étude du panier de la ménagère nécessite de stocker le niveau de finesse du ticket de caisse.

12 Les données agrégées Elles correspondent à des éléments d analyse représentatifs des besoins utilisateurs. Elles constituent déjà un résultat d analyse et une synthèse de l information contenue dans le système décisionnel, et doivent être facilement accessibles et compréhensibles. La facilité d accès est apportée par des structures multidimensionnelles qui permettent aux utilisateurs de naviguer dans les données suivant une logique intuitive, avec des performances optimales. (Certains SGBD du marché sont conçus pour faciliter la mise en place des agrégations et la navigation au sein de celles-ci). La définition complète de l information doit être mise à la disposition de l utilisateur pour une bonne compréhension. Dans le cas d un agrégat, l information est composée du contenu présenté (moyenne de s ventes, ) et de l unité (par mois, par produit, ). Les méta-données Elles regroupent l ensemble des informations concernant le Data Warehouse et les processus associés. Elles constituent une véritable aide en ligne permettant de connaître l information contenue dans le Data Warehouse. Elles sont idéalement intégrées dans un référentiel. Les principales informations sont destinées : A l utilisateur (sémantique, localisation). Aux équipes responsables des processus de transformation des données du système de production vers le Data Warehouse (localisation dans les systèmes de production, description des règles, processus de transformation). Aux équipes responsables des processus de création des données agrégées à partie des données détaillées. Aux équipes d administration de la base de données ( structure de la base implémentant le Data Warehouse). Aux équipes de production (procédures de changement, historique de mise à jour, )

13 Les données historisées Un des objectifs du Data Warehouse est de conserver en ligne les données historisées. Chaque nouvelle insertion de données provenant du système de production ne détruit pas les anciennes valeurs, mais créee un nouvelle occurrence de la donnée. Le support de stockage dépend du volume des données, de la fréquence d accès, du type d accès. Les supports les plus couramment utilisés sont les disques, les disques optiques numérique, les cassettes. La logique d accès aux données la plus utilisée est la suivante : les utilisateurs commencent à attaquer les données par le niveau le plus agrégé, puis approfondissent leur recherche vers les données les plus détaillées (Drill Drown). L accès des données se fait également directement par les données détaillées et historisées, ce qui conduit à des brassages de données lourds, demandant des machines très puissantes. Le Data Warehouse est une réussite dans une entreprise lorsque le nombre d utilisateur accédant aux données de détail augmente LES ARCHITECTURES Pour implémenter un Data Warehouse, trois types d architectures sont possibles : L architecture réelle, L architecture virtuelle, L architecture remote L ARCHITECTURE REELLE Elle est généralement retenue pour les systèmes décisionnels. Le stockage des données est réalisé dans un SGBD séparé du système de production. Le SGBD est alimenté par des extractions périodiques. Avant le chargement, les données subissent d importants processus d intégration, de nettoyage, de transformation.

14 L avantage est de disposer de données préparées pour les besoins de la décision et répondant aux objectifs du Data Warehouse. Les inconvénients sont le coût de stockage supplémentaire et le manque d accès en temps réel L ARCHITECTURE VIRTUELLE Cette architecture n est pratiquement pas utilisée pour le Data Warehouse. Les données résident dans le système de production. Elles sont rendues visibles par des produits middleware ou par des passerelles. Il en résulte deux avantages : pas de coût de stockage supplémentaire et l accès se fait en temps réel. L inconvénient est que les données ne sont pas préparées L ARCHITECTURE REMOTE C est une combinaison de l architecture réelle et de l architecture virtuelle. Elle est rarement utilisée. L objectif est d implémenter physiquement les niveaux agrégés afin d en faciliter l accès et de garder le niveau de détail dans le système de production en y donnant l accès par le biais de middleware ou de passerelle SYNTHESE Les différents éléments d'appréciation sont repris dans le tableau récapitulatif cidessous : Utilisation Stockage Avantages Architecture réelle Retenue pour les systèmes décisionnels SGBD séparé du système de production, alimenté par des extractions périodiques Données préparées pour les besoins de la Architecture virtuelle Rarement utilisée Données résidant dans le système de production Pas de coût de stockage Architecture remote Rarement utilisée Combinaison des architectures réelle et virtuelle

15 Inconvénients décision Coût de stockage supplémentaire, manque d accès temps réel supplémentaire, accès en temps réel Données non préparées Tableau 5 : tableau de synthèse des architectures de data warehouse

16 INFOCENTRE ET DATA WAREHOUSE Certaines caractéristiques sont identiques. Mais il existe de nombreux éléments permettant de différencier les deux notions. L infocentre est une collection de données orientées sujet, intégrées, volatiles, actuelles, organisées pour le support d un processus de décision ponctuel. Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées, organisées pour le support d un processus d aide à la décision. Dans un infocentre, chaque nouvelle valeur remplace l ancienne valeur. Il est donc impossible de retrouver une valeur calculée dans une session préalable aux dernières alimentations. La non volatilité est une caractéristique essentielle du Data Warehouse. De même, l historisation des données dans un infocentre, il n y a pas de gestion d historique des valeurs. L infocentre sert à prendre des décisions opérationnelles basées sur des valeurs courantes. Au niveau d un Data Warehouse, l utilisateur travaille sur les historiques pour des prises de décisions à long terme, des positionnements stratégiques et pour analyser des tendances. Dans un infocentre, l intégration des données est plus ou moins poussée. Le processus d alimentation est simple. Le finalité d un infocentre est de permettre aux utilisateurs d accéder à leur données dans leurs propres termes.

17 Infocentre Collection de données Orientées sujet Intégrées Volatiles Actuelles Organisées pour le support d un processus de décision ponctuelle Outil Data Warehouse Collection de données Orientées sujet Intégrées Non volatiles Historisées Organisées pour le support d un processus d aide à la décision Architecture Tableau 6 : tableau de comparaison entre infocentre et Data Warehouse La mise en évidence des différences est exprimée par les questions suivantes : Quels infocentres sont motivés par des objectifs business et sont au service de la stratégie de l entreprise? Quels infocentres permettent de connaître la concurrence, d anticiper les besoins? Quelles entreprises mesurent le retour sur investissement? L infocentre est un outil alors que le Data Warehouse est une architecture.

18 2 - LA CONSTRUCTION DU DATA WAREHOUSE L objectif à atteindre est de recomposer les données disponibles pour en obtenir une vision intégrée et transversale aux différentes fonctions de l entreprise, une vision métier au travers des différents axes d analyse et une vision agrégée ou détaillée, adaptée à son besoin. La transformation des données en connaissance est un processus complexe. Application N Application 3 Application 2 Application 1 ACQUISITION STOCKAGE ACCES IDENTIFIER Infrastructure opérationnelle Infrastructure technique Tableau 7 : cadre général d un Data Warehouse Source : EDS-Prométhéus Le cadre général d un Data Warehouse comporte trois domaines principaux : les applications, les composants fonctionnels du Data Warehouse (acquisition, stockage, accès),

19 les infrastructures (technique et opérationnelle).

20 2.1 - LES APPLICATIONS Un Data Warehouse se fait en plusieurs itérations. Chaque sujet traité est décomposé en un ensemble d initiatives (projet décisionnel entrant en jeu dans la construction d un Data Warehouse dans une démarche itérative). Les applications doivent rester maîtrisables et fournir des résultats tangibles dans un délai de moins de six mois, qui correspond au délai moyen de réalisation d applications. Le périmètre de chaque application doit être clairement défini (acteurs concernés, fréquences et périodicité des analyses,...) LES COMPOSANTS FONCTIONNELS Trois composants caractérisent un Data Warehouse : l acquisition, le stockage, l accès L ACQUISITION Elle se compose de trois phases : l extraction, la préparation et le chargement. L extraction : collecter les données utiles dans le système de production. La préparation : plusieurs technologies sont utilisables : les passerelles, fournies par les éditeurs de base de données, les utilitaires de réplication, utilisables si les systèmes de production et décisionnel sont homogènes, les outils spécifiques d extraction (prix élevé). La préparation inclus la mise en correspondance des formats de données, le nettoyage, la transformation et l agrégation.

21 Le chargement : il constitue la dernière phase d alimentation. Il est indispensable de maîtriser la structure du SGBD (tables et index) pour optimiser au mieux le processus.

22 LE STOCKAGE Le composant de base est le SGBD. Il doit être spécifiquement adapté aux caractéristiques de l accès décisionnel. Du fait de l importance de l historique, la structuration physique des données est également très importante. Le SGBD apporte la transparence à l évolution matérielle, l indépendance, que ce soit au niveau des types et du nombre de processeurs, des disques ou des mémoires, ainsi que la transparence à l évolution des systèmes d exploitation L ACCES Définir une architecture globale servant de support aux accès décisionnels impose des choix technologiques non structurants. Il faudra mettre en place une infrastructure commune à toutes les applications décisionnelles, tout en laissant aux utilisateurs l opportunité d utiliser les solutions d accès les mieux adaptées à leur problématique. (Les outils du marché sont les requêteurs, les outils d analyse multidimensionnelle, les EIS, le Data Mining, Les SIG). Interroger Requêtes ad-hoc (QUERY) Piloter EIS Agent intégré aux outils Analyser, Naviguer Les bases OLAP Les outils ROLAP POINTS DE VUES Analyse "simple" (opérationnels) Entrepôt de données "Data mining" (équipe R&D) Visualisation avancée Outils de visualisation avancés Système d'information géographique Segmenter, corrèler Arbres de décision, Découverte de règles, Statistiques... Simuler, prédire, extrapoler Statistiques Réseaux de neurones... Tableau 8 : data warehouse - points de vue pour les utilisateurs Source : EDS-Prométhéus

23 2.3 - LES INFRASTRUCTURES Il y a deux niveaux d infrastructures : l infrastructure technique : l ensemble des composants matériels et logiciels ( à associer aux composants fonctionnels : alimentation, stockage et accès). l infrastructure opérationnelle : l ensemble des procédures et des services pour administrer les données, gérer les utilisateurs et exploiter le système. Pour la construction d un Data Warehouse, de manière générale, il faut : 1. Bien connaître les métiers utilisateurs Impliquer les utilisateurs dans les projets, Faire participer l utilisateur à la définition et à l évolution des métadonnées, Former l utilisateur pour l aider à comprendre la logique du Data Warehouse, Avoir un chef de projet orienté utilisateur. 2. Assurer une véritable conduite de projet Le chef de projet fédère l ensemble des besoins. Il organise et planifie les différentes phases de déploiement en fonction de la culture de l entreprise. (La principale source d échec serait humaine et non technique). Seules les entreprises expérimentées peuvent faire l économie d un prototype. 3. Commencer petit et voir grand Il faut commencer petit, qu il s agisse d un prototype ou d un Data Mart.

24 4. Gérer l évolutivité alimentation et administration. Ce sont les points critiques du processus de construction du Data Warehouse.

25 3 - LA CONCEPTION DU DATA WAREHOUSE Quatre caractéristiques ont des effets déterminants sur la démarche de conception d un Data Warehouse : Les évolutions technologiques : un système d information peut se construire par intégration d un certain nombre de composants, chacun pouvant être choisi par rapport à son contexte d utilisation. L entreprise défini son architecture en fonction de ses besoins. La stratégie de l entreprise : le Data Warehouse est très proche de la stratégie de l entreprise. L objectif du Data Warehouse se définit en terme métier. Il faut donc impliquer les utilisateurs ayant le plus de connaissances dans leur entreprise ou dans leur métier. L amélioration continue : un Data Warehouse doit évoluer en fonction des demandes utilisateurs ou des nouveaux objectifs de l entreprise. La maturité de l entreprise : certaines entreprises ont déjà un système décisionnel. D autres n ont aucun acquis. Dans tous les cas, il n existe pas de cadre figé pour la conception d un Data Warehouse. Chaque entreprise doit adapter le projet à son contexte, en ne perdant pas les objectifs de vue. Cet objectif est de mettre en place un système d information cohérent et intégré, le système devant être décomposer en applications, chacune s intégrant dans le Data Warehouse. Il est possible de proposer trois phases pour la conception : Définir le pourquoi du Data Warehouse et les objectifs à atteindre (impliquer les utilisateurs). Définir l infrastructure technique et organisationnelle du Data Warehouse. Mettre en œuvre les applications.

26 3.1 - DECOUVRIR ET DEFINIR LES INITIATIVES Cette phase consiste en l étude stratégique du Data Warehouse et la définition du plan d action L ETUDE STRATEGIQUE Pendant l étude stratégique, il faut : Informer et motiver les personnes concernées dans l entreprise. Impliquer les managers, les équipes opérationnelles, les équipes informatiques : phase d identification et de compréhension des enjeux métier/entreprise. Identifier les projets Data Warehouse. L étude stratégique permet d identifier la stratégie de l entreprise, son organisation, les processus qu elle met en œuvre, la culture de l entreprise. Le but est de déterminer les domaines pour lesquels la mise en place d un Data Warehouse peut être le plus bénéfique. A la fin de cette étude, des sous-projets ou initiatives vont être dégagés. Les acteurs consultés doivent être des spécialistes métiers, convaincus de la nécessité et de l importance du Data Warehouse LE PLAN D ACTION Pour mettre en place le plan d action, il faut : Vérifier la faisabilité de chaque projet (s assurer de l existence et de la qualité des données, des possibilités techniques, des possibilités organisationnelles). Estimer les ressources pour chaque projet, les besoins. Séquencer et planifier les projets. Il est possible de commencer petit et voir grand : limiter l objectif à un domaine précis (Data Mart) ou faire un prototype. Ceci permet d avoir un retour sur investissement rapide et de prouver le bien fonder du concept.

27 Il faut déterminer la faisabilité de chaque projet envisagé et déterminer les moyens nécessaires (techniques, humains, organisationnels) à leur réalisation. Leur coût et leur durée de mise en œuvre sera estimé, ainsi que les bénéfices attendus et leur terme. Les projets envisagés (initiatives) doivent avoir une mise en œuvre courte ( environ six mois) et doivent être bien délimités. Il faut aussi évaluer le capital informatique, c est-à-dire analyser les systèmes de production sur lesquels le Date Warehouse doit s appuyer, ce qui ne peut pas être fait sans voir l évaluation des initiatives. Plusieurs décisions sont à prendre en ce qui concerne les données dont a besoin l entreprise : Si les données existent dans les systèmes de production, les initiatives sont envisageables. Si les données n existent pas dans l entreprise, ni à l extérieur (ach at de fichiers), il faut revoir ou abandonner les initiatives. Si les données n existent pas dans l entreprise, ni à l extérieur, mais sont stratégiques pour l entreprise, il faut reporter. Si les données existent à l extérieur, il faut prendre la décision d achat. Les estimations ne doivent pas être détaillées et doivent concerner le plus grand nombre possible d initiatives. Ce sera sur cette base que la politique technologique du Data Warehouse sera déterminée L INFRASTRUCTURE Il s agit de déterminer l infrastructure technologique et organisationnelle nécessaire à la mise en place du Data Warehouse et à la conduite du changement L INFRASTRUCTURE TECHNIQUE Des choix technologiques en phase avec la politique de l entreprise doivent être faits à plusieurs niveaux :

28 Les fournisseurs : faut-il prendre un seul fournisseur (ce qui facilite la politique d intégration et en réduit les coûts de mise en œuvre) ou assembler les meilleurs offres du marché (ce qui apporte une flexibilité, une adaptation à chaque projet, mais coûte beaucoup en intégration). Les outils : faut-il construire, acheter ou faire avec l existant. Comment sera utilisé le Data Warehouse, par qui, comment sera structuré l organisation qui l exploitera. Faut-il une architecture centralisé (Data Warehouse), distribuée (plusieurs Data Mart), ou une architecture répliquée (un Data Warehouse et plusieurs Data Mart). La structure de stockage, sera-t-elle relationnelle, multidimensionnelle, hybride (Data Warehouse en relationnel, Data Mart en multidimensionnel). Choisir le matériel : selon les volumes envisagés, les utilisateurs concernés, l architecture visée, la flexibilité attendue. Organiser l administration des systèmes et la gestion de la sécurité. Il faut vérifier que les solutions choisies fonctionnent entre elles. (Ne pas se fier aux plaquettes commerciales en ce qui concerne la portabilité) L INFRASTRUCTURE ORGANISATIONNELLE Parallèlement aux choix technologiques, il faut : Déterminer la logistique et l organisation nécessaires à la concrétisation des initiatives. Répartir les tâches entre les équipes de développement et les équipes d exploitation : déterminer l alimentation du Data Warehouse, l administration. Déterminer les flux d information entre le Data Warehouse et les utilisateurs LA FORMATION Selon l expérience de l entreprise en matière de décisionnel et des technologies utilisées, un plan de formation sera nécessaire.

29 Il sera impératif que les membres participants au projet soient favorables au changement LA MISE EN ŒUVRE DES APPLICATIONS La mise en œuvre est réalisée pour chaque initiative. La démarche proposée est une démarche en cinq étapes : la spécification, la conception, la mise en œuvre et l intégration, le déploiement et la mise en place des accompagnements, les mesures. Ces étapes correspondent à celles de mise en place d un projet informatique. Pendant l étape de spécification, les différentes étapes des initiatives sont définies et planifiées de manière plus détaillées. Il est recommandé de faire attention aux coûts cachés que peuvent entraîner les technologies informatiques. L étape de mesure permet de faire le bilan de la réalisation et de capitaliser les réussites et échecs rencontrés pendant le développement de l application. Deux visions du Data Warehouse cohabitent dans l approche précédente : Une vision entreprise : chaque projet défini dans la première phase (initiative) est construit de manière indépendante et répond à un objectif métier délimité, tout en s intégrant dans le Data Warehouse. Une vision projet : les projets identifiés deviennent des applications. Donc le processus est itératif. Il n existe pas de démarche complète et universelle pour la mise en œuvre d un data Warehouse. Toute approche doit être adaptée à l entreprise.

30 4 - L ADMINISTRATION DES DONNEES Comme tout autre système informatique, un Data Warehouse s administre. Dès la phase de conception de l architecture, il faut penser à l administration des données : c est une des fonctions les plus importantes du Data Warehouse. Cette fonction est d autant plus importante que le Data Warehouse évolue au fur et à mesure de son utilisation. La mise en place d un Data Warehouse doit s accompagner de celle d un référentiel de données, permettant de décrire, stocker et diffuser les méta-données associées. Cette mise en place passe par l organisation d une fonction d administration des données à plusieurs niveaux, par la définition de normes et de procédure d administration des référentiels LES METADONNEES Elles représentent toutes les informations nécessaires à l accès, à la compréhension et à l exploitation des données du Data Warehouse. Type d information Sémantique Origine Règle de calcul Règle d agrégation Stockage, format Utilisation Signification Que signifie la donnée D où vient-elle, où, par qui est-elle créée ou mise à jour Règle de calcul, de gestion Périmètre de consolidation Où, comment est-elle stockée, sous quel format Programmes informatiques qui l utilisent, Machines : comment et sur lesquelles, à disposition, Temps de conservation Tableau 9 : définition d une méta-donnée

31 La donnée est forcément liée à d autres objets du système d information. Il est donc nécessaire de représenter, décrire et stocker les interactions avec d autres données. Types de lien Domaines, sujets Structure organisationnelle, structure géographique Concepts génériques Applications, programmes Tables, colonnes Sites, machines Signification Chaque donnée va être indexée par sujet ou domaine Une donnée peut avoir des sens légèrement différents selon la personne qui la manipule Exemple : notion de produit se déclinant en lignes de produits, services,... Donnée manipulée par une ou plusieurs applications ou programmes Donnée située dans une ou plusieurs colonnes, tables et bases de données Localisation physique de la donnée Tableau 10 : interactions des données Généralement, pour représenter les méta-données, on utilise un symbolisme courant en informatique. Par exemple les modèles de données MERISE : modèle conceptuel de données et modèle logique de données LE REFERENTIEL DU DATA WAREHOUSE Le référentiel du Data Warehouse est l ensemble des outils nécessaires à la mise en œuvre de la fonction d administration de données. Les objectifs de l administration de données du Data Warehouse sont : Assurer la cohésion du système : Respecter la cohérence et la fiabilité des informations. Unifier la représentation des données. Respecter la cohérence des concepts. Vérifier la non redondance des informations.

32 Simplifier techniquement les systèmes d information : Diminuer le nombre de fichiers. Unifier la saisie et le stockage des informations. Organiser les mises à jour et la diffusion des informations. Un référentiel de données pour le Data Warehouse est un référentiel de données dans lequel sont décrits l organisation et la localisation des données, ainsi que les règles de consolidation des données agrégées et historisées. Il est conçu de manière à collecter l ensemble des modèles de données nécessaires à la construction et à l exploitation du Data Warehouse. La construction du référentiel est un projet qu il est nécessaire de prévoir en parallèle à celui du data Warehouse LA MISE EN ŒUVRE Il n existe pas une seule manière de le faire. La problématique doit être considérée sous deux aspects : organisationnel et technique. Acheter une solution clé en main est très risquée : les fonctionnalités de l outil conditionnent alors l organisation du projet. Quelque soit l outil choisi, il faut pouvoir le faire évoluer afin de s adapter à de nouveaux besoins SECURITE Le Data Warehouse a pour vocation de laisser à l utilisateur une totale autonomie en ce qui concerne la recherche et l analyse des données. Cette liberté doit cependant être souvent restreinte, notamment pour des raisons de sécurité. L outil doit donc permettre d adapter l environnement de travail à l utilisateur qui s y connecte selon sa fonction et donc ses droits. Afin de mener à bien cette politique de sécurité, les notions d utilisateur et de groupe d utilisateur sont indispensables. Cette notion doit néanmoins être dissociée de la notion d utilisateur du serveur de données. Il est en effet préférable que l utilisateur se connecte directement à l outil d aide à la décision et accède de manière transparente au serveur de données sans en connaître le nom d utilisateur et le mot de passe. Il n y a ainsi pas de risque que l utilisateur se connecte au serveur par d autres biais. Ce risque est d autant plus important que l utilisateur

33 trouve le plus souvent sur son poste de travail les moyens de se connecter à un serveur de données. Il peut par exemple se connecter à partir d Excel à un serveur de données, via le driver ODBC. Plus les autorisations pourront être définies à un niveau fin, plus l environnement de travail pourra être facilement adapté à chacun des profils d utilisateur. Au delà du catalogue dans sa globalité, l outil doit donc permettre de définir des droits sur chacun de ses éléments en restreignant le nombre de tables ou de colonnes disponibles ou, par un critère de recherche, le nombre de lignes accessibles. Au delà des droits concernant l accès aux données, la possibilité d affecter des privilèges sur les requêtes et rapports prédéfinis est un facteur essentiel dans la définition d une stratégie de diffusion GESTION DES PERFORMANCES La possibilité de limiter les accès aux ressources permet à l administrateur de mieux contrôler les requêtes émises par l utilisateur. Ce besoin est surtout essentiel pour les outils d infocentre, qui peuvent offrir à l utilisateur un espace de liberté et d autonomie important. En effet contrairement aux outils basés sur un modèle multidimensionnel, les utilisateurs accèdent aux informations non selon un schéma prédéfini mais selon leurs besoins. Ils génèrent ainsi les requêtes qu ils veulent et n accèdent pas toujours à un serveur optimisé en conséquence. Ce contrôle des ressources peut prendre plusieurs formes : limitation du temps d exécution ; cette fonctionnalité ne sera néanmoins pas géré de manière optimale par l outil qui, à moins d avoir déjà effectué une requête identique, n a pas moyen de connaître à priori le temps qu elle prendra. Certains serveurs (Ingres et Oracle notamment) offrent cette fonctionnalité. L idéal est donc d avoir un outil capable de demander au serveur le temps que va mettre une requête et d agir ensuite en conséquence (par exemple, refuser la demande selon l utilisateur). Sinon, l outil peut permettre l abandon de requêtes trop longues. limitation du nombre de lignes récupérées ; l outil peut soit permettre de ramener les lignes par paquets, soit ne rapatrier qu un certain nombre d enregistrements, soit abandonner une requête ramenant un volume trop important de données. L outil, en cas de dépassement des limites, peut soit prévenir l utilisateur et lui demander si il souhaite continuer, soit abandonner la demande.

34 Le contrôle du corps des requêtes permet de limiter considérablement le nombre de demandes coûteuses. Ce contrôle peut s exercer sur différents paramètres : le nombre de tables interrogées ; les jointures, l administrateur peut notamment interdire tout produit cartésien. Il peut de plus être intéressant d imposer d utiliser que les colonnes indexées ou d interdire un nombre trop important de théta-jointures,... Ce besoin de contrôler les performances est dû à l autonomie laissée aux utilisateurs par les outils d infocentre. En effet, l administrateur n a que très peu de maîtrise sur ce que vont faire les utilisateurs et le modèle de données ne peut être dès le départ optimisé pour un type d utilisation particulier. Des fonctions d audit permettent de remédier à cela en donnant à l utilisateur une vision des demandes les plus et les moins fréquemment utilisées. Il peut alors paramétrer et optimiser son environnement (serveur, client) en conséquence. L outil doit donc offrir la possibilité de journaliser le texte des requêtes, leur durée d exécution, le nom de l utilisateur les ayant envoyées BATCHS La possibilité d effectuer des requêtes en batch est une fonctionnalité essentielle dans un contexte de Data Warehouse où une requête peut avoir besoin de manipuler un volume important de données. Un scheduler, planificateur, peut alors permettre d envoyer une requête à un instant donné ou à intervalles réguliers. Imposer des plages horaires aux utilisateurs pour ces requêtes coûteuses est alors également une nécessité. L administrateur peut gérer les priorités d après les requêtes ou les utilisateurs. Le scheduler doit permettre non seulement d envoyer une requête mais une série de requêtes. Un mécanisme d alertes peut alors avertir l utilisateur si des valeurs sont exceptionnelles. On passe alors d une logique pull (l utilisateur part à la recherche de l information pertinente) à une logique push (l information vient vers l utilisateur quand elle est jugée pertinente). Outre les requêtes définies avec l outil d aide à la décision, le scheduler peut également permettre de lancer des requêtes d administration à un instant donné, pendant des plages horaires peu occupées.

35 5 - LE DATA MART Avec un Data Warehouse, il y a des risques d échec. Rien n invite l utilisateur à se servir d un Data Warehouse. Le succès d un Data Warehouse dépend donc uniquement de son effective utilisation. Un des gros risques de la construction est de se cristalliser autour de la problématique informatique et de se détourner de l utilisateur. Le Data Mart minimise la complexité informatique. Il est donc plus facile de se concentrer sur les besoins utilisateurs DEFINITION Le Data Mart est une base de données moins coûteuse que le Data Warehouse, et plus légère puisque destinée à quelques utilisateurs d un département. Il séduit plus que le Data Warehouse les candidats au décisionnel. C est une petite structure très ciblée et pilotée par les besoins utilisateurs. Il a la même vocation que le Data Warehouse (fournir une architecture décisionnelle), mais vise une problématique précise avec un nombre d utilisateurs plus restreint. En général, c est une petite base de données (SQL ou multidimensionnelle) avec quelques outils, et alimentée par un nombre assez restreint de sources de données. Son coût ne dépasse pas deux à trois millions de francs. Mais pour réussir, il y a quelques précautions à prendre, gage de son évolutivité vers le Data Warehouse. Data Warehouse Data Mart Cible utilisateur Toute l entreprise Département Implication du Elevée Faible ou moyen service informatique Base de données d entreprise SQL type serveur SQL milieu de gamme, bases multidimensionnelles Modèles de données A l échelle de l entreprise Département Champ applicatif Multi sujets, neutre Quelques sujets, spécifique Sources de données Multiples Quelques unes Stockage Base de données Plusieurs bases distribuées Taille Centaine de GO et plus Une à 2 dizaines de GO Temps de mise en place 9 à 18 mois pour les 3 étapes 6 à 12 mois (installation en plusieurs étapes) Coût > 6 millions de francs à 3 millions de francs

36 Matériel Unix NT, petit serveur Unix Tableau 11 : finalités des data marts et data warehouse MISE EN PLACE Construire un ou plusieurs Data Marts départementaux au lieu d un Data Warehouse central permet de valider rapidement le concept d informatique décisionnelle. Mais construire des Data Marts n est pas sans risques : En effet, dans les entreprises, des Data Marts isolés peuvent proliférer. Ces entreprises risquent de retomber dans le piège d une architecture composée de multiples systèmes décisionnels incohérents, contenant des informations redondantes. Cela coûte plus cher et c est plus complexe à gérer qu un Data Warehouse centralisé. Les entreprises américaines, plus en avance que les entreprises européennes, en ont fait les frais. Les Data Marts résolvent les problèmes de performance des gros Data Warehouse. Mais ils font régresser vers le vieux problème des îlots isolés. Les entreprises vont devoir affronter des problèmes techniques complexes et coûteux pour remettre en cohérence les ensembles. Fédérer des Data Marts ou les faire évoluer vers une structure centralisée n est pas facile. On peut se poser la question s il est préférable de bâtir un gros et unique Data Warehouse ou bien de concevoir un réservoir plus modeste, nourri par les données d un seul département. Il est intéressant de commencer par un Data Mart, à condition de respecter certaines règles : Impliquer les utilisateurs. Ne pas construire de multiples Data Marts isolés. Bannir les redondances.

37 Les Data Marts sont petits Les Data Marts sont moins complexes et plus facile à déployer que les Data Warehouse Les Data Marts peuvent évoluer facilement vers un Data Warehouse Les différents Data Marts indépendants peuvent être dynamiquement coupler pour se métamorphoser en Data Warehouse Les Data Marts ne se résument qu à une seule information métier (exemple : ventes) Les Data Marts sont plus flexibles que les Data Warehouse Les Data Marts sont un nouveau concept. Tableau 12 : les sept mythes du data mart (source : Gartner Groupe) Donc le Data Mart peut préparer au Data Warehouse. Mais il faut penser grand, avenir, et adopter des technologies capables d évoluer. 6 - LE CONCEPT OLAP PRESENTATION Les outils OLAP (On Line Analytical Process) reposent sur une base de données multidimensionnelle, destinée à exploiter rapidement les dimensions d'une population de données. La plupart des solutions OLAP reposent sur un même principe : restructurer et stocker dans un format multidimensionnel les données issues de fichiers plats ou de bases relationnelles. Ce format multidimensionnel, connu également sous le nom d'hypercube, organise les données le long de dimensions. Ainsi, les utilisateurs analysent les données suivant les axes propres à leur métier. Ce type d'analyse multidimensionnelle nécessite à la fois l'accès à un grand volume de données et des moyens adaptés pour les analyser selon différents points de vue. Ceci inclut la capacité à discerner des relations nouvelles ou non prévues entre les variables, la capacité à identifier les paramètres nécessaires à manier un volume

38 important de données pour créer un nombre illimité de dimensions et pour spécifier des expressions et conditions inter-dimensions. Ces dimensions représentent les chemins de consolidation. OLAP concerne de ce fait au moins autant le monde des serveurs, voire des structures de stockage, que celui des outils LES 12 REGLES OLAP Afin de formaliser le concept OLAP, fin 1993, à la demande de Arbor Software, Edgar F. Codd publie un article intitulé "Providing OLAP to User Analysts" aux Etats Unis, dans lequel il définit 12 règles que tout système de pilotage multidimensionnel devrait respecter.. "Ce qu il y a d agréable avec ces outils OLAP", explique Eric Klusman, de Cantor Fitzgerald LP, "c est que je suis en mesure de distribuer les données aux utilisateurs sans les obliger à apprendre des complexes formules de programmation, d interrogation ou même à ce qu ils aient à programmer leurs tableurs". D une façon générale, tous affirment que l on peut interfacer de nombreux outils d utilisateurs avec des bases de données multidimensionnelles sans qu il soit nécessaire de consentir de lourds efforts de formation ou des interventions importantes du service informatique.

39 Vue multidimensionnelle L'utilisateur a l'habitude de raisonner en vue multidimensionnelle comme par exemple lorsqu'il souhaite analyser les ventes par produit mais aussi par région ou par période. Ces modèles permettent des manipulations simples : rotation, pivot ou vues par tranche, analyse de type permutations d'axes (slice and dice) ou en cascade (drill anywhere). Transparence du serveur OLAP à différents types de logiciels Cette transparence se traduit pour l'utilisateur par un complément à ses outils habituels garantissant ainsi sa productivité et sa compétence. Elle s'appuie sur une architecture ouverte permettant à l'utilisateur d'implanter le système OLAP sans affecter les fonctionnalités du système central. Par ailleurs, l'utilisateur ne doit pas être concerné par l'intégration des données dans OLAP provenant d'un environnement homogène ou hétérogène. Accessibilité à de nombreuses sources de données Le système OLAP doit donner accès aux données nécessaires aux analyses demandées. Les outils OLAP doivent avoir leur propre schéma logique de stockage des données physiques hétérogènes, doivent accéder aux données et réaliser n'importe quelle conversion afin de présenter à l'utilisateur une vue simple et cohérente. Ils doivent aussi savoir de quel type de systèmes proviennent les données. Performance du système de Reporting L'augmentation du nombre de dimensions ou du volume de la base de données ne doit pas entraîner de dégradation visible par l'utilisateur. Architecture Client/Serveur La plupart des données pour OLAP sont stockées sur des gros systèmes et sont accessibles via des PC. Il est donc nécessaire que les produits OLAP soient capables de travailler dans un environnement Client/Serveur. Dimensions Génériques

40 Toutes les dimensions doivent être équivalentes en structure et en calcul. Il ne doit exister qu'une seule structure logique pour toutes les dimensions. Toute fonction qui s'applique à une dimension doit être aussi capable de s'appliquer à une autre dimension.

41 Gestion dynamique des matrices creuses Le schéma physique des outils OLAP doit s'adapter entièrement au modèle d'analyse spécifique créé pour optimiser la gestion des matrices creuses. En effet, dans une analyse à la fois sur les produits et les régions, tous les produits ne sont pas vendus dans toutes les régions. Support multi-utilisateurs Les outils OLAP doivent supporter les accès concurrents, garantir l'intégrité et la sécurité afin que plusieurs utilisateurs accèdent au même modèle d'analyse. Support multi-utilisateurs Les outils OLAP doivent supporter les accès concurrents, garantir l'intégrité et la sécurité afin que plusieurs utilisateurs accèdent au même modèle d'analyse. Calculs à travers les dimensions Les opérations doivent pouvoir s'effectuer sur toutes les dimensions et ne doivent pas faire intervenir l'utilisateur pour définir un calcul hiérarchique. Manipulation intuitive des données Toute manipulation doit être accomplie via une action directe sur les cellules du modèle sans utiliser de menus ou des chemins multiples à travers l'interface utilisateur. Souplesse et facilité de constitution des rapports La création des rapports dans les outils OLAP doit permettre aux utilisateurs de présenter comme ils le désirent des données synthétiques ou des résultats en fonction de l'orientation du modèle. Nombre illimité de niveaux d'agrégation et de dimensions Tout outil OLAP doit gérer au moins 15 à 20 dimensions.

42

43 D'après EF CODD & Associates, les SGBD Relationnels n'ont jamais été conçus pour fournir les puissantes fonctions de synthèse, d'analyse et de consolidation communément appelées analyse multidimensionnelle des données. Ces types de fonctions ont toujours été prévus pour être fournis par des outils séparés, orientés utilisateurs et complémentaires des SGBD Relationnels. Les tables vont être transformées en un hypercube de données. Les données vont pouvoir être visualisées sous différents angles grâce aux vues multidimensionnelles. OLAP, parce qu'il associe des mécanismes de navigation aux données, permet d'effectuer des analyses de manière interactive, à l'opposé du requêteur pour qui chaque requête est une fin en soi. Par contre, OLAP ne permet l'analyse d'information que dans un cadre prédéfini, limitant dès lors l'autonomie potentielle de l'utilisateur. De ce fait requêtes et outils OLAP doivent être considérés comme complémentaires plutôt que concurrents. Requêtes et outils OLAP doivent être considérés comme complémentaires plutôt que concurrents TYPOLOGIE DES REGLES O.L.A.P. Reprenant la structure du système décisionnel, nous rappelons qu un système d analyse multidimensionnelle peut se décomposer en 2 Siad élémentaires, un SGBD, un Tableur. Ainsi, nous présentons ces 12 règles en les classant selon les éléments du système décisionnel auxquels elles se rapportent. ( Cf Figure Ci-dessous). Analyse Mutidimensionnelle Système & Architecture 12 Règles de Codd. 5 Règles SGBD_SIAD_2 2 Règles Tableur_SIAD_1 3 Règles Interface Utilisateur 2 Règles

44 Tableau 13 : Ventilation des Règles de Codd. Ces règles s énoncent ainsi : Système & Architecture L architecture est Client / Serveur L accès possible à plusieurs utilisateurs simultanément La performance demeure stable quelque soit le volume de données Le système est transparent pour l utilisateur Le système gère dynamiquement les Matrices Creuses SGBD_SIAD_2 Vue Conceptuelle Multidimensionnelle des données Accessibilité à toutes les données utiles à la décision Tableur_SIAD_1 Nombre Illimité de Dimensions et Nombre illimité de niveaux d agrégation Toutes les dimensions sont équivalentes en structure et en calcul Il n y a pas d opérations restrictives sur les dimensions Interface Utilisateur Souplesse de Création de Rapports Manipulation intuitive des données COMMENTAIRES Codd fixe la méthode de SGBD; celle-ci est multidimensionnelle. Cet aspect est développé dans le paragraphe suivant au travers des méthodes M_OLAP et R_OLAP. Accessibilité à toutes les données utiles à la décision entraîne la possibilités d accéder à plusieurs bases de données internes ou externes à l entreprise. Conséquence : Codd recommande l architecture Client-Serveur. Aucun tableur n offre un nombre infini de dimensions et de niveaux d agrégation. 15 à 20 dimensions font partie des performances actuelles. Enfin, nous pourrions regrouper les règles orientées Utilisateur :

45 Système & Architecture L accès possible à plusieurs utilisateurs simultanément La performance demeure stable quelque soit le volume de données Le système est transparent pour l utilisateur SGBD_SIAD_2 Accessibilité à toutes les données utiles à la décision Interface Utilisateur Souplesse de Création de Rapports Manipulation intuitive des données 7 - ANALYSE MULTIDIMENTIONNELLE Les serveurs OLAP ont été conçus pour s'intégrer dans un environnement client/serveur afin d'en retirer les possibilités offertes. Les utilisateurs disposant de postes de travail intelligents accèdent à un serveur de base de données multidimensionnelle. Celui-ci contient un hypercube prédéfini dans lequel doit être stockée la globalité des données. Ce qui nécessite de s'appuyer sur une information pré-packagée et fortement structurée. Il permettra ainsi d'analyser la répartition d'un indicateur comme le " chiffre d'affaire" en fonction des axes ou dimensions " clients ", " produit ", " temps". En outre, des hiérarchies seront définies pour chaque axe d'analyse (par exemple, l'année, puis la saison, le mois et la semaine, pour l'axe temps). Une fois cette structure multidimensionnelle établie, l'outil OLAP propose des méthodes de navigation dans les données, comme le "drill-down" pour aller vers les informations détaillées dans une hiérarchie, le "slice and dice" pour changer d'axe d'analyse.

46 Temps Client Produit Tableau 14 : représentation sous forme de cube

47 7.1 - LE MODELE LES DIMENSIONS Un axe d analyse essentiel est la dimension temps. Les tables contiennent des rangées (tuples, enregistrements). Chaque rangée est constituée de colonnes (champs). Dans une base de données standard, le premier champ de chaque enregistrement est la clé primaire, l'unique identifiant de l'enregistrement. Par contre, le modèle de données multidimensionnel est un tableau à n dimensions (hypercube ). Chaque dimension possède une hiérarchie associée de niveaux de consolidation. Chaque position dans un tableau multidimensionnel, correspondant à une intersection de toutes les dimensions est appelée une cellule. Ces dimensions peuvent être affinées, décomposées en hiérarchies, afin de permettre à l utilisateur d examiner ses indicateurs à différents niveaux de détail, de " descendre " dans les données, allant du niveau global au niveau le plus fin. Par exemple, une date pourra être décomposée en <année, mois, semaine, jour>. On aura alors une vision pyramidale des données, la base de la pyramide représentant le niveau le plus détaillé et le haut le niveau le plus global. Hiérarchie d'une dimension Semaine Mois Année Indicateurs numériques Jour Période Produit Dimensions d'analyse Tableau 15 : représentation pyramidale

48 L utilisateur peut avoir besoin de personnaliser le modèle défini par l administrateur en incorporant par exemple ses propres attributs dans les dimensions ou en modifiant certaines des hiérarchies LES VARIABLES Les variables, qui sont aussi appelées métriques, dans un tableau multidimensionnel correspondent aux colonnes d'une table relationnelle. Les valeurs à l'intérieur d'une colonne correspondent aux valeurs pour cette variable dans un tableau multidimensionnel. Par rapport à l axe temps, nous pouvons distinguer deux types de variables à analyser : des variables de flux, dont les variations sont enregistrées dans la base de données. Pour déterminer leur montant pendant une certaine période, il suffit de cumuler les différentes variations ayant eu lieu dans cette période. Par exemple, pour obtenir le chiffre d'affaire du mois de Mai 1998, il suffit de faire la somme des chiffres d'affaire de chaque jour du mois. des variables d état, indiquant le contenu d une variable à un instant t. Le cumul des valeurs prises dans une période donnée n indique généralement plus la valeur de cette variable pour cette période. Par exemple pour une variable indiquant l état du stock au début de chacun des trimestres, l entreprise peut considérer que l état du stock pour l année est égal à son état au 1 er trimestre. Les valeurs des 4 trimestres n ont donc pas à être cumulées pour obtenir le stock annuel. L administrateur ou l utilisateur doit pouvoir indiquer à l outil si une variable est une variable d état et quelle valeur elle devra prendre pour un attribut donné. Les métriques de base sont l association d une colonne de fait et d une fonction d agrégation. Il est indispensable que l utilisateur puisse aller au-delà et utiliser des métriques complexes, dérivées de ces éléments de base en définissant des métriques composées d autres métriques, filtrées ou calculées par rapport à une dimension particulière. Une variable sera élue indicateur selon la stratégie choisie. Par exemple pour analyser les ventes on choisira comme indicateur la variable CA (chiffre d affaires). L utilisateur formulera alors ses requêtes en précisant les indicateurs à analyser (le chiffre d affaires), les dimensions sur lesquelles ces analyseurs

49 doivent être projetées (le produit et le client) et la population à observer (le mois de Mars 1998).

50 7.2 - NAVIGATION DANS LES DONNEES DRILL-DOWN, DRILL-UP Le drill-down / up désigne la faculté d aller du niveau global vers le niveau détaillé, et inversement. Ce mécanisme est totalement basé sur la notion de hiérarchie. Chacun des axes d analyse se décompose en attributs reliés entre eux par des relations père / fils. Une dimension doit normalement pouvoir comporter plusieurs hiérarchies. Par exemple, la dimension " produits " peut contenir une hiérarchie " Marque- Article " et une hiérarchie " Secteur-Segment-Article ". Le mécanisme de drill-down se fera ainsi de la marque vers l article et du secteur vers le segment puis vers l article. La mise en œuvre de cette fonctionnalité n est cependant pas toujours aussi simple. En effet, une dimension peut contenir des hiérarchies partant d un même attribut pour aller vers un attribut différent. Par exemple, l axe " Clients " peut contenir la hiérarchie " Client-Individu " et la hiérarchie " Client-Société-Filiale ". L outil doit alors permettre soit de redescendre de Client vers à la fois Individu et Société puis de redescendre au niveau Filiale pour les clients de type Société, soit plus simplement, permettre à l utilisateur de choisir de redescendre vers le niveau Individu ou vers le niveau Société. Secteur Client Marque Segment Individu Société Article Filiale Tableau 16 : exemple de hiérarchies multiples SLICE AND DICE Le " Slice and dice " désigne la possibilité de faire pivoter dynamiquement les axes du tableau d analyse croisée. Il est possible ainsi de passer d un tableau présentant les

51 ventes par magasin en lignes et jour en colonnes par un tableau similaire présentant les ventes par magasin en colonnes et jour en ligne DATA SURFING Le data surfing est la possibilité laissée à l utilisateur de circuler librement, de manière intuitive et ergonomique dans un modèle dimensionnel, au delà d un " simple " drill-down ou slice and dice. L utilisateur peut alors modifier dynamiquement ses axes d analyse ou appliquer un nouveau filtre à ses données. Ces mécanismes s appliquent sur le modèle défini soit par l administrateur, soit par l utilisateur. Ce modèle doit être assez complexe pour adresser l ensemble des demandes de l utilisateur et assez souple pour que l utilisateur puisse le personnaliser à son goût, en créant de nouveaux attributs ou de nouveaux axes d analyse ou en définissant de nouvelles métriques calculées PROBLEME DES MATRICES CREUSES Dans un cube idéal, toutes les cellules ont une valeur, on parle alors de cube dense. Ceci est cependant rarement le cas. Si certaines valeurs sont absentes, on parlera de cellules creuses, d éparpillement (sparcity). Ceci se rencontre notamment dans les cas suivants : des enregistrements n appartenant qu à une seule dimension. des dimensions qui n ont pas de valeur pour chaque occurrence. Plus on a de dimensions, plus le risque d éparpillement des données est grand. des dimensions comportant des valeurs exclusives. Par exemple, la dimension sexe est crée, chaque enregistrement sera soit homme, soit femme, ce qui engendrera un fort taux de cellules creuses lors de l analyse du CA par client et par sexe. Autre exemple, dans un magasin on ne vend pas chaque jour tous les articles. Le cube comportera alors un nombre important de cellules creuses. L ajout de colonnes pré-calculées fera aussi croître de manière significative la taille de la base de données. Dans un contexte de données stockées sous un format d hypercube, il est donc important de choisir ses dimensions avec attention, d en

52 restreindre le nombre en définissant le plus possible de dimensions composées. Une autre alternative est de diviser un hypercube en de petits cubes. Le stockage des données sous une forme relationnelle permet d éluder ces problèmes de place et de cellules creuses. 8 - MODELISATION Modéliser est une tâche délicate car elle met en jeu des populations différentes. Les administrateurs de données et les utilisateurs "métiers" doivent créer un modèle global et cohérent pour l'entreprise. Les données du Data Warehouse doivent être orientées " sujet ", facilement compréhensibles et utilisables par les utilisateurs. Le modèle doit donc être adapté à leur démarche de recherche et d analyse. Les modèles relationnels normalisés ne sont alors pas toujours l idéal. En effet, ils correspondent généralement plus à une vision " technique " et informaticienne des données qu à une vision utilisateur. Ils peuvent répondre aux requêtes ensemblistes (liste des commandes d un client) ou détaillées (adresse et numéro de téléphone d un client) mais adressent très peu la notion d analyse qui est essentielle dans le monde décisionnel. Ce concept est généralement lié à une vision multidimensionnelle des données. L utilisateur peut ainsi analyser des informations selon diverses perspectives, par rapport à différents axes (par exemple les ventes par rapport aux dimensions temps, régions et clients). La dénormalisation du modèle des données, la redondance d informations sont totalement envisageables dans un contexte de Data Warehouse car la non volatilité des données permet de ne pas se préoccuper, lors de l utilisation du Data Warehouse, des problèmes d intégrité des données ou de transaction. Afin de répondre à ce type de besoin tout en conservant la technologie des SGBD relationnels, il sera souvent nécessaire de modéliser les données de manière particulière, en distinguant les différents axes et les indicateurs à analyser. On parlera alors de modèle en étoile (star) ou en flocon (snowflake). Le serveur de données devra donc permettre la gestion de gros volumes d informations et supporter les machines parallèles. Afin d offrir à l utilisateur une performance optimale, il sera indispensable d agréger physiquement les données (par exemple par rapport au temps), et souvent nécessaire de partitionner ces données. Cinq axes permettent de qualifier un modèle décisionnel :

53 Lisibilité du point de vue de l'utilisateur final. Performances de chargement Performances d'exécution Administration, c'est à dire faire vivre le Data Warehouse Evolutivité, que tous les autres projets décisionnels s'intègrent facilement Le choix entre modèle dimensionnel (étoile ou flocon) et le modèle relationnel (normalisé ou non) dépend du type du besoin décisionnel à construire MODELISATION RELATIONNELLE MODELE DE DONNEES NORMALISE Ce modèle est très classique, il est formalisé par des méthodes comme MERISE. Il est très complet car on y trouve beaucoup de données détaillées, ce qui laisse beaucoup d autonomie à l utilisateur. Par contre aucune information intéressante dans un contexte décisionnel n existe directement. Les outils d infocentre ou de " query " accèdent pour la plupart à un modèle de données relationnel quelconque. L analyse multidimensionnelle de ces données pourra alors se faire directement à partir d un résultat de requête SQL. Les possibilités d analyse sont alors assez sommaires (par ex., définition d un tableau d analyse croisée). La seconde technique consiste à générer et à manipuler, à partir du résultat d une requête SQL, un hypercube, le plus souvent stocké en local. Cette manipulation pourra être faite soit par l outil de query lui même, soit par un outil complémentaire dédié à ce type d analyse. L hypercube généré ne permettra alors d analyser qu une partie des données de l entreprise, celles correspondant au contexte de la requête. Lorsque le modèle comprend un grand nombre de tables, les performances deviennent alors très mauvaises et les requêtes complexes à formuler par l utilisateur MODELE DE DONNEES DENORMALISE On prend le modèle normalisé et le simplifie afin qu il réponde mieux aux exigences du décisionnel. Cette dénormalisation n est pas réalisée en s appuyant sur une technique précise mais plutôt en s intéressant aux besoins des utilisateurs. On va ainsi créer des redondances d informations et des informations agrégées qui diminueront le nombre de tables. De ce fait, on améliorera les temps de réponse et on facilitera

54 l accès aux informations par les utilisateurs car le modèle lui apparaîtra comme plus lisible.

55 8.2 - MODELISATION DIMENSIONNELLE La modélisation dimensionnelle dérive des concepts OLAP. Les produits utilisent une structure de données multidimensionnelle. Elle permet l utilisation de bases de données relationnelles ou multidimensionnelles. L objectif majeur d un système décisionnel est l analyse de la performance. On mesure cette performance au travers des indicateurs que l on a retenu. Ces indicateurs vont donc être la base de la modélisation dimensionnelle et être regroupés dans une table dite table des faits MODELISER EN ETOILE Dans un modèle en étoile, tous les faits sont définis dans une simple table relationnelle. Cette table des faits va être reliée par clés primaires à d autres tables correspondant aux dimensions. Dans l'exemple ci-après il s'agit des PRODUITS, BRANCHE, REGION et TEMPS. En fait, le modèle en étoile essaie de superposer une structure multidimensionnelle au dessus d'un modèle relationnel normalisé à deux dimensions. Le modèle en étoile simplifie le modèle logique normalisé en organisant les données de manière optimale pour les traitements d'analyse MODELISER EN FLOCON La modélisation en flocon est une modélisation en étoile pour laquelle on éclate les tables de dimensions en sous-tables selon la hiérarchie de cette dimension. Dans notre exemple, on éclatera PRODUITS, BRANCHE, REGION et TEMPS. Dans les deux types de modèles décrits ci-dessus, on s aperçoit que les points forts sont la lisibilité du modèle par l utilisateur et la performance d exécution. Mais par contre on peut leur reprocher leur manque de complétude et leur orientation rapidement très métier avec le risque d évolution du modèle très problématique.

56 PRODUITS TABLE de FAITS REGION Couleur Bureaux de ventes Taille PRODUIT Administration Emballage REGION BRANCHE TEMPS BRANCHE CA TEMPS Ventes au détail Marge Semaines Ventes en gros Unité Mois Importation Exportation Trimestres Année Fiscale Tableau 17 : exemple de modèle en étoile Concrètement, la table des faits est énorme en nombre de lignes mais le volume de chaque ligne est limité. Les tables de dimensions sont elles beaucoup plus réduites. On accède aux tables des dimensions par une sélection. Par exemple le CA pour les produits électroménagers pour l année 97 pour la région Nord. On y récupère les identifiants qui seront les uniques points d entrées à la table des faits pour y trouver le CA correspondant. Une fois le modèle défini, la faculté de naviguer dans les données est un apport important des outils OLAP (MOLAP, ROLAP).

57 9 - STOCKAGE DES DONNEES Ces besoins en terme d analyse multidimensionnelle peuvent influer d une part sur le modèle physique, d autre part sur la vision que les utilisateurs ont des données. Les données peuvent être stockées soit sous forme multidimensionnelle, soit sous forme relationnelle. Les bases multidimensionnelles sont conçues pour optimiser l'analyse d'indicateurs (CA) par rapport aux dimensions qui leur sont associées (temps, produit, région). Elles sont de moins en moins exigeantes en terme de volume de stockage (technique de compression). Les bases relationnelles sont conçues à l'origine pour le décisionnel. Elles sont plus ouvertes et s'adaptent à de nombreuses plates formes LE STOCKAGE DES DONNEES EXTERNES Les données qui ne sont pas générées par les systèmes informatiques de l entreprise sont appelées des données externes et sont introduites sans formatage préalable. Elles ne sont donc pas forcément structurées. Typiquement, les données externes qui sont dans l entrepôt de données arrivent dans l entreprise par l intermédiaire d un poste client. Elles sont saisies manuellement dans un tableur, ce qui laisse peu de chances d identifier d ou viennent les données ainsi que leurs contenus. D autres types de données ont fait leur apparition, il s agit du son et de l image qui sont, sans compression, particulièrement volumineux. L entrepôt de données est le lieu idéal pour stocker des données externes et non structurées. Si ces données ne sont pas stockées dans un endroit bien défini, on ne peut plus savoir d où viennent les données et on laisse la porte ouverte aux éventuelles redondances. Les données externes peuvent être stockées au sein même de l entrepôt de données. Toutefois, pour diminuer le coût de stockage de ces données, on préférera les stocker séparément, sur un support économique. A la détection des données externes, on choisira de rediriger le stockage de ces données vers des périphériques d archivage dédiés. Le composant de base support du stockage est le SGBD. Outre le stockage, le SGBD doit être spécifiquement adapté aux caractéristiques de l accès décisionnel. Ces technologies sont principalement liées à la parallélisation des requêtes et à diverses optimisations proposées pour accélérer les sélections et les regroupements ensemblistes.

58 9.2 - OPTIMISATION PHYSIQUE Du fait de l importance de l historique dans un Data Warehouse, la structuration physique des données est également importante. Parmi les optimisations proposées par les éditeurs, on notera les index bitmaps (Sybase, Oracle), ou la génération assistée des agrégations (HP, Informix, Oracle, etc.) ainsi que le partitionnement des tables AGREGATION DE TABLES Les requêtes faisant appel à des données agrégées forment 80 % des demandes effectuées dans un système décisionnel. La construction de tables agrégées permet d'améliorer très nettement les temps de réponse de ces requêtes. Par exemple, on crée une table des ventes mensuelles représentant la somme des ventes journalières par magasin et cela sur chacun des mois. ventes journalières VENTES Ventes mensuelles Ventes annuelles Tableau 18 : exemple de tables agrégées Cette technique d'optimisation trouve ses limites lorsque les bases des données atteignent un volume important. Autre inconvénient, l'administration est complexe PARTITIONNEMENT DE TABLES Un partitionnement physique des tables en plus petites unités selon le critère temps apporte des performances stables dans le temps, des facilités pour les reprises, les

59 indexations, les restructurations et l archivage. Notre table des ventes sera éclatée en 12 tables, soit une par mois. ventes Ile de France VENTES Ventes Périgord Ventes Provence Ventes Autres Tableau 19 : exemple de tables partitionnées Cette technique n'est pas simple à administrer LES META-DONNEES Les méta-données sont des données sur les données. Les méta-données représentent la totalité des informations concernant le Data Warehouse et les processus associés. Elles sont intégrées dans un référentiel. La méta-donnée va également servir de mémoire pour les données externes en recueillant les informations suivantes : l identifiant du document, sa date d entrée dans l entrepôt de données, la description du document, l origine du document, la date d origine du document, les mots indexés du document, la date d épuration, la place physique du document, sa longueur... Dans le cadre d outils OLAP, les méta-données sont, pour l essentiel, la structure multidimensionnelle elle-même. Pour un outil d aide à la décision, elles ont pour vocation de présenter à l utilisateur des éléments qui lui sont familiers et qu il pourra donc analyser facilement, de manière intuitive.

60 Dans le cas d outil Rolap, les méta-données ont pour but de transformer le modèle de stockage relationnel en une vision utilisateur multidimensionnelle. Le mode de stockage privilégié pour les méta-données est le serveur relationnel. Elles sont ainsi stockées une seule fois et accessibles par l ensemble des utilisateurs. La mise à jour de l environnement client peut alors s effectuer de deux manières : soit en rapatriant à chaque connexion le contenu des méta-données, soit en ramenant en local les méta-données et en les mettant à jour de manière automatique lorsqu un changement est survenu. Cette deuxième solution est plus performante, un nouveau catalogue n étant ramené qu une fois sur le poste local LES DIFFERENTS OUTILS OLAP OLAP sera l'outil à privilégier pour les données quantitatives si leur structuration a priori est naturelle (cas rencontré fréquemment pour les applications financières ou commerciales), alors que le requêteur sera idéal pour les données qualitatives et pour toute analyse impromptue nécessitant l'autonomie de l'utilisateur (cas rencontré fréquemment pour le marketing ou la gestion du personnel). Si les besoins sont à combiner, il faudra choisir entre la richesse fonctionnelle apportée par plusieurs outils interfacés ou l homogénéité des outils intégrés. Deux versions d'olap s'affrontent actuellement. Les outils MOLAP (Multidimensional OLAP) d'une part qui s'appuient sur une base de données multidimensionnelle. Les outils ROLAP (Relational OLAP) d'autre part, qui représente leur équivalent sur une base de données relationnelle LES OUTILS MOLAP MOLAP est conçue exclusivement pour l'analyse multidimensionnelle, avec un mode de stockage optimisé par rapport aux chemins d'accès prédéfinis. Ainsi, toute valeur d'indicateur associée à l'axe temps sera pré-calculée au chargement pour toutes ses valeurs hebdomadaires, mensuelles, etc.

61 Data Warehouse Moteur MOLAP Aide à la décision Données Traitements Présentation Stockage des données détaillées (et agrégées) Rapports Multi-Dimensionnel Tableau 20 : architecture d un produit Molap (EDS) MOLAP agrège tout par défaut. Plus le volume de données à gérer est important, plus les principes d'agrégations implicites proposés par MOLAP sont pénalisants dans la phase de chargement de la base, tant en terme de performances que de volume. La limite fréquemment évoquée pour MOLAP étant de quelques giga octets. MOLAP surpasse ROLAP pour des fonctionnalités avancées comme la prévision ou la mise à jour des données pour la simulation. Cependant, ces différences s'expliquent par une plus grande maturité en faveur de MOLAP, concept qui date de près de vingt ans. MOLAP est incompatible avec d'autres modes d'accès aux données. Si MOLAP doit cohabiter avec d'autres techniques d'accès aux données (par requêteur, par data mining, etc.), deux bases de données doivent cohabiter. En effet, MOLAP repose sur un moteur spécialisé, qui stocke les données dans un format tabulaire propriétaire (cube). Pour accéder aux données de ce cube, on ne peut pas utiliser le langage de requête standard SQL, il faut utiliser une API spécifique. Le marché des bases MOLAP étant plus réduit, il est plus difficile pour les éditeurs qui le représentent d'investir sur de telles évolutions LES OUTILS ROLAP Les outils ROLAP superposent au dessus des SGBD/R bidimensionnels un modèle qui représente les données dans un format multidimensionnel. Ces produits diminuent sensiblement le coût lié à la mise en œuvre d'un serveur de base de données multidimensionnelle supplémentaire. Au travers des méta-données, ils permettent de transformer l analyse multidimensionnelle demandée par l utilisateur en requêtes

62 SQL. Pour cela, ces outils s appuient pour la plupart sur une modélisation particulière des données, distinguant les axes d analyse et les faits à observer. On parlera notamment de modèle en étoile et de modèle en flocon ou encore des techniques de définition physique d'agrégations. Ceci oblige à définir le modèle en fonction de l outil à utiliser et des analyses à mener mais est un gage de performance et de cohérence lors de l utilisation de ce type de produits. Cette contrainte exige un travail important des équipes informatiques et donc enlève beaucoup à l'intérêt d'utiliser un SGBD Relationnel comme support de stockage pour l'analyse multidimensionnelle. Data Warehouse Moteur ROLAP Aide à la décision Données Traitements Présentation Stockage des données détaillées (et agrégées) et des méta-données Génération de plans d'exécution SQL afin d'obtenir des fonctionnalités OLAP. Rapports Multi-Dimensionnel Tableau 21 : architecture d un produit Rolap (EDS) Les outils ROLAP proposent le plus souvent un composant serveur, pour optimiser les performances lors de la navigation dans les données ou pour les calculs complexes. Avec ROLAP, il est déconseillé d'accéder en direct à des bases de données de production pour faire des analyses sérieuses, pour des raisons de performances. ROLAP n'agrège rien, mais tire parti des agrégats s'ils existent. De ce fait ROLAP est plus lourd à administrer que MOLAP, puisqu'il demande de créer explicitement certains agrégats. Certains éditeurs, comme Informix avec Métacube ou Oracle avec Discoverer 2000, pallient cependant à cette faiblesse avec des outils d'administration aptes à conseiller pour une politique d'agrégation adéquate. ROLAP est donc mieux adapté aux gros volumes. En s'appuyant sur les bases relationnelles, référence du marché, ROLAP tire partie des évolutions de celles-ci (adaptation aux architectures hardware sophistiq uées, extensions objets, etc.).

63 EDITEUR PRODUIT MOLAP ARBOR SOFTWARE ORACLE DIMENSIONAL INSIGHT ESSBASE EXPRESS CROSS TARGET ROLAP INFORMIX MICROSTRATEGY PLATINUM TECHNOLOGY METACUBE DSS AGENT INFOBEACON Tableau 22 : principaux outils MOLAP et ROLAP 11 - L'ALIMENTATION DU DATA WAREHOUSE Les données du Data Warehouse sont, pour la plupart, issues des différentes sources de données opérationnelles de l entreprise. Des solutions logicielles sont alors nécessaires à leur intégration et à leur homogénéisation. Celles-ci peuvent aller de l écriture de batchs à l utilisation de logiciels spécialisés dans l extraction et la transformation d informations (ETI, Prism, Carleton,...). Ces outils ont pour objet de s assurer de la cohérence des données du Data Warehouse et d homogénéiser les différents formats trouvés dans les bases de données opérationnelles. Les solutions de réplication sont souvent citées comme pouvant répondre à ce besoin. Très liées à un éditeur et à une technologie, elles ne sont en fait adaptées qu à un très petit nombre de cas, où les données sont issues de sources homogènes et n ont pas besoin d être transformées. Alimenter le Data Warehouse est la difficulté technique majeure et la plus coûteuse LES PHASES DE L'ALIMENTATION Les phases de l'alimentation du Data Warehouse sont les suivantes :

64 Découvrir quelles sont les données à faire migrer. L acquisition des données se déroule en trois phases : l extraction, la transformation et le chargement. Données de production Extraction, Transformation Logiciels spécialisés Batch Modélisation, Chargement, Stockage, Optimisation SGBD Architecture parallèle Accélérateurs de requêtes Adaptation modèles spécifiques Outils clients Aide à la décision (interrogation, analyse) Data Mining (extraction de connaissances) Tableau 23 : les besoins et les outils du Data Warehouse (EDS) LA DECOUVERTE DES DONNEES La découverte des données consiste les localiser dans le système opérationnel et à prendre les plus judicieuses. Un mauvais choix des données a extraire va complexifier les phases suivantes de l'alimentation L'EXTRACTION DES DONNEES. L extraction des données consiste à collecter les données utiles dans le système de production. Pour rafraîchir la base décisionnelle, il faut identifier les données ayant évolué afin d extraire le minimum de données, puis planifier ces extractions afin d éviter les saturations du système de production. Le processus d'alimentation doit automatiquement et périodiquement rafraîchir les données et de préférence uniquement celles qui ont été modifiées afin d'optimiser les performances.

65 On réalisera des extractions différentielles en marquant les données (date dans un fichier LOG). Cette fonctionnalité devient importante lorsque le volume de données devient important. L intégrité des données est indispensable et nécessite la synchronisation des différents processus d extraction. Les problèmes liés à cette nécessaire synchronisation peuvent être complexes, soit fonctionnellement, soit techniquement dans des environnements très hétérogènes. Un autre problème est de traiter les données externes. Il faut maintenir une surveillance du système d information pour pouvoir les identifier et s assurer que ce sont les bonnes données qui sont recensées. De plus, la forme des données externes, qui est souvent totalement anarchique accentue la difficulté. Pour être utiles, ces données nécessitent un reformatage pour pouvoir les incorporer dans une forme exploitable pour l entreprise. Enfin le troisième problème vient de l apparition imprévisible de ces données qui les rend difficiles à capter. En conséquence, l'outil d'extraction doit attaquer toutes sortes de sources de données sans être perturbé et s adapter aux futures. Pour extraire les données sources, il y a plusieurs technologies utilisables : des passerelles, fournies principalement par les éditeurs de bases de données. Ces passerelles sont généralement insuffisantes car elles sont mal adaptées aux processus de transformation complexes ; des utilitaires de réplication, utilisables si les systèmes de production et décisionnel sont homogènes et si la transformation à appliquer aux données est légère ; des outils spécifiques d extraction. Ces outils sont certainement la solution opérationnelle au problème de l extraction, mais leur prix relativement élevé est un frein à leur utilisation dans les premières applications LA TRANSFORMATION DES DONNEES Le nettoyage des données est une discipline sur laquelle de nombreux éditeurs travaillent actuellement. Outre la qualité des données qu ils permettent d auditer et éventuellement d améliorer, les outils de nettoyage permettent de supprimer les doublons dans les fichiers. Il s'agit à ce stade d'appliquer des filtres prédéfinis sur les données afin d'attribuer des valeurs cohérentes aux variables mal ou non renseignées ou encore d'harmoniser les formats (date : jj/mm/aaaa). On peut également avoir à convertir les données d'un format EBCDIC vers ASCII. Dernier exemple, des données du système opérationnel doivent être agrégées ou calculées avant leur chargement dans la base décisionnelle.

66 Il faut également pouvoir associer des champs sources avec des champs cibles. Il existe plusieurs niveaux de complexité pour ces associations (cardinalités 1-1, 1-N, N- 1, N-N), comme par exemple : le transfert du "nom du client" vers un champ cible la décomposition d'une "adresse" vers les champs "numéro", "rue", "ville" ou l'inverse. Certains outils peuvent également réaliser des analyses lexicales des champs sources. Ils seront donc capables de comprendre que les champs suivants signifient la même chose : "Boulvd", "Bd","Boulevard". En complément, on trouve des outils d'audit et d'analyse pour assurer le suivi du processus afin notamment de contrôler les rejets LE CHARGEMENT DES DONNEES Le chargement est la dernière phase de l alimentation du Data Warehouse. C est une phase délicate notamment lorsque les volumes sont importants. Pour obtenir de bonnes performances en chargement, il est impératif de maîtriser les structures du SGBD (tables et index) associées aux données chargées afin d optimiser au mieux ces processus. Les techniques de parallélisation optimisent les chargements lourds. Pour les mettre en œuvre, des utilitaires particuliers existent chez la majorité des éditeurs de bases de données. La synchronisation des chargements de la source vers la cible est un problème majeur.

67 Pour réaliser ce transfert des données, on peut utiliser le transfert de fichiers ou le transfert de bases à bases. Le transfert de fichiers consiste à créer au moment de l'extraction des données, un ensemble de fichiers qui seront transférés sur le système cible afin d'alimenter la base décisionnelle. La transformation des données s'effectuera alors soit à la constitution des fichiers, soit à leur arrivée sur la cible. Le transfert de base à base est plus complexe, en effet chaque donnée est extraite de la base source, nettoyée si nécessaire, et transférée sur la base cible. Des logiciels contrôlent souvent les phases d'extraction, de transport et de chargement. Ils créent un enchaînement automatisé et gèrent les mises à jour mais ils sont rarement capables de s'occuper également du nettoyage des données Il faut donc souvent combiner les outils pour alimenter un Data Warehouse. EDITEUR EXTRACT SUITE PASSPORT WAREHOUSE MANAGER VALITY TECHNOLOGIE PRODUIT ETI CARLETON PRISM SOLUTIONS INTEGRITY DATA REENGINEERING Tableau 24 : principaux outils d extraction et de nettoyage

68