事实表组织

Question

我正在参与创建使用Kimball星型模式方法的报告软件。整个团队(包括我)都没有使用这项技术，所以我们在这方面是新的。

到目前为止，在或系统中有两个维度和事实表。例如：

• DIM_Customer (面向客户的维度表)
• DIM_BusinessUnit (业务单位的维度表)
• FT_Transaction (事实表，每个事务的粒度)
• FT_Customer (用于客户、客户id和日期的事实表在复合PK中)

这是当前FT_Customer的结构：

• customer_id #(客户id，复合PK的一部分)
• as_on_date #(观察日期，复合PK的一部分)
• 世界人工智能大会(KPI)
• 瓦特(KPI)
• waddl (KPI)
• wadtp (KPI)
• aging_bucket_current (KPI)
• aging_bucket_1_to_10 (KPI)
• aging_bucket_11_to_25 (KPI)
• . ...Fields世界人工智能大会、wat、waddl和wadtp与交易延迟有关.这些字段通过对FT_Transaction表的聚合查询计算，这些表由customer_id和as_on_date.Fields aging_bucket_current分组，aging_bucket_1_to_10和aging_bucket_11_to_25包含按延迟支付分类的事务数。例如，aging_bucket_current包含按时支付的事务数，aging_bucket_1_to_10包含以1至10天延迟支付的事务数，...This结构用于从PHP应用程序和Cognos生成报表。我们讨论了如何对FT_Customer表进行结构调整，以便使它更适用于Cognos这样的外部系统。 FT_Customer的新拟议结构：
• customer_id #(客户id，复合PK的一部分)
• as_on_date #(观察日期，复合PK的一部分)
• kpi_id #( KPI的id，指向DIM_KPI维度表的外键，复合PK的一部分)
• kpi_value (KPI值)
• . ...For这个提议，我们将有额外的维度表DIM_KPI：
• kpi_id #
• titleThis表将包含所有KPI (wat，世界人工智能大会，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. 您的事实表用于进程、或events，您想要分析。您应该将它们命名为noun_verb_noun (例如customers_order_items)。如果你不能想出一个这样的名字，你可能没有一个事实表。你的客户事实表是用来做什么的？客户通常是一个维度表。
3. 您的数据仓库的目的是促进分析。使用较长的列名(带有_ as单词分隔符)。让你的分析人员过轻松的生活。