データウェアハウスのDimテーブルとFactテーブルのセットアップ

Question

クライアント用のデータウェアハウスの作成を担当しています。関係するテーブルは、実際にはそこにある伝統的な例（製品/注文）に実際に従っていません。クライアントは、本質的にケースの処理センターです（法的ケースに似ています）。毎日、新しいケースが「ケース」の下でDBに入力されます。表。各列には、ケースに関連する情報が少し含まれています。ケースの処理中に、追加の1対多テーブルにケースに関連するイベントが入力されます。これらのイベントテーブルにはかなりの数があり、サンプルテーブルは次のとおりです（case-open、case-dept1、case-dept2、case-dept3など）。これらの各テーブルには、「cases」に戻るマップIDがあります。表。いくつかのルックアップテーブルも含まれます。

現在、レポートのニーズはさまざまな段階でボトルネックを明らかにすることに関連しており、粒度はプロセスの特定の領域の時間レベルです。

ここではあまりにも多くの質問をしているかもしれませんが、DimテーブルとFactテーブルをセットアップする方法や、他の提案があるかもしれません。

Answer 1

Kimballの本、特にこれをチェックすることをお勧めします。問題のあるドメインへのアプリケーションについて考えさせるための例をいくつか用意する必要があります。

いずれの場合でも、次元モデルが適切かどうかを判断する必要があります。 3NFデータベースの「エンタープライズデータウェアハウス」を、さまざまなインデックスやサマリーなどで処理することは非常に可能です。

現在のスキーマが表示されていなくても、言うのは非常に困難です。あなたが最終的にいくつかのスターモデルになり、いくつかの適合した寸法がそれらを結びつけるように聞こえます。そのため、適合ディメンションの1つとしてケースディメンションを使用できます。他の各テーブルのファクトは、適合ディメンションと、そのファクトに適切な他のディメンションの両方にリンクするファクトテーブルになります。たとえば、ケースオープンの従業員IDがある場合、従業員適合ディメンションにリンクします。 、case-open-factテーブルから。この適合ディメンションは、いくつかの補助ファクトテーブルから数回リンクされる場合があります。

Kimballのモデリング方法はかなり単純で、レシピのように従うことができます。すべてのファクトを識別し、それらをファクトテーブルにグループ化し、各ファクトテーブルの個々のディメンションを識別してから、必要に応じてディメンションテーブルにグループ化し、各ディメンションのタイプを識別することから始める必要があります。

Answer 2

ファクトテーブルはケースイベントであり、数値を持たないという点で「事実なし」です。ディメンションは、システム内の他のデータに応じて、時間、イベントタイプ、ケース、その他のディメンションになります。

イベントテーブルを単一のファクトテーブルに統合し、「イベントタイプ」ディメンションのラベルを付ける必要があります。スループット/ボトルネックレポートは、特定のケースのイベントタイプの特定の組み合わせについて、イベント時間の差を計算しています。

レポートはイベントとイベントの時間を計算し、場合によってはヒストグラムにまとめる必要があります。特定の種類のイベントの組み合わせにラベルを付け、対象のイベントにラベルを適用することもできます。その後、これらのイベントに時間を記録することができます。これにより、OLAPツールを使用した時間のスライスアンドダイス操作が可能になります。

ライフサイクルの進行の特定の段階をベンチマークする場合、ケースタイプ、イベントタイプ1、イベントタイプ2、ベンチマーク時間に対応するテーブルがあります。

少しのマッサージで、データマイニングツールキットまたは単純な回帰分析を使用して、ケース属性とイベントイベント時間（YMMV）の相関を見つけることができる場合があります。

Answer 3

開発の他の側面と同様に、最終要件（「もしそうなら「ユーザーストーリー」」）から逆方向に問題にアプローチする必要があります。ウェアハウスの最も保守的なアプローチは、トランザクションデータベースのコピーを単純に表すことです。そこから、要件に従って、特定のデータアクセスパターンのパフォーマンスを向上させるために特定の最適化を行うことができます。ただし、これらを最適化と見なし、データウェアハウスがすべてのファクトにわたって可能なすべてのディメンションの複雑な爆発であると自動的に判断することは重要ではないと考えています。私の経験では、ほとんどの目的で、分析クエリの90％以上に対して直線表現が適切であるか、理想的です。残りについては、最初にインデックス、インデックス付きビュー、追加の統計、または構造に影響を与えずに実行できるその他の最適化を検討します。次に、パフォーマンスを改善するために集約またはその他の冗長構造が必要な場合は、これらを「データマート」に分離することを検討してください。 （少なくとも概念的に）原始的な事実とその冗長性を分離します。最後に、要件があまりにも流動的であり、集約がこの方法で効率的に機能するために重い必要がある場合、データの大規模な爆発、つまりスタースキーマを検討することができます。繰り返しますが、これを可能な限りデータの最小断面に制限してください。

Answer 4

私が本質的に思いついたものは次のとおりです。 Thx NXC

ファクトイベント

EventID TimeKey CaseID

薄暗いイベント

EventID EventDesc

暗時

TimeKey

薄暗い地域

RegionID RegionDesc

ケース

CaseID RegionID

Answer 5

これは、問題を検討する前に解決策を選択する場合です。すべてのデータウェアハウスがスタースキーマモデルに適合するわけではありません。ここでデータを集約していることはわかりません。これまでのところ、事実のないファクトテーブルと、少なくとも1つの急速に変化するディメンション（ケース）があります。

これまで見てきたことを見てみると、このデータベースの中心的存在が当てはまると思います。イベントを真ん中に留めようとするのは正しくないようです。別の方法で見てみてください。おそらく、ケース、イベント、および開始するケースイベント。