4. 如何使用现有数据生成事实表?
以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:
4. 三种模式对比 它本身属于一种关系建模方法,但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念: 对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。 3. 星座模式 2. 雪花模式 1. 哪些维度对主题分析有用? 从技术上来讲这是一种很不值得推崇的方式,因为将使信息分散,影响了企业全局范围内数据分析的效率。此外,各组织之间的ETL架构相互独立无法复用,也浪费了企业的开发资源。然而出于某些公司制度及预算方面的考虑,有时也会使用到这种建模体系。 1. 维度表(dimension)
小结
数据仓库建模是一个综合性技术,需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候,这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术,还要有对现实业务清晰、透彻的理解。 2. 如何使用现有数据生成维表?
c. 维度STORE可由关系STROE和关系REGION连接得到; 2. 细节/聚集事实表 表示对分析主题的度量。比如上面那个例子中,200元就是事实信息。事实表包含了与各维度表相关联的外码,并通过JOIN方式与维度表关联。事实表的度量通常是数值类型,且记录数会不断增加,表规模迅速增长。 注:在数据仓库中不需要严格遵守规范化设计原则(具体原因请看上篇)。本文示例中的主码,外码均只表示一种对应关系,此处特别说明。 除了对应到维度的外码和度量属性,事实表中还常常考虑另外两个属性:事务标识码(transaction identifier)和事务时间(transaction time)。 雪花模式是将星型模式的维表进一步划分,使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用,请读者结合实例体会。 该建模体系首先对ETL得到的数据进行ER建模,关系建模,得到一个规范化的数据库模式。然后用这个中心数据库为公司各部门建立基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数,通常来说不允许直接访问中心数据库。 但仅仅这么做还是不够的,代理码需要配合时间戳,以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化: 1. 共享维度 3. 用什么指标来"度量"主题? 销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到; 表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析,可从这段信息中提取三个维度:时间维度(昨天早上),地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定,且数据量小。 b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码; 随后可利用建模工具将ER图直接映射到关系图: 本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系:规范化数据仓库,维度建模数据仓库,以及独立数据集市。