Le schéma en étoile

Aujourd'hui, les rapports et les analyses sont presque aussi importants que le cœur de métier. Les rapports peuvent être créés à partir de vos données en direct ; souvent, cette approche fera l'affaire pour les petites et moyennes entreprises qui ne disposent pas de beaucoup de données. Mais lorsque les choses deviennent plus importantes - ou que la quantité de données commence à augmenter de façon spectaculaire - il est temps de penser à séparer vos systèmes opérationnels et de reporting.

Avant d'aborder la modélisation de base des données, nous avons besoin de quelques informations sur les systèmes impliqués. Nous pouvons grossièrement diviser les systèmes en deux catégories :les systèmes opérationnels et les systèmes de rapport. Les systèmes opérationnels sont souvent appelés traitement des transactions en ligne (OLTP). Les systèmes de rapport et d'analyse sont appelés traitement analytique en ligne (OLAP). Les systèmes OLTP prennent en charge les processus métier. Ils fonctionnent avec des données opérationnelles "en direct", sont hautement normalisés et réagissent très rapidement aux actions des utilisateurs. D'autre part, l'objectif principal des systèmes OLAP est l'analyse. Ces systèmes utilisent des données résumées, qui sont généralement placées dans une structure d'entreposage de données dénormalisée comme le schéma en étoile. (Qu'est-ce que la dénormalisation ? En termes simples, il s'agit d'avoir des enregistrements de données redondants pour de meilleures performances. En savoir plus.)

Maintenant que nous en savons un peu plus sur les systèmes, commençons par examiner l'entrepôt de données, ses éléments et ses processus.

Entrepôts de données et datamarts

Un entrepôt de données (DWH) est un système utilisé pour stocker des informations à utiliser dans l'analyse des données et la création de rapports. Mart de données sont des zones d'un entrepôt de données utilisées pour stocker les informations nécessaires à un seul service ou même à un utilisateur individuel. (Considérez le DWH comme un bâtiment et les magasins de données comme des bureaux à l'intérieur du bâtiment.)

Pourquoi les datamarts sont-ils nécessaires ? Toutes les données pertinentes sont stockées au sein de la société DWH. Cependant, la plupart des utilisateurs n'ont besoin d'accéder qu'à certains sous-ensembles de données, comme celles relatives aux ventes, à la production, à la logistique ou au marketing. Les magasins de données sont importants à la fois du point de vue de la sécurité (limitant les accès inutiles) et du point de vue des utilisateurs (nous ne voulons pas les confondre ou les forcer à parcourir des données superflues).

Il existe deux approches différentes de la relation entre l'entrepôt de données et le magasin de données :

De haut en bas :Les magasins de données sont créés à partir de l'entrepôt de données. (C'est quelque chose avec lequel Bill Inmon, le "père de l'entrepôt de données", serait d'accord, ainsi que l'idée que les entrepôts devraient être en 3NF.)
Ascendant :Les magasins de données sont d'abord créés, puis combinés dans un entrepôt de données. (Cette approche est plus proche de ce que préconise Ralph Kimball, expert en entrepôt de données et en modélisation dimensionnelle.)

Le processus ETL est utilisé pour ajouter régulièrement de « nouvelles » données au système OLAP. ETL est l'abréviation de Extraire, Transformer et Charger. Comme son nom l'indique, nous allons extraire les données d'une ou plusieurs bases de données opérationnelles, les transformer pour les adapter à la structure de notre entrepôt et charger les données dans le DWH.

Modélisation dimensionnelle , qui fait partie de la conception de l'entrepôt de données, aboutit à la création du modèle dimensionnel. Deux types de tables sont concernés :

Tableaux de dimensions sont utilisés pour décrire les données que nous voulons stocker. Par exemple :un détaillant peut vouloir stocker la date, le magasin et l'employé impliqué dans un achat spécifique. Chaque table de dimension est sa propre catégorie (date, employé, magasin) et peut avoir un ou plusieurs attributs . Pour chaque magasin, nous pouvons enregistrer son emplacement au niveau de la ville, de la région, de l'état et du pays. Pour chaque date, nous pouvons stocker l'année, le mois, le jour du mois, le jour de la semaine, etc. Ceci est lié à la hiérarchie d'attributs dans la table de dimension.

Dans le schéma en étoile, nous constatons généralement que certains attributs sont un sous-ensemble d'autres attributs dans le même enregistrement. Cette redondance est délibérée et faite au nom d'une meilleure performance. Nous pourrions utiliser les dimensions de date, de lieu et d'agent commercial pour agréger (la partie transformation du processus ETL) et stocker les données dans DWH. Dans la modélisation dimensionnelle, il est très important de définir les bonnes dimensions et de choisir la bonne granulation.
Tableaux de faits contiennent les données que nous souhaitons inclure dans les rapports, agrégées en fonction des valeurs des tables de dimension associées. Une table de faits n'a que des colonnes qui stockent des valeurs et des clés étrangères référençant les tables de dimension. La combinaison de toutes les clés étrangères forme la clé primaire de la table de faits. Par exemple, une table de faits peut stocker un certain nombre de contacts et le nombre de ventes résultant de ces contacts.

Avec ces informations en place, nous pouvons maintenant creuser dans le modèle de données du schéma en étoile.

Le schéma en étoile

Le schéma en étoile est le modèle le plus simple utilisé dans DWH. Étant donné que la table de faits est au centre du schéma avec des tables de dimension autour d'elle, elle ressemble à peu près à une étoile. Cela est particulièrement évident lorsque la table de faits est entourée de tables à cinq dimensions. Une variante du schéma en étoile le schéma mille-pattes , où la table de faits est entourée d'un grand nombre de tables de petite dimension.

Les schémas en étoile sont très couramment utilisés dans les data marts. Nous pouvons les relier à l'approche du modèle de données descendant. Nous analyserons deux schémas en étoile (data marts) puis les combinerons pour créer un modèle unique.

Exemple de schéma en étoile :Ventes

Le rapport sur les ventes est l'un des rapports les plus courants d'aujourd'hui. Comme nous l'avons mentionné précédemment, dans la plupart des cas, nous pourrions générer des rapports de ventes à partir du système en direct. Mais lorsque les données ou la taille de l'entreprise rendent cela trop lourd, nous devrons construire un entrepôt de données ou un magasin de données pour rationaliser le processus. Après avoir conçu notre schéma en étoile, un ETL le processus obtiendra les données de la ou des bases de données opérationnelles, transformera les données dans le format approprié pour le DWH et chargera les données dans l'entrepôt.

Le modèle présenté ci-dessus contient une table de faits (colorée en rouge clair) et cinq tables de dimension (colorées en bleu clair). Les tables du modèle sont :

fact_sales – Ce tableau contient des références aux tableaux de dimensions plus deux faits (prix et quantité vendue). Notez que les cinq clés étrangères forment ensemble la clé primaire de la table.
dim_sales_type – Il s'agit d'une table de dimensions de type ventes avec un seul attribut, "type_name ”.
dim_employee – Il s'agit d'une table de dimension des employés qui stocke les attributs de base des employés :nom complet et année de naissance.
dim_product – Il s'agit d'une table de dimensions de produit avec seulement deux attributs (autres que la clé primaire) :le nom du produit et le type de produit.
dim_time – Cette table gère la dimension temporelle. Il contient cinq attributs en plus de la clé primaire. Les données de niveau le plus bas sont les ventes par date (action_date ). La action_week L'attribut est le numéro de la semaine de cette année (c'est-à-dire que la première semaine de janvier recevrait le numéro 1 ; la dernière semaine de décembre recevrait le numéro 52, etc.) Le actual_month et actual_year Les attributs stockent le mois et l'année du calendrier au cours desquels la vente a eu lieu. Ceux-ci peuvent être extraits de la action_date attribut. Le action_weekday l'attribut stocke le nom du jour où la vente a eu lieu.
dim_store – Il s'agit d'une dimension de magasin. Pour chaque magasin, nous enregistrerons la ville, la région, l'état et le pays où il se trouve. Ici, nous pouvons clairement remarquer que le schéma en étoile est dénormalisé.

