5

ディメンションとして、プロセス（何）をワーカー（担当者）と「現在の」ステータスにリンクするという事実があるD_PROCESSとD_WORKERしましょう。D_STATUSF_EVENT

プロセスステータスは時間とともに変化します。F_EVENTプロセス/ステータス/ワーカーごとに1行、またはプロセス/ワーカーごとに1行、および特定のプロセス/ワーカーのステータス変更ごとに「どこか別の場所」に1行を格納する必要がありますか？

私はDatawarehouseを初めて使用しますが、データモデル化に関連するベストプラクティス/チュートリアルを見つけるのは困難です。

4

1 に答える 1

8

次元モデリングの優れた入門書については、RalphKimballによるDataWarehouseToolkitをお読みください。

プロセス変更イベントをF_EVENTに保存しているようです。このプロセスに開始と終了が定義されている場合は、スナップショットファクトテーブルを作成して、プロセスを経時的に追跡できるようにします（プロセスが1つのステップから別のステップに移動するたびに行を更新するだけです）。

編集：

寸法を例として使用して、一般的なケースを作成してみます。

D_PROCESSの場合、「プロセス」のモデリングは通常、ディメンションとしてモデリングされておらず、「what」と呼ばれているため、これを「D_ACCOUNT」に名前変更します。

基本的なデータモデルは、WORKERSがACCOUNTSを処理する「税処理システム」用であり、各ACCOUNT / WORKERの組み合わせには、このプロセスが現在存在する場所のいくつかの可能な「ステータス」があります。

D_ACCOUNT
    ACCOUNT_NUMBER
    ACCOUNT_TYPE

D_WORKER
    WORKER_ID
    FIRST_NAME
    LAST_NAME
    BADGE_NUMBER
    SHIFT

D_STATUS
    STATUS_ID
    STATUS_NAME

これで、ワーカーによって実行された、アカウントで発生したすべての「イベント」についてレポートする場合は、トランザクションレベルのファクトテーブルF_EVENTを作成できます。

F_EVENT
    ACCOUNT_ID
    WORKER_ID
    STATUS_ID
    EVENT_TIME_ID
    Metrics taken at time of the measurement (Cost, Worker time spent, etc)

行を識別するディメンションの一意の組み合わせを、ファクトテーブルの粒度または粒度と呼びます。

このテーブルの詳細は、アカウント、ワーカー、ステータス、および時間です。「水曜日にシフト3の従業員がアカウントの処理にどのくらいの時間を費やしましたか？」などの質問に答えます。または「処理ステータスを「CLOSED」に変更したイベントがいくつ発生しましたか？

このタイプのテーブルがどれだけ役立つかはわかりません。

代わりに、プロセスがさまざまなステータスを移動するときに、プロセス自体を追跡することに関心があるとします。ステータスは常に「NOTSTARTED」から「INPROCESS」、「CLOSED」へと時間的に進むと仮定します。

キンボールが「累積スナップショットファクトテーブル」と呼ぶものを作成します。

F_TAXPROCESSING
    ACCOUNT_ID
    WORKER_ID 
    CURRENT_STATUS_ID
    NOT_STARTED_DTTM
    NOT_STARTED_FLAG
    IN_PROCESS_DTTM
    IN_PROCESS_FLAG
    CLOSED_DTTM
    CLOSED_FLAG

このテーブルの穀物は、アカウント、ワーカーです。このテーブルは、ステータスへの変更の日時と、そのステータスに達したときのフラグを更新することにより、「プロセス」を追跡します。

これにより、時間の経過とともにプロセスを追跡し、「処理中」ステータスに反応したアカウントの数、そこに到達するまでにかかった時間などを確認できます。

于 2012-06-20T12:56:15.817 に答える