0

スター スキーマを使用した最初のプロジェクトで、まだ計画段階です。次の問題について、ご意見やアドバイスをいただければ幸いです。

「使用される製品機能」のディメンション テーブルがあり、一連の機能は時間の経過とともに成長し、変化します。機能の動的セットのため、機能は列にすることはできず、行にする必要があると考えています。

「ユーザー イベント」のファクト テーブルがあり、各イベントでどの製品機能が使用されたかを知る必要があります。

したがって、ディメンション テーブル内で外部キーとして使用されるファクト テーブルに主キーが必要なようです (従来のスター スキーマとは正反対の方向です)。同様のダイナミクスを持ついくつかの異なるディメンション テーブルがあるため、ファクト テーブルへの同様の外部キーが必要です。

一方、ディメンション テーブルのほとんどはより従来型のものであり、ファクト テーブルはこれらの従来型のディメンション テーブルに外部キーを格納するだけです。これは、一部の結合 (多対 1) がディメンション テーブルの主キーを使用する一方で、他の結合 (1 対多) がファクト テーブルの主キーを使用することを意味するものではありません。ストレージ要件は増加しますが、一貫性を保つために、すべてのディメンション テーブルでファクト テーブル キーを外部キーとして使用することを検討しました。

「動的」ディメンション テーブルのキーを実装するより良い方法はありますか?

以下は、私たちが行っていることとは正確には異なりますが、似たような例です:

  • アプリでレストランを検索するとします。

  • ユーザーが指定できるオプション機能には、価格帯、最低星評価、または料理が含まれます。オプション機能のセットは、時間の経過とともに変化します (たとえば、料理を指定するオプションを削除し、最も人気のあるオプションを追加する場合があります)。データベースに記録される検索ごとに、使用される一連の機能が固定されています。

  • 各検索は、ファクト テーブルの行になります。

  • 現在、ファクト テーブルにプライマリ キーを設定し、それを "features" ディメンション テーブルの外部キーとして使用することを検討しています。したがって、次のようになります。

    ファクトテーブル (検索 ID 、ユーザー ID 、メトリック 1、メトリック2 )

  • 別の方法として、一貫性のある結合を行い、議論のためにストレージ要件を無視するために、すべてのディメンション テーブルでファクト テーブルの主キーを外部キーとして使用することもできます。

    fact_table( search_id , metric1, metric2) /* user_id はもうありません */
    feature_dimension_table(feature_id, search_id, feature_attribute1, feature_attribute2)
    user_dimension_table(user_id, search_id , user_attribute1, user_attribute2)

  • これらの主要なスキーマにはどのような落とし穴がありますか? それを行うためのより良い方法は何ですか？

4

1 に答える 1

1

Bridge テーブルが必要です。これは、ファクトとディメンション間の多対多の関係に推奨されるソリューションです。

http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/multivalued-dimension-bridge-table/

例を質問に追加した後に編集します。

OK、橋ではないかもしれません。この例は私の見方を変えます。

ディメンション モデリングの基本的な要件は、ファクト テーブルの粒度を正しく識別することです。一般的な例は請求書と明細項目で、粒度は通常明細項目です。

例が実際のユースケースを反映していると確信できないため、仮説的な例は難しいことがよくありますが、シナリオは検索と基準である可能性があり、穀物は基準レベルにある必要があると思います.

たとえば、ファクト テーブルは次のようになります。

事実検索 (date_id,time_id,search_id,criteria_id,criteria_value)

検索データに対して実行する可能性のあるクエリの種類を考えると、この設計が最良の選択です。私が目にする唯一の問題は、criteria_value のデータ型に関するものです。それは選択肢/テキスト値である必要があり、間違いなく非加算的です。

于 2016-02-12T11:36:36.030 に答える