Dans les deux articles précédents, nous avons examiné les deux modèles d'entrepôt de données les plus courants :le schéma en étoile et le schéma en flocon de neige. Aujourd'hui, nous allons examiner les différences entre ces deux schémas et nous vous expliquerons quand il est préférable d'utiliser l'un ou l'autre.
Le schéma en étoile et le schéma en flocon de neige sont des moyens d'organiser des magasins de données ou des entrepôts de données entiers à l'aide de bases de données relationnelles. Les deux utilisent des tableaux de dimensions pour décrire les données agrégées dans une table de faits .
Tout le monde vend quelque chose, que ce soit des connaissances, un produit ou un service. Le stockage de ces informations, soit dans un système opérationnel, soit dans un système de reporting, est également un besoin. Nous pouvons donc nous attendre à trouver un type de modèle de vente dans l'entrepôt de données de presque toutes les entreprises.
Jetons encore un coup d'œil au modèle de vente dans les schémas en étoile et en flocon de neige.
Le schéma en étoile
La caractéristique la plus évidente du schéma en étoile est que les tables de dimension ne sont pas normalisées. Dans le modèle ci-dessus, le fact_sales table stocke les données agrégées créées à partir de nos bases de données opérationnelles. Les tables bleu clair sont des tables de dimensions. Nous avons décidé d'utiliser ces cinq dimensions car nous devons créer des rapports en les utilisant comme paramètres. La granulation à l'intérieur de chaque dimension est également déterminée par nos besoins en matière de rapports.
À partir de ce modèle, nous pouvons facilement voir pourquoi ce schéma est appelé le "schéma en étoile" :il ressemble à une étoile, avec les tables de dimension entourant la table de faits centrale.
Le schéma du flocon de neige
Ce schéma en flocon stocke exactement les mêmes données que le schéma en étoile. La table de faits a les mêmes dimensions que dans l'exemple de schéma en étoile. La différence la plus importante est que les tables de dimension dans le schéma en flocon de neige sont normalisées. Il est intéressant de noter que le processus de normalisation des tables de dimensions s'appelle le snowflaking.
Encore une fois, visuellement, le schéma du flocon de neige nous rappelle son homonyme, avec plusieurs couches de tables de dimensions créant une forme irrégulière en forme de flocon de neige.
La première différence :la normalisation
Comme mentionné, la normalisation est une différence clé entre les schémas en étoile et en flocon de neige. À ce sujet, il y a deux choses à savoir :
- Les schémas Snowflake utiliseront moins d'espace pour stocker les tables de dimensions. En effet, en règle générale, toute base de données normalisée produit beaucoup moins d'enregistrements redondants .
- Les modèles de données dénormalisés augmentent les risques de problèmes d'intégrité des données. Ces problèmes compliqueront également les modifications et la maintenance futures.
- Pour les modélisateurs de données expérimentés, le schéma en flocon semble plus logiquement organisé que le schéma en étoile. (Ceci est mon opinion personnelle, pas un fait indéniable. :) )
Passons à la deuxième différence majeure entre ces deux schémas.
Deuxième différence :complexité des requêtes
Dans nos deux premiers articles, nous avons démontré une requête qui pourrait être utilisée sur le modèle de vente pour obtenir la quantité de tous les produits de type téléphone vendus dans les magasins de Berlin en 2016.
La requête de schéma en étoile ressemble à ceci :
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
Pour obtenir le même résultat à partir du schéma en flocon de neige, nous devons utiliser cette requête :
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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id WHERE dim_year.action_year = 2016 AND dim_city.city = 'Berlin' AND dim_product_type.product_type_name = 'phone' GROUP BY dim_store.store_id, dim_store.store_address
Évidemment, la requête de schéma en flocon de neige est plus complexe. Étant donné que les tableaux de dimensions sont normalisés, nous devons creuser plus profondément pour obtenir le nom du type de produit et la ville. Nous devons ajouter un autre JOIN pour chaque nouveau niveau à l'intérieur de la même dimension.
Dans le schéma en étoile, nous ne joignons la table de faits qu'avec les tables de dimension dont nous avons besoin. Au maximum, nous n'aurons qu'un seul JOIN par table de dimension. Et si nous n'utilisons pas de table de dimensions, nous n'avons même pas besoin de nous en soucier. Dans la requête de schéma en flocon de neige, nous ne savons pas jusqu'où nous devrons aller pour obtenir le bon niveau de dimension, ce qui complique le processus d'écriture des requêtes.
Joindre deux tables prend du temps car le DMBS met plus de temps à traiter la requête. Le dim_store et dim_city les tables sont placées à proximité dans notre modèle, mais elles peuvent ne pas être situées les unes à côté des autres sur le disque. Il est plus probable que les données soient physiquement plus proches sur le disque si elles résident dans la même table.
Fondamentalement, une requête exécutée sur un magasin de données de schéma en flocon de neige s'exécutera plus lentement. Mais dans la plupart des cas, cela ne posera pas de problème :peu importe si nous obtenons le résultat en une milliseconde ou une seconde.
Accélérer les choses
Pour accélérer la création de rapports, nous pouvons :
- Agréger les données au niveau dont nous avons besoin dans les rapports. Cela va considérablement comprimer les données. Nous devrons créer des procédures qui transformeront nos données en direct pour qu'elles s'intègrent dans la structure du schéma de création de rapports (le processus ETL).
- Construire une zone de stockage centrale pour tous les données agrégées de l'entreprise, et pas seulement les données sur les ventes.
- Donnez aux utilisateurs uniquement les données dont ils ont besoin pour l'analyse et les rapports.
Schémas flocon de neige et schémas en étoile :lequel devez-vous utiliser ?
Maintenant que nous avons examiné la théorie et la vitesse des requêtes, entrons dans le vif du sujet :comment savoir quel schéma utiliser pour un projet donné ?
Envisagez d'utiliser le schéma en flocon :
- Dans les entrepôts de données. Comme l'entrepôt est Data Central pour l'entreprise, nous pourrions économiser beaucoup d'espace de cette façon.
- Lorsque les tables de dimensions nécessitent une quantité importante d'espace de stockage. Dans la plupart des cas, les tables de faits seront celles qui occupent le plus d'espace. Ils augmenteront probablement aussi beaucoup plus rapidement que les tables de dimension. Mais il y a certaines situations où cela ne s'applique pas. Par exemple, les tables de dimension peuvent contenir de nombreux attributs redondants mais nécessaires. Dans notre exemple, nous avons utilisé la ville attribut pour décrire la ville où se trouve le magasin. Et si on voulait une description beaucoup plus détaillée de la ville, incluant la population, le code postal, les données démographiques, etc.? Décrire d'autres sous-dimensions – par exemple, magasin , région , état et pays – avec plus d'attributs transformerait le
dim_storetable de dimension en une grande table avec beaucoup de redondance. - Si vous utilisez des outils nécessitant un schéma en flocon de neige en arrière-plan. (Heureusement, la plupart des outils modernes prennent en charge les schémas et même le schéma de galaxie.)
Envisagez d'utiliser le schéma en étoile :
-
Dans les magasins de données. Les magasins de données sont des sous-ensembles de données extraites de l'entrepôt de données central. Ils sont généralement créés pour différents départements et ne contiennent même pas toutes les données d'historique. Dans ce paramètre, l'économie d'espace de stockage n'est pas une priorité.
En revanche, le schéma en étoile simplifie l'analyse. Il ne s'agit pas seulement d'efficacité des requêtes, mais aussi de simplification des actions futures pour les utilisateurs professionnels. Ils peuvent comprendre les bases de données et savoir écrire des requêtes, mais pourquoi compliquer les choses et inclure plus de jointures si nous pouvons l'éviter ? Un utilisateur professionnel peut avoir un modèle de requête qui joint la table de faits à toutes les tables de dimension. Ensuite, il leur suffit d'ajouter les sélections et les regroupements appropriés. (Cette approche est proche des tableaux croisés dynamiques d'Excel.)
- Si vous utilisez des outils qui nécessitent un schéma en étoile en arrière-plan. (Encore une fois, ce n'est généralement pas un problème.)
Le schéma en étoile et le schéma en flocon de neige sont tous deux des modèles relationnels utilisés pour organiser des entrepôts de données et/ou des magasins de données. Peu importe à quel point ils sont similaires, ils démontrent deux approches différentes et ont leurs propres avantages et inconvénients. Personnellement, j'opterais pour le schéma en flocon de neige lors de la mise en œuvre d'un entrepôt de données (pour économiser de l'espace de stockage) et avec le schéma en étoile pour les magasins de données (pour faciliter la vie des utilisateurs professionnels).
