Quels sont les moyens d'implémenter une relation plusieurs-à-plusieurs dans un entrepôt de données?
Les topologies dominantes de la modélisation de l'entrepôt de données (Star, Snowflake) sont conçues avec des relations un à plusieurs à l'esprit. La lisibilité, les performances et la structure des requêtes se dégradent fortement face à une relation plusieurs-à-plusieurs dans ces schémas de modélisation.
Quels sont les moyens d'implémenter une relation plusieurs-à-plusieurs entre les dimensions ou entre la table de faits et une dimension dans un entrepôt de données et quels compromis infligent-ils en ce qui concerne la granularité et les performances des requêtes nécessaires?
D'après mon expérience, une hiérarchie récursive est le moyen le plus pratique de résoudre ce problème. Il offre les avantages suivants:
- Profondeur illimitée.
- Compacité.
- Souplesse.
- La vitesse.
En revanche, il faut une table supplémentaire pour chaque niveau de jointures "à plusieurs". Ceci est codé en dur et difficile à maintenir contre les mises à jour de schéma.
En utilisant des index filtrés, une grande table de jointures hiérarchiques peut fonctionner à une vitesse supérieure aux tables dédiées. La raison en est que chaque jointure est uniquement "parent-enfant" par rapport à "pour joindre la table à la table de données". Ce dernier a plus d'index à traiter et à stocker.
J'essaie de résoudre ce problème depuis de nombreuses années. Récemment, c'est ce que j'ai trouvé.
Certains scénarios pour les relations M: M dans un modèle d'entrepôt de données
La plupart des serveurs OLAP et des systèmes ROLAP ont désormais un moyen de gérer les structures de données M: M, mais il y a quelques mises en garde auxquelles vous devrez faire attention. Si vous implémentez M: Les relations M dont vous aurez besoin pour garder un œil sur votre couche de rapports et sur les outils que vous souhaitez prendre en charge.
Scénario 1: dimension M: M sur une table de faits
Un exemple de ceci pourrait être plusieurs pilotes sur une politique de moteur. Si vous ajoutez ou supprimez un pilote, la transaction d'ajustement de stratégie peut avoir une relation avec une liste de pilotes qui change avec l'ajustement.
Option 1 - Table de pont M-M sur les pilotes Cela aura un volume de données assez important, car il a des pilotes x lignes de transactions pour une politique donnée. SSAS peut consommer directement cette structure de données, mais il est plus lent d'interroger via un outil ROLAP.
Si votre relation M: M est basée sur des entités spécifiques à la ligne de faits (par exemple, les conducteurs sur une voiture), cela peut également convenir à un outil ROLAP, à condition que votre outil ROLAP prenne en charge les relations M: M (par exemple, en utilisant des contextes dans Business Objets).
Option 2 - Table de dimension des "combinaisons" factices Si vous mappez une liste de codes communs à une table de faits (c'est-à-dire que les entités liées ne sont pas particulières à la ligne de faits), alors vous pouvez adopter une autre approche qui réduire les volumes de données. Un exemple de ce type de scénario est les codes ICD lors d'une visite en milieu hospitalier. Chaque visite d'hospitalisation aura un ou plusieurs diagnostics et/ou procédures de CIM énumérés. Les codes ICD sont globaux.
Dans ce cas, vous pouvez constituer une liste distincte des combinaisons de codes sur chaque cas. Créez un tableau de dimensions avec une ligne pour chaque combinaison distincte et disposez d'un tableau de liens entre les combinaisons et les tableaux de référence pour les codes ICD eux-mêmes.
La table de faits peut avoir une clé de dimension pour la dimension "combinaisons", et la ligne de dimension contient une liste de références aux codes ICD réels. La plupart des outils ROLAP peuvent consommer cette structure de données. Si votre outil ne fonctionne qu'avec une relation M: M réelle, vous pouvez créer une vue qui émule la relation M: M entre le fait et la table de référence de codage. Ce serait l'approche préférée avec SSAS.
Avantages de l'option 1: - Indexées de manière appropriée, les requêtes basées sur la sélection de lignes de table de faits avec une certaine relation via la table M: M peuvent être raisonnablement efficaces.
- Modèle conceptuel légèrement plus simple
Avantages de l'option 2: - Le stockage des données est plus compact
- Vous pouvez émuler une relation directe 1: M en présentant les combinaisons dans un format lisible par l'homme sous forme de code sur la dimension "combinaisons". Cela pourrait être plus utile sur les outils de rapport les plus stupides qui ne prennent pas en charge les relations M: M.
Scénario 2: relation M: M entre les dimensions:
Plus difficile de penser à un cas d'utilisation, mais on pourrait envisager à nouveau quelque chose hors des soins de santé avec des codes ICD. Sur un système d'analyse des coûts, la visite en milieu hospitalier peut devenir une dimension et aura des relations M: M entre la visite (ou l'épisode consultant en NHS) et les codages.
Dans ce cas, vous pouvez configurer les relations M: M et éventuellement en codifier un rendu lisible par l'homme sur la dimension de base. Les relations peuvent être établies via des tables de liens M: M droites ou via une table de "combinaisons" de pontage comme précédemment. Cette structure de données peut être interrogée correctement via Business Objects ou des outils ROLAP de meilleure qualité.
Du haut de ma tête, je ne peux pas voir SSAS être en mesure de consommer cela sans prendre la relation jusque dans la table de faits, vous devez donc présenter une vue de la relation M: M entre le codage et la table de faits lignes pour utiliser SSAS avec ces données.
J'aimerais savoir exactement à quel type de relation plusieurs-à-plusieurs vous pensez dans votre modèle, que ce soit dans le système transactionnel ou dans le modèle de données dans lequel il se trouve actuellement.
En règle générale, les relations plusieurs à plusieurs entre les dimensions sont des faits sur les dimensions. Le fait qu'un client commande dans plusieurs succursales qui desservent de nombreux clients, ou quelque chose comme ça. Chacun de ces éléments est un fait. Il aurait une date d'entrée en vigueur ou quelque chose comme ça, mais la relation pourrait être "sans faits". La relation elle-même peut avoir d'autres dimensions que le client et la succursale. C'est donc un schéma en étoile typique avec une table de faits (potentiellement sans faits) au centre. La façon dont cette étoile peut se relier à d'autres étoiles dimensionnelles dans l'entrepôt dépendra évidemment. Chaque fois que vous combinez différentes étoiles, vous devez le faire sur les clés de l'entreprise et vous assurer de ne pas effectuer de jointures croisées par inadvertance.
En règle générale, on ne rend pas compte de telles tables de relations de dimension au même degré que les tables de faits plus volumineuses et lorsqu'elles le font, ce ne sont pas toujours autant de données, donc cela n'a pas tendance à affecter les performances. Dans le cas ci-dessus, vous pouvez examiner l'utilisation du client/de l'agence au fil du temps, mais de meilleures données sur les quantités de commande réelles seraient disponibles dans votre table de faits de commande, qui aurait probablement aussi des dimensions pour le client, l'agence, etc. la plupart des gens envisageraient plusieurs-à-plusieurs (bien qu'une commande puisse être considérée comme définissant une relation plusieurs-à-plusieurs du client à la succursale), ils sont donc plus typiques dans les environnements d'entrepôt de données. Vous ne feriez des agrégats numériques sur des modèles plusieurs-à-plusieurs que si vous aviez regroupé les informations récapitulatives à ce niveau de relation - c'est-à-dire client, succursale, mois, ventes totales - un tableau récapitulatif des faits, qui ressemble plus à un fait-plusieurs modèle de dimension maintenant qu'il a des données numériques.
Voici quelques articles pertinents de Kimball et d'autres qui peuvent s'appliquer à la modélisation d'une relation plusieurs-à-plusieurs proposée. Notez qu'une relation plusieurs-à-plusieurs est un concept dans le domaine problème/modèle logique uniquement. Dans un modèle OLTP normalisé, il serait toujours géré avec une table de liens qui est, bien sûr, un à plusieurs dans chaque sens. Dans un modèle d'entrepôt de données Kimball non normalisé, il existe un certain nombre de façons pour ce faire, dont l'un traite essentiellement cette table de liens comme le fait au centre d'une étoile. Un autre est un tableau de colonnes d'indicateur.
En fin de compte, le choix dépendra de ce que vous modélisez exactement, de la façon dont il change et de la façon dont vous souhaitez en rendre compte. C'est là que la modélisation dimensionnelle et l'entreposage de données en général s'écartent fortement du modèle normalisé. Le modèle normalisé se concentre sur les relations logiques et théoriques dans les données, que l'entreposage de données garde toujours un œil sur les cas d'utilisation réalistes et dénormalise pour les faire fonctionner.
Modélisation de hiérarchies alternatives à l'aide d'une table de bridge:
http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf
Trois options pour une relation plusieurs à plusieurs (liée aux attributions d'actions numériques - voir les commentaires pour des allers-retours intéressants)
http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/
Malheureusement, de nombreux articles de la semaine de l'information/mag du SGBD de Kimball n'ont plus de bons liens ...
Une façon de résoudre ce problème est d'avoir une table de faits avec seulement 2 colonnes, de clé étrangère des 2 dimensions ayant une relation plusieurs à plusieurs.