問題タブ [dimensional-modeling]

私は現在、次元モデリング アプローチを大まかに利用してウェアハウス スキーマに取り組んでいます。

一般的な考え方は、最小レベルの粒度で、関心のあるイベント メトリックでいっぱいの単一のファクト テーブルを持つことです。これに加えて、もちろん、記録されているイベントの次元が保持される次元テーブル(a)になります。これらのテーブルはdimension_id.

私の質問は、何かがディメンションとメトリックの両方になることは可能ですか、それとも理にかなっていますか?

例としては、検索結果での製品の位置が考えられます。特定の製品の位置は、メトリックと見なすことができます。ユーザーは、製品に対して次のクエリを実行できます。

ディメンション x = y の商品が先週表示された平均掲載順位は?

同時に、位置自体を次元と見なすこともできます。

先月の掲載順位 = 2 のすべての商品のクリック率を表示

データ ウェアハウスでこのような問題に取り組む正しい方法は何ですか (違いが生じる場合は、列指向のソリューションを検討しています)。

クライアントは、幅 1 ピクセルまでのレスポンシブ Web デザインを要求しました (最初は 0 ピクセルを要求しましたが、実際には存在しないことを納得させることができました)。

明らかに、私は文字や画像をレンダリングすることができないので、ページの高さのピクセルを使用してモールスまたはバイナリ コードですべてをエンコードすることを考えています。これは CSS だけで実現できますか?

ソース リレーショナル データベースには、親 SuretyId 行を指す自己参照 ExtendsSuretyId FK 列を持つ INT IDENTITY PK SuretyId を持つ CompanySurety というテーブルがあります。

このデータをスター スキーマ モデルに取り込んで、CompanySurety ファクト テーブル (これまでのところ) を次のように設計しました。

問題は、この親子関係を適切な次元の方法でモデル化するにはどうすればよいか (実際には、次元モデルで親子階層をモデル化する方法) です。

親ファクトを表すために、すべてのディメンションとファクト列を複製することを検討しました (現時点では、階層の深さは 1 レベルのみであるため)。しかし、これは私には間違っているようです。

pentaho ケトルを初めて使用するので、データ ウェアハウス、ディメンション、およびファクト テーブルが自動的に作成されることを知りたいですか?

ケトルの全機能を学習できるリンクを教えてもらえますか?

リレーショナル ソースから Dim_tbls を設定するにはどうすればよいですか?

これらのテーブルの例は次のとおりです。

私の目標は、これらの属性を開始スキーマに入れることです。私が抱えている問題は、ディメンション テーブルの読み込みの背後にあるロジックです。つまり、どのデータを Dim_Product にロードするのでしょうか? tbl_product にあるすべての製品? しかし、特定の製品で行われた販売数をどのように知ることができますか?

私がやりたい分析は次のとおりです。

サンプルデータ:

[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] テーブルに存在する必要があります。これは代理キーである必要があるため、グループ化できませんか?

営業所を表すディメンションがあるとします。オフィスが移動する可能性がありますが、これはタイプ II の変更になります。古いオフィスの場所で行われた操作と、現在新しい場所で行われている操作を追跡し、変更がいつ発生したかを知りたいと考えています。これまでのところ、標準的なタイプ II のデザインだけです。ここで、オフィスが別のオフィスと合併するとしましょう。つまり、元々は別個の 2 つのオフィス (「親オフィス」) の運用活動が、現在は 1 つのオフィス (「合併オフィス」) で行われています。または、ビジネスの観点から、前の 2 つのオフィスの継続である完全に新しいオフィスである可能性があります。

レポート/分析要件は次のとおりです。

• 新しい統合されたオフィスの現在の活動をすべて確認できるようにしたいと考えています。
• 合併したオフィスまたは親オフィスがこれまでに行ったすべての活動を確認できるようにしたいと考えています。
• 合併前と合併後の両方で親オフィスの 1 つで発生したアクティビティを、他の親オフィスのアクティビティ (少なくとも合併前) を表示せずに経時的に表示できるようにしたいと考えています。

これを SCD タイプでモデル化する方法がわかりません。単純に 2 つの親オフィス エントリを 1 つの新しいエントリに置き換え、それに応じてすべてのファクト テーブルを更新すると、タイプ I が変更されます。これにより、現在のアクティビティを問題なく確認できますが、履歴は失われます。記録を別々に保管すると、合併についてはわかりません。合併したオフィスを表す 3 番目のレコードを追加すると、履歴も失われます (親オフィスのどちらの自然キーも適切ではないでしょう)。

