私はリレーショナルSQL Serverデータベースのバックグラウンドから来て、Analysis Servicesで多次元モデルに移行しようとしています。ファクトテーブルの設計 - 1対多
私は、リレーショナルの世界では信じられないほど簡単な次の問題にどのようにアプローチするのかと苦労しています。
私は、Incident、IncidentOffender、IncidentLossという3つのテーブルを持っています。どれも、1、または多くのIncidentOffendersとIncidentLossesがインシデントに存在しないかもしれない：
大げさな犯罪者が焼いた豆を盗んだ事件に対処するために過ごしましたか」と、「その豆の価値はどうでしたか？
これは単純ですが、ウェブを精査してさまざまな書籍を食べたことを謝罪しますが、私には日常のような現実的な例は見つけられません。
シナリオでは、ディメンションとメジャーグループの両方として3つのテーブルをすべてSSASにロードする必要があります。次に、インシデント犯罪者およびインシデントロスのディメンションは、インシデントメジャーグループの多対多ディメンションになります。 [ディメンションの使用法]タブでは次のようになります。
これは本当に感謝しています。実際には、私が構築した最初のキューブで解決した解決策ですが、私はそれを完全に快適に感じることはありませんでした。可能な限り細かい1つのファクトテーブルを持つ2つのキューブ（または必要に応じて複数）を構築することが「ベストプラクティス」ですか？ – Nugsson
いいえキューブあたりの1つのファクトテーブルは、間違いなくベストプラクティスです。同じレポート内の異なるファクトテーブルからの測定値を分析するには、多くの力があります。あなたのケースでは、他の2つのファクトテーブルが多対多のディメンションのブリッジテーブルに過ぎないので、これは少し話題です。 – GregGalloway
問題はありません@GregGalloway。私はまだ物事を検討していますが、私が幸せになると、これを受け入れられた答えとして間違いなくマークします。 – Nugsson
は私には正常に見えるが、私は、ファクトテーブルや寸法など事件とIncidentOffenderとしてIncidentLossをモデル化するだろうとします。 – tobi6
ありがとうございます - FactIncidentLossにはIncidentLossID、IncidentID、IncidentOffenderIDが含まれていますか？インシデントに複数のIncidentOffenderが存在する可能性があるため、問題の原因となっているのは最後の問題です。 – Nugsson
この要件では、マッピングm：nテーブルを参照し、パフォーマンスの問題を注意深くテストします。 – tobi6