Star-Schema Design [fermé]

Question

Une conception Star-Schema est-elle essentielle pour un entrepôt de données? Ou pouvez-vous effectuer l’entreposage de données avec un autre modèle de conception?

Answer 1

L'utilisation de schémas en étoile pour un système d'entrepôt de données vous procure de nombreux avantages et, dans la plupart des cas, il 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ù ce 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 ni engager une guerre entre Kimball et Inmon, les principaux avantages d’un schéma en étoile sont les suivants:

• La plupart des systèmes de gestion de base de données avoir des installations dans l'optimiseur de requête faire 'Star Transformations' que utiliser les structures Index de bitmap ou Intersection d'index pour plus de rapidité prédiction de résolution. Cela signifie que la sélection dans 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.

• Partitionner un schéma en étoile est relativement simple car seule la table des faits doit être partitionné (sauf si vous avez des dimensions bibliquement grandes). Élimination de partition signifie que l'optimiseur de requête peut ignorer les patitions qui ne pourraient éventuellement pas participer aux résultats de la requête, ce qui enregistre les entrées / sorties.

• Les dimensions de changement lent sont beaucoup plus faciles à implémenter sur un schéma en étoile qu'un flocon de neige .

• Le schéma est plus facile à comprendre et implique moins de jointures qu'un flocon de neige ou schéma ER. Votre équipe de reporting vous aimera pour cette

• Les schémas en étoile sont beaucoup plus faciles à utiliser et (plus important encore) fonctionnent bien avec des outils de requête ad hoc tels que Business Objects ou Générateur de rapports . En tant que développeur, vous avez très peu de contrôle sur le code 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ête une possibilité relativement limitée de se tromper.

Généralement, 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 pouvez implémenter un magasin de données opérationnelles . avec un schéma normalisé ou en flocon de neige pour accumuler les données. Ceci est plus facile car un SAO ne fait généralement pas l'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 enneigé reflète l'état "actuel" et ne conserve pas une vue historique au-delà de 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 à réaliser avec une structure normalisée. Une fois que vous avez des données propres dans une SAO, les charges de dimensions et de faits peuvent suivre l'historique (changements dans le temps) avec des mécanismes génériques ou relativement simples de manière relativement simple; c'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 les dimensions qui changent lentement 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 de séparer les responsabilités - la logique de nettoyage des entreprises et des données est traitée dans l'ODS et les chargements de schéma en étoile traitent de l'état historique.

Answer 2

Il existe un débat en cours dans la littérature sur le datawarehousing à propos de où dans l'architecture du datawarehouse, le Le schéma Star doit être appliqué.

En bref, Kimball préconise vivement d'utiliser uniquement la conception Star-Schema dans le datawarehouse, tandis que Inmon souhaite d'abord créer un entrepôt de données d'entreprise à l'aide de normalisé. 3NF et utilisez plus tard la conception Star-Schema dans les datamarts.

En outre, vous pouvez également indiquer que la conception de schéma Snowflake constitue une autre approche.

Une quatrième conception pourrait être l’approche Modélisation de Data Vault .

Answer 3

Les schémas en étoile permettent d’accéder à grande vitesse à de grands volumes de données. Les performances élevées sont activées en réduisant le nombre de jointures nécessaires pour spécifier toute requête pouvant être effectuée dans le domaine. Ceci est réalisé en permettant la redondance des données dans les tables de dimension.

Vous devez vous rappeler que le schéma en étoile est un motif pour la couche supérieure de l'entrepôt. Tous les modèles impliquent également des schémas de transfert en bas de la pile d'entrepôt, et certains incluent également une zone de transfert fusionnée transformée et persistante dans laquelle tous les systèmes source sont fusionnés dans un schéma modélisé 3NF. Les différents domaines se situent au-dessus de cette situation.

Les variantes du schéma en étoile au niveau supérieur incluent une variante, qui est un schéma en flocon de neige. La Modélisation de Data Vault proposée par Dan Linstedt est une nouvelle méthode pouvant justifier certaines investigations. >

Answer 4

Le problème des schémas en étoile est qu’ils constituent 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 ou jour ou année par exemple). Il est également efficace d’insérer des données d’entreprise types dans un schéma en étoile, qui est à nouveau 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, mais si vous ne connaissez pas très bien votre domaine d'activité, vos rapports ne fonctionneront probablement pas aussi efficacement que si vous utilisiez un schéma en étoile.

Answer 5

Les schémas en étoile conviennent parfaitement à 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 de Ralph Kimball. Vous voudrez peut-être examiner les théories de ces deux gars si / quand vous décidez de partir avec une star.

De plus, certains outils de rapport aiment vraiment la configuration du schéma en étoile. Si vous êtes bloqué dans un outil de génération de rapports spécifique, il se peut que cela donne l'impression que le magasin de rapports se présente dans votre entrepôt.

Answer 6

Le schéma en étoile est un modèle de données logique pour les bases de données relationnelles qui répond aux besoins habituels d’entreposage de données. si l’environnement relationnel est défini, un schéma en étoile ou en flocon de neige constituera un bon modèle de conception, câblé dans de nombreuses méthodologies de conception DW.

Il existe cependant d'autres moteurs de base de données relationnels, qui peuvent être utilisés pour un stockage efficace des données. Les moteurs de stockage multidimensionnels 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. Parmi les autres exemples nécessitant des modèles logiques spéciaux, citons les bases de données XML ou orientées colonnes (par exemple, le C-store expérimental. ) ).

Answer 7

C'est possible de s'en passer. Cependant, vous rendrez la vie plus difficile pour vous-même - votre organisation voudra utiliser des outils standard basés sur les outils de travail, et ces outils s’attendront à un schéma en étoile trou.

De nombreuses optimisations au niveau de la base de données supposent que vous ayez 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 assez étoile.

Assurez-vous que les avantages l'emportent sur les inconvénients.

(Cela semble-t-il être comme avant?)

-D

Answer 8

Il y a trois problèmes à résoudre.

1) Comment extraire les données du système source opérationnel sans exercer de pression excessive sur elles en joignant des tables à l'intérieur et entre elles, en nettoyant les données au fur et à mesure de leur extraction, en créant des dérivations, etc.

2) Comment fusionner des données provenant de sources disparates - certaines anciennes, certaines basées sur des fichiers, de différents départements dans un ensemble intégral, précis, efficacement stocké qui modélise l’activité et ne reflète pas les structures des systèmes source. 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 aussi rapidement et précisément que possible aux exigences spécifiques en matière d'analyse et de création de rapports pour des personnes / départements spécifiques de l'entreprise.

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 répliquons les structures des sources, mais seules les données modifiées à partir des sources sont chargées chaque nuit. une fois que les données sont extraites de la couche intermédiaire dans la couche suivante, elles 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.

Couche d'entreprise Il s'agit d'une 3ème base de données de forme normale orientée business. 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.

Couche de présentation (schéma en étoile) 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 pouvant occuper plusieurs tables de la couche entreprise sont réduites en une seule table de dimension et plusieurs tables de transaction peuvent être fusionnées en une seule table de faits.

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.