我正在许多 OLTP 表上创建数据仓库模型。 a) 我可以使用星型模式或 b) 平面表模型表。
很多人认为维度星型模式模型表不是必需的；因为大多数数据可以在一个表格中报告自己。此外，当性能和存储成为问题时，创建了星型模式 Kimball。有些声称技术改进，数据可以在一个表格中呈现。
我还是应该将数据分成维度/事实表还是直接在数据仓库中使用平面表？
在 Microsoft Azure 中，推荐使用平面宽表还是星型模式？
在这个问题中，我相信 AWS Redshift 员工更喜欢扁平宽桌。 Performance of Flat Tables Vs Dimension and Facts
【问题讨论】：
标签： azure data-warehouse dimensional-modeling azure-sqldw
我认为最好用“这取决于您的业务需求、时间和资源”来回答这个问题。我认为有理由支持两者，具体取决于您的情况。但是，根据我的经验，如果您要构建这些表以供大量报告和其他分析使用，我会使用星型模式。
我猜你正在引入的表格仍然是第 3 范式？在这两种情况下，您仍在去规范化，但是假设这是您长期创建的东西，我认为 Star 会更好地满足您的目的。 Kimball 提出维度/事实关系不仅是出于技术优化的原因，还有商业原因。
示例：您有一个构建一次的产品表，并且您有一个将其连接到的销售事实。在接下来的 6 个月中，也许现在有人想要与库存或折扣相关的所有业务指标，很可能两者兼而有之。您已经有一个适合它的产品表。如果您有一个包含产品的扁平化销售表，那么您最终会再次针对产品的库存和折扣进行相同的工作。当产品被分离出来时，将一个连接应用于这三个事实表中的每一个会更容易，而且将来肯定会出现更多。从长远来看，在 Star 上花费的时间会更少，因为您可以迭代添加新的可测量数字。
当您在桌面上工作时，维护该产品表或任何维度表（可测量数量的上下文）会容易得多。任何时候都可以使用新列来更好地对产品进行分类，例如
任何建模工具在大多数情况下都很容易使用，因为您可以使用星型模式（例如 SSAS 和 PowerPivot），拖放报告也是如此（例如连接到模型的数据透视表）
【讨论】：