Entrepôt de données

Un article de Wikipédia, l'encyclopédie libre.

L'entrepôt de données, ou datawarehouse, est un concept spécifique de l'informatique décisionnelle, issu du constat suivant : les données de l'informatique de production (également appelée « informatique transactionnelle »), notamment les progiciels de gestion intégrés (ou ERP, Enterprise Resource Planning) ne se prêtent pas à une exploitation dans un cadre d'analyse décisionnelle.

Les systèmes de production sont en effet construits dans le but de traiter des opérations individuelles qui peuvent impliquer différents métiers de l'entreprise et surtout, ne se préoccupent pas de leur compilation ou historisation dans le temps. À l'inverse, les systèmes décisionnels doivent permettre l'analyse par métiers ou par sujets et le suivi dans le temps d'indicateurs calculés ou agrégés. Il est donc souvent indispensable de séparer ces deux mondes et de repenser les schémas de données, ce qui implique l'unification des différents gisements de données de l'entreprise en un entrepôt de données global (datawarehouse) ou dédié à un sujet/métiers (datamart).

Sommaire

[modifier] Les principes

Un datawarehouse est un entrepôt de données (une base de données) qui se caractérise par des données :

  • orientées « métiers » ou business (par exemple, pour une banque un compte débiteur sera agrégé avec les prêts accordés par la banque et non pas avec les autres comptes restés créditeurs, à la différence de ce qui se passe dans la comptabilité et le système de production d'origine). L’objectif d’un datawarehouse est la prise de décisions autour des activités majeures de l’entreprise. Dans un datawarehouse, les données sont ainsi structurées par thèmes par opposition à celles organisées, dans les systèmes de production, par processus fonctionnel. 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. On peut ainsi passer d’une vision verticale de l’entreprise à une vision transversale beaucoup plus riche en informations. On dit que le Datawarehouse est orienté « métier », en réponse aux différents métiers de l’entreprise qu’il est censé préparer à l’analyse.
  • présentées selon différents axes d'analyse ou « dimensions » (par exemple : le temps, les types ou segments de clientèle, les différentes gammes de produits, les différents secteurs régionaux ou commerciaux, etc.). Il est utile de préciser que le Datawarehouse est conçu pour contenir les données en adéquation avec les besoins actuels et futurs de l’organisation, et répondre de manière centralisée à tous les utilisateurs. Ainsi, il n’y a pas de règle puriste qui s’applique en matière de stockage, ni de modélisation unique : le datawarehouse peut contenir certaines informations détaillées, issues des sources de production, nécessaires à un besoin de pilotage opérationnel récurrent, tout comme des tables de faits, prêtes à l’emploi.
  • non volatiles : stables, en lecture seule, non modifiables. Afin de conserver la traçabilité des informations et des décisions prises, les informations stockées au sein du Datawarehouse ne doivent pas disparaître. Une même requête lancée plusieurs fois, et ce à des mois d’intervalle, sur une même population doit restituer les mêmes résultats. Ainsi, dès lors qu’une donnée a été qualifiée pour être introduite au sein du Datawarehouse, elle ne peut ni être altérée, ni modifiée, ni supprimée (ou en tout cas en deçà d’un certain délai de purge). Elle devient, de fait, partie prenante de l’historique de l’entreprise. Cette caractéristique diffère de la logique des systèmes de production qui bien souvent remettent à jour les données par annule et remplace à chaque nouvelle transaction.
  • intégrées en provenance de sources hétérogènes ou d'origines diverses (y compris des fichiers externes de cotation ou de scoring). Dans un monde idéal, les systèmes d’informations sources (systèmes de production) sont homogènes et l’entreprise dispose de la connaissance parfaite de toutes les codifications dont elle a besoin pour tirer parti de son capital informationnel. Dans la réalité, les données, issues de différentes applications de production, existent sous des formes différentes. Il s’agit alors de les intégrer afin 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 efficiente que le système d’information sera réellement intégré. Cette intégration nécessite une forte normalisation, une bonne gestion des référentiels et de la cohérence, une parfaite maîtrise de la sémantique et des règles de gestion s’appliquant aux données manipulées. Elle concerne des données internes mais aussi des données externes qui posent des problèmes car leur codification et leur niveau de détail différent de ceux des données internes. Ce n’est qu’au prix d’une intégration « réussie » que l’on peut offrir une vision homogène et cohérente de l’entreprise via ses indicateurs. Ceci suppose que le système d’information de l’entreprise soit déjà bien structuré, bien maîtrisé, et bénéficie d’un niveau d’intégration suffisant. Si tel n’était pas le cas, la qualité des données peut empêcher la bonne mise en œuvre du Datawarehouse.
  • archivées et donc datées : avec une conservation de l'historique et de son évolution pour permettre les analyses comparatives (par exemple, d'une année sur l'autre, etc.). La non-volatilité permet l’historisation. D’un point de vue fonctionnel, cette propriété permet de suivre dans le temps l’évolution des différentes valeurs des indicateurs à analyser. De fait, dans un Datawarehouse un référentiel de temps est nécessaire. C’est l’axe temps ou période.

Ces données sont conservées dans le datawarehouse :

  • de préférence sous forme élémentaire et détaillée (exemple : chaque opération sur chaque compte de chaque client, ...) si la volumétrie le permet,
  • é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 datawarehouses proprement dits).

