哈喽艾瑞巴蒂~EVENING！

数据仓库

Data Warehouse（简称DW）

数据仓库是一个过程而不是一个项目。

引用

前几次俺老孙跟大家阐述了数据仓库是什么，在计算机发展的早期，人们已经提出了建立数据仓库的构想。“数据仓库”一词最早是在1900年，由Bill Inmon先生提出的，其描述如下：数据仓库是为支持企业决策而特别设计和建立的数据集合。

对于一个企业来说，最重要的就是数据，现有的数据存储形式已经不能满足信息分析的需要，因此我们就需要建立数据仓库来处理企业的事务性数据和决策支持型数据。

今天我们主要来看看数据模型的设计和建立方法。

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为几下几个层次，如图所示。

数据仓库模型

通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：

• 业务建模，生成业务模型，主要解决业务层面的分解和程序化。

• 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。

• 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。

• 物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。

在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。

数据仓库的发展大致经历了这样的三个过程：

• 简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。

• 数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。

• 数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。

通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。

一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：

• 进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。

• 建立全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。

• 解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。

• 帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。

综上所看，数据建模对数据仓库建设的意义非常重要

其也有自身的一套方法论和原则，他的模型设计遵循“自顶向下、逐步求精”的设计原则。

一般来说模型设计分为三个阶段：

对业务的范围和使用，从高度上进行抽象概括，也就是划分主题域。

一般划分为8个主题域：

客户、服务、服务使用、账务、结算、资源、客服、营销

对概念模型中的主题进行细化，定义实体与实体之间的关系，和实体的属性。

即定义具体表的作用，表与表的约束，表的字段。形成ER图。

这些实体的设计都是基于业务规则，可以说，这一阶段主要面对的是业务。也就是“业务驱动建模”。

依照逻辑模型，在数据库中进行建表、索引等。数据仓库，为了满足高性能的需求，可以增加冗余、隐藏表之间的约束等反第三范式操作。

这一阶段，主要针对的是数据库、硬件、性能。

范式：

第一范式：数据库表的字段都是单一属性，不可再分。

第二范式：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。

（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况）。即要求所有属性都依赖于主键。

第三范式：数据库表中不存在非关键字段对任一候选关键字段的传递函数依赖。

范式是向下兼容的。

例如：

1）违反第一范式。因为：学生部门可以分解为：学院，系，班级

2）违反第二范式。因为：关键字段是学生ID和课程ID, 但存在“课程ID”决定课程名称和课程学分。

3）违反第三范式。因为：关键字段是学生ID,但存在可能名称和学分依赖“课程ID”。

下面我们来看这样方法论建出来的几个基本模型

星型模型和雪花模型

首先，他们都是由一个事实表和一组维度表组成。

星型模型，也被称为维度建模。

区别在于：

星型模型：维度表直接跟事实表连接，图型像星星。

如区县和地市做为同一维度都在地市表中。

*维度预处理，维度会预先进行分类，排序等预处理。

雪花模型：一些维度表不是直接与事实表连接，而是通过维度表中转，图形像雪花。

例如：

星型模型

雪花模型

从性能来看，星型模型查询性能好。

为了提高性能，可以允许违反第三范式，适当的冗余、隐藏表之间的约束。

维度建模

将商业维度融合到数据模型中，由此得名维度建模。

或者说，为了分析方便（商业应用要求），将同一维度的不同层次的维度（如地市ID,区县ID）都融合到事实表中（如用户宽表）。

维度模型也是星型模型。

它强调的是先对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表，如上面的用户统一视图。包含了20多个维度。这样可以组合各维度，形成灵活的报表查询。

电信行业的数据仓库都采用了分层设计原则。

总的来说，分三层：接口层、中间汇总层和应用层。

特别强调的是：

中间层是数据仓库最重要的一层。直接决定了数据仓库的性能。

一般的做法是：

1）数据汇总。将底层数据按维度进行小颗粒度汇总

2）信息聚合。将多张表的信息聚合在一个表中。这样的好处，是避免使用表关联，提高查询性能。

如果说分层设计，是横向的设计原则，那么主题分域是纵向的处理方法。

具体做法就是从业务上，高度的抽象和归纳，将数据划分为不同的主题域。

分域后的好处：业务紧耦合、便于数据拓展、便于使用。

域是要具有明显的表命名规则，如：

用户信息域—— user

通信行为—— call

数据业务—— gprs

账务 —— bill

客户服务—— serv

xx经分系统的数据架构图

今天讲完基本的定义和方法原则

大家消化消化

明天我们继续讲讲怎么建立吧~

晚安哦~

如果睡不着的话，俺老孙给大家分享一个视频

大家点阅读原文看一看咯