joindre à travers plusieurs tables de faits avec une dimension entre

Quelle est la bonne approche de la design de l'entrepôt de données si les rapports demandés nécessitent des informations résumées sur les mêmes dimensions (et avec la même granularité), mais datatables sous-jacentes sont stockées dans des tables de faits distinctes?

Par exemple, un rapport indiquant le total des salaires versés et le total des dépenses déclarées pour chaque employé pour chaque année, lorsque le salaire et les dépenses sont enregistrés dans différentes tables de faits. Ou un rapport énumérant les ventes totales par mois et l'inventaire reçu par mois pour chaque UGS vendue par une entreprise, lorsque les ventes proviennent d'une table de faits et que la réception provient d'une autre.

La résolution naïve de ce problème semble assez simple: il suffit d'interroger et d'agréger les deux tables de faits en parallèle, puis de regrouper les résultats agrégés dans l'entrepôt de données ou dans l'application cliente.

Mais je suis également intéressé par d'autres façons de penser à ce problème. Comment les autres l'ont-ils résolu? Je m'interroge à la fois sur le schéma et la design de l'entrepôt de données, et je rends ce design convivial pour les outils clients afin de générer des rapports comme les exemples ci-dessus.

De plus, est-ce que ce cas d'utilisation "dimension sandwich" a un nom dans la terminologie canonique de l'entreposage de données? Si oui, cela facilitera la search via Google.

Nous travaillons avec SQL Server, mais les questions que j'ai à ce stade sont, je l'espère, neutres pour la plate-forme.

    J'ai appris aujourd'hui que cette technique s'appelle Drilling Across :

    L'exploration consiste simplement à effectuer des requêtes distinctes sur deux tables de faits ou plus, les en-têtes de chaque requête étant constitués d'attributes conforms identiques. Les sets de réponses des deux requêtes sont alignés en effectuant une opération de sorting-fusion sur les en-têtes de ligne d'atsortingbut de dimension commune. Les fournisseurs d'outils BI se réfèrent à cette fonctionnalité par différents noms, y compris les requêtes stitch et multipass.

    On dirait que la solution naïve ci-dessus (interroger plusieurs tables de faits en parallèle et assembler les résultats) est également la solution suggérée.

    Plus d'informations:

    Merci beaucoup à @MarekGrzenkowicz de m'avoir indiqué la bonne direction pour find ma propre réponse! Je réponds ici au cas où quelqu'un d'autre cherche la même chose.

    La "solution naïve" que vous avez décrite est la plupart du time la solution préférée.

    Une exception courante est lorsque vous devez filterr les lignes détaillées d'un fait en utilisant une autre table de faits. Par exemple, "montrez-moi le capital-tieup (inventaire des stocks) pour les articles que nous n'avons pas vendus cette année" . Vous ne pouvez pas simplement résumer le capital-tieup dans une requête. Dans ce cas, un fait consolidé peut être une solution, si vous êtes en mesure d'exprimer les deux mesures sur un grain commun.