企业级数据仓库构建过程

        3、数据仓库的模型

        数据仓库模型设计是数据仓库建设过程中最为复杂的任务之一，设计人员不仅需要理解大量的业务需求，还需要熟悉企业已有操作型数据源系统的数据状况。正确的模型是用户需求的集中体现，是商业智能项目能否成功的重要因素之一。

        目前国外比较成熟的数据仓库建模方法主要以bill Inmon(比尔·恩门)推崇的数据驱动 (data-driven)方法和Ralph Kimball（拉尔夫·金博尔）所提倡的业务驱动(demand-driven)建模方法为主。前者关注数据源系统数据，而忽视了企业最终用户的业务需求；后者仅强调满足各个业务部门的业务需求，从而导致数据仓库逻辑模型可能难以满足整个企业级的需要，并且，这种方法未考虑数据源问题，所以设计出的数据仓库可能会出现没有充分底层数据支持的情况。

        概念模型是最高层次的数据模型，放映了数据仓库的主要主题和重要业务之间的关系。通常，在数据仓库实施之前，开发人员和业务人员对概念模型已经达成共识，因为概念模型反应的是核心的业务问题。概念模型的设计步骤如下：

        1.从业务需求中提取重要的业务数据主题，并对业务主题数据作详细的解释，在业务数据主题基础上进行数据主题域的划分确定数据主题域的详细解释。

        2.规划数据主题域概念模型，根据主题域的划分，细化内部的组织机构和业务关系。

        总之，概念模型建模的流程包含：对业务系统或者操作型数据系统（ODS）的详细说明，进行数据的梳理，列出数据主题详细的清单，并对数据主题做出尽可能完善的解释。然后经过归纳、分类、整理成各个数据主题域，列出每个主题域包含哪些部分，并对每个数据主题域做出详细解释，最后划分为主题域概念模型。

        逻辑模型的设计是数据仓库实施中最重要的一步，因为它直接反映了业务部门的实际需求和业务规则，同时对物理模型的设计和实现具有指导作用。它的特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规划。逻辑模型一般遵循第三范式，主要关注细节性的业务规则，同时需要解决每个主题域的包含哪些概念范畴和跨主题域的继承和共享的问题。在逻辑上建立数据模型的目的，是确定如何组建数据及数据之间的相互关系 ，以满足业务应用的需要。逻辑模型的构建需要以下几个步骤：

        1.分析需求，列出需要分析的主题，需求目标、指标维度、维度层次、分析的指标、分析的方法、数据的来源、关注的对象等。
 

        2.选择用户感兴趣的数据，通过业务需求将需要分析的指标分离抽取出来，转化成逻辑模型需要的实体。
 

        3.在实体中需要增加时间戳属性，因为实体中需要保存各个阶段的历史数据。通常情况下，如果实体为统一编码则不需要时间戳属性。
 

        4.需要考虑粒度层次的划分。数据仓库的粒度层次划分直接影响了数据仓库模型的设计，通常细粒度的数据模型直接从企业模型选择实体作为数据仓库逻辑模型的实体；而粗粒度的数据模型需要经过汇总计算得到相应的实体。粒度决定了数据仓库实现方式、性能、灵活性和数据仓库的数据量。
        5.在粒度层次划分基础上，还需要进行关系模式的定义。关系模式一般采用第三范式的特点定义。对当前的主题进行关系模式的划分，形成各个实体、实体属性、实体之间的关系等内容。同时在逻辑模型框架的基础上对实体的中英文名称、属性、属性的值域进行明确、完善和细化，真实反映业务逻辑关系和业务规则。

        数据仓库中广泛采用的模型设计有两种：关系型和多维型。普遍认为在数据仓库的设计方法中关系模型是“Inmon”方法，而多维模型是“Kimball”方法。关系型数据以一种称为“标准化”的形式存在。数据标准化是指模型设计会使数据分解成非常低的粒度级，标准化数据以一种孤立模式存在，这种情况下对数据表里的数据关系要求非常严格，一般遵循3NF范式。采用关系型设计的数据模型一般具有较强的灵活性和多功能性（可以支持数据的多种视图）。而多维模型一般有星型模式、雪花模式、混杂模式（又叫星系模式）。多维模型设计的最大优点在于访问的高效性。

        关系模式，数据以最低粒度级和标准化形式存储；关系表间的关系已经定义好并且包含一个含有外键的关键字表；新表可以对关系表中的基本数据集定义新的汇总和筛选标准；也就是说可以很简单以一种形式创建关系表，再以另一种形式重新塑造这些表，这样做对于数据仓库环境来说是非常理想的。多维模型在直接访问数据方面是快速而高效的。从体系结构观点来看，在数据仓库设计基础方面关系模型是更好地支持数据仓库的模式，其原因是，数据仓库需要根据不同的议程和多种观察数据的方式来支持许多不同的用户组。也就是说，数据仓库对于访问已给定的用户并不是最佳的。相反，数据仓库可以以多种方式支持多个不同的用户。

        数据仓库（EDW）的物理模型较常见的操作型数据库（ODS）的物理模型有很大不同。最明显的区别是：操作型数据库主要是用来支撑即时操作，对数据库的性能和数据质量要求都比较高，为了防止“garbage in，garbage out”，通常设计操作型数据库都要遵循几个范式的约束，除非少数情况下为了性能进行折衷，才可能出现冗余。数据仓库的建立并不是为了支撑即时操作，或者说，数据仓库的数据是来源于即时操作产生的数据，而不是直接来源于即时操作。所以它的数据质量是由操作性系统来保证的，而不是由几个范式来保证的。为了更好的跟踪历史信息，以及更快地产生报表，数据仓库的物理模型中存在着大量冗余字段。

        4、数据仓库的集市

        数据集市是为了满足特定的部门或者用户需求，按照多维的方式进行存储。包括定义维度、维度的层次、定义指标、指标的统计口径、指标多维度展现方式。以及生成面向决策分析需求的立方体。数据集市通常被定义为星型或者雪花模型，由事实表和维度表来组成。

        事实表是与日俱增，而维度表则增长缓慢，所以绝对数字也不会太大。在事实表和维度表做连接查询的时候，会产生与事实表一样大的数据量，如果还需要group by等操作的话，导致结果就是：其一是会增加计算，其二是由于引入了计算，索引会失效。这个代价比引入冗余字段要大的多。总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。

        （1）事实表设计

