1

我正在参与创建利用 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、waddl 和 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 生成报告。我们讨论了重组 FT_Customer 表，以使其更适用于 Cognos 等外部系统。
FT_Customer 的新提议结构：
- customer_id #（客户 ID，复合 PK 的一部分）
- as_on_date #（观察日期，复合 PK 的一部分）
- kpi_id #（KPI 的 id，指向 DIM_KPI 维度表的外键，复合 PK 的一部分）
- kpi_value（值 KPI）
- ... ...
对于这个提案，我们将有额外的维度表 DIM_KPI：
- kpi_id #
-标题
此表将包含所有 KPI（wat、waic、waddl、老化桶...）。
FT_Customer 的第二个结构显然会比当前结构有更多的行。
FT_Customer 哪种结构更通用？
将两种结构保存在单独的表中是否可以接受？这显然会给 ETL 层带来额外的负担，因为有些工作会重复两次，但另一方面它会更容易生成各种报告。

提前感谢您的建议。

4

2 回答 2

0

  1. 在继续之前，请自行购买敏捷数据仓库设计并通读一遍。它很便宜。

    http://www.amazon.com/Agile-Data-Warehouse-Design-Collaborative/dp/0956817203

  2. 您的事实表用于您要分析的过程或事件。您应该为它们命名（示例）。如果你想不出这样的名字，你可能没有事实表。您的客户资料表是做什么用的？客户通常是一个维度表。noun_verb_nouncustomers_order_items

  3. 数据仓库的目的是便于分析。使用较长的列名（使用 _ 作为单词分隔符）。让您的分析师生活轻松。

于 2014-05-27T17:01:10.943 回答
0

第一种结构对我来说似乎更自然和常见。但是，第 2 个更灵活，因为它支持在不改变事实表结构的情况下添加新的 KPI。

如果访问数据的不同方式实际上需要不同的结构，那么拥有两个具有相同数据的事实表并没有错，只要：

  1. 两个表总是一起加载（不一定是并行的，而是在同一个数据加载作业/工作流中），
  2. 措施计算是一致的（如果可能，重用逻辑）。

您应该测试任何数据不一致的结果。

于 2014-05-21T19:46:56.407 回答