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.