Exemple de schéma en étoile :commandes de fournitures

Il existe de nombreuses similitudes entre ce modèle, illustré ci-dessous, et le modèle de vente.

Ce modèle est destiné à stocker l'historique des commandes passées. Nous avons une table de faits et quatre tables de dimension. Les tableaux de dimension dim_employee , dim_product et dim_time sont exactement les mêmes que dans le modèle de vente. Cependant, les tableaux suivants sont différents :

fact_supply_order – contient des données agrégées sur les commandes passées.
dim_supplier – est une table de dimensions qui stocke les données des fournisseurs de la même manière que dim_store conserver les données du magasin dans le modèle de vente.

Avantages et inconvénients du schéma en étoile

L'utilisation du schéma en étoile présente de nombreux avantages. La table de faits est liée à chaque table de dimension par exactement une relation, et nous n'avons pas besoin de dictionnaires supplémentaires pour décrire les tables de dimension. Cela simplifie les requêtes et diminue le temps d'exécution des requêtes. Nous pourrions produire le même rapport directement à partir de notre système OLTP, mais la requête serait beaucoup plus complexe et pourrait affecter les performances globales du système. L'exemple de requête suivant pour le modèle de vente renverra la quantité de tous les types de produits de type téléphone vendus dans les magasins de Berlin en 2016 :

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Le principal inconvénient du schéma en étoile est la redondance. Chaque dimension est stockée dans une table de dimension distincte, ce qui entraîne une dénormalisation. Dans notre exemple, la ville appartient à une région ou à un état, qui appartient à un pays ; nous ne stockons pas cette relation en règle générale dans notre base de données, mais nous la répétons continuellement. Cela signifie que nous dépenserons plus d'espace disque et que nous aurons un risque pour l'intégrité des données.

Le Schéma Galactique

Nous pouvons considérer les deux modèles précédents comme deux data marts, l'un pour le service des ventes et l'autre pour le service des approvisionnements. Chacun d'eux se compose d'une seule table de faits et de quelques tables dimensionnelles. Si nous le voulions, nous pourrions combiner ces deux magasins de données en un seul modèle. Ce type de schéma, contenant plusieurs tables de faits et partageant certaines tables de dimensions, est appelé un schéma de galaxie . Le partage de tables de dimension peut réduire la taille de la base de données, en particulier lorsque les dimensions partagées ont de nombreuses valeurs possibles. Idéalement, dans les deux magasins de données, les dimensions sont définies de la même manière. Si ce n'est pas le cas, nous devrons ajuster les dimensions pour répondre aux deux besoins.

Un schéma de galaxie, construit à partir de nos deux exemples de magasins de données, est présenté ci-dessous :

Le schéma en étoile est une approche pour organiser un entrepôt de données. Il est très simple et est le plus souvent utilisé dans les magasins de données. Si nous n'avons pas à nous soucier de l'espace disque et que nous prenons bien soin de l'intégrité des données, alors le schéma en étoile est un premier et meilleur choix viable. Sinon, nous devrions penser à une autre approche. L'un est le schéma du flocon de neige, dont nous parlerons dans un prochain article.