Database 我的事实表中是否可以将非度量值代码与度量值混合？

我们正在做一个复杂的数据积累。我们的客户向我们发送了一些包含两个维度（时间和业务单位）的内容。时间主要是一年一个月。业务单元维度只有几个属性：一个名称和几个类别，业务单元可以属于这些类别，以便进行报告和分析

他们发给我们的东西包括一些当前状态信息（日期和代码）。这些似乎是事实。它们还发送一些描述与业务部门关系的信息（主要是附加代码）。同样，这些是业务部门和时间段所特有的

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

---

我是否应该将这些定性信息与附加事实混合在一个事实表中？或者我应该将定性数据（只能与计数一起使用）与定量数据（可以与总和一起使用）分开吗？

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

---

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

只有当数据退化时才将其放入事实表中（在维度中导致高基数/唯一性问题，导致维度与事实表的1-1关系）。Kimball建议避免将退化维度以外的任何东西与事实（例如，唯一订单号）放在一起

你可以把这些放在Kimball所谓的“垃圾”维度中。所有这些代码都可以简单地归为一个垃圾维度。大多数日期都会在事实表中作为键进入特定角色中的日期维度（通常使用YYYYMMDD形式的自然int键-这是我们唯一不使用非标识无意义代理键的情况之一）

---

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

Brad Wilson准确地描述了将它们添加到事实表中的风险。在过去，我将垃圾属性添加到事实表中只是为了以后需要重构

他们寄给我们的东西包括 当前状态信息（日期和时间） 代码）。这些似乎是事实。他们 同时发送一些信息 描述了与 业务部门（主要是额外的） 代码）。同样，这些是唯一的 业务单位和时间段

这些日期有什么商业用途？顺便说一句，我建议把这些东西做成自己的尺寸，并准确地描述它们

输入的额外代码有多不稳定？如果事实表的粒度是date和BU，为什么不能将它们包含在BU维度中，并将其视为缓慢变化的属性

---

如果没有更多的细节，我无法提出明确的建议，但这些将是我首先要问自己的问题。

你说的“混在一起”是什么意思？也许一个更具体的例子会有所帮助。你在使用什么OLAP系统？Comingle的意思是“在一个事实表中”。哪个OLAP？关系数据库管理系统。SQL。特别是MySQL。你说的“有损”是指当我聚合事实表中的其他值时，细节将丢失？