1

私は BI/データウェアハウジングの初心者で、いくつかの簡単なサンプルを構築した後、より複雑な構造を構築する必要があります。私のプロジェクトは当初、製品ライセンスに関係していました。月/年別、およびプログラム別に販売数を測定し、ライセンス数を数えただけでした。

ここでの要件は、これらのメトリックからのジャンプオフを導入することです。たとえば、特定のライセンス グループにアクセスすると、それらのライセンスのまったく異なるメトリックが表示されます。たとえば、2011 年 3 月に 100 ライセンスが販売された場合、そのうちの何ライセンスが製品をインストール、アクティブ化、キャンセルしたかなどです。(私たちはその情報を追跡しますが、DW では追跡しません)。だから、私はこれを行うための最良の方法を探しています.私がしなければならない最初のことは、インストール済み、アクティブ化、キャンセルの 3 つのディメンションを追加することだと思います-そして 3 つのファクト テーブルがありますか? または、ライセンスごとに 1 つのファクト テーブルがあり、キャンセル、インストール、またはアクティブ化の行がありますか? (したがって、1 つのライセンスを繰り返すことができます)。または、1 つのファクト テーブルに、インストール済み、キャンセル済み、アクティブ化用の異なるフィールドを用意しますか? また、あるファクト テーブルを別のファクト テーブルにどのように関連付けますか? ディメンションによるものですか、それとも他の方法で関連付けることができますか?

どんな助けでも大歓迎です！

編集：

投稿していただきありがとうございます...また、2番目のオプションがおそらく正しいと考えていました。しかし、この実装では、固有の問題があります。したがって、測定される事実の 1 つは、販売されたライセンスの数です。もちろん日付別です。インストール済み、キャンセル済み、アクティブ化の行を追加するとします。要件は、関連する事実を確認できることです。たとえば、時間枠を指定して個々の行を追加すると、販売された数とインストールされた数がわかります。

しかし、彼らは与えられた時間枠、購入された数、そのうちインストールされた数を知りたがっています。たとえば、時間枠が 3 月で、3 月に 100 個が販売された場合、それらの 100 個のうち、インストールされた数は - たとえ 3 月よりもかなり遅れてインストールされた可能性があるとしても、したがって、行の日付は彼らが探している時間枠に含まれません。で....これは一般的な問題ですか？それはどのように解決されますか？

4

1 に答える 1

4

最初に、インストール済み、有効化、キャンセル済みの 3 つのディメンションを追加する必要があると思います。3 つのファクト テーブルを作成しますか?

あまり。ライセンス販売は事実です。価格があります。

ライセンス販売には、日付、製品、顧客、プログラムなどのディメンションがあります。

「インストール」または「アクティベーション」は、ライセンスの状態変更イベントです。ライセンスごとに「イベント」があります (販売、インストール、有効化など)。

したがって、ライセンスには「販売」ファクト、「インストール」ファクト、および「アクティベーション」ファクトがあります。それぞれが (最低限) 時間との関係です。

または、ライセンスごとに 1 つのファクト テーブルがあり、キャンセル、インストール、またはアクティブ化の行がありますか? (したがって、1 つのライセンスを繰り返すことができます)。

これにより、各イベントが複数のディメンションでリッチになる可能性があるため、最も柔軟性が高くなります。その後、一連のイベントを編成して、ライセンスの履歴を提供できます。

これは非常にうまくいきます。

最も一般的なダッシュボード メトリックのすべてのイベントをトラバースする手間を省くために、単純なカウントと合計のサマリー テーブルを作成することがよくあります。

要件は、関連する事実を確認できることです。

右。ファクト テーブルの複数の行を結合しています。イベントが販売された行、イベントがインストールされた行と外部結合された行、イベントがアクティブ化された行と外部結合された行など。事実の中の単なる外部結合です。

そう。3月の売上集計は簡単です。イベント=「セール」。時間は、time.month = "march" のすべての行です。簡単。

インストールになった 3 月の販売数。これらのライセンスのすべての「インストール」イベントと外側の節が結合された同じ「マーチ セール」。"sales" のカウントは count(*) と同じです。外部結合によっていくつかの null が挿入されるため、インストール数が少なくなる可能性があります。

アクティベーションとなった 3 月の販売数。すべての「活性化」イベントに節外が加わった「マーチセール」。アクティベーションには日付の制約がないことに注意してください。

または、1 つのファクト テーブルに、インストール済み、キャンセル済み、アクティブ化用の異なるフィールドを用意しますか?

テーブルの列がビジネス プロセスを指示するため、これはうまくいきません。そのビジネス プロセスは変更される可能性があり、ファクト テーブルの列を際限なく調整することになります。

「同様に」うまくいかないと言ったということは、究極の柔軟性を提供しないことを意味します。場合によっては、究極の柔軟性は必要ありません。場合によっては、業界 (または規制) によって、非常に固定された構造が定義されることがあります。

また、あるファクト テーブルを別のファクト テーブルにどのように関連付けますか? ディメンションによるものですか、それとも他の方法で関連付けることができますか?

定義による寸法。ファクト テーブルには、測定値とディメンションへの FK の 2 つしかありません。

一部のディメンション (「ライセンス インスタンス」など) は、PK 以外の使用可能な属性がほとんどないため、縮退しています。

つまり、ライセンスに関連付けられた「販売済み」ファクト、ライセンスに関連付けられたオプションの「インストール済み」ファクト、およびライセンスに関連付けられたオプションの「アクティブ化」ファクトがあります。ライセンスは、オブジェクト ID (データベースの代理キー) と、おそらくライセンス ID 自体 (ライセンスのシリアル番号またはデータベース外のもの) です。

それ以上のことをする前に、Ralph Kimball の Data Warehouse Toolkit を試してください。

于 2011-04-14T17:22:36.250 に答える