Quels sont les moyens d'implémenter une relation plusieurs-à-plusieurs dans un entrepôt de données?


25

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?


Vous devez formuler votre question plus clairement. C'est peut-être pourquoi personne n'y a répondu depuis le 4. Ce que vous dites en réponse à ma réponse n'est pas le même que votre question d'origine.
IamIC

@IanC Edited. Est-ce mieux?
Brian Ballsun-Stanton

parfait :)
IamIC

Réponses:


17

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:

  1. Profondeur illimitée.
  2. Compacité.
  3. Souplesse.
  4. 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é.


1
Vous avez demandé "Quels sont les moyens de modéliser ces plusieurs à plusieurs et quelles sont leurs implications en termes de performances et de granularité?". J'ai répondu sur la modélisation. Pas besoin de voter contre.
IamIC

4
Vous devez fournir plus de données sur ce dont vous avez besoin. J'ai surmonté le problème exact que vous avez indiqué via une hiérarchie récursive. Mais, sans savoir quelque chose sur vos données et leurs connexions, il est très difficile de répondre.
IamIC

2
Oui, ils ne modélisent pas cela de manière native. Qu'y aurait-il de mal à ajouter une table et une jointure supplémentaires, réalisant ainsi le plusieurs-à-plusieurs? Dans un SGBDR, peu importe la façon dont vous structurez vos tables, vous allez avoir 2 jointures pour plusieurs à plusieurs. Il n'y a pas de raccourci. La seule exception possible concerne les tableaux dans PostgreSQL ou Caché / M.
IamIC

1
(Une hiérarchie récursive est une bonne idée, en fait.) Une façon dont j'ai résolu le problème était de précalculer la liste des relations plusieurs-à-plusieurs possibles dans une dimension, de la référencer à une table de dimension normale, puis de joindre la table de faits à celle-ci. tableau récapitulatif des dimensions. Votre réponse de «hiérarchie récursive» est une autre réponse de conception utile. Je me demande s'il y a eu des recherches sur les implications en termes de performances de ces différents hacks?
Brian Ballsun-Stanton

3
@Brian n'oubliez pas les votes pour des réponses utiles. Cela aide à créer une communauté. Pour répondre à votre question, je n'ai trouvé aucune recherche sur ces hacks, sauf "qu'est-ce qui est plus rapide: un CTE récursif ou une construction manuelle d'arborescence?". Votre solution précédemment déclarée est logique. Je le combinerais avec une vue indexée, qui bien sûr vous assure toujours la bonne carte de relations pré-remplie.
IamIC

6

Quelques 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 à ce sujet auxquelles vous devrez faire attention. Si vous implémentez des relations M: M, vous devrez 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 des faits M: M Elle contiendra un volume de données assez important, car elle comporte des lignes pilotes x 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 «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), vous pouvez alors adopter une autre approche qui réduira 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 dans chaque cas. Créez un tableau de dimensions avec une ligne pour chaque combinaison distincte et 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 a 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 peut ê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 en dehors des soins de santé avec des codes ICD. Dans 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.


5

J'aimerais savoir exactement à quel type de relation plusieurs à plusieurs vous avez à l'esprit 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 (client, succursale, mois, etc.).


Bonne réponse. Il y a deux cas que j'explore ici. Un N: M entre le fait et la dimension, et un 1: N: M entre le fait, la dimension et la dimension.
Brian Ballsun-Stanton

3
@Brian Ballsun-Stanton Lorsque vous dites N: M entre le fait et la dimension, vous voulez dire qu'un fait donné a plusieurs dimensions de frère ou sœur de cardinalité non distinctes et variables qui s'appliquent toutes, comme des balises sur des questions? Donc une question (fait) est étiquetée sql-server, data-warehouse et une autre est étiquetée data-warehouse, sql-server, business-intelligence. Je voudrais quand même tirer cela dans une étoile distincte pour le fait d'affectation des balises (qui a un grain légèrement différent de celui de la question). Il va avoir de grandes possibilités d'indexation et vous pourrez capturer le changement dimensionnel plus évidemment.
Cade Roux

@Brian Ballsun-Stanton Quant à 1: N: M, c'est un flocon de neige, je suppose, et j'ai tendance à éviter cela. Si vous souhaitez définir d'autres étoiles (ou ponts) pour les relations entre les dimensions, c'est très bien. N'oubliez pas qu'un entrepôt de données dimensionnel n'est pas normalisé et surtout qu'il s'agit d'une construction pratique conçue pour prendre en charge des types d'opérations spécifiques, non pour représenter spécifiquement la relation d'entité réelle ou éliminer la redondance.
Cade Roux

1
@Brian Ballsun-Stanton Jetez un œil au Kimball Forum et à ce qu'il appelle des ponts et des stabilisateurs dans ses livres de boîte à outils: forum.kimballgroup.com/…
Cade Roux

@Cade Pouvez-vous donner une réponse décrivant ceux-ci? :)
Brian Ballsun-Stanton

5

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 plusieurs façons de procéder, dont l'une traite essentiellement cette table de liens comme le fait au centre d'une étoile. Un autre est un tableau de colonnes de drapeaux.

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 SGBD de Kimball n'ont plus de bons liens ...


Le lien vers l'article «Autre hiérarchie» est rompu. Peut-être que vous faites référence à ceci: kimballgroup.com/html/designtipsPDF/DesignTips2004/…
Endy Tjahjono

Merci pour le lien vers plusieurs articles . J'ai mon 'Aha!' moment de lui.
Endy Tjahjono

Le deuxième lien est mort. Voici un lien plus récent vers le même article. Cependant, il est quelque peu brouillé et a perdu tous ses graphismes à un moment donné. blog.pythian.com/…
posfan12

1

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.


1
Comment cela résout-il les problèmes?
Brian Ballsun-Stanton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.