我们正在做一些复杂的数据积累。我们的客户向我们发送了一些包含两个维度（时间和业务单位）的内容。时间主要是年月。业务单位维度只有几个属性：名称和几个类别，BU 可以属于这些类别以用于报告和分析目的。
他们发给我们的东西包括一些当前状态信息（日期和代码）。这些看起来像事实。他们还发送一些描述与业务部门关系的信息（主要是附加代码）。同样，这些对于业务部门和时间段来说是独一无二的。
最后，他们向我们发送了显然是附加事实的东西。它包括具有适当单位的货币和计数。
我应该将这些定性信息与附加事实混合在一个事实表中吗？或者我应该将定性的东西（只能与计数一起使用）与定量的东西（可以与总和一起使用）分开吗？
如果数据既与附加事实直接相关，又不是您想要对其进行分组/排序/搜索的数据，那么将其放入事实表中是可以的。
但请注意，事实表中的非相加数据要么会阻止汇总，要么会成为有损操作。
仅当事物退化时才将它们放入事实表中（导致维度中的高基数/唯一性问题，其中维度与事实表的关系为 1-1）。Kimball 建议避免将退化维度以外的任何内容与事实（例如，唯一的订单号）结合起来。
你总是可以把这些放在 Kimball 所说的“垃圾”维度中。所有这些代码都可以简单地归为垃圾维度。大多数日期将作为特定角色的日期维度的键进入事实表（通常使用 YYYYMMDD 形式的自然 int 键 - 这是我们不使用非身份无意义代理键的唯一时间之一）
我喜欢天真地将星星视为所有事实，然后哪些列进入哪些维度只是由方便决定的。不必将它们视为对应于特定的业务实体 - 请记住，星号不是 ERD 样式的规范化 OLTP 数据库。
Brad Wilson 准确地描述了将它们添加到事实表中的风险。过去，我在事实表中添加了垃圾属性，只是为了以后需要重构。
他们发给我们的东西包括一些当前状态信息（日期和代码）。这些看起来像事实。他们还发送一些描述与业务部门关系的信息（主要是附加代码）。同样，这些对于业务部门和时间段来说是独一无二的。
这些日期有什么商业目的？顺便说一句，我建议将它们设为自己的尺寸并准确描述它们。
进来的额外代码有多不稳定？如果事实表的粒度是日期和BU，为什么不能将它们包含在BU维度中并视为渐变属性？
如果没有更多细节，我无法做出坚定的建议，但这些将是我要问自己的第一个问题。