Qu'est-ce qu'un schéma en étoile, et quand normaliseriez-vous plutôt une dimension en flocon ?

Un schéma en étoile a une table de faits entourée de tables de dimension dénormalisées, si bien que la plupart des requêtes n'ont besoin que d'une jointure par dimension. Le flocon normalise une dimension en sous-tables, ce qui économise du stockage et centralise les attributs partagés, mais ajoute des jointures. Sur un entrepôt en colonnes, le stockage est bon marché et les jointures coûtent plus cher que la duplication : l'étoile est donc le choix par défaut. Passez au flocon quand la dimension est vraiment volumineuse, hiérarchique ou partagée entre de nombreux marts.

Une étoile, c'est une table de faits à une granularité définie, avec des dimensions dénormalisées accrochées autour, si bien qu'un analyste écrit une jointure par dimension et obtient des noms de colonnes lisibles. C'est mon choix par défaut, parce que sur un entrepôt en colonnes, répéter un nom de pays sur deux millions de lignes se compresse à presque rien, et la petite dimension part en broadcast de toute façon. Le flocon prend du sens quand la dimension est réellement volumineuse et hiérarchique, par exemple une dimension produit avec un arbre de catégories que plusieurs marts doivent partager, puisque maintenir cette hiérarchie à un seul endroit vaut mieux que la dupliquer cinq fois. Le point que je soulèverais avant l'un ou l'autre, c'est la granularité. Décider que la table de faits est à une ligne par ligne de commande plutôt que par commande détermine tout en aval, et se tromper là-dessus produit le classique bug de revenus comptés deux fois. J'ai déjà dû reconstruire un mart parce que la granularité était mélangée, et c'est bien plus coûteux que n'importe quel débat sur la normalisation.