0

[events] と [event_segment] と [event_staff] を記述したファクト テーブルがあります。

[イベント] は、多くの [event_segment] で構成されます。たとえば、「紹介」、「事前チェック」、「第 1 段階」、「第 2 段階」などです。[イベント] のキー (つまり、粒状の一意の ID) は [event_ref] です。ただし、[event_segment] のキー (一意の識別子) は [event_ref] と [segment_order] の複合です。

[event_staff] は 1 つのイベントに対して多くのスタッフが参加するため、一意の ID は [event_ref] と [staff_id] の合成です。

日、場所など、いくつかの適合した次元があります。

特にレポートで、3 つのテーブル間で集計された事実を簡単に比較できるようにしたいので、このデータのモデルを決定するのに苦労しています。すなわち count([staff]) vs sum([event_segment_duration]) where [staff_type] = 'basic' and [event_segment_type] != 'clean up'

イベントには多くのスタッフが参加しているため、イベントには多くのセグメントがありますが、[event_ref] でグループ化しなければならないセグメントにスタッフを結び付けることができません。

これは「機能」しますが、イベントに参加する (適切にグループ化する) ため、Kimball/データ ウェアハウスの標準に違反していると見なされますか?

また、[event_ref] は [event_segment] テーブルに存在する必要があります。これは代理キーである必要があるため、グループ化できませんか?

4

1 に答える 1

0

あなたが基準を破っているとは思いません。

たまたま、粒度の異なる 2 つの追加のファクト テーブルがあるとします。

私の意見では、セグメントをイベントの子と見なすことができるため、セグメントをイベント ディメンションの一部と見なすことができます。

スタッフは単なる別のディメンションであり (ディメンションを複数の子に分割することは決して良い考えではありません)、スタッフ ディメンションの最下位レベルがイベント 1 の最下位レベルに一致しないことがあります。

これは通常の実際のシナリオであり、非常に頻繁に発生します。サッカー チームを想像してみてください。ゲームの統計情報をPlayers (子供) に関連付けたり、Team(親) に関連付けたりすることができますが、それぞれに販売されたチケットなどの他の情報もありますGame（別の次元）特定のプレーヤーに関連付けることはできませんが、レベルよりも詳細であることは確かTeamです.

于 2013-10-24T22:34:11.827 に答える