Les donné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 posteriori sur le « passé ») mais représentent un plus grand volume et nécessitent donc des matériels plus performants.

Les données agrégées présentent d'autres avantages (facilité d'analyse, rapidité d'accès, moindre volume) mais il n'est pas toujours possible de retrouver le détail et la profondeur des indicateurs une fois ceux-ci agrégés et figés : on prend le risque de figer les données dans une certaine vue, selon les axes d'agrégation retenus, et de ne plus pouvoir revenir plus tard 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 peut-être plus possible de faire une analyse par journée).

L'entrepôt de données de type datawarehouse a une structure de données :

  • en général, représentée par un modèle de données de type normalisé pour les données de détail et/ou en étoile ou en flocon pour les données aggrégées et ce dans un SGBD relationnel (notamment lorsqu'il s'agit de données élémentaires ou unitaires non agrégées)
  • éventuellement multidimensionnelle, stockée dans un cube ou hypercube M-OLAP (mais ces structures sont plutôt réservées aux données agrégées des datamarts).

L'application de ces différents principes amène une rupture avec l'ancien concept d'Infocentre. Etre à même de gérer ses activités en s'aidant de tableaux de bord et de moyens d'analyse à posteriori, c'est bien mais totalement insuffisant dans le monde compétitif d'aujourd'hui où le fait de pouvoir comprendre ce qui s'est passé et d'être simplement réactif ne permet pas d'envisager de prendre le leadership sur un marché. Il convient de pouvoir être beaucoup plus actif, il faut pouvoir être préactif, interactif et même proactif. Pour cela il ne s’agit plus seulement d’exploiter des données historiques plus ou moins fraîches, stockées dans un « data warehouse », mais d’opérer un véritable couplage entre l’entrepôt de données et les systèmes opérationnels de façon à être en mesure de toujours fournir au moment voulu une analyse pour l’action, s’appuyant sur la confrontation de données immédiates et d’informations historiques : c’est le concept de l’entrepôt de données actif. La mise en œuvre de ce concept a pour effet concret de faire passer les moyens décisionnels de l’entreprise d’un rôle « passif » à un rôle « actif ». La bonne définition de l’intelligence active est le « juste à temps », c'est-à-dire la bonne information au bon moment, au bon endroit et donc au bon acteur, qu’il s’agisse d’une personne ou d’un système.

[modifier] En amont et en aval

En amont du datawarehouse 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 du datawarehouse 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
  • 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 (les clients, les contrats, les commandes, les encours, ...).

La mise en place d'un système d'alimentation fiable du datawarehouse est souvent le poste budgétaire le plus coûteux dans un projet d'informatique décisionnelle.

En aval du datawarehouse (et/ou des datamarts) se place tout l'outillage de restitution et d'analyse des données (en anglais : Business Intelligence) :

Le datawarehousing est donc un processus en perpétuelle évolution. Sous cet angle, on peut finalement voir le datawarehouse 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é.

[modifier] Différences entre les bases et les entrepôts de données

Caractéristique Base de données Entrepôt de données
Opération gestion courante, production analyse, support à la décision
Modèle de données entité/relation 3NF, étoile, flocon de neige
Normalisation fréquente plus rare dans les data marts
Données actuelles, brutes historisées, parfois agrégées
Mise à jour immédiate, temps réel souvent différée
Niveau de consolidation faible élevé
Perception bidimensionnelle multidimensionnelle
Opérations lectures, mises à jour, suppressions lectures, analyses croisées, rafraîchissements
Taille en gigaoctets en téraoctets



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.

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.

[modifier] Architecture d'un entrepôt de données

Un entrepôt de données est généralement construit selon une architecture en 3 strates :

  1. d'un serveur d'entrepôt (serveur de données)
  2. d'un serveur OLAP (de type HOLAP/MOLAP ou ROLAP)
  3. d'un client

[modifier] Citation

« Un datawarehouse ne s'achète pas, il se construit. » (Citation généralement attribuée à Bill Inmon, un des précurseurs du concept de datawarehouse)

« Un datawarehouse 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 ». (Bill Inmon, en 1994)

[modifier] Voir également

[modifier] Autres articles

[modifier] Liens externes