数据仓库建模技术

数据仓库建模技术2024/3/24数据仓库建模技术数据仓库建模原则满足不同的用户需求兼顾效率与数据粒度的需要支持需求的变化避免对业务运营系统造成影响考虑未来的可扩展性数据仓库建模技术数据仓库建模特点OLTP系统是面向应用数据仓库则一般按照主题(Subject)来建模数据仓库建模技术数据仓库建模的一般步骤对用户需求进行归纳，需要综合考虑业务划分和用户组织两方面的问题；高层模型设计即概念模型设计确定数据仓库的主要主题和相互关系中层模型设计明确各主题域的实体底层模型设计明确各实体的属性数据仓库建模技术数据仓库的建模方法目前较常用的两种建模方法是所谓的第三范式(3NF,即ThirdNormalForm)和星型模式(Star-Schema),数据仓库建模技术什么是第三范式范式是数据库逻辑模型设计的基本理论一个符合第三范式的关系必须具有以下三个条件:每个属性的值唯一,不具有多义性;每个非主属性必须完全依赖于整个主键,而非主键的一部分;每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。数据仓库建模技术两种属性类別

键属性(Key)非键属性(NonKey)ConsultantIdConsultantLastNameConsultantFirstNameConsultantSpecializationConsultantHourlyRateCONSULTANT键属性非键属性数据仓库建模技术数据规范重复数据组这个设计违反了第一范式，第一范式是设计"外形"的基本定义，即数据的行和列组成一个在任何单元中没有嵌套结构的二维表格，数据库中每一个数据值必须是原子的，没有列表、重复元素或内部结构。

Emp-idemp-nameemp-addresschildren's-namesE1TomBerkeleyJaneE2DonBerkeleyTom,Dick,DonnaE3BobPrinceton------E4JohnNewYorkLisaE5CarolBerkeley------数据仓库建模技术数据规范规范数据仓库建模技术数据规范相同属性的多个用途

转换数据仓库建模技术数据规范相同事实的多个值如果事实由实体的部分健来决定，那么这个实体违犯了第二范式。如果事实通过实体的一些非键属性来了解，那么就违犯了第三范式。

数据仓库建模技术第三范式小结我们有如下规则的三范式总结，它归功于E.F.Codd博士------关系模型之父。如果每个非-键属性取决于键（全部键），没键就什么都没有，这样的实体就是第三范式。规范化的目标的口号是：ONEFACTINONEPLACE!数据仓库建模技术什么是星型模式星型模式是一种多维的数据关系,它由一个事实表(FactTable)和一组维表(DimensionTable)组成。每个维表都有一个维作为主键,所有这些维则组合成事实表的主键,换言之,事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实(Fact),它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。数据仓库建模技术第三范式和星型模式在数据仓库中的应用大多数人在设计中央数据仓库的逻辑模型时,都按照第三范式来设计;而在进行物理实施时,则由于数据库引擎的限制,不得不对逻辑模型进行不规范处理(De-Normalize),以提高系统的响应速度。根据数据仓库的测试标准TPC-D规范,在数据仓库系统中,对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。数据仓库建模技术第三范式和星型模式在数据仓库中的应用下面列出了一些DBMS在实际系统中针对这些困难所采用的折衷处理办法:

1、如何避免多表连接:在设计模型时对表进行合并,即所谓的预连接(Pre-Join)。当数据规模小时,也可以采用星型模式,这样能提高系统速度,但增加了数据冗余量。

2、如何避免表的累计:在模型中增加有关小计数据(SummarizedData)的项。这样也增加了数据冗余,而且如果某项问题不在预建的累计项内,需临时调整。

3、如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行,不断有新的数据加入,数据库管理员的工作将大大增加。大量的时间将用于对系统的整理,系统的可用性随之降低。

4、如何避免大表扫描:通过使用大量的索引,可以避免对大量数据进行扫描。但这也将增加系统的复杂程度,降低系统进行动态查询的能力。

数据仓库建模技术不规范处理的阶段由于中央数据仓库的数据模型反映了整个企业的业务运行规律,在这里进行不规范处理容易影响整个系统,不利于今后的扩展。而且不规范处理产生的数据冗余将使