本文是《Star Schema The Complete Reference》的读书笔记，探讨了Star Schema在现代数据仓库中的核心地位。内容包括：Star Schema的构成（fact table与dimension tables）、dimension table的设计原则（如surrogate key的使用）、数据仓库架构的不同模式，以及预计算结果的影响。同时，文章提出了在dimension table中存储预计算结果的优缺点，以及分析不同Data Warehouse架构性能的必要性。
现代数据仓库架构中，表结构以Star Schema为主。由于数据来源往往是类似于XML的半结构格式，如何转换为表结构存入数据库中，特别是Star Schema结构尤其重要。
1. Star Schema由一个fact table和很多dimension tables 组成，首先是在原来的所有属性中选择 fact attributes和 dimension attributes。一般来说，能够被上下文以不同粒度表示的是fact attributes，表示上下文的是dimension attributes。
2. 每个dimension table都有一个属性是surrogate key，是附加属性，作为表主键。
3. 有不同的Data Warehouse architecture.
1）源数据通过ETL传送给Data Warehouse，在Data Warehouse中数据存储为ER模型（推荐为第三范式），这些数据不能直接进行查询分析。而Data Warehouse中的数据通过data delivery发送给不同的data marts，在data marts中数据存储为dimensional form( star schema or cube) ，供用户或分析工具进行查询。
2）源数据通过ETL传送给Data Warehouse，在Data Warehouse中数据存储为dimensional form( star schema or cube) ，直接供用户或分析工具进行查询。data marts只是Data Warehouse的不同area。
3）由于从不同的数据源构造dimensional form是很challenging的，所以可以首先将数据源转换为第三范式的表，此时的表不能进行查询，只能由ETL工具操作。再将这些表转换为star schema.
4) 这样也可以有data marts. 即是从data warehouse 中的dimensional form生成 data marts 中的 dimensional form, 这时data marts取代 data warehouse 由用户或分析工具进行查询。
4. dimension table的属性可能很多，不但要存储基本的dimension attributes，还可能存储dimension attributes的计算结果或分解值。
5. 还可能有些junk dimension table，表中的属性并无什么关系，例如一些flag，表中也没有natural key，只有surrogate key作为主键。
6. Fact table 比dimension table行多得多，但列要少得多。但幸运的是，fact table比较紧凑，即其值大多都是整数和浮点数。
总结 && 后记 &&问题：
在dimension table中存储一些预计算结果，对查询很有利，而不利于update。
从根本上来说，需要清楚为什么Star Schema适合于Data Warehouse。
从性能上分析不同Data Warehouse architecture 的优劣。为什么数据源直接转化为star schema很challenge，而转化为ER就OK？
扫一扫
942
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
