事实表设计

Question

我对事实表的设计提出了一些一般建议。我一直在搜索论坛和阅读书籍，但我只是在经过一些确认后我猜。

事实表需要根据工作日志类型分解项目所需时间来回答问题。每个项目都有许多项目工作项目。每个项目仅适用于单个客户。

我到目前为止是Date，Customer，Project，worklogtype，worklogstatus的维度。然后我的事实表是每个项目工作项目的一行。事实表上的每一行都只是一个WorklogID，ProjectID，CustomerID，WorklogTime，WorkLogType，WorklogStatus，Date，Duration。

我想我们可以报告每个项目的持续时间，按工作类型进行切片。然后我可以根据客户信息进一步过滤。

事情是有人可能会去改变以前的工作日志项目并修改持续时间（尽管业务规则说应该添加另一个记录）。所以我想或者只是更新现有的记录，或者添加一条新记录以及一列来指定活动记录。

我的问题是，这是一个好方法去做，或者应该工作日志信息是它自己的维度和项目信息是事实（从我了解的最细微的信息应该是事实）。

任何帮助将不胜感激，哪怕它只是链接到其他答案我已经错过或书上=读了）

Answer 1

其实设计这个你将没有互动问答几乎不可能& A.但是，你提出了许多可以从改进中受益的特定断言，所以我可以提供至少一系列具体的改进，但最终的设计仍然是你的。

• 仔细查看累积快照事实表。当你有事件的时间表时，这通常是最好的设计。它允许你输入一系列可能是你需要的日期。要小心，因为它不适用于无数的日期 - 你必须有一个明确定义的集合，或限制重复次数。例如。保险过程中的重新报价数量;原则上你可以不断要求你的车保险报价永远，但我们可能会限制在，比如说3.

• 你说“更新记录”。没有！无论你做什么，都不要更新！您可以更新一次（除了修复数据加载问题），是添加一个您设置为不活动的活动/不活动指示器。即使这是有争议的。一般来说，如果你认为你需要更新，挑战你的模型。你说，“还要添加一列来指定活动记录”。不知道这是否正是你需要的，但它比更新更好！

• 你说“项目信息是事实”。这是一个不连贯的陈述，所以你的意思是：1）事实表的粒度在项目级别，或者2）与项目维度建立连接，以便在项目级别切分和切割事实表。每＃1，你的解决方案不能只是在项目粮食。从上面的定义可以看出，它需要处于更深层次的阶段，我相信Worklog级别。现在，这仍然需要项目维度，因此请连接到项目维度。但是，如果您有项目级别的事实，请勿将它们填入Worklog或任何其他更深的谷物中。相反，您需要多个事实表。如果您有工作日志级别的指标，则需要一个工作日志级别的事实。如果您还有项目级指标，则需要项目级事实。现在，有一些关于在更细粒度表上显式显示更高粒度的事实表与总表的争论。但无论哪种方式，都不要在工作日级粒度下填充项目级度量标准，更一般的情况是不要在较低级别填充任何更高级别的度量标准。在我们处理它时，不要在较高级别的粮食上重复较低级别的度量标准，例如在项目级事实表中复制工作日志级度量标准。像这样的谷物移动使得模型难以理解，并且在聚合时引入用户错误的高机会。

• 也考虑“时间块”作为一个维度。也就是说，这听起来像你的工作可以分解。也就是说，对于你提到的所有相同的维度，你仍然可以在事实表中获得多个条目。如果是这样，请添加另一个维度，使“更多的事实信息以相同的维度值出现”的概念。我一直把这些东西放在引号中，因为它往往是一个垃圾维（研究，如果你不知道它是什么），名称因问题领域和设计者意见而异。但是，这个概念是，你将捕获随着时间推移而来的零件的概念，作为它自己的维度自己的概念。

• 我在上面简单地提到过，可以有一个最低谷物事实表并根据需要聚合起来。你也暗示它，如果你阅读了简单的金宝球的东西，它会告诉你这一点。在我构建的每个现实系统中，这是行不通的 - 因为几乎总是有非常复杂的规则适用于聚合。也就是说，这不仅仅是SUM或CASE可以解决的问题。例如，保险在州一级进行管理，所以州的汇总往往不仅仅是要求所有新英格兰国家的问题。因此，计划拥有最低谷物事实表，是的，但计划在其他几个谷物上有一个事实。就个人而言，我从一开始就为每一个合理的谷物设计一个，然后只有当项目显示简单时，我们才会退出，这是非常罕见的。

希望这会有所帮助。谢谢！