我正在众多OLTP表上创建数据仓库模型。a) 我可以使用星形模式，也可以使用b)平面表模型表。
许多人认为维度星模式模型表不是必需的；因为大多数数据可以在一个表中报告自己。此外，星形模式Kimball是在性能和存储存在问题时创建的。一些人声称，随着技术的进步，数据可以在一个表格中显示。
我应该仍然将数据划分为维度/事实表，还是直接在数据仓库中使用平面表？
在Microsoft Azure中，建议使用平面宽表还是星形架构？
在这个问题上，我相信AWS Redshift员工更喜欢平宽的桌子。平板表的性能与尺寸和事实
我认为这个问题最好用"这取决于你的业务需求、时间和资源。"我认为根据你的情况，有理由同时支持这两个问题。然而，根据我的经验，如果您正在构建这些表以供大量报告和其他分析使用，我会使用Star Schema。
我猜你带来的桌子还处于第三正常状态？在这两种情况下，你仍然在去正常化，但假设这是你长期以来创造的东西，我认为Star会更好地满足你的目的。Kimball提出维度/事实关系不仅仅是因为技术优化的原因，还有商业原因。
-
示例：您有一个只构建过一次的产品表，并且有一个连接到它的销售事实。在接下来的6个月里，也许现在有人想要与库存或折扣相关的所有业务指标，很可能两者都有。你已经有了一个适合它的产品表。如果你有一张包含产品的扁平销售表，你最终会在库存和产品折扣方面再次做同样的工作。当产品被分离出来时，只需将一个连接应用于这三个事实表中的每一个就更容易了，而且将来肯定会出现更多的连接。从长远来看，花在Star上的时间更少，因为你可以迭代添加新的可测量数字。
-
当您有工作表时，维护产品表或任何维度表(可测量金额的上下文)会容易得多。任何时候都有一个新的专栏来更好地对产品进行分类，例如
-
当您有一个星形模式(例如SSAS和PowerPivot)时，任何建模工具在大多数时候都很容易使用，与拖放报告(如连接到模型的数据透视表)一样