Data warehouse

Le terme entrepôt de données (data warehouse) désigne une base de données utilisée pour collecter et stocker de manière définitive des informations volatiles provenant d'autres bases de données. Chaque information 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 l'évolution de cette information au cours du temps.

Parfois les informations des différentes bases de données d'une entreprise sont collectées dans un seul entrepôt de données, ou alors il existe différents entrepôts de données en fonction du sujet ou du métier en rapport avec chaque information (datamart).

Les informations collectées serviront à faire des statistiques, des recherches et des rapports. Les entrepôts de données sont utilisés notamment en informatique decisionnelle.

Sommaire 1 Les principes 2 En amont et en aval 3 Différences entre les bases et les entrepôts de données 4 Architecture 5 Histoire 6 Citations 7 Voir aussi 7.1 Articles connexes 7.2 Liens externes

Les principes

L’objectif d’un data warehouse est la prise de décisions autour des activités majeures de l’entreprise. Dans un data warehouse, 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 data warehouse 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.). Le data warehouse 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 data warehouse 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 data warehouse 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 data warehouse, 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 data warehouse.
• 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 data warehouse 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 data warehouse :

• 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 data warehouses 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 data warehouse a une structure de données :

• en général, 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)
• é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. Être à même de gérer ses activités en s'aidant de tableaux de bord et de moyens d'analyse a 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.

En amont et en aval

En amont du data warehouse 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 data warehouse 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 data warehouse est souvent le poste budgétaire le plus coûteux dans un projet d'informatique décisionnelle.

En aval du data warehouse (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.

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

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.

Architecture

Un entrepôt de données est généralement construit selon une architecture en trois 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
   • outil pour l'exécution des requêtes ;
   • outil pour l'analyse des données.

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 and 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 datawarehousing, est fondé.
• 1996 - Ralph Kimball publie "The Data Warehouse Toolkit", "La boîte à outils de l'Entrepôt de données".

Citations

• « Un entrepôt de données ne s'achète pas, il se construit. » - Citation généralement attribuée à Bill Inmon, un des précurseurs du concept d'entrepôt de données

• « Un entrepôt de données 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

Voir aussi

Articles connexes

• Les grands éditeurs de bases de données pour entrepôt de données : IBM, Oracle, Teradata, Microsoft et Sybase IQ.
• Datamart
• Datamining
• Modèle de données dit "en étoile" ou "en flocon"
• Executive Information System
• Hypercubes multidimensionnels
• Informatique décisionnelle
• M-OLAP, R-OLAP, H-OLAP, S-OLAP

Liens externes

• Journées francophones sur les entrepôts de données et l'analyse en ligne (EDA)

• Portail de l’informatique