Le Data Warehouse et les Systèmes Multidimensionnels Le Data
Warehouse et les Systèmes Multidimensionnels
ELABORER PAR : Mr. ER-RIFAI Youssef Mr. YAMANE Achraf Mr. EL ASRI Salim ENCADRE PAR : Mr. Boulfdlour
Sommaire : INRODUCTION I-Définition et construction II-Objectifs d’un Datawarehouse III-Principe de fonctionnement IV-Architecture d’un Data warehouse 123-
4-
Les Bases de Données Opérations sur les données Les Data-Marts Les bases multidimensionnelles et les outils OLAP
V- Autour de l'entrepôt de données VI-Comparatif entre les bases de données de l'entreprise
VII-Etudes de cas 1-Cas d’une compagnie d’assurance 2-Cas d’une banque
INTRODUCTION De nos jours, l’évolution des technologies, la mondialisation des marchés et le raccourcissement du cycle de vie des produits rendent la concurrence toujours plus rude. Il devient très difficile pour une entreprise de conserver sa part de marché en se basant uniquement sur les prix et les produits. La communication bidirectionnelle ainsi que la circulation de l’information sont des données primordiales pour élaborer une stratégie CRM. Il est effectivement indispensable pour l’entreprise de comprendre ce que veut le client, ce dernier étant placé au centre des préoccupations. Les connaissances que l’entreprise se doit d’avoir du marché sur lequel elle se trouvent ainsi que l’acquisition des informations récoltées sur le client à chaque contact avec celui-ci, vont permettre à l’entreprise, pour autant qu’elles soient utilisées à bon escient, d’optimiser la satisfaction de sa clientèle. Comme nous le verrons plus tard dans le travail, la technologie revêt un rôle essentiel dans le CRM. Elle va permettre d’extraire des connaissances à partir de données stockées et gérées dans un entrepôt de données, puis analysées grâce aux outils OLAP et au data mining.
I-Définition et construction (data werhouse) ou Entrepôt de données est une base de données regroupant une partie ou l'ensemble des données fonctionnelles d'une entreprise. Il entre dans le cadre de l'informatique décisionnelle ; son but est de fournir un ensemble de données servant de référence unique, utilisée pour la prise de décisions dans l'entreprise par le biais de statistiques et de rapports réalisés via des outils de reporting. D'un point de vue technique, il sert surtout à 'délester' les bases de données opérationnelles des requêtes pouvant nuire à leurs performances. D'un point de vue architectural, il existe deux manières de l'appréhender :
L'architecture de haut en bas : selon Bill Inmon, l'entrepôt de données est une base de données au niveau détail, consistant en un référentiel global et centralisé de l'entreprise. En cela, il se distingue du Datamart, qui regroupe, agrège et cible fonctionnellement les données.
L'architecture de bas en haut : selon Ralph Kimball, l'entrepôt de données est constitué peu à peu par les Datamarts de l'entreprise, regroupant ainsi différents niveaux d'agrégation et d'historisation de données au sein d'une même base.
La définition la plus communément admise est un mélange de ces deux points de vue. Le terme Data warehouse englobe le contenant et le contenu : il désigne d'une part la base détaillée qui est la source de données à l'origine des Datamarts, et d'autre part l'ensemble constitué par cette base détaillée et ses Datamarts. De la même manière, les méthodes de conception actuelles prennent en compte ces deux approches, privilégiant certains aspects selon les risques et les opportunités inhérents à chaque entreprise.
II-Objectifs d’un Datawarehouse • permet le développement d’applications décisionnelles et de pilotage de l’entreprise et de ses processus • joue un rôle de référentiel pour l’entreprise puis qu’il permet de fédérer des données souvent éparpillées dans différentes bases de données • offre une vision globale et orientée métiers de toutes les données que manipule l’entreprise • permet de faire face aux changements du marché et de l’entreprise • offre une information compréhensible, utile et rapide
III-Principe de fonctionnement Intégration Dans les faits, les données alimentant l'Entrepôt de données sont hétérogènes, issues de différentes applications de production, voire de fichiers dits "plats" (fichiers Excel, fichiers texte, XML...). Il s’agit alors de les intégrer, de les homogénéiser et de leur donner un sens unique compréhensible par tous les utilisateurs. La transversalité recherchée sera d’autant plus efficace que le système d’information sera réellement intégré dans sa globalité. Cette intégration nécessite notamment :
une forte activité de normalisation et de rationalisation, orientée vers la qualité ;
une bonne gestion des référentiels, incluant une vérification constante de leur intégrité ;
une parfaite maîtrise de la sémantique et des règles de gestion des métadonnées manipulées. La problématique de l'intégration repose sur la standardisation de données internes à l'entreprise, mais aussi des données externes (provenant par exemple de clients ou de fournisseurs). Ce n’est qu’au prix d’une intégration poussée que l’on peut offrir une vision homogène et véritablement transverse de l’entreprise. Ceci suppose que le système d’information de l’entreprise en amont soit bien structuré, bien maîtrisé, et bénéficie déjà d’un niveau d’intégration suffisant. Si tel n'est pas le cas, la mauvaise qualité des données peut empêcher la mise en œuvre de l'entrepôt de données.
Historisation L'historisation d'un Datawarehouse repose sur le principe de conservation des données (ou de non-volatilité des données). Afin de conserver la traçabilité des informations et des décisions prises, les données une fois entrées dans l'Entrepôt sont stables, en lecture seule, non modifiables par les utilisateurs. Une même requête lancée plusieurs fois à différents moments doit ainsi restituer les mêmes résultats. Dès qu’une donnée est qualifiée pour être introduite dans l'Entrepôt de données, elle ne peut donc plus être altérée, modifiée ou supprimée (jusqu'à un certain délai de purge). Elle devient, de fait, partie intégrante de l’historique de l’entreprise. Le principe de non-volatilité tranche avec la logique des systèmes de production, qui bien souvent remettent à jour les données par « annule et remplace » à chaque nouvelle transaction. Chaque donnée collectée se voit affecter une date ou un numéro de version pour éviter de recouvrir une information déjà présente dans la base de données, et permettre de suivre son évolution au cours du temps. Il y a de cette manière conservation de l'historique. D’un point de vue fonctionnel, cette propriété permet de suivre dans le temps l’évolution des indicateurs et de réaliser des analyses comparatives (par exemple, les ventes d'une année sur l'autre). De ce fait, dans un entrepôt de données, un référentiel de temps unique est nécessaire.
Organisation fonctionnelle L'Entrepôt de données intègre au sein d'une même base les informations provenant de multiples applications opérationnelles. On passe ainsi d’une vision verticale de l’entreprise, dictée par des contraintes techniques, à une
vision transversale, dictée par le besoin métier, qui permet de croiser fonctionnellement les informations. 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 (services) de l’entreprise. On dit que l'Entrepôt de données est orienté « métier », en réponse aux différents métiers de l’entreprise dont il prépare l’analyse. D'un point de vue conceptuel, les données d'un Data warehouse sont interprétables sous forme d' indicateurs répartis selon des axes (ou dimensions) : par exemple, le nombre de clients (indicateur) réparti par jour de vente, magasin ou segment de clientèle (axes). Techniquement, la modélisation de l'Entrepôt de données peut matérialiser cette organisation sous forme de tables de fait ou et de tables de référentiel. L'Entrepôt de données a une structure de données qui peut en général être représentée par un modèle de données normalisé 3FN ((en)3NF) pour les données de détail et/ou en étoile ou en flocon pour les données agrégées et ce dans un SGBD relationnel (notamment lorsqu'il s'agit de données élémentaires ou unitaires non agrégées). La traduction technique de ce modèle se fait souvent au sein d'un cube OLAP. L'Entrepôt de données est conçu pour contenir les données en adéquation avec les besoins de l’organisation, et répondre de manière centralisée à tous les utilisateurs. Il n’existe donc pas de règle unique en matière de stockage ou de modélisation. Ainsi, ces données peuvent donc être conservées :
de préférence, sous forme élémentaire et détaillée (exemple : pour une banque, chaque opération sur chaque compte de chaque client) si la volumétrie le permet. Lesdonnées élémentaires présentent des avantages évidents (profondeur et niveau de détail, possibilité d'appliquer de nouveaux axes d'analyse et même de revenir a posteriorisur le
« passé ») mais représentent un plus grand volume et nécessitent donc des matériels plus performants.
éventuellement, sous forme agrégée selon les axes ou dimensions d'analyse prévus (mais ces agrégations sont plutôt réalisées dans les datamarts que dans les entrepôts de données proprement dits). Les données agrégées présentent d'autres avantages (facilité d'analyse, rapidité d'accès, moindre volume). Par contre, il est impossible de retrouver le détail et la profondeur des indicateurs une fois ceux-ci agrégés : on prend le risque de figer les données selon une certaine vue avec les axes d'agrégation retenus, et de ne plus pouvoir revenir sur ces critères si l'on n'a pas conservé le détail (par exemple, si l'on a agrégé les résultats par mois, il ne sera plus possible de faire une analyse par journée).
IV-Architecture d’un Data warehouse 1- Les Bases de Données • Bases de production de l’entreprise • Bases créées par les utilisateurs • Bases de données externes à l’entreprise (Nielsen, INSEE, …) qui nécessitent leur identification, leur rapatriement et leur intégration. 2- Opérations sur les données EXTRACTION •
Extraire les données de leur environnement d’origine (bases de données relationnelles, fichiers plats, …).
•
Utiliser une technique appropriée pour n ’extraire que les données nécessaires : données créées ou modifiées depuis
la dernière opération d’extraction. TRANSFORMATION •
Une même donnée peut avoir une structure ou une valeur différente en fonction de la base (production, externe, utilisateurs) dont elle provient.
• On peut être confronté à des redondances (un même client peut apparaître avec différents attributs et propriétés selon la source consultée). • Il faut supprimer certaines données aberrantes qui risqueraient de fausser les analyses. • Il faut donc épurer et transformer les données.
CHARGEMENT/RAFRAICHISSEMENT •
Effectuer sur les données des opérations de calcul et d’agrégation.
•
Remplacer certaines bases si d’extraction satisfaisante n’est possible.
aucune
solution
• Mettre en place des procédures de chargement (nocturnes?) et de restauration (en cas de problème). • Si la disponibilité du système ne peut être interrompue, envisager la mise en place de systèmes redondants.
• LES OUTILS • On peut automatiser tout ou partie des opérations décrites. • Des outils sont disponibles : Extract d’ETI, Genio de Leonard ’s Logic, …
• Le développement d’outils spécifiques est envisageable mais risque d ’alourdir les tâches. 3- Les Data-Marts • Un data-mart est un DW focalisé sur un sujet particulier, souvent au niveau départemental ou métier. • C ’est donc un mini DW lié à un métier particulier de l ’entreprise (finance, commercial, …). • Un DW est souvent volumineux (plusieurs centaines de Go voire quelques To ) avec des performances inappropriées (temps de réponse trop longs). Un Data-mart, quant à lui, comporte moins de 50 Go, ce qui permet des performances acceptables. • La création d’un data-mart peut être un moyen de débuter un projet de DW (projet pilote).
4-Les bases multidimensionnelles et les outils OLAP 1-Les modèles de données • Le modèle d ’intégration unifie les données opérationnelles. • Le modèle de diffusion représente le modèle conceptuel des données. Il correspond aux bases multidimensionnelles (serveur OLAP). • Le modèle de présentation est un complément au modèle conceptuel. C’est à travers ce modèle que l’utilisateur voit les données. Il correspond à différents outils physiques : les tableurs, les requêteurs, les outils clients OLAP, etc
Processing)
2-Les outils OLAP (On-Line Analytical
• OLAP caractérise l’architecture nécessaire à la mise en place d ’un système d ’information décisionnel. • OLAP s’oppose à OLTP (On-Line Transactional Processing) qui caractérise les SIO.
3 -Les outils relationnels OLAP Outils relationnels : requêteurs, infocentres, jointures complexes exemple : Business Objects Hypercubes relationnels : les données sont stockées dans une BD relationnelle, mais avec une structure adaptée aux données multi-dimensionnelles exemple : SGBD relationnels OLAP relationnel (ROLAP) : ces outils utilisent directement le modèle relationnel. Au travers des méta-données, ils permettent de transformer l’analyse multidimensionnelle en requêtes SQL : distinguent les axes d ’analyse et les faits à observer (modèles en étoile ou en flocon)
V-Autour de l'entrepôt de données : En amont En amont de l'entrepôt de données se place toute la logistique d'alimentation des données de l'entrepôt :
extraction des données de production, transformations éventuelles et chargement de l'entrepôt (c'est l'ETL ou Extract, Transform and Load ou encore datapumping). au passage les données sont épurées ou transformées par :
un filtrage et une validation des données (les valeurs incohérentes doivent être rejetées)
un codage (une donnée représentée différemment d'un système de production à un autre impose le choix d'une représentation unique pour les futures analyses)
une synchronisation (s'il y a nécessité d'intégrer en même temps ou à la même « date de valeur » des événements reçus ou constatés de manière décalée)
une certification (pour rapprocher les données de l'entrepôt des autres systèmes « légaux » de l'entreprise comme la comptabilité ou les déclarations réglementaires). Cette alimentation de l'entrepôt de données se base sur les données sources issues des systèmes transactionnels de production, sous forme de :
compte-rendu d'événement ou compte-rendu d'opération : c'est le constat au fil du temps des opérations (achats, ventes, écritures comptables, ...), le film de l'activité de l'entreprise ou flux ;
compte-rendu d'inventaire ou compte-rendu de stock : c'est l'image photo prise à un instant donné (à une fin de période : mois, trimestre, ...) de l'ensemble du stock (clients, contrats, commandes, encours...). La mise en place d'un système d'alimentation fiable de l'entrepôt de données est souvent le poste budgétaire le plus coûteux dans un projet d'informatique décisionnelle.
En aval
En aval de l'entrepôt de données (et/ou des datamarts) se place tout l'outillage de restitution et d'analyse des données (en anglais : Business Intelligence) :
outils de requêtage ou de reporting
cubes ou hypercubes multidimensionnels
data mining. La conception d'entrepôts de données est donc un processus en perpétuelle évolution. Sous cet angle, on peut finalement voir l'entrepôt de données comme une architecture décisionnelle capable à la fois de gérer l'hétérogénéité et le changement et dont l'enjeu est de transformer les données en informations directement exploitables par les utilisateurs du métier concerné.
VI-Comparatif entre les bases de données de l'entreprise
Caractéristique
Base de données de
Data warehouses
Datamarts
production Opération
Modèle de
gestion courante,
référentiel,
analyse récurrente, outil
production
analyse
de pilotage, support à la
ponctuelle
décision
3NF, étoile, flocon
étoile, flocon de neige
entité/relation
données Normalisation
de neige fréquente
maximum
rare (redondance d'information)
Données
actuelles, brutes,
historisées,
détaillées
détaillées
historisées, agrégées
Mise à jour
souvent différée,
souvent différée,
périodique
périodique
faible
faible
Elevé
Perception
verticale
transverse
Horizontale
Opérations
lectures, insertions,
lectures,
lectures, insertions, mises
mises à jour,
insertions, mises
à jour, suppressions
suppressions
à jour
en gigaoctets
en téraoctets
Niveau de
immédiate, temps réel
consolidation
Taille
en gigaoctets
Ces différences tiennent au fait que les Entrepôts permettent des requêtes qui peuvent être complexes et qui ne reposent pas nécessairement sur une table unique. On peut résumer les conséquences de la transformation d'un Data warehouse en Datamart comme suit : un gain de temps de traitement et une perte de puissance d'utilisation. Exemples de requêtes OLAP :
Quel est le nombre de paires de chaussures vendues par le magasin « OnVendDesChaussuresIci » en mai 2003 ET Comparer les ventes avec le même mois de 2001 et 2002
Quelles sont les composantes des machines de production ayant eu le plus grand nombre d’incidents imprévisibles au cours de la période 1992-97 ? Les réponses aux requêtes OLAP peuvent prendre de quelques secondes à plusieurs minutes, voire plusieurs heures.
Histoire Les principales dates à retenir construisant l'histoire de l'entrepôt de données sont les suivantes :
Années 1960 - General Mills et l'Université Dartmouth, dans un projet conjoint, créent les termes faits et dimensions.
1983 - Teradata introduit dans sa base de données managériale un système exclusivement destiné à la prise de décision.
1988 - Barry Devlin et Paul Murphy publient l'article Une architecture pour les systèmes d'information financiers (An architecture for a business and information systems) où ils utilisent pour la première fois le terme Datawarehouse.
1990 - Red Brick Systems crée Red Brick Warehouse, un système spécifiquement dédié à la construction de l'entrepôt de données.
1991 - Bill Inmon publie Building the Data Warehouse (Construire l'entrepôt de données).
1995 - Le Data Warehousing Institute, une organisation à but lucratif destinée à promouvoir le data warehousing, est fondé.
1996 - Ralph Kimball publie The Data Warehouse Toolkit (La boîte à outils de l'entrepôt de données).
VII-Etudes de cas I-
Cas d’une compagnie d’assurance Une compagnie d’assurance de biens (automobile, immobilier, responsabilité civile) possède une application transactionnelle de production permet de gérer les polices (contrats) de ses clients ainsi que les sinistres (accidents) déclarés par ces clients. Gestion des polices : Pour gérer les polices, les agents d’assurance peuvent effectuer les transactions suivantes : Créer, mettre à jour ou supprimer une police d’assurance Créer, mettre à jour ou supprimer un risque (pour une police donnée) Créer, mettre à jour ou supprimer des biens assurés (voiture, maison) sur un risque Chiffrer ou refuser le risque Valider ou refuser la police
On enregistre dans ces transactions un grand nombre d’informations, et notamment : date d’écriture (date de la transaction), date d’effet (date de début d’assurance), client (personne(s) privée(s), personne morale), opérateur (employé, agent: chiffrage, vérificateur : validation), risque (produit vendu par la compagnie d’assurance), couverture (description des biens assurés), police (numéro de police, « note » de la police ou du risque,…) , transaction (code transaction).
Gestion des sinistres Pour gérer les sinistres déclarés par les clients, les agents d’assurance ont à leur disposition les transactions suivantes : Créer, mettre à jour ou supprimer une déclaration de sinistre Créer, mettre à jour ou supprimer une expertise Créer, mettre à jour ou supprimer des paiements Clore le sinistre Ces transactions comportent notamment : date d’écriture (date de la transaction), date d’effet (date de déclaration), client, opérateur, risque, biens sinistrés, police, les tiers impliqués dans le sinistre, les montants financiers (limites, déjà payé, reste à payer, …), code transaction.
Conception
A partir de cette application transactionnelle, on veut créer un Datawarehouse permettant de répondre aux questions suivantes : Pour chaque bien assuré, on veut connaître le montant de la prime (somme annuelle payée par le client pour assurer le bien) associée au bien assuré, et le nombre de transactions du mois pour ce bien. De même on veut pouvoir sortir des tableaux de bord par sinistre avec le total payé dans ler mois et le total reçu dans le mois pour ce sinistre.
1. Faire le schéma en étoile d’un Datamart « Police » ne prenant pas en compte les sinistres. 2. De même, faire le schéma en étoile d’un Datamart « Sinistre ». 3. Faire un seul Datawarehouse de ces deux Datamarts. Année Académique 2009-2010 Cours & TD Datawarehouse
II-Cas d’une banque
Une banque distribue une carte de paiement « carte de crédit » à ses clients. Elle décide de réaliser un Datawarehouse (DW) afin de faire le suivi des paiements suivants effectués avec la carte : a. Voyages en avion, b. Locations de voiture, c. Hôtellerie. Elle veut faire un suivi indépendant de chacun des paiements a, b ou c, mais aussi avoir la possibilité d’un suivi global. A chaque déplacement en avion, la compagnie aérienne lui envoie un fichier contenant les éléments suivants: identification de la carte de paiement, coordonnées du client et de la compagnie aérienne; ville de départ, ville d’arrivée, n° du vol, date du vol, n° du billet, classe du siège, distance parcourue, date d’achat et prix payé. Les loueurs de véhicule transmettent après chaque location: identification de la carte de paiement, coordonnées du client et de la société de location de véhicules, catégorie du véhicule, date de début de location, date de fin de location, nombre de jours, distance parcourue, date de réservation et prix payé. L’hôtel transmet à chaque séjour: identification de la carte de paiement, coordonnées du client et de l’hôtel, catégorie de chambre, date de début de séjour, date de fin de séjour, nombre de nuitées, date de réservation, prix de l’hébergement et prix de la restauration. 1. Un premier DW ne concerne que les déplacements en avion. Etablir le modèle dimensionnel. Faire clairement apparaître les dimensions et les indicateurs. Ce
DW doit permettre de répondre aux questions suivantes : quel est le chiffre d’affaires (CA) par Client , par date de voyage (et par mois, trimestre et année), par compagnie aérienne, par ville de destination ? 2. De même, établir deux autres modèles dimensionnels, l’un pour les locations de voiture, l’autre pour l’hôtellerie. Dans le cas de la location de voiture, on souhaite éditer le CA, le nombre de jours de location, et le kilométrage pour chaque: client, date de réservation, ville, loueur, et catégorie de véhicule. Dans le cas de l’hôtellerie, on veut des tableaux de bord par client, hôtel, ville, date de début de séjour, catégorie de chambre, faisant apparaître le nombre de nuitées, le prix total payé. 3. On veut maintenant regrouper ces trois DW en un seul, afin de répondre aux questions supplémentaires suivantes : Quel est le CA total induit par un déplacement en avion ? Quelle est la durée du séjour ? Quel est le CA en location de voiture ? En hôtellerie ? On désire ici pouvoir éditer les détails de CA par période de temps et par client, ville de destination, ville de location (si différente), ville d’hébergement (si différente), compagnie aérienne, loueur et hôtelier, et faire tous les regroupements utiles. Figurer le modèle dimensionnel d’un tel DW, en faisant clairement apparaître les dimensions et les indicateurs.
