问题

我试图设计一个数据仓库，用于存储从财务系统、项目调度系统到无数科学系统等常见的数据。许多不同的数据集市。

我一直在阅读数据仓库和流行的方法，如星型模式和Kimball方法等，但有一个问题我找不到答案：

为什么将DW数据集市设计为星型模式而不是单个平面表更好？

当然，事实和属性/维度之间没有连接比所有维度表都有许多小连接更快、更简单吗？磁盘空间不是问题，如果需要的话，我们将向数据库抛出更多的磁盘。现在的星型模式是稍微过时了，还是仍然是数据架构师的教条？

答案1：

你的问题很好：维度建模的Kimball mantra是提高性能和可用性。

但我不认为这是过时的，或教条-这是一个合理的，实用的方法，为许多情况和平台。

关系数据库存储数据的方式意味着在表的数量和类型、典型查询到数据的路由、数据之间关系的易维护性和描述、连接的数量、连接的构造方式、列的可索引性等方面需要平衡。

3NF（或更进一步）是频谱的一端，适用于OLTP系统，一个表是频谱的另一端。维度模型居中，适合于报告，至少在使用某些技术时是这样。

性能并不完全与“连接数”有关，尽管星型模式在报告工作负载方面比完全标准化的数据库性能更好，部分原因是连接数减少。维度通常非常宽。如果您在每个事实的每一行中都包含所有这些维度字段，那么实际上您有非常大的行，并且找到进入这些行的方法对于典型的查询将执行非常糟糕的操作。

事实是很多的，所以如果你能使这些表变得紧凑，并且“更冗长”的维度是可过滤的，那么你就达到了一个性能上的最佳点，除非索引很重，否则一个表是不匹配的。

是的，对于一个事实来说，一个表在表的数量上更简单，但它真的更容易导航吗？维度和事实是很容易理解的概念，如果您想跨事实交叉查询呢？您有许多不同的数据集市，但首先拥有数据仓库的好处之一是，这些集市并不明显—它们是相关的，可以跨数据仓库进行报告。一致的维度使之成为可能。

如果将事实和维度合并到一个表中，则可能会丢失从未使用过的维度属性的可见性，或者通过为未使用的维度属性包含虚拟事件而放弃度量。

例如，餐厅菜单是一个维度，购买的食物是一个事实。如果你把这些东西放在一张桌子上，你会如何确定哪些食物从未被点过？因此，在您第一次点餐之前，您如何确定菜单上有哪些食物？

维度代表可能性，事实代表可能性的实现。

本文：

讨论：请加入知识星球或者微信圈子【首席架构师圈】