在星型模式设计中，事实表的维度表几乎是必须的。在许多商业案例中，建模者可以可信地假设某些维度值在没有控制的情况下不会改变。例如，性别有时被用作维度，实际上它也可以是事实表中的列。
我不确定人们是否总会想到这一点。更容易添加维度而不考虑它。然而，作为Kimball规则之一，事实表不应该有太多维度（我认为他建议的数字大约是20）。
我以性别为例，但还有许多其他如州名，城市名称，信用卡类型等。
我的问题是：
应该使用什么规则来决定是否嵌入/折叠事实表中的值而不是为其设置单独的维度？ 一些可能的答案是： 1.当它没有改变时（例如性别）。 2.什么时候值很小，长度很短？
还有什么？
修改
即使我认为这个问题得到了解答，我仍然进行了进一步的研究。有一种情况是可能使用维度。案例在这里： ＆＃34;事实维度经常用于支持钻取操作，因为SQL Server Analysis Services（SSAS）中的钻取操作要求您从维度中选择属性。因此，如果用户希望在进行深入检查时看到某些字段，则必须在维度中包含这些字段。＆＃34;
我认为这个主题需要进一步分析感兴趣的人。
答案 0 :(得分：1)
听起来你正在描述Kimball所谓的“退化维度” - 你将维度值直接存储在事实表中。 Kimball自己对这些问题的看法就是当你只拥有该维度的一列时使用它们。事实上，这通常是非常低的基数。一个很好的例子就是采购订单 - 您将拥有一个采购订单事实表，然后有一个名为PurchaseOrderReference的列，它实际上是一个退化维度，而不是具有与事实一对一的采购订单维度。 / p>
但是，保持维度数量相当低的原因是阻止事实表变得过宽 - 如果您开始将维度列放入事实中，它们将变得更宽，性能将受到影响。例如，如果您要添加大型字符串列或某些数字格式，这些可能比维度键列更大 - 如果您要添加多个列，您可以使用单个维度键，则影响会更大。
对此的解决方案是尺寸的非规范化。你提到州和城市 - 这些可以一起进入一个位置维度，然后你只需要一个维度键，从你的事实到位置维度，而不是两个（一个到城市，一个到州）。您的性别示例可能是退化维度的候选者，但前提是性别是您存储的人的唯一属性。如果你有一个人的维度，或者甚至有几个关于人的属性（例如性别，身高，头发颜色），那么这些属性在一个维度上会更好。
你说的很正确很多人没有这样设计 - 我认为这是因为很多人习惯于更规范化的数据库，其中单独的城市和州表是正常的（并且是正确的），因此他们错误地创建了许多具有少量属性的维度，其中一些更宽的维度会更好。