Datawarehouse est un anglicisme signifiant entrepôt de données. Il 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.

Les informations collectées peuvent provenir de plusieurs bases de données. Parfois les informations des différentes bases de données d'une entreprise sont collectées dans un seul datawarehouse, ou alors il existe différents datawarehouse 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 décisionnelle.

Un peu d'histoire

Apparu au début des années 1990 et mis en avant par W. Inmon et par R. Kimball, des spécialistes du monde des bases de données : « Un système de DW organise et conserve les données nécessaires aux processus informationnels et analytiques dans une perspective de long terme. Ce système correspond à un ensemble de données orientées selon un sujet, intégrées, évoluant dans le temps et non volatiles, qui a pour but l'aide aux processus de prise de décision de gestion. » (Inmon, 1996).

En outre, un DW intègre d’une manière systématique des métadonnées afin de fournir un référentiel unique à l’ensemble des utilisateurs.

Ce qui constitue alors l’originalité d’un système de DW réside dans le fait que les SAD (Systèmes d'aide à la décision) n’interrogent plus directement les bases transactionnelles. En effet, l’entrepôt de données est une base de données dont la structure est orientée vers la prise de décision et qui se positionne entre les applications transactionnelles et les SAD.

Le principal avantage qui a conduit à la généralisation de ce type d’architecture est qu’elle ne replace pas l’architecture transactionnelle précédente, mais qu’elle s’insère dans un existant informatique. De plus cette architecture met clairement en lumière la différence qu’il peut exister entre une donnée et l’information qui en résulte après un processus d’interprétation. Ainsi, dans un système de DW, les décideurs ont accès aux mêmes données afin de se construire leurs propres informations.

Les DW sont, maintenant, bien implantés dans les organisations et ils constituent une architecture décisionnelle globale utilisée par l’ensemble des décideurs d’une organisation.

Rappelons toutefois, qu’au départ, les DW étaient destinés à un petit nombre de décideurs : les dirigeants de l’entreprise. En effet, le système ne pouvait supporter un grand nombre d’interrogations sur l’ensemble des données de l’entrepôt. Cependant, les décisions se prenant à tous les niveaux hiérarchiques, il a été nécessaire d’élargir le nombre de personnes pouvant avoir accès à cette architecture décisionnelle.

Plutôt que de donner un accès à l’entrepôt pour tous les utilisateurs, d’autres solutions ont été mises en oeuvre :

• pour les responsables de fonctions ou d’unités (niveau N-1), les marchés de données (Datamart) ont été crées. Ces marchés importent seulement une partie des données del’entrepôt afin de répondre plus rapidement à un besoin spécifique ;
• pour les cadres opérationnels ayant, par exemple, un contact direct avec la clientèle, un nouveau type d’application a été mis en oeuvre. Plutôt que d’interroger directement la base de données transactionnelle, le concept de magasin de données opérationnelles (Operational Data Store) a été développé. Ces magasins possèdent certaines caractéristiques des entrepôts de données (orientation « sujet » des données, par exemple) et d’autres des bases transactionnelles (processus de mis à jour des données, par exemple). Ils constituent, à ce jour, le dernier développement de l’architecture fondée sur des DW.

Ainsi, une véritable architecture décisionnelle destinée à l’ensemble des personnels de l’organisation se met en place. D’ailleurs, W. Inmon et C. Imhoff parlent de « Corporate Information Factory » (Inmon et al., 2000).

L’attention portée à la constitution d’une architecture technologique dédiée à la prise de décision a conduit à l’apparition d’un grand nombre de types de SAD.
Le tableau ci-dessous regroupe les différentes applications décisionnelles que l’on trouve en sortie d’un SAD :

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