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