Entreposage de données - Schéma en étoile vs table plate
J'essaie de concevoir un entrepôt de données pour un seul magasin de données couramment requises, allant des systèmes financiers, des systèmes de planification de projet et une myriade de systèmes scientifiques. C'est à dire. de nombreux data marts différents.
J'ai lu sur l'entreposage de données et les méthodes populaires telles que les méthodes Star Schemas et Kimball, etc., mais une question à laquelle je ne trouve pas de réponse est:
Pourquoi est-il préférable de concevoir votre DW Data Mart comme un schéma en étoile plutôt que comme une seule table plate?
Il est certain que l'absence de jointures entre les faits et les attributs/dimensions est plus rapide et plus simple que de nombreuses petites jointures à toutes les tables de dimensions. L'espace disque n'est pas un problème, nous allons simplement jeter plus de disques dans la base de données si nécessaire. Le schéma en étoile est-il un peu dépassé de nos jours ou est-ce toujours le dogme de l'architecte de données?
Votre question est très bonne: le mantra Kimball pour la modélisation dimensionnelle est d'améliorer les performances et d'améliorer la convivialité.
Mais je ne pense pas que ce soit dépassé, ni dogme - c'est une approche raisonnable et pratique pour de nombreuses situations et plateformes.
La façon dont les bases de données relationnelles stockent les données signifie qu'il y a un équilibre à trouver entre les nombres et les types de tables, les itinéraires vers les données pour les requêtes typiques, la facilité de maintenance et la description des relations entre les données, le nombre de jointures, la façon dont les jointures sont construits, l'indexabilité des colonnes, etc.
3NF (ou plus) est une extrémité du spectre, adaptée aux systèmes OLTP, et une seule table est l'autre extrémité du spectre. Les modèles dimensionnels sont au milieu et appropriés pour le rapport, au moins lors de l'utilisation de certaines technologies.
Les performances ne reposent pas uniquement sur le "nombre de jointures", bien qu'un schéma en étoile fonctionne mieux pour la génération de rapports de charges de travail qu'une base de données entièrement normalisée, en partie en raison d'un nombre réduit de jointures. Les dimensions sont généralement très larges. Si vous incluez tous ces champs de dimension dans chaque ligne de chaque fait, vous avez en effet de très grandes lignes, et trouver votre chemin dans ces lignes fonctionnera très mal pour les requêtes typiques.
Les faits sont nombreux, donc si vous pouvez rendre ces tables compactes, avec les dimensions `` plus verbeuses '' filtrables, vous atteignez un point faible de performance qu'une seule table ne va pas correspondre, sauf si elle est fortement indexée.
Et oui, une seule table pour un fait est plus simple en termes de nombre de tables mais est-elle vraiment plus facile à naviguer? Les dimensions et les faits sont des concepts faciles à comprendre, et que se passe-t-il si vous souhaitez croiser vos requêtes entre les faits? Vous avez de nombreux data marts différents, mais l'un des avantages d'avoir un entrepôt de données en premier lieu est que ceux-ci ne sont pas distincts - ils sont liés et peuvent être signalés d'un bout à l'autre. Les dimensions conformes le permettent.
Si vous combinez votre fait et vos dimensions dans une seule table, vous perdrez soit la visibilité des attributs de dimension qui n'ont jamais été utilisés, soit vos mesures seront supprimées par l'inclusion d'un événement factice pour l'attribut de dimension inutilisé.
Par exemple, un menu de restaurant est une dimension et la nourriture achetée est un fait. Si vous les regroupiez en un seul tableau, comment identifieriez-vous les aliments qui n'ont jamais été commandés? D'ailleurs, avant votre première commande, comment identifieriez-vous les plats disponibles sur le menu?
La dimension représente les possibilités, le fait représente la réalisation des possibilités.
La combinaison de faits et de dimensions dans le même tableau limite l'évolutivité et la flexibilité.
Supposons qu'un jour, l'entreprise décide de modifier une description de dimension (par exemple, le nom du produit). Les tables de dimensions ne sont pas aussi profondes que les tables de faits et le processus de mise à jour ou la gestion SCD devrait être plus facile et nécessiter moins de ressources.