2

免責事項:以前にデータ ウェアハウスを作成したことがありません。Kimball の Data Warehouse Toolkit のいくつかの章を読みました。

背景:工場 (工場) の管理チームは、さまざまな方法で生産情報を細かく分析できる必要があり、部門内の製造工場全体で一貫したレポート形式が必要です。ビジネス分析を通じて、事実粒度はプロセスが完了するごとに 1 行であるという結論に達しました。完成したプロセスは、「機械加工」または「組み立て」を意味します。私はこれを「生産事実」と呼んでいます。

ビジネスが答える必要がある質問は次のとおりです。

  • プロセスが完了したとき、誰が作業していましたか?
  • プロセスのサイクル タイムはどのくらいでしたか?
  • このプロセスで製造された部品のシリアル番号は何ですか?

私のスキーマには、次の第 1 レベルのディメンションが含まれています。第 1 レベルを超えるディメンションはありませんが、工場のディメンションと、部品タイプ、シフト、およびプロセスのディメンションとの間に相互関係があります。

  • 部品タイプ (属性: サロゲート キー、部品番号、モデル、バリアント、部品名)
  • 植物 (属性: サロゲート キー、植物名、植物頭字語)
  • シフト (属性: サロゲート キー、プラント キー、開始時間 24、開始時間、終了時間 24、終了時間)
  • プロセス (属性: サロゲート キー、プラント キー、生産ライン、プロセス グループ、プロセス名、マシン タイプ)
  • 日付 (典型的な日付ディメンション属性)
  • 時刻 (典型的な時刻ディメンション属性)

非次元の事実は次のとおりです。

  • 部品シリアル番号 (部品タイプのインスタンス)
  • サイクルタイム
  • 従業員 ID *MULTI-VALUED*

問題

私の問題は、複数の従業員がその時点でプロセスに取り組んでいた可能性があることです。そのため、モデルを変更する必要があるかどうか、およびモデルで従業員を最もよく表現する方法を考えています。従業員情報を保存しようとしているのではなく、会社の従業員 ID だけを保存しようとしています。次のオプションを検討しました。

  1. ファクト テーブルの従業員列に複数の従業員 ID を許可します (たとえば、コンマ区切り)。欠点: プロセスに従事する従業員の数は可変数です。最大 X 人の従業員を収容するのに十分な大きさのフィールドを作成する必要がありますか? X はどうあるべきか?
  2. 従業員ごとに各生産ファクトのレコードを作成します。これは、同じファクトに対して複数のレコードを意味します。それは悪いでしょう。:)
  3. 従業員ディメンションと、従業員ディメンション テーブルとファクト テーブルの間に "Process Employees" ブリッジ テーブルを作成します。問題: その時点でプロセスに取り組んでいた従業員がファクト テーブルに表示されません。
  4. Employee ディメンション、Process Employees Group テーブル、および Process Employees Group テーブルと Employee ディメンション テーブル間のブリッジ テーブルを作成します。従業員グループとブリッジ テーブルには、a) 考えられるすべての従業員の組み合わせを事前に入力する必要があります。これは、何千人もの従業員がいるため、どのレベルでも実用的ではありません。または、b) ETL 中にその場で入力します。4b では、特定の従業員グループが各プロセスにすでに存在するかどうかを確認する必要があります。これは、ソース レコードが 1 日に数回よりも頻繁にバッチ処理される場合 (たとえば、ほぼリアルタイムのレポートで 1 時間に 10 X)、DBMS/ETL システムに負担をかける可能性があります。

私の質問

オプション 3 が最も実行可能なオプションだと考えていますが、いくつか留保があります。潜在的な注意事項はありますか？他に検討すべき代替案はありますか? プロセスに携わった従業員をファクト テーブルから除外してもよろしいですか。

アドバイスありがとうございます。

4

2 に答える 2

2

緩やかに変化する次元という概念があります。これらはディメンションと見なされます。基本的にここに、PartEmployee と呼ぶテーブルがあります。

このテーブルの構造は

PartId - PK
EmployeeId - PK
EmployeeStartDate - PK
EmployeeEndDate

従業員がまだ部品に取り組んでいる場合、終了日は null になります。新しい従業員が部品の作業を開始すると、その部品の以前の従業員レコードは閉じられ、新しい従業員の部品に対して新しいレコードが作成されます。

PartFact テーブルに従業員を追加します。

EmployeeId

この列は現在の従業員を保持します。このファクト レコードは、新しい従業員が部品の作業を開始するたびに更新されます...

これにより、どの従業員がその部品を担当したかという歴史的な視点と、その部品を最後に担当した従業員の情報が得られます。

お役に立てれば...

于 2014-05-17T04:06:56.870 に答える
2

オプションについて考える時間がありましたが、元の投稿に記載されている 4 つのオプションのどれも正しくありません。議論されている問題は、古典的な「カバレッジ」の問題のようです。ビジネスは、特定の時間にどの従業員がどのプロセスで働いていたかを知る必要があります。その情報があれば、特定のプロセスが完了したときに、誰が特定の部品に取り組んでいたかがわかります。これは、従業員ディメンションと生産プロセス ディメンションの間のファクトレス ファクト テーブルとして表すのが最適です。

このアプローチは、1 人の従業員の「カバレッジ」ファクトが複数のプロセス生産ファクトにまたがるため、スペースを節約し、クエリ能力を向上させるのにも役立ちます。

于 2014-05-19T14:38:31.883 に答える