当前位置:文档之家› 维度建模与关系建模的比较

维度建模与关系建模的比较

维度建模与关系建模的比较徐辉强北京大学智能科学系1001213776摘要:数据仓库技术的快速发展,使得从数据库中获取信息快速高效准确。

但涉及一个能够真正支持用户进行决策分析的数据仓库,并非是一件轻而易举的事情。

这需要经历一个从实现环境到抽象模型,从抽象模型到具体实现的过程。

要完成这一过程,必须依靠各种不同的数据模型。

本文主要将介绍两种数据数据仓库建模技术实体关系建模与维度建模,并比较两者之间的关系关键词:数据仓库、实体关系建模、维度建模1、引言传统的数据库技术是以单一的数据资源,即数据库为中心,进行从事务处理、批处理到决策分析等各种类型的数据处理工作。

近年来,计算机技术正向着两个不同的方向扩展:一是广度计算;二是深度计算。

特别是数据库处理可以大致地划分为两大类:操作型处理和分析型处理(或信息型处理)。

这种分离划清了数据处理的分析型环境与操作型环境之间的界限,由原来的以单一数据库为中心的数据环境发展为一种新的体系化环境,从而导致了数据仓库技术的出现和迅速发展。

数据仓库是决策支持系统(dss)和联机分析应用数据源的结构化数据环境。

数据仓库研究和解决从数据库中获取信息的问题。

数据仓库的特征在于面向主题、集成性、稳定性和时变性。

数据仓库之父William H. Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。

数据仓库,是在数据库已经大量存在的情况下,为了进一步挖掘数据资源、为了决策需要而产生的,它并不是所谓的“大型数据库”。

数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。

设计好一个数据仓库是一个相对比较复杂的过程,需要抽象数据进行具体化,并且建立好模型,因此在这个过程中,模型设计是一个比较重要的一环。

2、关系建模实体关系模型是通过两个概念(“实体”和“关系”)构造特定的数据模型,实体关系模型是一种抽象的工具,能够简化复杂的数据关系,并用规范的方式表示出来,使其易于理解。

关系模型:用二维表的形式表示实体和实体间联系的数据模型。

关系数据模型是以集合论中的关系概念为基础发展起来的。

关系模型中无论是实体还是实体间的联系均由单一的结构类型——关系来表示。

在实际的关系数据库中的关系也称表。

一个关系数据库就是由若干个表组成。

关系模型主要的组成部分有:1)关系数据结构单一的数据结构——关系现实世界的实体以及实体间的各种联系均用关系来表示,从用户角度看,关系模型中数据的逻辑结构是一张二维表。

2)关系操作集合常用的关系操作包括查询操作和插入、删除、修改操作两大部分。

其中查询操作的表达能力最重要,包括:选择、投影、连接、除、并、交、差等。

关系模型中的关系操作能力早期通常是用代数方法或逻辑方法来表示,分别称为关系代数和关系演算。

关系代数是用对关系的代数运算来表达查询要求的方式;关系演算是用谓词来表达查询要求的方式。

另外还有一种介于关系代数和关系演算的语言称位结构化查询语言,简称SQL。

3)关系的数据完整性包括:域完整性、实体完整性、参照完整性和用户自定义的完整性。

域完整性:指属性的取值范围,如性别取值应为男或女。

实体完整性(Entity Integrity)规则:若属性A是基本关系R 的主属性,则属性A不能取空值。

例如:在课程表(课程号,课程名,教师,周课时数,备注)中,“课程号”属性为主键,则“课程号”不能取相同的值,也不能取空值。

参照完整性规则:若属性(或属性组)F是基本关系R的外键,它与基本关系S的主键Ks相对应(关系R和S不一定是不同的关系),则对于关系R中每个元组在属性F上的值必须为:1)或者取空值(F中的每个属性值均为空);2)或者等于S中某个元组的主键值。

域完整性、实体完整性和参照完整性是关系模型中必须满足的完整性约束条件,只要是关系数据库系统就应该支持域完整性、实体完整性和参照完整性。

除此之外,不同的关系数据库系统根据其应用环境的不同,往往还需要一些特殊的约束条件,用户定义的完整性就是对某些具体关系数据库的约束条件。

3、维度建模维度建模(dimensional modeling)是数据仓库建设中的一种数据建模方法。

Kimball 最先提出这一概念。

其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。

