Que ce soit à partir d’un EDW, d’un ODS ou d’un OLTP, voici les étapes à suivre pour convertir le modèle Entités/Relations à un modèle dimensionnel et plus spécifiquement le schéma en étoile (star schema) :
Identifier le processus d’affaire à partir du modèle E/R;
Identifier les tables de relations n-à-n ( many-to-many) à convertir en tables de faits;
Dénormaliser les autres tables en dimensions aplaties;
Identifier le temps dans le modèle E/R
Ces étapes sont détaillées dans les sections suivantes.
Cerner le processus d’affaires dans le modèle E/R.
Un modèle E/R d’un système OLTP, d’un EDW ou d’un ODS consiste en plusieurs processus d’affaires. Un modèle E/R d’un système ERP, par exemple, est composé des processus suivants : gestion de ventes, gestion des approvisionnements, gestion de stocks, gestion des commandes...

Figure 1 : Un modèle E/R de l’entreprise consiste en plusieurs processus d’affaires
Identifier les tables qui représentent les relations n-à-n dans le modèle E/R.
Après avoir identifié et séparé les différents processus d’affaires, l’étape suivante consiste en la découverte des tables qui représentent les relations n-à-n dans le modèle E/R et les convertir en tables de faits. Ce genre de table de relations contient en général des attributs numériques et additifs qui deviennent ce qu’on appelle les mesures ou faits dans les tables de faits.
Qu’est ce qu’une table qui représente une relation n-à-n ?
C’est une table qui permet de lier deux tables ayant une relation n-à-n, par exemple, la table ventes permet de lier la table des produits avec celle des clients. Pourquoi n-à-n ? Parce qu’un client peut acheter un ou plusieurs produits et un produit peut être vendu à un ou plusieurs clients.
Comment identifier ces tables de relations n-à-n ?
Chaque modèle E/R contient en général deux sortes de tables :
Les tables transactionnelles : Dans ces tables on insère, met à jour ou détruit fréquemment des données. Par exemple, la table des commandes et celles des lignes de commandes sont des tables transactionnelles.
Les tables « statiques » : Il existe d’autres tables comme celles des clients, des employés ou produits qui sont le plus souvent statiques, on effectue rarement des transactions là-dessus. Elles représentent le contexte dans lequel une transaction a été effectuée.
Les tables transactionnelles qui représentent une relation n-à-n sont alors converties en tables de faits. Cependant il faut bien noter que l’on ne prend pas la table au complet pour en faire une table de fait, rappelez-vous qu’une table de faits est constituée souvent et seulement de clés étrangères, mesures et dimensions dégénérées. Ne faites donc pas l’erreur de copier la table des ventes, y ajouter quelques colonnes, et dire que c’est ça votre table de faits !!!!
Dénormaliser les autres tables pour créer les tables de dimensions
L’étape finale consiste à dénormaliser toutes les autres tables (Si elles sont nécessaires à votre besoin d’affaires) dans le but de créer des dimensions. On utilise souvent un autre terme pour traduire ce mécanisme de dénormalisation, on parle souvent d’aplatissement des tables de dimension !
Par « autres tables » nous insinuons ce que nous avons appelé les tables « statiques » dans la section précédente.
Par « Aplatissement » nous voulons dire :
La troisième forme normale force la règle de normalisation des données, le modèle dimensionnel la défait. Donc toutes les tables qui ont un lien 1-à-n et représente le contexte de la transaction sous un même angle sont regroupées dans une seule table appelée dimension. Ces niveaux de relation 1-à-n du spécifique au général sont appelés niveaux hiérarchiques de la dimension. On dit donc que la dimension est aplatie, vu que tous ses niveaux hiérarchiques sont stockés dans la même table. Une autre alternative est le schéma en flocons de neige..
Extraire la dimension temps à partir du modèle E/R
La dernière étape concerne la définition de la dimension temps.
En général les dates sont stockées dans des colonnes de type Date dans le modèle E/R, elles se retrouvent souvent dans les tables transactionnelles.