Schéma du flocon de neige

En informatique , un schéma en flocon de neige ou modèle en flocon de neige est un arrangement logique de tables dans une base de données multidimensionnelle de telle sorte que le diagramme de relation entité ressemble à une forme de flocon de neige . Le schéma en flocon de neige est représenté par des tables de faits centralisées qui sont connectées à plusieurs dimensions . Le « snowflaking » est une méthode de normalisation des tables de dimension dans un schéma en étoile . Lorsqu'il est complètement normalisé sur toutes les tables de dimension, la structure résultante ressemble à un flocon de neige avec la table de faits au milieu. Le principe derrière le snowflaking est la normalisation des tables de dimension en supprimant les attributs de faible cardinalité et en formant des tables séparées.

Le schéma en flocon de neige est similaire au schéma en étoile. Cependant, dans le schéma en flocon de neige, les dimensions sont normalisées en plusieurs tables liées, alors que les dimensions du schéma en étoile sont dénormalisées, chaque dimension étant représentée par une seule table. Une forme complexe de flocon de neige émerge lorsque les dimensions d'un schéma en flocon de neige sont élaborées, avec plusieurs niveaux de relations, et que les tables enfants ont plusieurs tables parentes (« bifurcations sur la route »).

Les schémas en étoile et en flocon se trouvent le plus souvent dans les entrepôts de données dimensionnels et les data marts où la vitesse de récupération des données est plus importante que l'efficacité des manipulations de données. En tant que telles, les tables de ces schémas ne sont pas beaucoup normalisées et sont souvent conçues à un niveau de normalisation inférieur à la troisième forme normale .

La normalisation fractionne les données pour éviter la redondance (duplication) en déplaçant les groupes de données qui se répètent fréquemment dans de nouvelles tables. La normalisation tend donc à augmenter le nombre de tables qui doivent être jointes pour exécuter une requête donnée, mais réduit l'espace requis pour contenir les données et le nombre d'emplacements où elles doivent être mises à jour si les données changent.

Du point de vue de l'espace de stockage, les tables dimensionnelles sont généralement plus petites que les tables de faits. Cela annule souvent les avantages potentiels en termes d'espace de stockage du schéma en flocon par rapport au schéma en étoile. Exemple : un million de transactions de vente dans 300 magasins dans 220 pays donnerait lieu à 1 000 300 enregistrements dans un schéma en étoile (1 000 000 d'enregistrements dans la table de faits et 300 enregistrements dans la table dimensionnelle où chaque pays serait répertorié explicitement pour chaque magasin de ce pays). Un schéma en flocon plus normalisé avec des clés de pays faisant référence à une table de pays serait composé de la même table de faits de 1 000 000 d'enregistrements, d'une table de magasins de 300 enregistrements avec des références à une table de pays de 220 enregistrements. Dans ce cas, le schéma en étoile, bien que davantage dénormalisé, ne réduirait le nombre d'enregistrements que d'environ 0,02 % (négligeable) (= [1 000 000 + 300] au lieu de [1 000 000 + 300 + 220]).

Certains développeurs de bases de données font un compromis en créant un schéma en flocon sous-jacent avec des vues construites dessus qui effectuent la plupart des jointures nécessaires pour simuler un schéma en étoile. Cela offre les avantages de stockage obtenus grâce à la normalisation des dimensions avec la facilité d'interrogation qu'offre le schéma en étoile. Le compromis est que le fait d'obliger le serveur à effectuer automatiquement les jointures sous-jacentes peut entraîner une baisse des performances lors de l'interrogation ainsi que des jointures supplémentaires vers des tables qui peuvent ne pas être nécessaires pour répondre à certaines requêtes.

Le schéma en flocon de neige appartient à la même famille que le modèle logique du schéma en étoile . En fait, le schéma en étoile est considéré comme un cas particulier du schéma en flocon de neige. Le schéma en flocon de neige offre certains avantages par rapport au schéma en étoile dans certaines situations, notamment :

• Certains outils de modélisation de bases de données multidimensionnelles OLAP sont optimisés pour les schémas en flocon de neige.
• La normalisation des attributs entraîne des économies de stockage, le compromis étant une complexité supplémentaire dans les jointures de requêtes sources.

Le principal inconvénient du schéma en flocon est que les niveaux supplémentaires de normalisation des attributs ajoutent de la complexité aux jointures de requêtes sources, par rapport au schéma en étoile .

Les schémas en flocons de neige, contrairement aux dimensions de table unique plates, ont été fortement critiqués. Leur objectif est supposé être un stockage efficace et compact de données normalisées, mais cela se fait au prix de mauvaises performances lors de la navigation dans les jointures requises dans cette dimension. Cet inconvénient a peut-être diminué au cours des années qui ont suivi sa première reconnaissance, grâce à de meilleures performances de requête dans les outils de navigation.

L'exemple de schéma illustré à droite est une version en flocon de neige de l'exemple de schéma en étoile fourni dans l' article sur le schéma en étoile .

L'exemple de requête suivant est l'équivalent du schéma en flocon de neige de l'exemple de code du schéma en étoile qui renvoie le nombre total d'unités de télévision vendues par marque et par pays pour 1997. Notez que la requête du schéma en flocon de neige nécessite beaucoup plus de jointures que la version du schéma en étoile pour répondre à une requête même simple. L'avantage de l'utilisation du schéma en flocon de neige dans cet exemple est que les besoins en stockage sont moindres puisque le schéma en flocon de neige élimine de nombreuses valeurs en double des dimensions elles-mêmes.

SÉLECTIONNEZ 
B. Marque , G. Pays , SUM ( F . Unités_Vendues ) DE Fact_Ventes F INNER JOIN Dim_Date D SUR F. Date_Id = D. Id INNER JOIN Dim_Magasin S SUR F. Magasin_Id = S. Id INNER JOIN Dim_Géographie G SUR S. Géographie_Id = G. Id INNER JOIN Dim_Produit P SUR F. Produit_Id = P. Id INNER JOIN Dim_Marque B SUR P. Marque_Id = B. Id INNER JOIN Dim_Catégorie_Produit C SUR P. Catégorie_Produit_Id = C. Id OÙ D. Année = 1997 ET C. Catégorie_Produit = ' tv ' GROUP BY B. Marque , G. Pays​​​​​​​​​​​​​​​​