关于数据仓库的数据模型

业务驱动

 

任何需求均来源于业务 , 业务决定了需求 , 需求分析的正确与否是关系到项目成败的关键所在 , 从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的 ,但是数据仓库不同于日常的信息系统开发 , 除了遵循其他系统开发的需求 , 分析 , 设计 , 测试等通常的软件声明周期之外 ; 他还涉及到企业信息数据的集成 , 大容量 数据的阶段处理和分层存储 , 数据仓库的模式选择等等 , 因此数据仓库的物理模型异常重要 , 这也是关系到数据仓库项目成败的关键 .

数据仓库的结构总的来说是采用了三级数据模型的方式 :

概念模型 : 也就是业务模型 , 由企业决策者 , 商务领域知识专家和 IT 专家共同企业级地跨领域业务系统需求分析的结果 .

逻辑模型：用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型 , 定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头 .

物理模型：构建数据仓库的物理分布模型 , 主要包含数据仓库的软硬件配置 , 资源情况以及数据仓库模式。

如上图所示 , 在数据仓库项目中 , 物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施 , 两者并行不悖 , 缺一不可 . 实际上 , 我有意的扩大了 物理模型和业务模型的内涵和外延 . 在这里物理模型不仅仅是数据的存储 , 而且也包含了数据仓库项目实施的方法论 , 资源 , 以及软硬件选型等等 ; 而业务模型不仅 仅是主题模型的确立 , 也包含了企业的发展战略 , 行业模本等等 .

一个优秀的项目必定会兼顾业务需求和行业的标准两个方面 , 业务需求即包括用户提出的实际需求 , 也要客观分析它隐含的更深层次的需求 , 但是往往用户的需求是 不明确的 , 需要加以提炼甚至在商务知识专家引导下加以引导升华 , 和用户一起进行需求分析工作 ; 不能满足用户的需求 , 项目也就失去原本的意义了 .

物理模型就像大厦的基础架构 , 就是通用的业界标准 , 无论是一座摩天大厦也好 , 还是茅草房也好 , 在架构师的眼里 , 他只是一所建筑 , 地基 -> 层层建筑 -> 封顶 , 这样的工序一样也不能少 , 关系到住户的安全 , 房屋的建筑质量也必须得以保证 , 唯一的区别是建筑的材料 , 地基是采用钢筋水泥还是石头 , 墙壁 采用木质还是钢筋水泥或是砖头 ; 当然材料和建筑细节还是会有区别的 , 视用户给出的成本而定 ; 还有不可忽视的一点是 , 数据仓库的数据从几百 GB 到几十 TB 不 等 , 即使支撑这些数据的 RDBMS 无论有多么强大 , 仍不可避免的要考虑到数据库的物理设计 .

接下来 , 将详细阐述数据仓库概念模型 ( 业务模型 ), 逻辑模型 , 物理模型的意义

概念模型设计

进行概念模型设计所要完成的工作是 :

   界定系统边界

   确定主要的主题域及其内容

   确定主题域的关系

概念模型设计是，在原有的业务数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所 以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中 “ 有什么 ” 、 “ 怎样组织的 ” 和 “ 如何分布的 ” 等，然后再来考虑应 当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而 清晰的认识 ; 另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。

概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。

1.              界定系统的边界

数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前 :

. 要做的决策类型有哪些 ?

. 决策者感兴趣的是什么问题 ?

. 这些问题的需要什么样的信息 ?

. 要得到这些信息需要包含原有数据库系统的哪些部分的数据 ?

这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。

2 ，确定主要的主题域

在这一步中，要确定所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在 XX 行业中的应用的描述，描述的内容包括 :

. 主题域的公共码键 ;

. 主题域之间的联系 :

. 充分代表主题的属性组。

概念模型的构建通常是企业的 shakeholder, 商务领域知识专家和 IT 专家共同企业级地跨领域业务系统需求分析的结果 .

