其中一个星型模式的事务事实表需要回答诸如第一个应用程序是最终应用程序的问题。这与一个业务流程相关联。 将其保留为具有列名的事实表的一部分是否是个好主意， IsFirstAppLastFlag。 没有太多标志可以创建单独的维度。此外，这个标志（计算标志）在报告编写中是必不可少的。在这种情况下，我们需要将其保留在 Dimension 中还是 Fact 中！
我假设垃圾维度的创建是针对那些不太有用的标志/低基数列可以将其保留在维度内？！
【问题讨论】：
标签： sql-server database-design entity-relationship dimensional-modeling star-schema
这将取决于您自己的需求，但如果您喜欢事实表的最纯粹视图，那么答案是否定的，这些字段不应包含在您的事实表中。
事实表应包括维度键、退化维度键和事实。
IsStatusOne、IsStatusTwo 等是属性，正如您正确建议的那样，如果它们不属于更合适的维度，它们将非常适合垃圾维度，例如，IsWeekDay 将适合维度“日期”表。
您可能从事实表中的几个“Is”属性开始，但随着时间的推移，您可能需要越来越多的这些属性，您回过头来看可能希望您创建了一个垃圾维度。
性能： 有趣的是，如果您对标志使用位列，那么在事实表中使用 8 位标志然后使用一个 tinyint 维度键几乎没有存储差异，但是当您的标志更冗长或具有多个状态值时，您应该使用垃圾维度以提高事实表的性能，减少存储空间，内存，页面中的更多行等。
就我个人而言，我会把它们扔掉
【讨论】：
这似乎很好，只要它是事实的属性，而不是某个维度的属性。在某些情况下，我认为您可能会有一个缓慢变化的维度，在其中放置它会更合适。
我担心此计划可能需要更新事实表，例如，如果您打算标记特定事实是客户的最新事实。如果是这种情况，最好在事实表中保留一个事务号，在维度表中保留一个“最近的事务号”，并提供一种索引方法来有效地检索每个客户的最近一次。
【讨论】：
您可以使用Junk Dimension。
您可以在维度上创建具有所有可能的值组合的维度，而不是使用几行创建多个维度，然后您只需在事实表中添加一个 foregion 键。
您可以使用如下查询填充您的垃圾维度。
WITH cteFlags AS
(
SELECT 'N' AS Value
UNION ALL
SELECT 'Y'
)
SELECT
Flag1.Value,
Flag2.Value,
Flag3.Value
FROM
cteFlags Flag1
CROSS JOIN cteFlags Flag2
CROSS JOIN cteFlags Flag3
【讨论】：