维度设计：不确定某些类型数据的事实与维度

Question

对于我正在开发的星型模式，我在决定特定维度中应该包含哪些内容以及事实表中应该包含哪些内容时遇到了一些麻烦。

举个例子，假设该项目正在为一家物业管理公司跟踪房屋。各种日期、承租人、合同等维度都相当简单。对于房子，无论数据位于何处，我们都希望跟踪当前所有者、当前租户、当前租赁合同，以及邻域、地址、当前租金价格、当前市场价值等信息.请注意，owner、renter 和 contract 本身就是维度（邻居和地址也可能是维度，但我不太关心这些）。

很多关于房屋的数据将用于过滤查询，或用于多维数据集的行和列标题。其中一些仅作为辅助信息需要，逐个查看，而不是汇总。

鉴于数据，以及我需要用它做什么，我有（至少）三个选择：

• DimHouse：房屋表是一个维度，有很多属性在事实表中可能看起来更好，但由于它们用于浏览和过滤，所以它们需要在这里。当前租户等属性需要雪花/支腿。
• FactHouse：拥有连接到其他事实表的房屋信息的累积快照，可能使用修剪过的 DimHouse 作为桥梁。这对我来说似乎很奇怪，但它把看似事实的东西放在了事实表中。
  • 将当前所有者、当前承租人等放入相关事实表中，然后将这些事实作为所有者/承租人/等保持最新。变化（也很奇怪，但会让我们处于星型模式中）。

所以我一直在走维度路线。它让我有些心痛，但它达到了目标。我只想知道是否有更好的方法来组织数据。我不介意冗余（例如具有相似数据的事实表和维度表）或雪花，如果它们有意义并且是做事的最佳方式（对于“最佳”值）。

Answer 1

星型模式的特点是它是专门为使某些类型的查询变得简单和高效而设计的。

如果您发现某些类型的查询由于什么是维度和什么是事实而没有得到您的星标的帮助，那么您可以围绕维度和事实的替代视图构建额外的星标，这将更轻松支持您要执行的查询。

您保持事务数据库的规范化。当涉及到您的 BI 数据仓库时，您需要让您的冗余焦虑去避免心脏灼伤。