事实表组织

Question

我正在参与创建使用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）
  - ...... Fields 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层带来额外的负担，因为有些工作会完成两次，但另一方面它会更容易生成各种报告。
 
提前感谢您的建议。

Answer 1

第一种结构对我来说似乎更自然和共同。但是，第二个更灵活，因为它支持添加新的KPI而不改变事实表的结构。

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

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

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

Answer 2

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

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

2. 您的事实表适用于您要分析的流程或事件。您应该将它们命名为noun_verb_noun（示例customers_order_items）。如果你不能提出这样的名字，你可能没有事实表。您的客户事实表是什么？客户通常是维度表。

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