問題タブ [snowflake-schema]

スター スキーマの設計に関して、スノーフレークを使用する必要があるかどうかについて質問があります (これは避けるべきだと読んでいます)。次の 3 つのディメンション テーブルがあります。

• メインリスト薄暗い。- 人のリストが含まれています
• サブリストは暗くなります。- メインリストからのあらゆる種類の組み合わせが含まれています
• プログラム薄暗い。- プログラムのリストを識別します。各プログラムはサブリストに接続できます

ファクト テーブルの各行には、次の 3 つのテーブル (およびメトリック) からのキーが含まれますが、問題はこれです。一部のサブ リストは (リストの内容に関して) 正確なリストである可能性がありますが、異なるプログラムを指しています。では、同じコンテンツのサブリスト次元の繰り返しを作成する必要がありますか、それともサブリストとプログラムの間を接続するためにスノーフレークを使用する必要がありますか? 例 - メイン リストに 100K のレコードが含まれており、3 つのプログラム A、B、C があると仮定します。プログラム A には 10K のサブ リストがあるため、サブ リスト ディメンションには 10K のエントリがありますが、プログラム B と C には同じサブ リストがあり、 30K のレコードなので、それぞれ 30K の 60K エントリを作成する必要がありますか?? プログラム DIM には、各プログラムを区別する他の属性があり、ファクト データはプログラム レベルにあることに注意してください。

ありがとう！

次のような冗長なフィールドを含むCountry_Dimensionを既に持っているため、 を追加する必要があるかどうかをためらっています。Customer_Dimension

• 大陸名
• 国の名前
• 郵便番号_＃

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

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

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

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

一方、ディメンション テーブルのほとんどはより従来型のものであり、ファクト テーブルはこれらの従来型のディメンション テーブルに外部キーを格納するだけです。これは、一部の結合 (多対 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)

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

SCD2 ディメンション テーブルにデータを入力するには、最新のアクティブな行を示すマーカーが常に役立ちます。

私が考えることができる2つの方法があります 1) valid_from/valid_to 2) active_status: active/deleted

valid_from/valid_to がより多くの情報を保持していることは明らかですが、そうすると ETL プロセスが非常に複雑になるのでしょうか?

これら2つの方法の利点と欠点は何ですか?

私のスター スキーマには、start_date、finish_date、service_date、onhold_date、resume_dateなどの列を持つプロジェクト ディメンションがあります。

ファクト テーブルのすべての日付に外部キーを導入し、それらを日付ディメンションに接続する必要がありますか、それともproject_dimensionをdate_dimensionでスノーフレークする必要がありますか? 特定のプロジェクトですべての日付を使用できるわけではないため、これらすべての列を fact_table に保持すると、fact_table に null キーが含まれる可能性があります。

このシナリオで日付を処理する最良の方法は何ですか?

RESOURCE_IDリソース テーブルにリンクするファクト テーブルがあります。リソースには、それ自体がリソースであるという役割があります。

ROLEここで、属性を含むディメンションを作成したいと考えていますTITLE。

これを行う方法？Mondrian 4スキーマの例をいただければ幸いです。

<Link>for<PhysicalSchema>と<ForeignKeyLink>forがあること<DimensionLinks>は知っていますが、それらを適切に使用する方法がわかりません。