我在决定什么应该进入特定维度以及我正在开发的星型模式的事实表中应该包含什么时遇到了一些麻烦。
例如，假设该项目正在跟踪物业管理公司的房屋。各种日期、承租人、合同等维度都相当简单。对于房子，无论数据位于何处，我们都希望跟踪当前所有者、当前租户、当前租赁合同，以及社区、地址、当前租金价格、当前市场价值等信息。请注意，业主、承租人和合同本身就是维度（邻里和地址也可能是维度，但我不太关心这些）。
保留的有关房屋的许多数据将用于过滤查询，或用于立方体的行和列标题。其中一些只是作为辅助信息需要，逐个房屋查看，但不是汇总的。
鉴于数据以及我需要用它做什么，我（至少）有三种选择：
- DimHouse：house 表是一个维度，具有许多属性，这些属性在事实数据表中可能看起来更好，但由于它们用于浏览和过滤，因此它们需要在此处。对于当前租户等属性，需要雪花/支腿。
- FactHouse：有一个累积的房屋信息的快照，该快照与其他事实表相连，也许使用修剪后的DimHouse作为桥梁。这对我来说似乎很奇怪，但它将看似事实的内容放在事实表中。
- 将当前所有者
- ，当前租户等放在相关的事实表中，然后在所有者/租户/等更改时保持这些事实的最新状态（也很奇怪，但会让我们保持在星型图式中）。
所以我一直在沿着维度路线走下去。它让我有些胃灼热，但它实现了目标。我只想知道是否有更好的方法来组织数据。我不介意冗余（例如有一个事实表和一个具有相似数据的维度表）或雪花，如果它们有意义并且是做事的最佳方式（对于"最佳"的值）。
关于星型模式的事情是，它是专门为使某些类型的查询变得简单和高效而构建的。
如果你发现某些类型的查询由于什么是维度和什么是事实而没有得到星号的帮助，那么你围绕维度和事实的替代视图构建额外的星星，这将更容易支持你想要执行的查询。
保持事务数据库规范化。 当涉及到您的 BI 数据仓库时，您需要释放冗余焦虑以避免心脏灼热。