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

Question

我在确定特定维度应该采用什么方面遇到一些麻烦，以及我正在开发的星型模式的事实表应该是什么。

为了举例，我们假设该项目正在跟踪物业管理公司的房屋。各种日期，租房者，合同等维度都相当简单。对于房子而言，无论数据存在于何处，我们都希望跟踪当前所有者，当前租房者，当前租赁合同以及邻居，地址，当前租赁价格，当前市场价值等等。 。请注意，所有者，承租人和合同本身就是维度（邻域和地址也可能是维度，但我并不关心那些）。

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

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

• DimHouse：house表是一个维度，在事实表中有很多可能看起来更好的属性，但由于它们用于浏览和过滤，所以它们必须在这里。当前租房者等属性需要Snowflaking /舷外支架。
• FactHouse：拥有与其他事实表相关联的房屋信息的累积快照，可能使用精简的DimHouse作为桥梁。这对我来说似乎很奇怪，但它把事实看似事实放在事实表中。
  • 将当前所有者，当前租房者等放入相关事实表中，然后将这些事实作为所有者/承租人/等保持最新。变化（也很奇怪，但会让我们留在星型模式中）。

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

Answer 1

关于星型模式的事情是它专门用于使某些类型的查询变得简单而有效。

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

您将事务数据库标准化。对于您的BI数据仓库，您需要让您的冗余焦虑，以避免心脏病。