Identifier le projet

1. Deux éléments distincts

Il convient dorénavant de distinguer clairement "entrepôt de données" (datawarehouse) et "magasins de données" (datamarts). En caricaturant, une description donne :

Si les magasins de données sont des sous-ensembles de l’entrepôt, l’ensemble des magasins de données ne représente pas forcément l’entrepôt. En effet, l’entrepôt de données est susceptible de contenir plus de données (en périmètre ou en détail) que l’ensemble des magasins de données. Et inversement, le périmètre d’un datamart n’est pas exclusif et peut se recouper avec le périmètre d’un autre.

Pour les critères de modélisation, à savoir le nombre, la durée de rétention, la granularité et la fréquence de chargement, les caractéristiques de l’entrepôt sont contraintes à la fois par celles des magasins de données et par celles des données sources. D’une part, ces caractéristiques...

1. Inmon : de l’entrepôt aux magasins

Dans les années 1990, William Inmon propose une vision descendante de la structuration de la donnée de l’entreprise, dite "top-down".

L’entrepôt de donnée a pour rôle de rassembler toutes les données de l’entreprise, et les magasins de données sont alors des sous-parties issues de cet entrepôt.

La mise en place de l’entrepôt de données nécessite une grande phase d’étude et de recueil du besoin afin de connaître l’intégralité des besoins analytiques et pouvoir réaliser l’entrepôt.

2. Kimball : des magasins à l’entrepôt

Ralph Kimball propose une vision radicalement différente, ascendante, de la structuration de la donnée, dite "bottom-up".

Les besoins de l’entreprise sont modélisés dans les magasins de données, l’entrepôt de données n’est par la suite qu’une simple union de ses magasins de données.

Cette approche incrémentale permet une mise en place plus rapide, car le besoin final est directement traduit dans les magasins de données et il n’est pas nécessaire d’avoir une vision exhaustive des données pour commencer la réalisation. Cependant, la mise en place de l’entrepôt en aval des magasins nécessite un plus grand travail d’intégration à cause des différences de conception et de cohérence entre les magasins développés de manières plus indépendantes. Cette indépendance dans la création des magasins peut aussi entraîner une certaine redondance dans les données.

En contrepartie, l’élargissement à un nouveau métier est relativement simple : le nouveau métier apporte son magasin de données qu’il suffit "d’ajouter" dans l’entrepôt de données.

1. Les différents rôles de l’entrepôt de données

Objet central du système décisionnel, l’entrepôt de données en est indissociable puisqu’il a été conceptualisé pour ces systèmes. Bien qu’il porte le nom d’entrepôt, celui-ci n’est pas qu’une accumulation de tables sans réflexion, sorte de base de données fourre-tout en vue de rassembler toutes les données d’une entreprise au sein d’une même base de données. Ceci était le concept de l’infocentre en vogue jusque dans les années 1990 avant que celui-ci ne montre ses limites et évolue logiquement vers le datawarehouse.

L’entrepôt de données est la frontière entre l’opérationnel et le décisionnel : tout ce qui se trouve en amont est une donnée technique, orientée application, alors que tout ce qui se trouve en aval est une donnée décisionnelle et orientée objet.

Outre les volumes de données supposément importants qui y sont intégrés, les transformations complexes et importantes qui ont lieu sur la donnée entrante dans le datawarehouse justifient l’emploi de logiciels d’intégration de données - les fameux ETL - en lieu et place de simples requêtes de bases de données. C’est au moment d’y être intégrée, que la donnée est "repensée", comme dit lors du chapitre précédent. Les transformations suivantes sont donc nécessaires :

L’entrepôt de données n’est rien d’autre qu’un concept, une modélisation. Techniquement il repose sur des systèmes de bases de données relationnelles traditionnelles. Il est d’ailleurs courant que l’entreposage des données opérationnelles non transformées dans l’ODS (Operational Data Store) en vue de leur intégration et transformation et le datawarehouse, soient hébergés sur le même serveur ainsi que la même instance...

1. L’ODS

Déjà évoquée de nombreuses fois depuis le début de l’ouvrage, l’ODS (pour Operational Data Storage ou Store), pouvant être traduit en "base de données opérationnelle") est une réplication des données reçues par le système. Bien qu’intégrée dans le SID, elle ne fait pas partie de la base de données décisionnelle !

Le rôle de cette base de données est de conserver une copie des données opérationnelles sources, à leur format brut. Cela permet :

1. Avant-propos

Les aspects technologique et technique du SID sont primordiaux, mais d’un projet à un autre, la question est à traiter différemment. Ces choix peuvent être faits (ou imposés) en amont de la modélisation et ainsi, contraindre cette dernière. Inversement, une modélisation maîtresse du projet contraint les choix technologiques et techniques.

Ainsi, même d’un point de vue maîtrise d’ouvrage, ces points sont soit à spécifier pour régir les choix technologiques, soit à prendre en compte pour limiter le modèle au domaine du possible techniquement : durée de rétention, granularité, historisation, périmètre du projet…

2. Contraintes technologiques