Cal*_*nus 17 data-warehouse star-schema
我正在尝试为一个通常需要的数据存储设计数据仓库,这些数据包括财务系统,项目调度系统和无数的科学系统.即许多不同的数据集市.
我一直在阅读数据仓库和流行的方法,如Star Schemas和Kimball方法等,但我找不到答案的一个问题是:
为什么将DW数据集市设计为星型模式而不是单个平面表更好？
当然,事实和属性/维度之间没有连接比对所有维度表进行大量小连接更快更简单吗？磁盘空间不是问题,如果需要,我们只会在数据库中抛出更多磁盘.这些天的星型架构是否略显过时,还是数据架构师的教条？
Ric*_*ich 11
你的问题非常好:用于维度建模的Kimball口头禅是提高性能和提高可用性.
但我不认为它已经过时,或者说教条 - 对于许多情况和平台来说,它是一种合理,实用的方法.
关系数据库存储数据的方式意味着在表的数量和类型之间存在平衡行为,典型查询的数据路由,易于维护以及数据之间关系的描述,连接数,连接方式构造,列的可索引性等
3NF(或更远)是频谱的一端,适合OLTP系统,单个表是频谱的另一端.尺寸模型位于中间,适用于报告,至少在使用某些技术时.
性能并非完全与"连接数"有关,尽管星型模式比完全规范化的数据库更适合报告工作负载,部分原因是连接数量减少.尺寸通常非常宽.如果要在每个事实的每一行中包含所有这些维度字段,那么确实存在非常大的行,并且找到进入这些行的方式对于典型查询将表现得非常糟糕.
事实很多,所以如果你可以使那些表格紧凑,并且'wordier'维度可以过滤,那么你就会达到单个表不匹配的性能最佳点,除非重度索引.
是的,就表的数量而言,单个表的事实更简单但是它更容易导航吗？维度和事实是易于理解的概念,如果您想跨越事实跨越查询,该怎么办？您有许多不同的数据集市,但首先拥有数据仓库的好处之一是它们并不是独特的 - 它们是相关的并且可以跨报告.一致的尺寸使这成为可能.
如果将事实和维度合并到一个表中，则可能会失去对从未使用过的维度属性的可见性，或者通过为未使用的维度属性包含一个虚拟事件来放弃度量。
例如，餐厅菜单是一个维度，购买的食物是事实。如果将它们组合成一张桌子，您将如何识别从未订购的食物？因此，在您下单之前，如何确定菜单上有哪些食物？
维度代表可能性，事实代表可能性的实现。