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 レイヤーに追加の負担がかかりますが、一方で、さまざまなレポートの生成が容易になります。
提案をお寄せいただきありがとうございます。