ブリッジ/多対多テーブルを使用する必要がありますか? それは私が避けたい複雑さをもたらします。ただし、それが最善の方法である場合は、そうしてください。ただし、それがどのように構造化されるかはまだわかりません。おそらく、ファクト テーブルはオフィス エントリを指し、オフィスは多対多の方法でグループ化されます。レポートは、オフィス ディメンションに直接ではなく、グループに基づいて行われます。

ElectricLlama の質問への回答

• ほとんどのユーザー インタラクションは既定のレポートを介して行われるため、基礎となる構造の複雑さはレポートから隠されます。
• 一部のユーザーは、SQL または SAS を使用してデータを取得します。現時点では、彼らがこの特定の問題を気にする可能性はほとんどありませんが、これらのツールを使用するユーザーが増えるにつれて、状況が変わる可能性があります.
• 現時点では、クエリ ライターはありません。
• 複数レベルの合併があるとは思いませんが、絶対にノーとは言えません。あったとしても、私は驚くだろう。
• この種のことをエンドユーザーにとって簡単にする方法がわかりません。これは、いくつかの要件を緩和するのに十分な議論かもしれません。

次元データベースを設計しようとすると、この問題が発生します。基本的に、代理キー、いくつかの外部キー (製品 ID の pid、国 ID と日付の cid)、および販売データを含むファクト テーブル (sale_fact) があります。粒度またはこのファクト テーブルは日単位です。これらの外部キーのさまざまな組み合わせに応じて、週 (または月) の売上データを合計するにはどうすればよいですか? たとえば、今週の国 1 での製品 1 の売上データ (pid = 1 および cid = 1 および日付 = 月曜日) と、同じ週の国 2 での製品 2 の売上データ (pid = 2 およびcid = 2 および日付 = 月曜日)。1 つの SQL でこのデータを取得するにはどうすればよいですか? サンプルの結果セットは次のようになります。

時間ディメンションを設計するジレンマがあります。時間ディメンションにミリ秒を含めるか、ミリ秒単位のディメンションを作成するかがわかりません。

ミリ秒の粒度を時間ディメンションに含めることの長所と短所を確認できます。

利点:

• ディメンション キーに対して直接計算を実行します (日付と時刻のディメンションは、インテリジェンスを格納できる唯一のデータ ウェアハウスです)。ファクト テーブルの目的は、応答時間を測定することです。

短所:

• 時間ディメンションが大きくなり、クエリのパフォーマンスが低下する可能性があります。

知っておくことが重要なその他の情報:

• マーケティング担当者は、1 か月あたり 5,000 万件の事実を期待するように私に言いました (私たちはそれがどのようなものであるかを知っています。もう少し準備する必要があります)。
• 事実は集計され、非加算的な方法で次のようになります。サービス品質の測定値が必要です: 平均 (半加算)、中央値、パーセンタイル。
  • 各ファクトには 12 のタイム チェックポイントがあります。

私のウェアハウスには、リレーショナル データベースで関連するイベントになる可能性のある 3 つのファクトがあります。それらは、PhoneContact、Appointment、およびDonationです。PhoneContactは、Appoinmentおよび/またはDonationにつながる可能性があります。私は既に予定と寄付のファクトを関連するディメンションとともに持っており、現在、PhoneContact をウェアハウスに追加しています。これらすべての事実に共通するディメンションは、誰が電話を受け、予約と寄付を行ったかを示すドナー ディメンションです。

PhoneContactがAppointmentおよび/またはDonationにつながった場合、私はそれらの事実に参加したいと思いますが、事実に参加することは禁止されていることを理解しています。それらの事実をどのように関連付ければよいでしょうか? 今のところこれ以上のことは考えられないので、Phonecontacts ファクトに AppointmentID フィールドと DonationID フィールドを配置することを検討しています。

詳細情報: 1 か月あたり約 120 万件のPhoneContactsがありますが、約 10 万件のみがAppointmentまたはDonationにつながるため、事実を結合しないことは別として、NULL1 か月あたり 110 万件をテーブルに入れるだけで、10 万件の他のイベントを取得できるようです。素晴らしいとは言えません。