我们正在做一些复杂的数据累积。我们的客户向我们发送了一些东西，其中包括两个维度(时间和业务部门)。时间主要是一年中的一个月。业务部门维度仅具有一些属性：名称和业务单位可用于报告和分析目的的一些类别。

他们发送给我们的内容包括一些当前状态信息(日期和代码)。这些看起来像事实。他们还发送一些表征与业务部门之间关系的信息(主要是添加代码)。同样，这些对于业务部门和时间段是唯一的。

最后，他们向我们发送显然是加法事实的东西。它包括货币和具有适当单位的计数。

我是否应该将这些定性信息与单个事实表混合在一个事实表中？还是应该将定性材料(只能用于计数)与定量材料(可以用于总和)分开？

解决方案

如果数据都直接与加法事实相关，并且不是我们要分组/排序/搜索的数据，那么将其放入事实表中就可以了。

但是请注意，事实表中的非累加数据将防止汇总，或者将成为有损操作。

仅当事物退化时才将它们放入事实表中(在维中导致维数高/唯一性问题，因为维将事实表与维关系成1-1关系)。 Kimball建议避免除事实之外(例如唯一的订单号)使尺寸退化的任何诱惑。

我们总是可以将它们放在Kimball所谓的"垃圾"维度中。所有这些代码都可以简单地归入垃圾内容。大多数日期将作为特定角色中日期维度的键进入事实表(通常使用YYYYMMDD形式的自然int键，这是我们唯一一次不使用非身份无意义的替代键的情况之一)

我喜欢天真地将星星视为所有事实，然后方便地确定哪一维度进入哪个维度。记住，明星不一定是ERD风格的规范化OLTP数据库，而不一定是将它们视为与特定业务实体相对应的。

布拉德·威尔逊(Brad Wilson)准确地描述了将它们添加到事实表中的风险。过去，我在事实表中添加了垃圾属性，只是以后需要重构。

The stuff they send us includes some
  current state information (dates and
  codes). These seem fact-like. They
  also send some information that
  characterizes the relationship with
  the business unit (mostly additional
  codes). Again, these are unique to the
  business unit and time period.

日期有什么商业目的？暂时，我建议将它们设置为自己的尺寸并准确地描述它们。

输入的额外代码有多大的可变性？如果事实表的详细信息是日期和BU，为什么不能将它们包括在BU维中并视为缓慢变化的属性？

没有更多细节，我无法提出明确的建议，但这将是我要问自己的第一个问题。