通常企业决策者有自己的发展战略和规划 , 他们会定期阅读由各部门经理上报的分析报告 , 他们也知道大致了解自己企业信息系统的功能 , 但是未必清楚自己的每一个业务系统的每一个功能和每一部分数据 , 毕竟决策者不是信息专家 , 他们更关心的企业的经营业绩 , 资产负债 , 盈亏受益等等核心指标 .

各个部门经理往往很了解自己部门的信息系统 , 在信息系统规划时优先考虑的是自己的利益 , 因此每个部门往往都在独立的构建自己的信息系统 , 无法或者不可能从 企业总体角度和其他业务系统接轨 , 如 ERP 系统 ,MIS 系统 ,CRM 系统等等 , 这就造成了企业在发展企业信息系统时的不平衡 , 导致了所谓的孤岛效应 , 他们 会阅读下属提供的分析报告 , 然后进行归纳整理 , 形成部门报表进行上报 , 但是最终结果却是每个部门都在上报自己的经营业绩 , 却始终缺乏一个一致的统一的数 字 .

普通用户更关注的是某一类与工作相关的报表 , 包括报表的数据准确性 , 报表的样式 , 图标格式这类的细节 .

而 IT 部门负责企业 IT 系统的预算 , 采购 , 但是因为职能部门不同 , 无法深入了解各个信息系统的业务 .

有这么一句话 : 如果你想实施某个企业信息系统 , 你必须能够具备担当这个企业副总的能力 . 这就要求项目负责人能够站在企业的战略高度考虑 , 同时具备很高的协 调能力和管理能力 ; 所以必须引入商务领域知识专家和 IT 专家的角色 ( 就是通常所说的咨询顾问 ), 这些人往往具备比较资深的行业背景 , 具备丰富的独立实施该 行业信息系统建设的经验 , 了解该行业最先进和通用的标准和规范 , 同时在结合现有企业信息系统的基础上 , 以及融合企业发展战略的基础上 , 提出当前企业的业务 模型 , 来帮助企业提高决策支持分析能力 , 但是这样的模型不能太超前 , 太超前则意味脱离了实际 , 不具备实际可操作性 ; 当然更不能停留在于企业目前的信息建设 水平上 , 否则就失去了意义 .

 

逻辑模型设计

逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。通过实体和关系勾勒出真个企业的数据蓝图。

在这一步里进行的工作主要有 :

        分析丰富主题域，确定当前要装载的主题 ;

        确定粒度层次划分 ;

        确定数据分割策略 ;

        关系模式定义 ;

        记录系统定义

逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括 :

   适当的粒度划分 ;

   合理的数据分割策略 ;

   适当的表划分 ;

  定义合适的数据来源等。

 

1. 分析主题域

在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐 步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。选择第一个主题域所要考虑的是它要足够大，以 便使得该主题域能建设成为一个可应用的系统 ; 它还要足够小，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义 的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。具体的实施细节需要和 AAA 业务部门和信息中心沟通。

 

2.              粒度层次划分

数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型。由于主题 数据库响应企业级业务 OLTP 需求，所以必须保存最细类度数据，同时根据业务部门的查询需求考虑确定多重粒度来提高复杂查询速度。

 

3.              确定数据分割策略

在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素 : 数据量〔而非记录行数 ) 、数据分析处理的实际情况、简单易行以及粒度划分策略等。数 据量的大小是决定是否进行数据分割和如何分割的主要因素 ; 数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密 联系的 ; 我们还要考虑到所选择的数据分割标准应是自然的、易于实施的 : 同时也要考虑数据分割的标准与粒度划分层次是适应的。

 

4.              关系模式定义

数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了数据仓库的基本 主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。

 

物理模型设计

这一步所做的工作是根据信息系统的容量 , 复杂度 , 项目资源以及数据仓库项目自身的软件生命周期确定数据仓库系统的软硬件配置 , 数据仓库分层设计模式 , 数据的存储结构，确定索引策略，确定数据存放位置，确定存储分配等等。这部分应该是由项目经理和数据仓库架构师共同实施的 .

