Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Du 22 au 24 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Modélisation décisionnelle
  3. Identifier le projet
Extrait - Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP
Extraits du livre
Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP Revenir à la page d'achat du livre

Identifier le projet

Entrepôts et magasins de données

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 :

  • Entrepôt de données : exhaustivité des données de l’entreprise au format décisionnel caractérisée par un périmètre large et une fine granularité. Son rôle est de stocker toutes les données susceptibles de servir à une restitution ou analyse.

  • Magasins de données : partie des données de l’entreprise au format décisionnel caractérisée par un périmètre restreint et une granularité modérée en adéquation avec les besoins d’une analyse ou d’une restitution. Son rôle est de préparer les données pour répondre de manière optimale à une restitution ou analyse.

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.

images/5-1.png
images/5-1b.png

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

Méthodologies de conception

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.

images/5-3.png

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.

  • Avantages :

  • Des données exhaustives

  • Des données cohérentes

  • Inconvénient :

  • Mise en place longue

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.

images/5-4.png

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.

  • Avantages :

  • Rapidité de mise en place

  • Meilleure adaptabilité

  • Inconvénients :

  • Union parfois difficile des magasins de données

  • Vision moins exhaustive dans l’entrepôt...

Formaliser l’entrepôt et les magasins 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 :

  • Harmonisation des données et des formats de données.

  • Regroupement des données par objet métier.

  • Historisation des données.

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

La base de données opérationnelle

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 :

  • D’avoir un premier contrôle simple sur les données (contrôle du format des colonnes uniquement).

  • Dans le cas où la source de données est constituée de fichiers plats : pouvoir charger les données du datawarehouse à partir d’une base de données relationnelle plutôt que de fichiers plats (qui en fait, auront été chargés au préalable dans l’ODS).

  • Dans le cas où la source de données est une base de données externe : pouvoir disposer en local des données pour plus tard, sans ne plus avoir besoin de solliciter la base source.

  • Sauvegarder les données opérationnelles brutes au-delà des limites de rétention du système source.

  • Disposer des données...

Identifier les contraintes

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

a. Processus de choix des technologies

Les choix technologiques sont primordiaux et doivent impérativement être définis au démarrage du projet, avec en question prioritaire : "avec ou sans OLAP ?" Parle-t-on uniquement de base de données décisionnelle relationnelle, ou bien est-elle en interaction avec une base de données multidimensionnelle ?

À vrai dire, aujourd’hui, les projets décisionnels sans multidimensionnel se font rares tant les apports en termes de réactivité et de fonctionnalités analytiques avancées apportent une réelle valeur ajoutée par rapport à une solution construite sur du relationnel. Cependant, dans un projet d’envergure réduite et à l’évolutivité réduite (voire nulle) des rapports dans le temps, une solution sans OLAP est encore cohérente et peut éviter un sensible investissement en temps, main-d’œuvre qualifiée et coût de la licence.

Au-delà du simple choix de la présence ou non de l’OLAP, les différences entre le produit d’un éditeur et celui d’un autre ne sont pas négligeables et peuvent influencer sur les modélisations comme le choix d’un modèle en étoile ou en flocon. Le choix de la solution de reporting est également conditionné par ce choix, puisque chaque éditeur a naturellement choisi de privilégier l’interaction entre ses différents produits plutôt...