問題タブ [dimensional-modeling]

免責事項:以前にデータ ウェアハウスを作成したことがありません。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 が最も実行可能なオプションだと考えていますが、いくつか留保があります。潜在的な注意事項はありますか？他に検討すべき代替案はありますか? プロセスに携わった従業員をファクト テーブルから除外してもよろしいですか。

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

顧客ディメンション テーブルがファクト テーブルよりも大きいデータ ウェアハウス プロジェクトに取り組んでいます。ディメンションとファクト テーブルは、CRM システムから作成されます。

ファクト テーブルは、手紙が顧客に送信されたり、顧客が支援を求めたりするなどのアクティビティを監視します。顧客の半分は活動がなく、残りの顧客は活動がほとんどありません。アクティビティを持っている顧客のほとんどは、単一のアクティビティを持っています。

スター スキーマがプロジェクトにとって最適なソリューションであるかどうかはわかりません。同様のプロジェクトに取り組んだことがありますか?その解決策は何ですか?

Kimball スター スキーマ法を利用したレポーティング ソフトウェアの作成に参加しています。チーム全体 (私を含む) はこのテクノロジを使用したことがないため、これは初めてです。
これまでのところ、またはシステムにはいくつかのディメンション テーブルとファクト テーブルがあります。例:
- DIM_Customer (顧客のディメンション テーブル)
- DIM_BusinessUnit (ビジネス ユニットのディメンション テーブル)
- FT_Transaction (ファクト テーブル、トランザクションごとの粒度)
- FT_Customer (顧客のファクト テーブル、顧客 ID および日付は複合 PK にあります)

これは FT_Customer の現在の構造です:
- customer_id # (顧客 ID、複合 PK の一部)
- as_on_date # (観測日、複合 PK の一部)
- waic (KPI)
- wat (KPI)
- waddl (KPI)
- wadtp ( KPI)
-aging_bucket_current (KPI)
-aging_bucket_1_to_10 (KPI)
-aging_bucket_11_to_25 (KPI)
- ... ...
フィールド waic、wat、wadl、wadtp は、トランザクションの支払いの遅延に関連しています。これらのフィールドは、customer_id および as_on_date でグループ化された FT_Transaction テーブルに対する集計クエリによって計算されます。
フィールドaging_bucket_current、aging_bucket_1_to_10、aging_bucket_11_to_25には、支払いの遅延によって分類されたトランザクションの数が含まれています。たとえば、aging_bucket_current には期限内に支払われるトランザクションの数が含まれ、aging_bucket_1_to_10 には 1 ～ 10 日の遅延で支払われるトランザクションの数が含まれます...
この構造は、PHP Web アプリケーションおよび Cognos Studio からのレポート生成に使用されます。Cognos などの外部システムでより使いやすくするために、FT_Customer テーブルを再構築することについて説明しました。
FT_Customer の新しい提案された構造:
- customer_id # (顧客 ID、複合 PK の一部)
- as_on_date # (観察日、複合 PK の一部)
- kpi_id # (KPI の ID、DIM_KPI ディメンション テーブルを指す外部キー、複合 PK の一部)
- kpi_value (値 KPI)
- ... ...
この提案では、追加のディメンション テーブル DIM_KPI:
- kpi_id #
- title
このテーブルには、すべての KPI (wat、waic、wadl、エージング バケットなど) が含まれます。
FT_Customer の 2 番目の構造には、明らかに現在の構造よりも多くの行があります。
FT_Customer のどの構造がより普遍的ですか?
両方の構造を別々のテーブルに保持することは許容されますか? 一部の作業が 2 回行われるため、明らかに ETL レイヤーに追加の負担がかかりますが、一方で、さまざまなレポートの生成が容易になります。

提案をお寄せいただきありがとうございます。

DataWarehouse の日付ディメンションを実装しています。私のシナリオによれば、10 月から 1 月までSeason_Aの日と 4 月から 8 月までの日をとしてマークする必要がありSeason_Bます。

dimDate以下のようにテーブルを作成しました。

3 つのファクトといくつかのディメンションを持つ表形式のモデルがあります。

3 つの事実のうち 2 つは、アカウントと製品に関するものです。

顧客のアカウントに実現した事実。アクティブな数、現在の残高、開始時の残高など。

Product Fact は、顧客が持っているさまざまなサプリメント製品に関するものです。彼/彼女はサプリメント製品を持っているかもしれませんし、持っていないかもしれません. 現在、これには、顧客がさまざまな製品で支払うべき金額、リベート額などの事実があります。

現在、両者は共通の Dim として Dimension Account を持っています。

アカウントと製品の関係は 1-M です。アカウントにサプリメント製品がある場合は、1、2、最大 3 になります。ない場合は、1-0 です:)

私たちが抱えている問題は、Account Dim 属性で両方の事実をスライスしたい場合、補足製品を持つアカウントのみを取得することです。テーブルモデルはINNER JOINSで機能すると信じているためです。この場合、OUTER JOINが必要です。クエリですべてのアカウントを取得したいので、サプリメント製品と一致する場所で、その製品の事実を確認します。

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

古いデータ ウェアハウスを調べていると、ファクトレス ファクト テーブル (Fact_contact) と Dim_Incident の間の異常な 1 対 1 の関係に遭遇しました。

通常、Fact_Contact はケース/チケット/問い合わせの記録に使用されます。一部の顧客は匿名です。したがって、一意のカウントに使用される uniqueCustRef および CustomerRef の「ファクト」があります。

ファクト テーブルとディメンション テーブルの 1 対 1 の関係は適切ではありません。それは推奨される解決策ですか？現在、なぜこのように設計されたのかについてのドキュメントはありません。

ありがとうございました。

データ モデリングでは、ディメンションが別のディメンションへの代理キーを属性として持つことは許容されますか?それとも、これは常にビジネス キーであるべきですか?

部門番号を属性として持つ項目ディメンションがあります。また、Department ディメンションもあります。Item ディメンションが SK を Department ディメンションまたは単にビジネス キーに保持することは許容されますか?

ディメンション テーブルもファクト テーブルにすることはできますか? たとえば、名前、性別などの標準属性を持つ Customer ディメンション テーブルがあります。

SSAS を使用して、今日、先月、昨年などに作成された顧客の数を知る必要があります。

顧客キーと日付キーを使用して顔のないファクト テーブルを作成することも、両方のキーが既にあるため、同じ顧客ディメンション テーブルを使用することもできます。

Customer Dimension テーブルを Fact と Dimension の両方として使用するのは普通ですか?

ありがとう