这种方法的最被人广泛知晓的名字就是星型模式(Star-schema)。

实体关系(E-R)建模通常用于为单位的所有进程创建一个复杂的模型。

这种方法已被证实在创建高效的联机事务处理(OLTP) 系统方面很有效。

相反,维度建模针对零散的业务进程创建个别的模型。

例如,销售信息可以创建为一个模型,库存可以创建为另一个模型,而客户帐户也可以创建为另一个模型。

每个模型捕获事实数据表中的事实,以及那些事实在链接到事实数据表的维度表中的特性。

由这些排列产生的架构称为星型架构或雪花型架构,已被证实在数据仓库设计中很有效。

维度建模将信息组织到结构中,这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。

1999 年第三季度西北地区的食品销售额是多少?表示使用三个维度(产品、地理、时间)指定要汇总的信息。

星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。

通过这些预处理,能够极大的提升数据仓库的处理能力。

特别是针对3NF 的建模方法,星型模式在性能上占据明显的优势。

同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。

不需要经过特别的抽象处理,即可以完成维度建模。

这一点也是维度建模的优势。

但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。

而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。

而在这些与处理过程中,往往会导致大量的数据冗余。

另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。

4、两者的比较ER模型(实体关系模型)有两个基本的组成部分,实体和实体之间的关系,ER模型的最高境界是去除数据中的一切冗余,这对于事务处理非常有益,它是事务处理简单明了,可以想象一家公司收到订单并且销售产品给客户,在关系数据库没有出现之前,我们将原始的纸质记录作为一条有许多字段的记录来处理,把这些交易数据输入计算机,在这样的记录里有一些字段的记录重复出现,比如客户的姓名和地址,每当一个新订单产生时就会重复出现一次,而且,由于所有客户地址都是相互独立的,更新客户地址就成一件乱糟糟的处理事务。

数据存储不仅冗余而且很难保持一致性。

关系数据库中事务处理的成功得益于ER建模及其范式化技术。

尽管如此,我们在努力地让事务处理高效的同时,却创建了一个不容易查询的数据库。

即使是一个简单的订单处理过程也会在数据库中创建许多的表,而且这些表之间的连接关系像蔓延的蜘蛛网一般纷乱。

一个企业的ER模型可能有几百个逻辑实体,像SAP那样的高端系统则有几千个实体。

没有关系数据库专业知识的最终用户不理解也记不住ER模型,使用ER建模技术违背了建立数据仓库的基本理由---也就是直接高效地获取数据。

自从关系数据库出现以来,数据库设计人员就注意到这个问题,并做了多种努力和尝试,但最终发现将这种及其复杂的模型向最终用户讲明白是非常困难的事,就连他们自己使用起来也非常复杂和难以记忆。

因此许多设计人员开始退回一步,尝试一些不那么规范有一些冗余但“简单一点的设计”。

令人吃惊的事这些“简单点”的设计看起来都非常的相似。

几乎所有这些简单点的设计都可以被看做是“维度模型”。

这种自然而然的维度建模方法并不是某一个人发明出来的,当我们将可理解性和查询性能作为数据库设计的主要目标时,这种方法就有了不可抗拒的力量而被人们采用。

在数据仓库环境中,主要从事联机分析处理(OLAP),根据系统对数据周期的要求,采用批处理方式进行数据整理,数据一次性装入数据库中,一般不再进行插入、更新等操作,OLAP系统要反映业务的发展趋势,保证数据高效查询且易于理解分析、保证数据围绕商务对象及其对活动来组织、并且要回答全局问题,此时,维度模型取代了ER模型。

维度建模也有两个基本的组成部分,对象(维度、关键指标)和对象之间相互作用的度量(事实、分析空间),维度建模是非范式化,允许数据冗余,其结构简单易于理解,当利用关键指标对分析空间进行分析时,可以直观方便地进行切片、切块、上卷、下钻、聚合等处理,因此,非常适合于OLAP系统。

5、总结维度模型,相对关系模型,有着很多优势,但是也面临着一些挑战,主要有非标准化、使用多重事实表查询、维表数据量、聚集管理、雪片和数据共享等问题。

总之,维度建模技术是众多数据建模技术中的一种,维度建模在解决策略类问题时特别有用,然而在解决其他问题时效率并不高。

使用维度数据建模,简单的决策支持系统能够实现高性能的目标。

相关主题