星型模型是一种由一点向外辐射的建模范例，中间有一单一对象沿半径向外连接到多个对象。星型模型反映了最终用户对商务查询的看法:销售事实、赔偿、付款和货物的托运都用一维或多维描述(按月、产品、地理位置)。星型模型中心的对象称为“事实表”，与之相连的对象称为“维表”。对事实表的查询就是获取指向维表的指针表，当对事实表的查询与对维表的查询结合在一起时，就可以检索大量的信息。通过联合，维表可以对查找标准细剖和聚集。
2、雪花模型
雪花模型是对星型模型的扩展，每一个点都沿半径向外连接到多个点.雪花模型对星型的维表进一步标准化，它的优点是通过最大限度的减少数据存储量以及把较小的标准化表(而不是大的非标准化表)联合在一起来改善查询性能。化及维的较低的粒度，雪花模型增加了应用程序的灵活性。
3、混合模型
混合模型是星型模型和雪花模型的一种折衷模式，其中星型模型由事实表和标准化的维表组成，雪花模型的所有维表都进行了标准化。在混合模型中，只有最大的维表才进行标准化，这些表一般包含一列列完全标准化的(重复的)数据。
从目前的数据库及数据仓库建模方法来说，主要分为四类。第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种 *** 作型数据库系统。
第二类是Inmon提倡的三范式数据仓库建模，它和 *** 作型数据库系统的三范式建模在侧重点上有些不同。Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的 *** 作型数据库系统建模方法是相同的；第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的 *** 作型数据库系统的建模方法产生了不同；第三层物理层是第二层的具体实现。
第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。
第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。
下面简单谈谈第四类建模方法的一些的经验。
数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行 *** 作的人只有ETL工程师。ETL工程师可以自己来决定表中数据的范围和数据的生命周期。下面举两个例子：
1）数据范围小的临时表
当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。这样，不论是更新还是对表中某些项的计算都会效率提高很多。处理好的数据发送入准备加载到数据仓库中的表中，最后一次性加载入数据仓库。
2）带有冗余字段的临时表
由于数据准备区中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承担风险。
举例来说，笔者在项目中曾遇到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。其中，客户净扣值和债项余额已知，需要计算债项净扣值。计算的规则是按债项余额的比例分配客户的净扣值。这时，我们可以给两个表增加几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。这样通过三条SQL就可以直接完成整个计算过程。将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中通过（债项余额×客户净扣值/客户余额）公式即可直接计算处债项净扣值。
另外还有很多大家可以发挥的建表方式，如不需要主键的临时表等等。总结来说，正因为数据准备区是不对用户提供接口的，所以我们一定要利用好这一点，以给我们的数据处理工作带来最大的便利为目的来进行数据准备区的表设计。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）