Schéma décisionnel : en étoile ou en flocons de neige ?

0
98

Schéma en étoile Vs Schéma en flocons de neige.

A la question « Entre le schéma en étoile et le schéma en flocons de neige, quel est le modèle qui  présente la meilleure performance ? » une multitude de réponses existe ! Nous avons choisi celle de Mr Tom Haughey (Cliquez-ici pour accéder à la réponse en anglais) parce qu’elle permet de mettre en évidence la différence entre les deux schémas et ce en se basant sur des situations et cas réels.

Commençons tout d’abord par définir les deux modèles.

Un schéma en étoile est une structure dimensionnelle qui représente une seule table de faits entourée par un seul cercle de dimensions. Toute dimension à niveaux multiples est aplatie en une seule dimension. Le schéma en étoile est conçu pour répondre à des requêtes inhérentes à la structure dimension-fait.

Un schéma en flocons de neige est aussi une structure dans laquelle une seule table de faits est entourée par un seul cercle de dimensions. Cependant pour toute dimension à niveaux multiples au moins un niveau de dimension est géré dans une structure séparée des autres niveaux. Le schéma en flocons de neige est conçu pour répondre à des requêtes sur une dimension ayant des relations complexes entre ses niveaux. Le schéma en flocons de neige est approprié aux dimensions dont les niveaux sont reliés par des relations n à n et 1 à n.  Par ailleurs, le schéma en flocons de neige devient obligatoire pour une relation dimension-fait de n à n. Un bon exemple est la relation entre la table des clients et celle des polices d’assurance dans le domaine des assurances. Un client peut disposer de plusieurs polices d’assurance et une police d’assurance peut couvrir plusieurs clients. Les principales justifications à l’utilisation d’un schéma en étoile sont la performance et la facilité de compréhension. La simplicité est l’un des aspects attrayants du schéma en étoile. Alors que le schéma en étoile est généralement considéré comme la structure qui offre la meilleure performance, il n’est pas souvent le cas. En général, quand c’est faisable, le schéma en étoile devrait être le premier choix. Cependant quelques exceptions importantes existent. La suite de cette réponse adresse ces situations.

1 – La technologie

Certaines technologies telle que MicroStrategy requièrent un schéma en flocons de neige alors que d’autres comme Cognos requièrent le schéma en étoile. Facteur à ne pas négliger !

2 – La nature des requêtes

Certaines requêtes se prêtent mieux à la structure dimension-fait. Pas forcément toutes les requêtes mais quand c’est le cas un schéma en étoile est le meilleur choix.

3 – Besoins d’affaires spécifiques

Ils existent des besoins d’affaires qui ne peuvent tout simplement pas être structurés en schéma en étoile. La relation entre l’entité « client » et  l’entité « compte » dans le domaine bancaire, celle entre l’entité « client » et l’entité « police d’assurance » dans le domaine des assurances ne peuvent être représentées par un schéma en étoile à cause de la relation n à n qui lie ces entités. Vous n’avez pas d’autres choix raisonnables que de choisir un schéma en flocons de neige. Il existe plusieurs autres exemples analogiques. Le monde n’est pas une étoile et ne peut pas être forcé à s’y adapter !

4 – Besoin de flexibilité

Le schéma en flocons de neige devrait être utilisé lorsque l’on a besoin d’une plus grande flexibilité dans la corrélation à travers les niveaux et les composantes d’une dimension. L’avantage principal d’un flocon de neige est la plus grande flexibilité dans les données.

5 – Ratio Attributs Maître : Nombre de rangées Détail

Prenons l’exemple typique des données des « commandes » dans l’entrepôt de données. Le concepteur dimensionnel ne se poserait pas de question à aplatir la table des « commandes » et celle des « Lignes de commandes ». Cependant, considérez ce qui suit. Disons que 25 attributs communs à la commande sont dans la table des « commandes ». On vend des produits de consommation et une livraison typique contient 50 produits, on se retrouve ainsi avec 25 attributs ayant un ratio 1:50. Dans ce cas de figure, il serait excessivement encombrant d’aplatir la table des « commandes » et celle des « Lignes de commandes » pour réaliser le schéma en étoile. Dans une table de faits énorme on introduira beaucoup de redondance pour, disons, plus de 2 milliards de rangées. D’ailleurs, dans le modèle de Walmart, qui est un des plus célèbres, la table des « Commandes » n’est pas aplatie avec celle des « Lignes de commandes ». Cependant, si vous disposez d’un magasin de vidéos, avec peu d’attributs dans la transaction et un ratio moyen de 1:2, il serait mieux d’aplatir les deux tables en une seule table de fait.

6 – Gestion complexe de SCD

Prenons l’exemple de dimensions à évolution lente (Slowly Changing Dimensions). Disons que la dimension  « Employé » consiste en des données qui ne changent pas (Ou même si ça change ce n’est pas important, c à d de type 1) et d’autres données qui changent (type 2). Disons aussi que vous avez un intérêt envers les données de l’employés qui ne changent pas (Vous voulez toujours avoir la valeur courante) et non pas les données qui changent. Le modélisateur dimensionnel va donc mélanger les deux types de données en créant une dimension à évolution lente de type 2. Ce qui veut dire que le type 1 est absorbé par le type 2. J’ai travaillé sur des cas où le fait d’aplatir à causer plus de problèmes, il était mieux de scinder la dimension en deux tables « Employé » qui regroupe les attributs de type 1 et « employé historique » qui regroupe ceux de type 2.  De ce fait, quand il s’agit de cas complexe de gestion de l’évolution de dimension,  un schéma en flocons de neige est préférable.

7 – Difficulté de navigation dans les hiérarchies

Le constat que le schéma en étoile est plus compréhensible que le schéma en flocons de neige est complètement subjectif.  J’ai personnellement travaillé sur plusieurs entrepôts de données où les utilisateurs se sont plaints que dans le schéma en étoile, et parce que tout a été aplati, ils ne pouvaient pas comprendre les hiérarchies des dimensions.  C’était le cas, en particulier, quand la dimension est composée de plusieurs colonnes.

De la théorie à la pratique

Il serait profitable de passer de la théorie à la pratique en effectuant des tests. Chose faite, j’ai pris un modèle de données contenant une grande table des clients et je l’ai testé en tant que schéma en étoile et en flocons de neige. La dimension des clients est composée de plusieurs attributs.  Nous avons utilisé quelques 150 millions d’enregistrements. J’ai scindé la dimension des clients en trois tables avec des relations 1:1:1. Le schéma en flocons de neige était plus rapide. Pourquoi ? La dimension étant large (dans le sens que celle-ci contient plusieurs attributs), le SGBD pourrait traiter seulement un petit nombre d’enregistrements par page. Vu que Le SGBD utilise ce qu’on appelle « la lecture anticipée » (pre-fetch) des données, il est capable de lire moins d’enregistrements que lorsque la dimension contient moins d’attributs. Si c’est votre cas, assurez-vous donc de scinder votre table dépendamment de l’utilisation des données. Regroupez les données dans différentes tables ayant une relation 1:1:1 et qui sont utilisées conjointement.

Moralité de l’histoire !

Quelle est la moralité de l’histoire ?  Je pense qu’il faut être prudent lorsqu’il s’agit de déterminer la meilleure solution.  Un certain nombre de facteurs importants entrent en jeu et se doivent d’être considérés.

PARTAGER