Entrepôt de données

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

Vous avez de nouveaux messages (diff^?).

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

1 Les principes
2 En amont et en aval
3 Différences entre les bases et les entrepôts de données
4 Architecture d'un entrepôt de données
5 Citation
6 Voir également
- 6.1 Autres articles
- 6.2 Liens

[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étier » 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)
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.)
non volatiles : stables, en lecture seule, non modifiables,
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)
historisé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.).

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ées).

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 en étoile ou en flocon 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.

[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) :

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 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	étoile, flocon de neige
Normalisation	fréquente	plus rare
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 unique table.

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 :

d'un serveur d'entrepôt (serveur de données)
d'un serveur OLAP (de type HOLAP/MOLAP ou ROLAP)
d'un client
- outil pour l'exécution des requêtes
- outil pour l'analyse des données

[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)