事实表是数据仓库星型结构中最重要的表，它直接放映了数据仓库应用的主题，包含了数据仓库中最基本、最主要的信息。一个事实表，通常包含了业务需求所关心的一系列指标值。一个事实表的行包括，具有可加性的数值型指标、与维表相连接的外键（通常具有两个或两个以上的外键），事实表的特征是，数据量庞大、内容相对狭窄、并且经常发生变化（新事件的发生、事实表中增加一条记录），适合各类指标值的聚集计算。数据仓库当中，事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的（允许追加）。对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的（为了追踪事实变化的历史）。主键都是冗余的，那么事实表一般是没有主键的。

        事实表是由一个多方键（mutipartkey）标识的，该多方键是由来自同一业务过程中若干个相交维度表的外键所组成的。多方键意味着事实表通常描述的是多对多的关系。事实表的每一个外键都必须与维度表中的唯一主键相匹配（事实表的外键应当不为空，若为空则违背了参照完整性）。事实表仅有键和数值型度量值所组成，因此它具有健壮性和完整性的特点。

        事实表的设计应从满足最终用户的要求和决策支持的基本需求出发，瞄准应用的主题，纵观和兼顾操作型数据源的结构和特性，以多维分析的模式满足数据仓库这种大数据容量、大吞吐量、高速相应的特有的环境。另一方面，事实表应该设计成简洁规范的形式，绝大多数数据项应该由数字键和数值组成，以便于累加和运算。并且数据项中避免冗长的描述性字符，事实表改进设计的关键也是将这些描述性的数据项目从事实表中剔除，并迁移到维度表中。

        事实表的设计主要考虑的是选定与主题有关的度量，如销售量、销售额、成本、用户消费活动、产品服务情况等。在设计过程中要确定与维表链接的键。粒度的选择和确定主要取决于两方面的因素，一是操作性数据源中的粒度，二是用户最终进行联机分析所需要的明细程度（如钻入分析的细微程度、计算系统和数据库系统所能承受的数据量、总计报表的响应时间等）。一般来讲，星型结构中的维度变化对事实表的粒度有着非常重要的影响。比如，在一个有关销售的星型结构中引入一个新的维度（交易类型），可能会造成事实表的粒度向下一层。通常事实表中一般包含几个方面的内容：度量、维数标志符（作为外部键连接维表）、OLAP外键（链接其他事实表）、事实表属性描述、粒度（影响粒度的属性），图2为保险企业数据仓库基本理赔事实表的设计内容为例，阐述了事实表的主要组成部分。

首页 上一页 1 2 3 下一页 尾页

扫码即可手机
阅读转发此文