确定数据仓库实现的物理模型，要求设计人员必须做到以下几方面 :

1.      确定项目资源

根据预算和业务需求 , 并参考以往的数据仓库项目经验 , 对该项目的成本周期和资源进行估算 .

关于项目周期的估算 , 主要基于 ETL 函数功能点以及加权后的复杂度进行估算 , 因为 ETL 过程占据了整个数据仓库项目的 70%,;ETL 过程主要是基于 源 <=> 目的的原则进行处理的 , 而不同的功能点具有不同的复杂度 , 通过以往项目经验和专家评估 , 然后再根据软件生命周期的划分 , 可以有效的得 知项目的整体周期 .
关于人员的估算 , 主要取决于人员的工作经验 , 素养 , 对新技术的掌握能力 , 还要考虑到人员流动等方面的人员备份 .

协作 , 每一个 IT 企业都应该具备一个丰富的技能和人力资源库 , 当项目资源遇到瓶颈的时候 , 就可以考虑需求协作 .

2.      确定软硬件配置

数据仓库项目与其他业务系统不同 , 尤其需要对数据容量进行估算 , 这是因为数据仓库是历史的稳定的基于主题的集成的等等特性所决定的 , 他是对以往历史数据的集成 , 如果项目初期不加以考虑 , 很快就会造成灾难性的后果 .

数据仓库的容量估算应该是可预见的 , 首先确定核心明细数据的存储年限 , 相关表的平均字段长度值 * 每年的记录数 *( 每年预计的增长 ), 然后再加上 20% 的冗余 , 以及磁盘预留的 20% 的冗余 , 我们不难得到数据仓库的预计容量 .

数据仓库的处理能力和容量息息相关 , 也和具体的关系数据库的性能息息相关 , 如何在 Oracle,SQLServer,DB,Sybase 甚至 MySQL 之间寻找平衡 , 既要考虑实际的预算 , 也要视实际的需求而定 .

关于硬件的配置 , 既需要发挥软件的功能 , 满足实际的处理要求 , 也要为将来的系统扩展保留一定的空间 .

3.      数据仓库存储设计

数据仓库一般采用分层设计 , 即 ODS 层 , 数据仓库层 , 数据仓库聚合层数据集市等等 ; 数据仓库的分层是灵活的 , 没有固定的模式 , 一切视实际情况而定 .

ODS 层存放从原系统采集来的原始交易数据，只保存一定期限内的数据，同时 ODS 支持部分近实时性报表的展示 .

数据仓库层保存经过清洗，转换和重新组织的历史业务数据，数据将保留较长时间 (5~10 年不等 ), 满足系统最细粒度的查询需要 .

数据仓库聚合层面向 KPI 指标计算和分析，支持汇总层面交易级的指标查询 , 提高汇总级的 KPI 数据展示速度和数据保存时间。保存较长的历史数据 .

数据集市是基于部门或者某一类特定分析主题需要 , 从企业级数据仓库单独获取的一个数据的逻辑或者物理的子集 .

4.      数据仓库模式

数据抽取策略

制定系统的主题数据库 ETL 抽取方案来满足主题数据库的业务处理，数据仓库系统分析及决策支持分析的需要，同时必须保证不能影响业务系统的性能

数据转换策略

数据转换是指对从业务系统中抽取的源数据根据主题数据库系统模型的要求，进行数据的转换、清洗、拆分等处理，保证来自不同系统、不同格式的数据的一致性和完整性，并按要求装入主题数据库

数据加载策略

从业务系统中抽取、转换后的数据加载到主题数据库系统中。

数据质量的检查

星型模型

数据通常采用星型模型存储。星型模型由维表与事实表构成，一般并非业务系统中的规范化的范式结构。在核心层中，针对即定的主题，通常会建立若干星型模型。