我正在尝试为常用数据的单一存储设计一个数据仓库，这些数据包括财务系统、项目调度系统和无数的科学系统。 IE。许多不同的数据集市。
我一直在阅读数据仓库和流行的方法，例如星型模式和 Kimball 方法等，但我找不到答案的一个问题是：
为什么将 DW 数据集市设计为星型模式而不是单个平面表更好？
事实和属性/维度之间没有联接肯定比对所有维度表进行大量小联接更快、更简单吗？磁盘空间不是问题，如有必要，我们将在数据库中添加更多磁盘。如今，星型模式是否有点过时了，或者它仍然是数据架构师的教条？
你的问题很好：维度建模的 Kimball 口号是提高性能和可用性。
但我不认为它已经过时，也不是教条——对于许多情况和平台来说，这是一种合理、实用的方法。
关系数据库存储数据的方式意味着表的数量和类型、典型查询的数据路由、数据之间关系的易于维护性和描述、连接的数量、连接的方式之间需要达到平衡。连接的构造、列的可索引性等
3NF（或更进一步）是该范围的一端，适合 OLTP 系统，而单个表是该范围的另一端。维度模型位于中间，适合报告，至少在使用某些技术时是这样。
性能并不全与“连接数量”有关，尽管星型模式在报告工作负载方面比完全规范化的数据库表现更好，部分原因是连接数量减少。尺寸通常非常宽。如果您在每个事实的每一行中都包含所有这些维度字段，那么您确实拥有非常大的行，并且找到进入这些行的方式对于典型查询来说将表现非常糟糕。
事实有很多，因此，如果您可以使这些表变得紧凑，并且可以过滤“更冗长”的维度，那么您就可以达到单个表无法匹配的性能最佳点，除非有大量索引。
是的，事实的单个表格在表格数量方面更简单，但它真的更容易导航吗？维度和事实是易于理解的概念，如果您想跨事实进行交叉查询该怎么办？您拥有许多不同的数据集市，但拥有数据仓库的好处之一是，这些数据集市并没有明显的区别——它们是相关的并且可以相互报告。一致的尺寸可以实现这一点。
如果将事实和维度合并到一个表中，您将失去对从未使用过的维度属性的可见性，或者您的度量将因包含未使用的维度属性的虚拟事件而失效。
例如，餐厅菜单是一个维度，购买的食物是一个事实。 如果将这些合并到一张表中，您如何识别哪些食物从未被点过？ 就此而言，在您第一次点餐之前，您如何确定菜单上有哪些食物？
维度呈现选项，事实呈现决策。
将事实和维度组合在同一个表中会限制可扩展性和灵活性。
假设有一天企业决定更改维度描述（例如产品名称）。维度表不像事实表那么深，更新过程或 SCD 管理应该更容易并且占用的资源更少。