Conception en étoile
Une conception Star-Schema est-elle essentielle à un entrepôt de données? Ou pouvez-vous faire de l'entreposage de données avec un autre modèle de conception?
L'utilisation de schémas en étoile pour un système d'entrepôt de données vous offre plusieurs avantages et dans la plupart des cas, il est approprié de les utiliser pour la couche supérieure. Vous pouvez également avoir un magasin de données opérationnelles (ODS) - une structure normalisée qui contient "l'état actuel" et facilite les opérations telles que la conformation des données. Cependant, il existe des situations raisonnables où cela n'est pas souhaitable. J'ai eu l'occasion de construire des systèmes avec et sans couches ODS, et j'avais des raisons spécifiques pour le choix de l'architecture dans chaque cas.
Sans entrer dans les subtilités de l'architecture de l'entrepôt de données ou lancer une guerre de flammes Kimball contre Inmon, les principaux avantages d'un schéma en étoile sont:
La plupart des systèmes de gestion de bases de données ont des fonctionnalités dans l'optimiseur de requêtes pour effectuer des "transformations en étoile" qui utilisent des structures Bitmap Index ou Index Intersection pour une résolution rapide des prédicats. Cela signifie que la sélection à partir d'un schéma en étoile peut être effectuée sans toucher la table de faits (qui est généralement beaucoup plus grande que les index) jusqu'à ce que la sélection soit résolue.
Partitionnement un schéma en étoile est relativement simple car seule la table de faits doit être partitionnée (sauf si vous avez des dimensions bibliquement grandes). Élimination de partition signifie que l'optimiseur de requêtes peut ignorer les requêtes qui ne pouvaient pas participer aux résultats de la requête, ce qui économise sur les E/S.
Les dimensions changent lentement sont beaucoup plus faciles à mettre en œuvre sur un schéma en étoile qu'un flocon de neige.
Le schéma est plus facile à comprendre et a tendance à impliquer moins de jointures qu'un schéma flocon de neige ou E-R. Votre équipe de reporting vous aimera pour cela
Les schémas en étoile sont beaucoup plus faciles à utiliser et (plus important encore) améliorent les performances avec des outils de requête ad hoc tels que Business Objects ou Report Builder . En tant que développeur, vous avez très peu de contrôle sur le SQL généré par ces outils, vous devez donc fournir à l'optimiseur de requêtes autant d'aide que possible. Les schémas en étoile donnent à l'optimiseur de requêtes relativement peu d'occasions de se tromper.
En règle générale, votre couche de génération de rapports utilise des schémas en étoile, sauf si vous avez une raison spécifique de ne pas le faire. Si vous avez plusieurs systèmes sources, vous souhaiterez peut-être implémenter un Operational Data Store avec un schéma normalisé ou en flocon de neige pour accumuler les données. C'est plus facile car un ODS ne fait généralement pas d'historique. L'état historique est suivi dans les schémas en étoile où cela est beaucoup plus facile à faire qu'avec des structures normalisées. Un magasin de données opérationnelles normalisé ou en flocons de neige reflète l'état "actuel" et ne détient pas une vue historique au-delà de tout ce qui est inhérent aux données.
Les processus de chargement ODS concernent le nettoyage et la conformité des données, ce qui est plus facile à faire avec une structure normalisée. Une fois que vous avez des données propres dans un ODS, les charges de dimension et de fait peuvent suivre l'historique (les changements dans le temps) avec des mécanismes génériques ou relativement simples relativement simplement; cela est beaucoup plus facile à faire avec un schéma en étoile, de nombreux outils ETL (par exemple) fournissent des fonctionnalités intégrées pour modifier lentement les dimensions et la mise en œuvre d'un mécanisme générique est relativement simple.
La superposition du système de cette manière permet une séparation des responsabilités - la logique de nettoyage des affaires et des données est traitée dans l'ODS et les charges du schéma en étoile traitent de l'état historique.
Il y a un débat en cours dans la littérature sur les entrepôts de données sur où dans l'architecture de l'entrepôt de données sur les Star- Schéma la conception doit être appliquée.
En bref Kimball préconise fortement d'utiliser uniquement la conception Star-Schema dans le datawarehouse, tandis que Inmon veut d'abord construire un Enterprise Datawarehouse en utilisant NF normalisé = design et plus tard utiliser la conception Star-Schema dans les datamarts.
En plus ici, vous pouvez également dire que conception du schéma Snowflake est une autre approche.
Une quatrième conception pourrait être l'approche Data Vault Modeling .
Les schémas en étoile sont utilisés pour permettre un accès haut débit à de gros volumes de données. La haute performance est activée en réduisant la quantité de jointures nécessaires pour saturer toute requête qui peut être faite sur le domaine. Cela se fait en autorisant la redondance des données dans les tables de dimension.
Vous devez vous rappeler que le schéma en étoile est un modèle pour la couche supérieure de l'entrepôt. Tous les modèles impliquent également des schémas de transfert au bas de la pile d'entrepôt, et certains incluent également une zone de transfert fusionnée transformée persistante où tous les systèmes source sont fusionnés dans un schéma modélisé 3NF. Les différents sujets se situent au-dessus de cela.
Les alternatives aux schémas en étoile au niveau supérieur incluent une variation, qui est un schéma en flocons de neige. Une nouvelle méthode qui pourrait également justifier certaines recherches est Data Vault Modeling proposée par Dan Linstedt.
La chose à propos des schémas en étoile est qu'ils sont un modèle naturel pour le genre de choses que la plupart des gens veulent faire avec un entrepôt de données. Par exemple, il est facile de produire des rapports avec différents niveaux de granularité (mois, jour ou année par exemple). Il est également efficace d'insérer des données d'entreprise typiques dans un schéma en étoile, là encore une caractéristique commune et importante d'un entrepôt de données.
Vous pouvez certainement utiliser n'importe quel type de base de données que vous souhaitez, mais à moins que vous ne connaissiez très bien votre domaine d'activité, il est probable que vos rapports ne fonctionneront pas aussi efficacement qu'ils le pourraient si vous aviez utilisé un schéma en étoile.
Les schémas en étoile conviennent naturellement à la dernière couche d'un entrepôt de données. Comment y arriver est une autre question. Autant que je sache, il y a deux grands camps, ceux de Bill Inmon et Ralph Kimball. Vous voudrez peut-être regarder les théories de ces deux gars si/quand vous décidez d'aller avec une star.
De plus, certains outils de création de rapports aiment vraiment la configuration du schéma en étoile. Si vous êtes enfermé dans un outil de génération de rapports spécifique, cela pourrait conduire à quoi ressemble le centre de reporting dans votre entrepôt.
Le schéma en étoile est un modèle de données logique pour les bases de données relationnelles qui correspond aux besoins réguliers de l'entreposage de données; si l'environnement relationnel est donné, une étoile ou un schéma de flocon de neige sera un bon modèle de conception, câblé dans de nombreuses méthodologies de conception DW.
Il existe cependant d'autres moteurs que les moteurs de bases de données relationnelles, et ils peuvent être utilisés pour un entreposage de données efficace. Les moteurs de stockage multidimensionnel peuvent être très rapides pour les tâches OLAP (TM1 par exemple). Nous ne pouvons pas appliquer la conception de schéma en étoile dans ce cas. D'autres exemples nécessitant des modèles logiques spéciaux incluent les bases de données XML ou les bases de données orientées colonnes (par exemple, l'expérimental magasin C) ).
Il est possible de s'en passer. Cependant, vous vous compliquerez la vie - votre organisation voudra utiliser des outils standard qui vivent au-dessus des DW, et ces outils s'attendront à un schéma en étoile - beaucoup d'efforts seront dépensés pour installer une cheville carrée dans un tour trou.
De nombreuses optimisations au niveau de la base de données supposent que vous avez un schéma en étoile; vous passerez beaucoup de temps à optimiser et à restructurer pour que la DB fasse "la bonne chose" avec votre mise en page pas tout à fait star.
Assurez-vous que les avantages l'emportent sur les inconvénients.
(Est-ce que ça sonne comme si j'y étais déjà allé?)
-RÉ
Il y a trois problèmes que nous devons résoudre.
1) Comment extraire les données du système source opérationnel sans exercer une pression excessive sur elles en joignant des tables à l'intérieur et entre elles, en nettoyant les données lors de l'extraction, en créant des dérivations, etc.
2) Comment fusionner des données provenant de sources disparates - certains hérités, certains basés sur des fichiers, provenant de différents services en un ensemble intégral, précis et efficacement stocké qui modélise l'entreprise et ne reflète pas les structures des systèmes sources. N'oubliez pas que les systèmes changent/sont remplacés assez rapidement, mais le modèle de base de l'entreprise change lentement.
3) Comment structurer les données de manière à répondre aux exigences spécifiques d'analyse et de reporting pour des personnes/services particuliers dans l'entreprise aussi rapidement et précisément que possible.
La solution à ces trois problèmes très différents nécessite des couches architecturales différentes pour les résoudre
Couche intermédiaire Nous reproduisons les structures des sources, mais seules les données modifiées des sources sont chargées chaque nuit. une fois que les données sont extraites de la couche intermédiaire dans la couche suivante, les données sont supprimées. Les requêtes sont des requêtes à table unique avec un simple filtre data_time. Très peu d'effet sur la source.
Enterprise Layer Il s'agit d'une 3ème base de données sous forme normale orientée métier. Les données sont extraites (puis supprimées) de la couche intermédiaire dans la couche entreprise, où elles sont nettoyées, intégrées et normalisées.
Présentation (Schéma en étoile) Couche Ici, nous modélisons dimensionnellement pour répondre à des exigences spécifiques. Les données sont délibérément dénormalisées pour réduire le nombre de jointures. Les hiérarchies qui peuvent occuper plusieurs tables dans la couche Enterprise sont regroupées en une seule table de dimension et plusieurs tables transactionnelles peuvent être fusionnées en tables de faits uniques.
Vous faites toujours face à ces trois problèmes. Si vous choisissez de supprimer la couche entreprise, vous devez toujours résoudre le deuxième problème, mais vous devez le faire dans la couche de schéma en étoile, et à mon avis, ce n'est pas le bon endroit pour le faire.