Schéma flocon de neige vs schéma en étoile

Lors du choix d'un schéma de base de données pour un entrepôt de données, flocon de neige et schémas en étoile ont tendance à être des choix populaires. Cette comparaison traite de la pertinence des schémas étoile par rapport au schéma en flocon de neige dans différents scénarios et de leurs caractéristiques..

Tableau de comparaison

Tableau comparatif schéma flocon de neige et schéma en étoile

Schéma de flocon de neige	Schéma en étoile
Facilité de maintenance / changement	Aucune redondance, les schémas en flocon de neige sont donc plus faciles à gérer et à modifier.	A des données redondantes et donc moins facile à maintenir / changer
Facilité d'utilisation	Requêtes plus complexes et donc moins faciles à comprendre	Requis moins complexe et facile à comprendre
Performance de la requête	Plus de clés étrangères et donc plus de temps d'exécution de la requête (plus lent)	Moins de clés étrangères et donc moins de temps d'exécution de la requête (plus rapide)
Type d'entrepôt de données	Bon à utiliser pour le noyau de l'entrepôt de données afin de simplifier les relations complexes (plusieurs: beaucoup)	Bon pour les datamarts avec des relations simples (1: 1 ou 1: plusieurs)
Jointures	Plus grand nombre de jointures	Moins de jointures
Table de dimension	Un schéma de flocon de neige peut avoir plusieurs tables de dimensions pour chaque dimension.	Un schéma en étoile ne contient qu'une seule table de dimension pour chaque dimension.
Quand utiliser	Lorsque le tableau des dimensions est relativement grand, le flocon de neige est préférable car il réduit l'espace.	Lorsque la table de dimension contient moins de lignes, nous pouvons choisir le schéma en étoile.
Normalisation / Dé-normalisation	Les tables de dimension sont sous forme normalisée, mais la table de faits est sous forme non normalisée.	Les tables de dimensions et de faits sont sous forme non normalisée.
Modèle de données	Une approche en profondeur	Approche descendante

Contenu: schéma flocon de neige vs schéma en étoile

• 1 exemples
  • 1.1 Exemple de schéma en étoile
  • 1.2 Exemple de schéma flocon de neige
• 2 références

Exemples

Prenons une base de données pour un détaillant qui compte de nombreux magasins, chacun d'entre eux vendant de nombreux produits appartenant à de nombreuses catégories de produits et de différentes marques. Un entrepôt de données ou un datamart pour un tel détaillant devrait permettre aux analystes de générer des rapports sur les ventes groupés par magasin, date (ou mois, trimestre ou année), catégorie de produit ou marque..

Exemple de schéma en étoile

Si ce magasin de données utilisait un schéma en étoile, il se présenterait comme suit:

Exemple de schéma en étoile

La table de faits serait un enregistrement des transactions de vente, alors qu'il existe des tables de dimension pour la date, le magasin et le produit. Les tables de dimension sont chacune connectées à la table de faits via leur clé primaire, qui est une clé étrangère pour la table de faits. Par exemple, au lieu de stocker la date de transaction réelle dans une ligne de la table de faits, le date_id est stocké. Cet identificateur de date correspond à une ligne unique de la table Dim_Date. Cette ligne stocke également d'autres attributs de la date requis pour le regroupement dans les rapports. par exemple, jour de la semaine, mois, trimestre de l’année, etc. Les données sont dénormalisées pour un reporting plus facile.

Voici comment obtenir un rapport sur le nombre de téléviseurs vendus par marque et par pays à l'aide de liens internes..

Exemple de schéma de flocon de neige

Le même scénario peut également utiliser un schéma de flocon de neige, auquel cas il serait structuré comme suit:

Exemple de schéma de flocon de neige (cliquez pour agrandir)

La principale différence, par rapport au schéma en étoile, est que les données des tables de dimension sont plus normalisées. Par exemple, au lieu de stocker le mois, le trimestre et le jour de la semaine dans chaque ligne de la table Dim_Date, ceux-ci sont ensuite divisés en leurs propres tables de dimension. De même pour la table Dim_Store, l'état et le pays sont des attributs géographiques supprimés en une étape. Au lieu d'être stockés dans la table Dim_Store, ils sont désormais stockés dans une table Dim_Geography séparée..

Le même rapport - le nombre de téléviseurs vendus par pays et par marque - est maintenant un peu plus compliqué que dans un schéma en étoile:

Requête SQL pour obtenir le nombre de produits vendus par pays et par marque, lorsque la base de données utilise un schéma en flocon de neige.

Références

• wikipedia: Snowflake_schema
• wikipedia: Star_schema