Schéma en étoile (Star schema)

0
136

La définition

La modélisation dimensionnelle structure les données d’une façon très différente de la structure en 3FN ( 3ième forme normale) fréquemment utilisée par les modélisateurs des systèmes OLTP. La modélisation dimensionnelle produit ce qu’on appelle le modèle dimensionnel ou communément le schéma en étoile. C’est la structure de données la plus utilisée et la plus appropriée aux requêtes et analyses des utilisateurs d’entrepôts de données. Elle est simples à créer, stable et intuitivement compréhensible par les utilisateurs finaux. Le modèle dimensionnel est la fondation même de la construction des cubes OLAP.

Il consiste en une grande table de faits ( fact table) et un cercle d’autres tables qui contiennent les éléments descriptifs du fait, appelées « dimensions ». Quand illustré, le modèle ressemble à une étoile, c’est d’ailleurs l’origine du terme « En étoile ».

La figure suivante illustre le schéma en étoile (star schema) :

PageLines- OLAP-Northwind.gif

Première Composante : Table de faits.

Table qui contient les données observables (les faits) que l’on possède sur un sujet et que l’on veut étudier, selon divers axes d’analyse (les dimensions). Les « faits », dans un entrepôt de données, sont normalement numériques, puisque d’ordre quantitatif. Il peut s’agir du montant en argent des ventes, du nombre d’unités vendues d’un produit, etc.Les tables de faits représentent des associations dont l’existence d’une occurrence dépend de l’existence des occurrences correspondantes dans les tables dimensionnelles, c’est-à-dire la table de fait contient l’ensemble des mesures correspondant aux informations de l’activité à analyser. Mais rappelons que certaines tables de faits peuvent contenir aucun attribut et représentent que des liaisons entre tables dimensionnelles.Tous les éléments qui pointent sur la table de faits sont liés à une sémantique exprimable par une phrase. Par conséquent, la table de faits est la matérialisation d’une association entre entités.

Structure de base d’une table de faits

Une table de faits devrait avoir la structure suivante :

Caractéristiques d’une table de faits :

  • Une table de faits contient les valeurs numériques de ce qu’on désire mesurer;
  • Une table de fait contient les clés associées aux dimensions. Il s’agit des clés étrangères dans la table de faits;
  • En général une table de fait contient un petit nombre de colonnes;
  • Une table de fait contient plus d’enregistrements qu’une table de dimension;
  • Les informations dans une table de fait sont caractérisées par :
  • Elles sont numériques et sont utilisées pour faire des SUM, AVG…
  • Les données doivent être additives ou semi-additives;
  • Toutes les colonnes représentant les faits (mesure1, mesure2.. dans la figure 1)  dans la table de fait doivent référer et avoir un lien direct aux clés de dimensions

Deuxième composante : Table de dimension

Table qui contient les axes d’analyse (les dimensions) selon lesquels on veut étudier des données observables (les faits) qui, soumises à une analyse multidimensionnelle, donnent aux utilisateurs des renseignements nécessaires à la prise de décision.On appelle « dimension » un axe d’analyse. Il peut s’agir des clients ou des produits d’une entreprise, d’une période de temps comme un exercice financier, des activités menées au sein d’une société, etc.
On appelle donc « dimension » un axe d’analyse. Il peut s’agir des clients ou des produits d’une entreprise, d’une période de temps comme un exercice financier, des activités menées au sein d’une société, etc.

Structure de base d’une dimension

Une dimension devrait avoir la structure suivante :

Table de dimension

Caractéristiques d’une dimension :

  • Une table de dimension contient le détail sur les faits;
  • Une table de dimension contient les informations descriptives des valeurs numériques de la table de faits;
  • Vu que les données dans la table de dimensions sont normalisées, elle contient un plus grand nombre de colonnes;
  • Une table de dimension contient en général beaucoup moins d’enregistrement qu’une table de faits;
Les attributs d’une table de dimension sont souvent utilisés comme « Lignes » et « Colonne » dans un rapport ou résultat de requête. Par exemple, les attributs textuels d’un rapport proviennent souvent d’une dimension

Composantes d’une dimension :

Composante 1 : surrogate key  ou clé de substitution

La Définition
Une clé de substitution (surrogate key) est une clé non intelligente utilisée afin de substituer la clé naturelle (business key) qui provient des systèmes opérationnels. La clé naturelle est en général composée de plusieurs colonnes.
La clé de substitution ne doit pas être confondue avec la clé artificielle attribuée par les systèmes opérationnels. Du fait qu’il est parfois (voire même souvent) impossible de trouver une clé naturelle pour les entités telles que client, employé, alors on crée une clé artificielle dans le système opérationnel afin d’identifier d’une façon unique un élément de l’entité: client_id pour l’entité client, et emp_id pour l’entité employé. Ces clés artificielles ne doivent pas changer dans le temps pour un client par exemple !
La clé de substitution est alors utilisée dans un entrepôt de données pour remplacer et compléter la clé artificielle du système opérationnel afin de rendre un élément unique dans la dimension.
Les Fonctionnalités
  1. Remplacer la clé naturelle : Effectivement une clé de substitution remplace la clé artificielle en terme d’utilisation, ce n’est plus la clé naturelle qui sera utilisé pour faire les jointures avec les tables de faits ou les autres tables de dimension (niveaux hiérarchiques dans le cas d’une dimension en flocons de neiges);
  2. Complèter l’information :La clé de substitution n’a aucun sens en terme d’affaire, elle est utilisée dans l’entrepôt de données seulement ! et on aura toujours besoin de la clé artificielle ou naturelle dans la dimension pour pouvoir faire la correspondance entre l’élément de dimension (un client par exemple) dans l’entrepôt de données et l’élément de la table des clients dans le système opérationnel.

