Microsoft Azure数据仓库:平面表或星型模式

Question

我正在许多OLTP表上创建数据仓库模型。( a)我可以使用星型模式，也可以使用平面表模型表。

许多人认为不需要维度星型模式模型表，因为大多数数据都可以在单个表中报告自己。此外，星型Kimball是在性能和存储出现问题时创建的。一些声称与改进的技术，数据可以显示在一个单一的表。

我还是应该将数据分离成维度/事实表，还是直接在数据仓库中使用平面表？

在Microsoft中，推荐使用平面宽表还是星型模式？

在这个问题上，我认为AWS红班员工更喜欢平面宽桌。Performance of Flat Tables Vs Dimension and Facts

Answer 1

我认为这个问题最好的回答是：“这取决于你的业务需求，你的时间和资源。”我认为有理由支持这两者，这取决于你的情况。然而，根据我的经验，如果您正在构建这些表以供大量报告和其他分析使用，我将使用星型模式。

我猜你带进来的桌子还在第三种正常状态？在这两种情况下，你仍然是去正常化，然而，假设这是你正在创造的东西，从长远来看，我认为明星会更好地服务于你的目的。Kimball不只是因为技术优化的原因而提出维度/事实的关系，也有业务上的原因。

1. 示例:您有一个只构建一次的products表，并且有一个连接它的销售事实。在接下来的6个月里，也许现在有人想要所有与库存或折扣相关的商业指标，很有可能两者都有。您已经有了一个与此相适应的产品表。如果您有一个单一的扁平表的销售，包括产品，您最终做同样的工作，对库存和折扣的产品。当产品被分离出来时，将这一连接应用于这三个事实表中的每一个就更容易了，而且将来肯定会有更多的加入。从长远来看，花在星空上的时间要少一些，因为你可以用新的可测量的数字进行迭代。
2. 维护该产品表或任何维度表(可测量金额的上下文)在有表可处理时要容易得多。任何时候新列都可以更好地对产品进行分类，例如
3. 任何建模工具在需要使用星型模式(例如SSAS和PowerPivot )时，大多数时候都很容易使用，拖放报告(如连接到模型的枢轴表)也是如此。