3

ディメンションテーブルとファクトテーブルが1：1の関係になる適切なBIソリューションを開発しようとしています。

たとえば、次のようにします。

Fact_UserData

  • ユーザーID
  • ロケーションID
  • 職業ID
  • 意味のある集計が可能な一連の数値データ

Dim_User

  • ユーザーID
  • 性別
  • 民族性

Dim_Location

  • ロケーションID
  • 区域
  • 街
  • 州

Dim_Occupation

  • 職業ID
  • 職業名

この例では、Fact_UserDataとDim_UserがユーザーIDを介して常に1：1の関係にあると想定しています。

主に私を失望させているのは、1：1の関係です。専用のユーザーディメンションを使用する必要がありますか、それともこれらの属性をファクトテーブルにマージする必要がありますか？キンボールによれば、縮退した次元は運用管理番号のために予約されるべきであるため、私はマージすることを躊躇しています。また、職業を専用の次元として持つことが理にかなっているのではないかと思います。職業ごとにグループ化することは、ビジネスの観点から非常に重要です。そのため、当初は独自の次元として持っていました。

職業ディメンションの質問の一般化として、ディメンションにIDと名前の2つのフィールドしかない状況を処理するためのベストプラクティスのアプローチは何でしょうか。（通常のCustomersディメンションのように考えて、[CustomerID]フィールドと[CustomerName]フィールドのみがあることを想定してください。）ディメンションに10以上のエントリがあり、階層がないとします。

4

1 に答える 1

1

DateKeyさて、人が職業や場所を変えることができることを考えると、私はそのファクトテーブルにも期待しています。職業や場所をユーザーディメンションに取り込むと、タイプ2ディメンションになってしまうため、そこでの時間的変化を追跡する必要があります。次元を持っているだけで問題はありませんKey, BusinessKey-物事は時間とともに変化し、最終的に何かを追加します。

于 2012-06-26T12:00:50.837 に答える