我正在尝试为单个必需的数据存储设计一个数据仓库，这些数据包括财务系统，项目计划系统和无数的科学系统。即许多不同的数据集市。
我一直在阅读有关数据仓库和流行方法（例如，星型模式和Kimball方法等）的内容，但我找不到答案的一个问题是：
为什么将DW数据集市设计为星型模式而不是单个平面表更好？
当然，在事实和属性/维度之间没有任何联接比与所有维度表进行大量小的联接会更快更简单吗？磁盘空间不是问题，如有必要，我们将在数据库中放置更多磁盘。如今，星型架构是否有些过时？还是数据架构师教条？
最佳答案
您的问题很好：尺寸建模的Kimball口号是提高性能并提高可用性。
但是我不认为它是过时的或教条的-对于许多情况和平台，这是一种合理，实用的方法。
关系数据库存储数据的方式意味着要在表的数量和类型，用于典型查询的数据路由，易于维护和描述数据之间的关系，联接数，联接方式之间达成平衡。构造，列的可索引性等。
3NF（或更远）是频谱的一端，适合OLTP系统，而单个表是频谱的另一端。尺寸模型位于中间，并且至少在使用某些技术时才适合报告。
尽管星型模式在报告工作负载方面比完全规范化的数据库执行得更好，但性能并不仅限于“联接数”，部分原因是联接数减少了。尺寸通常很宽。如果在每个事实的每一行中都包含所有这些维度字段，则确实有非常大的行，并且对于典型查询而言，找到进入这些行的方式将非常不利。
事实不胜枚举，因此，如果您可以使这些表紧凑，并且“ wordier”维度是可过滤的，那么您将达到一个性能最佳点，除非对表进行大量索引，否则单个表将无法匹配。
是的，对于事实而言，单个表在表数方面更简单，但导航真的更容易吗？维度和事实是易于理解的概念，如果您想跨事实查询，该怎么办？您有许多不同的数据集市，但是首先拥有数据仓库的好处之一是它们没有区别-它们是相关的并且可以报告。一致的尺寸可以做到这一点。
关于data-warehouse - 数据仓库-星型架构与平面表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44517192/