Les avantages

  1. Performance : Accélère l’accès aux données du moment ou l’on va utiliser un index numérique vu que le type de données de la clé de substitution est numérique.
  2. Indépendance du système source : On ne peut garantir que la clé d’affaire ne change pas dans les systèmes sources.
  3. Historique des changements et granularité infinie : Si l’on désire garder l’historique des changements de la dimension selon certains critères (SCD) nous devons gérer la clé de substitution. Nous nous retrouverons facilement avec plusieurs enregistrements de la même clé d’affaire dans la dimension.
Composantes 2 : attributs
En plus de la clé de substitution et de la clé naturelle, d’autres attributs sont ajoutés à la dimension. Ces attributs sont descriptifs et représente l’information utile sur la dimension (le salaire d’un employé, l’adresse d’un client…).
Composantes 3: clés spéciales
Chaque table de dimension devrait contenir les colonnes suivantes :
  1. Date effective : c’est la date à la quelle l’enregistrement à été crée, de préférence dans le système d’enregistrements (System of records).
  2. Date retrait : C’est la date à laquelle l’enregistrement a été retiré du système d’enregistrements.
  3. Indicateur effectif : En général est ‘O’ si l’enregistrement est toujours actif (Date retrait non nulle), ‘N’ sinon.

D’autres colonnes peuvent être rajoutées selon le type de l’évolution lente (scd-slowly changing dimension) que l’on désire implanter. Pour le type 3, une colonne est ajoutée pour contenir la valeur avant le changement

Types de dimensions

Dimension dégénérée (Degenerate dimension)

La dimension dégénérée est une clé de dimension dans la table de fait qui est en général sans attribut. Par exemple No de bon de commande, No d’interruption de service, etc. Dans le cas de numéro de l’interruption de service, les utilisateurs veulent savoir par exemple « combien de fois un client a été interrompu dans une période de temps précise».
Vu qu’il s’agit d’une seule clé de dimension, nous évitons alors de créer une table de dimension, ce qui fait que cette table de dimension a dégénéré dans la table de fait, c’est pour cette raison que cette clé est appelée « dimension dégénérée »

Dimension causale (Causal dimension)

Il s’agit d’une dimension qui provoque des faits. Un bon exemple de ce genre de dimension est la dimension « Promotion » qui en général peut provoquer des ventes. Un autre exemple dans le domaine de la distribution de l’énergie la dimension « Condition climatique » peut provoquer des « interruptions de service ». La dimension « Condition climatique » est donc une dimension causale.

Junk dimension (Fourre-tout)

La dimension de genre « Junk dimension » est une dimension qui contient toutes sorte de flags, statuts, codes qui ne font partie d’aucune dimension régulière. Dans le domaine de la distribution de l’énergie, une interruption de service peut être de type « Basse tension » ou « Moyenne tension ». Ce genre de code est donc stocké dans une table spéciale appelée « Junk dimension ».

Dimension conforme (Conformed dimension)

On parle de dimension conforme ou partagée lorsque la dimension est utilisée par les faits de plus qu’un data mart. L’exemple le plus courant est la dimension « Produit » qui est utilisée par différents data mart «Finance », « Marketing »…

Dimension à évolution lente (Slowly changing dimension)

  1. Un client peut changer d’adresse, se marier, …
  2. Un produit peut changer de noms, de formulations « Tree ’s » en « M&M », « Raider » en « Twix »,« Yaourt à la vanille en Yaourt » en « saveur Vanille »

Nous gérons la situation en choisissant entre 3 solutions :

  1. Écrasement de l’ancienne valeur
  2. Versionnement
  3. Valeur d’origine / valeur courante

Dans certain cas la transition n’est pas immédiate : il reste pendant un certain temps des anciens produits en rayon il est alors conseillé de les traiter comme deux membres différents.

Dimension à évolution rapide (Rapid changing dimension)

Une dimension à changement rapide est une dimension qui subit des changements très fréquents des attributs dont on veut préserver l’historique. Par exemple si l’on veut préserver l’historique des changements d’adresse dans la dimension client dans un pays ou 70% de la population déménage une fois par année (le premier juillet par exemple au canada), la dimension client devient dans ce cas une dimension à évolution rapide.

Mini dimension

Dans tout entrepôt de données il existe au moins une grande dimension, que ce soit en terme d’enregistrements ou d’attributs. L’exemple le plus fréquent est la dimension « client » qui peut contenir des millions d’enregistrements. Le plus souvent on gère l’évolution lente (Voir même l’évolution rapide) sur ce genre de dimension ce qui augmente encore plus leurs tailles. Un moyen de réduire la taille de ce genre de dimension est soit de recourir à la technique de « flocon de neige » si la dimension est hiérarchique (Chaque niveau hiérarchique dans une table différente) ou encore créer une mini dimension, qui contient tous les attributs sur lesquels on gère l’évolution lente.

PARTAGER