我正在尝试为财务系统、项目调度系统和无数科学系统等常用数据的单一存储设计一个数据仓库。 IE。许多不同的数据集市。
我一直在阅读数据仓库和流行的方法，例如星型模式和 Kimball 方法等，但我找不到答案的一个问题是：
为什么将 DW 数据集市设计为星型模式而不是单个平面表更好？
当然，事实和属性/维度之间没有联接比对所有维度表进行大量小联接更快、更简单？磁盘空间不是问题，如有必要，我们将在数据库中添加更多磁盘。如今，星型模式是否有点过时了，或者它仍然是数据架构师的教条？
你的问题很好：维度建模的 Kimball 口号是提高性能和可用性。
但我不认为它已经过时，也不是教条——对于许多情况和平台来说，它是一种合理、实用的方法。
关系数据库存储数据的方式意味着表的数量和类型、典型查询的数据路由、数据之间关系的易于维护性和描述、连接数量、连接方式之间需要达到平衡构造、列的可索引性等。
3NF（或更进一步）是该范围的一端，适合 OLTP 系统，而单个表是该范围的另一端。维度模型位于中间，适合报告，至少在使用某些技术时是这样。
性能并不完全与“连接数量”有关，尽管星型模式在报告工作负载方面比完全规范化的数据库表现更好，部分原因是连接数量减少。尺寸通常非常宽。如果您在每个事实的每一行中都包含所有这些维度字段，那么您确实拥有非常大的行，并且对于典型的查询来说，找到进入这些行的方式将会表现得非常糟糕。
事实有很多，因此，如果您可以使这些表变得紧凑，并且可以过滤“更冗长”的维度，那么您将达到单个表无法匹配的性能最佳点，除非有大量索引。
是的，事实的单个表格在表格数量方面更简单，但它真的更容易导航吗？维度和事实是易于理解的概念，如果您想跨事实进行交叉查询该怎么办？您拥有许多不同的数据集市，但拥有数据仓库的好处之一是，这些数据集市并没有明显的区别——它们是相关的并且可以相互报告。一致的尺寸可以实现这一点。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
