Entrepôt de données

Un 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.

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.

Le concept de data warehousing remonte à la fin des années 1980 [4] lorsque les chercheurs d'IBM Barry Devlin et Paul Murphy ont développé le « business data warehouse ». Essentiellement, le concept d'entreposage de données visait à fournir un modèle architectural pour le flux de données des systèmes opérationnels aux environnements d'aide à la décision.

Le concept a tenté de répondre aux différents problèmes associés à ce flux, principalement les coûts élevés qui y sont associés. En l'absence d'une architecture d'entreposage de données, une énorme quantité de redondance était nécessaire pour prendre en charge plusieurs environnements d'aide à la décision. Dans les grandes entreprises, il était courant que plusieurs environnements d'aide à la décision fonctionnent de manière indépendante. Bien que chaque environnement servait des utilisateurs différents, ils nécessitaient souvent une grande partie des mêmes données stockées. Le processus de collecte, de nettoyage et d'intégration des données provenant de diverses sources, généralement des systèmes opérationnels existants à long terme (souvent appelés systèmes hérités), était en partie répliqué pour chaque environnement. De plus, les systèmes opérationnels étaient fréquemment réexaminés au fur et à mesure de l'émergence de nouveaux besoins d'aide à la décision. Souvent, les nouvelles exigences nécessitaient la collecte, le nettoyage et l'intégration de nouvelles données à partir de « datamarts » conçues pour un accès facile par les utilisateurs.

De plus, avec la publication de The IRM Imperative (Wiley & Sons, 1991) par James M. Kerr, l'idée de gérer et d'attribuer une valeur monétaire aux ressources de données d'une organisation, puis de déclarer cette valeur en tant qu'actif dans un bilan est devenue populaire. Dans le livre, Kerr a décrit un moyen de remplir des bases de données de domaines à partir de données dérivées de systèmes axés sur les transactions pour créer une zone de stockage où les données récapitulatives pourraient être davantage exploitées pour éclairer la prise de décision des dirigeants. Ce concept a servi à promouvoir une réflexion plus approfondie sur la manière dont un Data Warehouse pourrait être développé et géré de manière pratique au sein de toute entreprise.

Principaux développements au cours des premières années de l'entreposage de données :

• Années 1960 – General Mills et Dartmouth College, dans le cadre d'un projet de recherche conjoint, développent les termes dimensions et facts[5].
• Années 1970 – ACNielsen et IRI fournissent des magasins de données dimensionnelles pour les ventes au détail.
• Années 1970 – Bill Inmon commence à définir et à discuter du terme Data Warehouse.
• 1975 – Sperry Univac lance MAPPER (Maintain, Prepare, and Produce Executive Reports), un système de gestion de base de données et de reporting qui inclut le premier 4GL au monde. Il s'agit de la première plate-forme conçue pour la construction de centres d'information (un précurseur de la technologie contemporaine de Data Warehouse).
• 1983 – Teradata introduit l'ordinateur de base de données DBC/1012 spécialement conçu pour l'aide à la décision [6].
• 1984 – Metaphor Computer Systems, fondé par David Liddle et Don Massaro, publie un package matériel/logiciel et une interface graphique permettant aux utilisateurs professionnels de créer un système de gestion de base de données et d'analyse.
• 1985 - Sperry Corporation publie un article (Martyn Jones et Philip Newman) sur les centres d'information, où ils introduisent le terme Data Warehouse MAPPER dans le contexte des centres d'information.
• 1988 – Barry Devlin et Paul Murphy publient l'article « An architecture for a business and information system » où ils introduisent le terme « business data warehouse »[7].
• 1990 – Red Brick Systems, fondée par Ralph Kimball, lance Red Brick Warehouse, un système de gestion de base de données spécialement conçu pour l'entreposage de données.
• 1991 - James M. Kerr, auteurs de The IRM Imperative, qui suggère que les ressources de données pourraient être déclarées comme un actif dans un bilan, renforçant l'intérêt commercial pour la création d'entrepôts de données.
• 1991 – Prism Solutions, fondée par Bill Inmon, présente Prism Warehouse Manager, un logiciel de développement d'un Data Warehouse.
• 1992 – Bill Inmon publie le livre Building the Data Warehouse[8] .
• 1995 – Le Data Warehousing Institute, une organisation à but lucratif qui promeut l'entreposage de données, est fondé.
• 1996 – Ralph Kimball publie le livre The Data Warehouse Toolkit[9] .
• 2000 - Dan Linstedt publie dans le domaine public la modélisation Data Vault, conçue en 1990 comme une alternative à Inmon et Kimball pour fournir un stockage historique à long terme des données provenant de plusieurs systèmes opérationnels, en mettant l'accent sur le traçage, l'audit et la résilience au changement du modèle de données source.
• 2008 - Bill Inmon, avec Derek Strauss et Genia Neushloss, publie « DW 2.0: The Architecture for the Next Generation of Data Warehousing », expliquant son approche descendante de l'entreposage de données et forgeant l'expression terme data-warehousing 2.0.
• 2012 – Bill Inmon développe et fait connaître la technologie publique sous le nom de « textual disambiguation ». La désambiguïsation textuelle applique le contexte au texte brut et reformate le texte brut et le contexte dans un format de base de données standard. Une fois que le texte brut est passé à travers la désambiguïsation textuelle, il peut être facilement et efficacement accessible et analysé par la technologie de business intelligence standard. La désambiguïsation textuelle est accomplie par l'exécution d'ETL textuel. La désambiguïsation textuelle est utile partout où du texte brut est trouvé, comme dans les documents, Hadoop, les e-mails, etc.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Data warehouse » (voir la liste des auteurs).