周三保(zhousb@cn.ibm.com) IBM 软件部信息技术专家.
简介： 本文的主要内容不是介绍现有的比较流行的主要行业的一些数据模型，而是将笔者在数据仓库建设项目中的一些经验，在这里分享给大家。希望帮助大家在数据仓库项目建设中总结出一套能够合乎目前业界规范的，满足大部分行业数据仓库建设标准的一种方法。
所谓水无定势，兵无常法。不同的行业，有不同行业的特点，因此，从业务角度看，其相应的数据模型是千差万别的。目前业界较为主流的是数据仓库厂商主要是 IBM 和 NCR，这两家公司的除了能够提供较为强大的数据仓库平台之外，也有各自的针对某个行业的数据模型。
例如，在银行业，IBM 有自己的 BDWM(Banking data warehouse model)，而 NCR 有自己的 FS-LDM 模型。在电信业，IBM 有 TDWM（Telecom Data warehouse model），而 NCR 有自己的 TS-LDM 模型。因此，我们看到，不同的公司有自己针对某个行业的理解，因此会有不同的公司针对某个行业的模型。而对于不同的行业，同一个公司也会有不同的模型，这主要取决于不同行业的不同业务特点。
举例来说，IBM 的 TDWM 的模型总共包含了以下 9 个概念，如下图：
图 1. IBM 的 TDWM 概念模型

可能很多人要问，为什么你们的模型是 9 个概念而不是 10 个，11 个呢？你们的数据仓库模型的依据又是什么？其实这是我们在给客户介绍我们的数据模型时，经常被问到的一个问题，我希望读者在读完本文时，能够找到自己的答案。
虽然每个行业有自己的模型，但是，我们发现，不同行业的数据模型，在数据建模的方法上，却都有着共通的基本特点。
本文的主要目的之一，就是希望读者能够通过对本文的阅读，同时，结合自己对数据仓库建设的经验，在建设数据仓库的时候能够总结出一套适合自己的建模方法，能够更好的帮助客户去发挥数据仓库的作用。
本文主要的主线就是回答下面三个问题：
什么是数据模型
为什么需要数据模型
如何建设数据模型
最后，我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例，帮助大家来了解整个数据建模的过程。
一、    什么是数据模型
数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。
数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为几下几个层次，如图 2 所示。
图 2. 数据仓库模型

通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：
业务建模，生成业务模型，主要解决业务层面的分解和程序化。
领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。
二、    为什么需要数据模型
在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。
数据仓库的发展大致经历了这样的三个过程：
简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：
进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
建立全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
三、    如何建设数据模型
建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分，那么，怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。
1)       数据仓库数据模型架构
数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的，我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到，整个数据模型的架构分成 5 大部分，每个部分其实都有其独特的功能。
图 3. 数据仓库数据模型架构

从上图我们可以看出，整个数据仓库的数据模型可以分为大概 5大部分：
系统记录域（System of Record）：这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。
内部管理域（Housekeeping）：这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。
汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。
分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置这一区域。
通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该涵盖了从业务到实现技术的各个部分。
2)       数据仓库建模阶段划分
我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的不同阶段的数据建模的工作的主要内容：
图 4. 数据仓库建模阶段划分

从上图我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：
1.   业务建模，这部分建模工作，主要包含以下几个部分：
划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
深入了解各个业务部门的内具体业务流程并将其程序化。
提出修改和改进业务部门工作流程的方法并程序化。
数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
2.   领域概念建模，这部分得建模工作，主要包含以下几个部分：
抽取关键业务概念，并将之抽象化。
将业务概念分组，按照业务主线聚合类似的分组概念。
细化分组概念，理清分组概念内的业务流程并抽象化。
理清分组概念之间的关联，形成完整的领域概念模型。
3.   逻辑建模，这部分的建模工作，主要包含以下几个部分：
业务概念实体化，并考虑其具体的属性
事件实体化，并考虑其属性内容
说明实体化，并考虑其属性内容
4.   物理建模，这部分得建模工作，主要包含以下几个部分：
针对特定物理化平台，做出相应的技术调整
针对模型的性能考虑，对特定平台作出相应的调整
针对管理的需要，结合特定的平台，做出相应的调整
生成最后的执行脚本，并完善之。
从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所帮助。
3)       数据仓库建模方法
大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。
1. 范式建模法（Third Normal Form，3NF）
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
每个属性值唯一，不具有多义性 ;
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。
图 5. 范式建模法

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：
数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。
以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。
2. 维度建模法
维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）。
图 6. 维度建模法

上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF的建模方法，星型模式在性能上占据明显的优势。
同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。
但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
因此以笔者的观点看，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
3. 实体建模法
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如下图所示：
图 7. 实体建模法

上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3个部分：
实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
说明，主要是针对实体和事件的特殊说明。
由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。
但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。
因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。
四、    数据仓库建模样例
上面介绍得是一些抽象得建模方法和理论，可能理解起来相对有些难度，因此，笔者在这里举一个例子，读者可以跟着我们的这个样例，来初步了解整个数据仓库建模的大概过程。
熟悉社保行业的读者可以知道，目前我们国家的社保主要分为养老，失业，工伤，生育，医疗保险和劳动力市场这 6 大块主要业务领域。在这 6 大业务领域中，目前的状况养老和事业的系统已经基本完善，已经有一部分数据开始联网检测。而，对于工伤，生育，医疗和劳动力市场这一块业务，有些地方发展的比较成熟，而有些地方还不够成熟。
1.业务建模阶段
基于以上的背景介绍，我们在业务建模阶段，就很容易来划分相应的业务。因此，在业务建模阶段，我们基本上确定我们本次数据仓库建设的目标，建设的方法，以及长远规划等。如下图：
图 8. 业务建模阶段
在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。
因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。
同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。
2.领域概念建模阶段
领域概念建模阶段是数据仓库数据建模的一个重要阶段，由于我们在业务建模阶段已经完全理清相应的业务范围和流程，因此，我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象，整个领域概念建模的工作层次如下图所示：
图 9. 领域概念建模阶段

从上图我们可以清楚地看到，领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。
从图上看，我们可以把整个抽象过程分为四个层次，分别为：
抽象方法层，整个数据模型的核心方法，领域概念建模的实体的划分通过这种抽象方法来实现。
领域概念层，这是我们整个数据模型的核心部分，因为不同程度的抽象方法，决定了我们领域概念的不同。例如：在这里，我们可以使用“参与方”这个概念，同时，你也可以把他分成三个概念：“个人”，“公司”，和“经办机构”这三个概念。而我们在构建自己的模型的时候，可以参考业务的状况以及我们自己模型的需要，选择抽象程度高的概念或者是抽象程度低的概念。相对来说，抽象程度高的概念，理解起来较为复杂，需要专业的建模专家才能理解，而抽象程度低的概念，较适合于一般业务人员的理解，使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体，以方便业务人员和技术人员之间的交流和沟通。
具体业务层，主要是解决具体的业务问题，从这张图我们可以看出，具体的业务层，其实只是领域概念模型中实体之间的一些不同组合而已。因此，完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求，而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。
业务主线层，这个层次主要划分大的业务领域，一般在业务建模阶段即已经完成这方面的划分。我们一般通过这种大的业务主线来划分整个业务模型大的框架。
通过领域概念建模，数据仓库的模型已经被抽象成一个个的实体，模型的框架已经搭建完毕，下面的工作就是给这些框架注入有效的肌体。
3.逻辑建模阶段
通过领域概念建模之后，虽然模型的框架已经完成，但是还有很多细致的工作需要完成。一般在这个阶段，我们还需要做非常多的工作，主要包括：
实例话每一个抽象的实体，例如：在上面的概念模型之后，我们需要对“人”和“公司”等这些抽象实体进行实例化。主要是，我们需要考虑“人”的属性包括那些，在业务模块中，用到的所有跟“人”相关的属性是哪些，我们都需要将这些属性附着在我们数据模型的“人”这个实体上，例如“人”得年龄，性别，受教育程度等等。同理，我们对其他属性同样需要做这个工作。
找出抽象实体间的联系，并将其实例话。这里，我们主要考虑是“事件”这个抽象概念的实例话，例如：对于养老金征缴这个“事件”的属性得考虑，对于失业劳动者培训这个“事件”的属性得考虑等等。
找出抽象事件的关系，并对其进行说明。在这里我们主要是要针对“事件”进行完善的“说明”。例如：对于“事件”中的地域，事件等因素的考量等等。
总而言之，在逻辑建模阶段，我们主要考虑得是抽象实体的一些细致的属性。通过逻辑建模阶段，我们才能够将整个概念模型完整串联成一个有机的实体，才能够完整的表达出业务之间的关联性。
在这个阶段，笔者建议大家可以参考 3NF 的建模方法，表达出实体的属性，以及实体与实体之间的联系。例如：在这个阶段，我们可以通过采用 ERWIN 等建模工具等作出符合 3NF 的关系型数据模型来。
4.物理建模阶段
物理建模阶段是整个数据建模的最后一个过程，这个过程其实是将前面的逻辑数据模型落地的一个过程。考虑到数据仓库平台的不同，因此，数据模型得物理建模过程可能会稍微有一些不同，在这个阶段我们主要的工作是：
生成创建表的脚本。不同的数据仓库平台可能生成不同的脚本。
针对不同的数据仓库平台，进行一些相应的优化工作，例如对于 DB2 数据仓库来说，创建一些 MQT 表，来加速报表的生成等等。
针对数据集市的需要，按照维度建模的方法，生成一些事实表，维表等工作。
针对数据仓库的 ETL 车和元数据管理的需要，生成一些数据仓库维护的表，例如：日志表等。
经过物理建模阶段，整个数据仓库的模型已经全部完成，我们可以按照自己的设计来针对当前的行业创建满足自己需要的数据模型来。
这里，笔者通过一个数据建模的样例，希望能够给读者一个关于数据仓库建模的感性的认识。希望读者在利用这些数据仓库得建模方法创建自己的数据模型的时候，可以根据业务实际的需要和自己对抽象能力的把握来创建适合自己的数据模型。

一、数据的获取
 
1.从Excel中读取数据
 
（1）xlsread函数 ：从EXCEL读入数据到MATLAB中。
 例如：
 
 a = xlsread(‘D:\adc.xlsx’,1,‘A1:D2’)
 其中，‘D:\abc.xlsx’表示读入的EXCEL数据所在的路径以及EXCEL的文件名称；1表示位于sheet1；'A1:D2’表示需要读入的数据范围。
 
 （2）xlswrite函数：从MATLAB中往EXCEL写入数据。
 xlswrite(‘D:\adc.xlsx’,a,1,‘A1:D2’)
 其中，‘D:\abc.xlsx’表示写入EXCEL工作簿所在的位置，如果指定位置不存在指定的EXCEL文件，则MATLAB会自动创建工作簿；a表示待写入的数据；1表示sheet1；'A1:D2’表示写入EXCEL中的具体位置。
 
 注意，不要在MATLAB正在读写操作的时候打开EXCEL工作簿，这样有可能使程序终止运行。
 
2.从TXT中读取数据
 
（1）load函数：从TXT中读取数据。
 load(‘***.txt’)
 实操：
 
 
 （2）textread函数： 如果TXT文件中存储了不同类型的字符或者数据，分类读取数据就需要使用textread函数了。textread读取信息的好处是，可以做到控制输出更精准，以及不需要使用fopen命令打开文件就可以直接读取TXT里的内容。
 [A,B,C,…]=textread(‘filename’,‘format’,N,‘headerlines’,M)
 其中，filename表示需要读取的TXT文件名称；format表示所读取变量的字段格式；N表示读取的次数，每一次读取一行；headerlines表示从第M+1行开始读入。
 实操：
 
 
3.读取图片
 
imread函数： MATLAB中读取图片的常用函数。
 A = imread(filename)
 A = imread(filename,fmt)
 A = imread(___,idx)
 A = imread(___,Name,Value)
 [A,map] = imread(___)
 [A,map,transparency] = imread(___)
 
其中，A为返回的数组，用于存放图像中的像素矩阵。
 实操：
 
 
 
4.读取视频
 
VideoFileReader ：在MATLAB中使用计算机视觉工具箱中的VideoFileReader来读取视频数据，包括mp4、avi等格式的视频文件。
 实操：
 ![在这里插入图片描述]](https://img-blog.csdnimg.cn/20200530202023784.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ1MDU5NDU3,size_16,color_FFFFFF,t_70)
 
 
 运行结果：
 
 
5.总结
 
（1）用xlsread(),xlswrite()函数从Excel读取数据
 （2）用textread()函数读取txt文档
 （3）用imread()函数读取图片
 （4）工具箱中VideoFileReader来读取视频数据
 
二、数据的预处理
 
为什么需要数据预处理？
 原因：
 收集数据的设备可能出故障；
 输入错误数据；
 当用户不希望提交个人信息时，可能故意向强制输入字段输入不正确的值；
 错误也可能在数据传输中出现，这些可能是由于技术的限制。
 由命名约定或所用的数据代码不一致，或输入字段的格式不一致而导致的。
 影响数据质量的另外两个因素是可信性和可解释性。可信性反映有多少数据是用户信赖的，而可解释性反映数据是否容易理解。
 我们并不需要过多关注数据质量差的原因，只需关注如何让数据质量更好，也就是说，如何对数据进行预处理，以提高数据质量，满足数据挖掘的需要。
 
1.缺失值处理
 
（1）均值插补。如果缺失值是定距型的，就以该属性存在值的平均值来插补缺失的值；如果缺失值是非定距型的，就根据统计学中的众数原理，用该属性的众数来补齐缺失的值；如果数据符合较规范的分布规律，则还可以用中值插补。
 （ 2）回归插补。利用线性或非线性回归技术得到的数据来对某个变量的缺失数据进行插补。
 

 （ 3）极大似然估计。在缺失类型为随机缺失的条件下，假设模型对于完整的样本是正确的，那么通过观测数据的边际分布可以对未知参数进行极大似然估计。
 
2.噪声过滤
 
1、回归法：用一个函数拟合数据来光滑数据。
 
 
2、均值平滑法：对于具有序列特征的变量用邻近的若干数据的均值来替换原始数据的方法。
 
 3、离群点分析：通过聚类等方法来检测离群点，并将其删除，从而实现去噪的方法。
 4、小波过滤法（又称小波去噪）：在数学上，小波去噪问题的本质是一个函数逼近问题，即如何在由小波母函数伸缩和平移所展成的函数空间中，根据提出的衡量准则，寻找对原信号的最佳逼近，以完成原信号和噪声信号的区分。
 
 
3.数据集成
 
数据集成就是将若干个分散的数据源中的数据，逻辑地或物理地集成到一个统一的数据集合中。
 实现数据集成的系统称作数据集成系统，它为用户提供统一的数据源访问接口，执行用户对数据源的访问请求。
 
 
4.数据归约
 
数据归约的目的：得到能够与原始数据集近似等效甚至更好但数据量却较少的数据集。
 
 
5.数据变换
 
数据变换是指将数据从一种表示形式变为另一种表现形式的过程。
 
 
三、数据的统计
 
1.基本描述性统计
 
 
2.分布描述统计
 
 
3.总结
 
(1)表示位置的统计量：算术平均值和中位数
 (2)表示数据散点的统计量：标准差、方差和极差
 (3)表示分布形状的统计量：偏度和峰度
 
四、数据可视化
 
1.基本可视化
 
基本可视化是最常用的方法。在对数据进行可视化探索时，通常先用plot这样最基本的绘图命令来绘制各变量的分布趋势，以了解数据的基本特征。
 实操：
 
 
 

 上图是用plot绘制的数据最原始的分布形态，通过该图能了解数据大致的分布中心、边界、数据集中程度等信息。
 
2.数据分布形状可视化
 
在数据建模中，数据的分布特征对我们了解数据是非常有利的。
 
 
3.数据关联可视化
 
数据关联可视化对分析哪些变量更有效具有更直观的效果，所以在进行变量筛选前，可以先利用关联可视化了解各变量间的关联关系。
 实操：
 
 
变量间相关性关联图
 
 绘制变量间相关性强度图
 
 
4.数据分组可视化
 
数据分组可视化是指按照不同的分位数将数据进行分组，典型的图形是箱体图。箱体图的含义如下图所示。
 
 绘制箱体图的MATLAB命令是boxplot。
 实操：
 
 画所有变量的箱体图
 
 绘画dv1和eva两个变量的箱体图
 
 
5.总结
 
（1）基本可视化看总体
 （2）分布可视化辨别各个变量是否对数据建模有意义
 （3）数据关联可视化在进行变量筛选前使用
 （4）数据分组可视化可以看出分布特征和异常值得数量，典型图形是箱体图，绘制箱体图的MATLAB命令是boxplot。
 
五、数据降维
 
1.主成分分析（PCA）基本原理及算法步骤
 
主成分分析是采取一种数学降维的方法，其所要做的就是设法将原来众多具有一定相关性的变量，重新组合为一组新的相互无关的综合变量来代替原来变量。
 算法步骤
 （1）对原始数据进行标准化处理
 （2）计算样本相关系数矩阵
 （3）计算相关系数矩阵的特征值和相应的特征向量
 （4）选择重要的主成分，并写出主成分表达式
 （5）计算主成分得分
 （6）依据主成分得分的数据，进一步对问题进行后续的分析和建模。
 
2.案例
 
为了系统分析某IT类企业的经济效益，选择了8个不同的利润指标，对15家企业进行了调研，并得到下表所示的数据。请根据这些数据对这15家企业进行综合实力排序。
 
 代码：
 %% 导入数据
 clc, clear, close all
 A = xlsread(‘D:\数学建模\第3章 数据建模基础\5.数据降维\Coporation_evaluation.xlsx’,‘Sheet1’,‘B2:I16’);
 
%%数据标准化处理
 a=size(A,1);
 b=size(A,2);
 for i=1:b
 SA(:,i)=(A(:,i)-mean(A(:,i)))/std(A(:,i))
 end
 
%%特征值、特征向量
 CM=corrcoef(SA)
 [V,D]=eig(CM)
 for j=1:b
 DS(j,1)=D(b+1-j,b+1-j)
 end
 for i=1:b
 DS(i,2)=DS(i,1)/sum(DS(:,1));
 DS(i,3)=sum(DS(1:i,1))/sum(DS(:,1))
 end
 T=0.9;
 for K=1:b
 if DS(K,3)>=T
 Com_num=K;
 break;
 end
 end
 
%%提取主成分对应的特征向量
 for j=1:Com_num
 PV(:,j)=V(:,b+1-j);
 end
 
new_score=SA*PV;
 for i=1:a
 total_score(i,2)=sum(new_score(i,:))
 total_score(i,1)=i;
 end
 new_score_s=sortrows(total_score,-2)
 
%%显示结果
 disp(‘特征值及贡献率：’)
 DS
 disp(‘阀值T对应的主成分数与特征向量：’)
 Com_num
 PV
 disp(‘主要分分数：’)
 new_score
 disp(‘主成分分数排序：’)
 new_score_s
 
运行结果：
 主成分分数排序：
 
new_score_s =
 
9.0000 4.2350
 1.0000 3.9717
 8.0000 2.3677
 6.0000 1.9710
 5.0000 1.7984
 13.0000 1.1033
 15.0000 0.7527
 14.0000 0.1682
 2.0000 -0.2923
 10.0000 -1.0075
 7.0000 -1.5238
 4.0000 -2.0545
 11.0000 -2.5137
 3.0000 -3.6435
 12.0000 -5.3327
 
3.相关系数降维
 
相关系数用r表示，r在-1到+1之间取值。相关系数r 的绝对值大小（即| r |），表示两个变量之间的直线相关强度；相关系数r的正负号，表示相关的方向，分别是正相关和负相关。
 | r | =0：零相关；
 | r | =1：完全相关。
 0.7<|r |<1：高度相关；
 0.4<|r |<0.7：中度相关；
 0.2<|r |<0.4：低度相关；
 |r |<0.2：极低相关或接近零相关。
 
4.总结
 
（1）数据的读取有表格的读取，txt文档的读取，照片和视频的读取等等。
 （2）数据的预处理帮助我们优化数据，满足建模需要。
 （3）数据统计我们可以从算数平均值、中位数、标准差、方差、极差、偏度、峰度、概率分布函数、概率密度函数入手。
 （4）数据的可视化让我们更好掌握数据的总体情况和各个变量的重要性。
 （4）数据降维有两种方法：主成分分析法和相关系数法。

 
 
根据boss想法整理一般通用的数据仓库模型构建思路，这里参考了公众号内文章，觉得写得很好，既有理论指导又有实践案例，能够详细地说明；
 
 
目录
 
什么是数据模型？
 
为什么需要数据模型？
 
如何建设数据模型？
 
数据仓库数据模型架构
 
数据仓库建模阶段划分
 
数据仓库建模方法
 
数据仓库建模样例
 
业务建模阶段
 
领域概念建模阶段
 
逻辑建模阶段
 
物理建模阶段
 

 
 
什么是数据模型？
 
数据模型是抽象描述现实世界的工具和方法，通过抽象的实体及实体之间联系的形式，表示现实世界中事务的相互关系的一种映射。数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。
 
数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定数据模型，数据仓库模型分为几个层次：
 
 
 
 
通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：
 
业务建模，生成业务模型，主要解决业务层面的分解和程序化。
 
领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
 
逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
 
物理建模，生成物理模型，主要解决逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
 
因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。
 
为什么需要数据模型？
 
在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。
 
数据仓库的发展大致经历了这样的3个过程：
 
简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
 
数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
 
数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
 
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
 
一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：
 
进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
 
建立全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
 
解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
 
帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
 
如何建设数据模型？
 
如何创建适合自己的数据模型？
 
数据仓库数据模型架构
 
数据仓库的数据模型的架构和数据仓库的整体架构紧密关联，数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到，整个数据模型的架构分成 5 大部分，每个部分都有其独特的功能。
 
 
从上图我们可以看出，整个数据仓库的数据模型可以分为大概 5 大部分：
 
系统记录域（System of Record）：这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。
 
内部管理域（Housekeeping）：这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。
 
汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。
 
分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
 
反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置。
 
通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该涵盖了从业务到实现技术的各个部分。
 
数据仓库建模阶段划分
 
我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的不同阶段的数据建模的工作的主要内容：
 
 
从上图我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：
 
业务建模
 
这部分建模工作，主要包含以下几个部分：
 
划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
 
深入了解各个业务部门的内具体业务流程并将其程序化。
 
提出修改和改进业务部门工作流程的方法并程序化。
 
数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
 
领域概念建模
 
这部分得建模工作，主要包含以下几个部分：
 
抽取关键业务概念，并将之抽象化。
 
将业务概念分组，按照业务主线聚合类似的分组概念。
 
细化分组概念，理清分组概念内的业务流程并抽象化。
 
理清分组概念之间的关联，形成完整的领域概念模型。
 
逻辑建模
 
这部分的建模工作，主要包含以下几个部分：
 
业务概念实体化，并考虑其具体的属性
 
事件实体化，并考虑其属性内容
 
说明实体化，并考虑其属性内容
 
物理建模
 
这部分得建模工作，主要包含以下几个部分：
 
针对特定物理化平台，做出相应的技术调整
 
针对模型的性能考虑，对特定平台作出相应的调整
 
针对管理的需要，结合特定的平台，做出相应的调整
 
生成最后的执行脚本，并完善之。
 
从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所帮助。
 
数据仓库建模方法
 
大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。
 
范式建模法（Third Normal Form，3NF）
 
范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。
 
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
 
每个属性值唯一，不具有多义性 ;
 
每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
 
每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
 
由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
 
根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。
 
 
从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：
 
数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
 
在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。
 
以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。
 
维度建模法
 
维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）。
 
 
上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。
 
雪花模型也是维度建模中的一种选择。雪花模型的维度表可以拥有其他维度表的，虽然这种模型相比星型模型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用。雪花模型如下图
 
 
同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。
 
但维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
 
另一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
 
维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
 
实体建模法
 
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
 
虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如下图所示：
 
 
上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
 
从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3 个部分：
 
实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
说明，主要是针对实体和事件的特殊说明。
由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。
 
但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。
 
因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。
 
数据仓库建模样例
 
上面介绍得是一些抽象得建模方法和理论，可能理解起来相对有些难度，因此，笔者在这里举一个例子，读者可以跟着我们的这个样例，来初步了解整个数据仓库建模的大概过程。
 
熟悉社保行业的读者可以知道，目前我们国家的社保主要分为养老，失业，工伤，生育，医疗保险和劳动力市场这 6 大块主要业务领域。在这 6 大业务领域中，目前的状况养老和事业的系统已经基本完善，已经有一部分数据开始联网检测。而，对于工伤，生育，医疗和劳动力市场这一块业务，有些地方发展的比较成熟，而有些地方还不够成熟。
 
业务建模阶段
 
基于以上的背景介绍，我们在业务建模阶段，就很容易来划分相应的业务。因此，在业务建模阶段，我们基本上确定我们本次数据仓库建设的目标，建设的方法，以及长远规划等。如下图
 
 
在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。
 
因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。
 
同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。
 
领域概念建模阶段
 
领域概念建模阶段是数据仓库数据建模的一个重要阶段，由于我们在业务建模阶段已经完全理清相应的业务范围和流程，因此，我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象，整个领域概念建模的工作层次如下图所示：
 
 
从上图我们可以清楚地看到，领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。
 
从图上看，我们可以把整个抽象过程分为四个层次，分别为：
 
抽象方法层，整个数据模型的核心方法，领域概念建模的实体的划分通过这种抽象方法来实现。
 
领域概念层，这是我们整个数据模型的核心部分，因为不同程度的抽象方法，决定了我们领域概念的不同。例如：在这里，我们可以使用“参与方”这个概念，同时，你也可以把他分成三个概念：“个人”，“公司”，和“经办机构”这三个概念。而我们在构建自己的模型的时候，可以参考业务的状况以及我们自己模型的需要，选择抽象程度高的概念或者是抽象程度低的概念。相对来说，抽象程度高的概念，理解起来较为复杂，需要专业的建模专家才能理解，而抽象程度低的概念，较适合于一般业务人员的理解，使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体，以方便业务人员和技术人员之间的交流和沟通。
 
具体业务层，主要是解决具体的业务问题，从这张图我们可以看出，具体的业务层，其实只是领域概念模型中实体之间的一些不同组合而已。因此，完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求，而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。
 
业务主线层，这个层次主要划分大的业务领域，一般在业务建模阶段即已经完成这方面的划分。我们一般通过这种大的业务主线来划分整个业务模型大的框架。
通过领域概念建模，数据仓库的模型已经被抽象成一个个的实体，模型的框架已经搭建完毕，下面的工作就是给这些框架注入有效的肌体。
 
逻辑建模阶段
 
通过领域概念建模之后，虽然模型的框架已经完成，但是还有很多细致的工作需要完成。一般在这个阶段，我们还需要做非常多的工作，主要包括：
 
实例话每一个抽象的实体，例如：在上面的概念模型之后，我们需要对“人”和“公司”等这些抽象实体进行实例化。主要是，我们需要考虑“人”的属性包括那些，在业务模块中，用到的所有跟“人”相关的属性是哪些，我们都需要将这些属性附着在我们数据模型的“人”这个实体上，例如“人”得年龄，性别，受教育程度等等。同理，我们对其他属性同样需要做这个工作。
 
找出抽象实体间的联系，并将其实例话。这里，我们主要考虑是“事件”这个抽象概念的实例话，例如：对于养老金征缴这个“事件”的属性得考虑，对于失业劳动者培训这个“事件”的属性得考虑等等。
 
找出抽象事件的关系，并对其进行说明。在这里我们主要是要针对“事件”进行完善的“说明”。例如：对于“事件”中的地域，事件等因素的考量等等。
总而言之，在逻辑建模阶段，我们主要考虑得是抽象实体的一些细致的属性。通过逻辑建模阶段，我们才能够将整个概念模型完整串联成一个有机的实体，才能够完整的表达出业务之间的关联性。
 
在这个阶段，笔者建议大家可以参考 3NF 的建模方法，表达出实体的属性，以及实体与实体之间的联系。例如：在这个阶段，我们可以通过采用 ERWIN 等建模工具等作出符合 3NF 的关系型数据模型来。
 
物理建模阶段
 
物理建模阶段是整个数据建模的最后一个过程，这个过程其实是将前面的逻辑数据模型落地的一个过程。考虑到数据仓库平台的不同，因此，数据模型得物理建模过程可能会稍微有一些不同，在这个阶段我们主要的工作是：
 
生成创建表的脚本。不同的数据仓库平台可能生成不同的脚本。
针对不同的数据仓库平台，进行一些相应的优化工作，例如对于 DB2 数据仓库来说，创建一些 MQT 表，来加速报表的生成等等。
针对数据集市的需要，按照维度建模的方法，生成一些事实表，维表等工作。
针对数据仓库的 ETL 车和元数据管理的需要，生成一些数据仓库维护的表，例如：日志表等。
经过物理建模阶段，整个数据仓库的模型已经全部完成，我们可以按照自己的设计来针对当前的行业创建满足自己需要的数据模型来。
这里，笔者通过一个数据建模的样例，希望能够给读者一个关于数据仓库建模的感性的认识。希望读者在利用这些数据仓库得建模方法创建自己的数据模型的时候，可以根据业务实际的需要和自己对抽象能力的把握来创建适合自己的数据模型。

数据分析是一项实践性很强的工作，涉及到很多交叉学科，需要不同的岗位和角色，来实现不同的性质的工作。
 
一 、数据分析师中的角色和职责
 
数据分析团队师应该在科技部门内部还在业务部门内部一直存在争议。在业务部门内部，对数据场景比较了解，容易找到数据变现的场景，数据分析师对业务提升帮助较大，容易出成绩。但是弊端是仅仅对自己部门的业务数据了解，分析只是局限独立的业务单元之内，在数据获取的效率上，数据维度和数据视角方面缺乏全局观，数据的商业视野不大，对公司整体业务的推动发展有限。业务部门的数据分析团队缺少数据技术能力，无法利用最新的大数据计算和分析技术，来实现数据分析和建模。数据分析和计算依赖于科技部门，效率较低，无法打通各个环节和实现效率和收益最优。
 
1. 数据库(仓库)管理员DBA
 
DBA最了解企业内部的数据和可用的数据资源，包括数据的存储细节和数据字典，另外其对数据的采集、清洗和转化起到关键作用。
 
DBA为数据科学家和数据分析师提供加工好的原始数据，这些数据是数据分析和建模的基础，DBA做了数据分析工作中最重要的基础工作，完成了大量的脏活和累活。
 
2 .业务专家
 
业务专家的优势是数据的商业敏感度，了解业务需求，可以将业务需求转化为数据需求，进一步找到数据应用场景。另外业务专家也可以通过对数据的分析，找到新的商业机会，同业务部门一起制定商业计划，利用数据分析推动业务增长。
 
业务专家的经验对于数据分析和建模是非常关键的，他们可能是风险管理人员、欺诈监测专家、投资专家等。数据建模来源于业务经验和业务知识，正是业务专家的专业分析找到了业务规律，从而找到了建模方向，并对建模工作给出建议和解释。
 
3. 数据科学家
 
过去统计分析依赖于统计分析工具，大数据时代之后，数据量级的提升和数据类型的复杂程度，让很多传统的统计分析工具无法完成分析计算。这个时候，数据科学家出现了，他们可以利用自己的专业技能帮助业务专家和数据分析人员进行建模和计算。
 
过去数据统计分析建模常用SPSS，SAS，MATLAB等工具，现在基于大数据平台的分析建模可以使用Spark+Scala/Python/R/Java。数据科学家了解模型和算法，可以直接承担建模和调优工作，懂得选择合适的算法来进行计算，提高效率。
 
4. 数据分析师
 
数据分析师站在数据和商业的角度来解读数据，利用图标和曲线等方式向管理层和业务人员展现分析结果，揭示数据分析产生的商业机会和挑战。
 
数据分析师将杂乱的数据进行整理后，将数据以不同的形式展现给产品经理、运营人员、营销人员、财务人员、业务人员等。提出基于数据的结果和分析建议，完成数据从原始到商业化应用到关键一步，数据分析师的数据敏感度、商业敏感度、分析角度、表达方式对于商业决策很重要。
 
5 .运营专家
 
数据分析结果和商业决策出来之后，运营专家负责实现商业决策。通过有计划的运营活动，将数据分析的结果应用到实际的商业活动之中，运营专家是实现数据变现最后一公里的关键人物。
 
运营专家属于业务人员，实际上参与业务运营活动，利用数据分析结果，实现业务场景和数据场景的结合，实现数据商业化应用。
 
二、 数据分析之前的各项准备工作
 
数据分析团队各成员确定之后，将进行下一项工作，就是找到有价值的数据进行分析了。数据是分析的基础，因此数据的质量、数据的相关度、数据的维度等会影响数据分析的结果影，其中GIGO(垃圾进垃圾出)对于数据分析结果影响最大。
 
1 .数据源选择
 
数据分析团队面对大量的数据源，各个数据源之间交叉联系，各个数据域之间具有逻辑关系，各个产品统计口径不同，不同的时间段数值不同等。这一系列问题多会影响数据分析结果，因此确定数据源选择和数据整理至关重要。
 
DBA可以基于数据分析需要，找到相关数据，建立一张数据宽表，将数据仓库的数据引入到这张宽表当中，基于一定的逻辑关系进行汇总计算。这张宽表作为数据分析的基础，然后再依据数据分析需要衍生出一些不同的表单，为数据分析提供干净全面的数据源。宽表一方面是用于集中相关分析数据，一方面是提高效率，不需要每次分析时都查询其他的数据表，影响数据仓库效率。
 
2. 数据抽样选择
 
简单的数据分析可以调用全体数据进行分析，数据抽样主要用于建模分析，抽样需考虑样本具有代表性，覆盖各种客户类型，抽样的时间也很重要，越近的时间窗口越有利于分析和预测。在进行分层抽样时，需要保证分成出来的样本比例同原始数据基本一致。
 
3 .数据类型选择
 
数据类型分为连续型和离散型，建模分析时需要确定数据类型。进行业务收入趋势分析、销售额预测分析、RFM分析时，一般采用连续型变量。信用评级、分类预测时一般采用离散变量。
 
4 .缺失值处理
 
数据分析过程中会面对很多缺失值，其产生原因不同，有的是由于隐私的原因，故意隐去。有的是变量本身就没有数值，有的是数据合并时不当操作产生的数据缺失。
 
缺失值处理可以采用替代法(估值法)，利用已知经验值代替缺失值，维持缺失值不变和删除缺失值等方法。具体方法将参考变量和自变量的关系以及样本量的多少来决定。
 
5. 异常值检测和处理
 
异常值对于某些数据分析结果影响很大，例如聚类分析、线性回归(逻辑回归)。但是对决策树、神经网络、SVM支持向量机影响较小。
 
一般异常值是指明显偏离观测值的平均值，例如年龄为200岁，平均收入为10万元时，有个异常值为300万元。第一个异常值为无效异常值，需要删掉，但是第二个异常值可能属于有效异常值，可以根据经验来决定是否保留或删掉。
 
6 .数据标准化
 
数据标准化的目的是将不同性质、不同量级的数据进行指数化处理，调整到可以类比的范围。例如在建立逻辑回归模型时，性别的取值是0或以，但是收入取值可能就是0-100万，跨度较大，需要进行标准化。
 
一般可以采用最佳/最大标准化(Min-Max标准化法)将数值定在0和1之间，便于计算。Z分数法和小数定标标准化法也可以采用。
 
7 .数据粗分类(Categorization)处理
 
归类和分类的目的是减少样本的变量，常有的方法由等间距分类，等频数分类。可以依据经验将自变量分成几类，分类的方法可以不同，建议采用卡方检验来决定采用哪种分类方法。连续型变量可以用WOE变化方法来简化模型，但降低了模型的可解释性。
 
8 .变量选择
 
数据分析过程中会面对成百上千的变量，一般情况下只有少数变量同目标变量有关，有助于提高预测精度。通常建模分析时，有意义的变量不会超过10-15个，称他们为强相关变量(聪明变量)。可以利用变量过滤器的方法来选择变量。常见的变量过滤器应用场景如下。
 
一般IV值大于0.3代表变量的预测力较强，可以采用。
 
三 、数据分析过程
 
1. 向业务部门进行调研，了解业务需要解决的问题，将业务问题映射成数据分析工作和任务。
 
2.调研企业内外部数据，找到分析需要的数据，将数据汇聚到一个特定的区域，数据集市或数据仓库，探索性分析
 
3.数据清洗，包括检查数据的一致性，处理异常值和缺失值，删除重复数据等
 
4.数据转换，例如数据分箱(Binning)，将字符型变量转化为数字型变量，按照数据所需维度进行汇总
 
5.建立模型，按照业务需求建立不同模型(例如客户流失预警、欺诈检测、购物篮分析、营销响应等)
 
6.模型结果解释和评估，业务专家进行业务解释和结果评价
 
四 、大数据分析场景和模型应用
 
数据分析建模需要先明确业务需求，然后选择是描述型分析还是预测型分析。如果分析的目的是描述客户行为模式，就采用描述型数据分析，描述型分析就考虑关联规则、序列规则、聚类等模型。
 
预测型数据分析就是量化未来一段时间内，某个事件的发生概率。有两大预测分析模型，分类预测和回归预测。常见的分类预测模型中，目标变量通常都是二元分类变量例如欺诈与否，流失与否，信用好坏等。回归预测模型中，目标变量通常都是连续型变量，常见的有股票价格预测、违约损失率预测(LGD)等。
 
生存分析聚焦于将事件的结果和出现这一结果所经历的时间进行分析，源于医疗领域，研究患者治疗后的存活时间。生存分析可也可以用于预测客户流失时间，客户下次购买时间，客户违约时间，客户提前偿还贷款时间，客户下次访问网站时间等。
 
常见的数据分析应用场景如下：
 
1 .市场营销
 
营销响应分析建模(逻辑回归，决策树)
 
净提升度分析建模(关联规则)
 
客户保有分析建模(卡普兰梅尔分析，神经网络)
 
购物蓝分析(关联分析Apriori)
 
自动推荐系统(协同过滤推荐，基于内容推荐，基于人口统计推荐，基于知识推荐，组合推荐，关联规则)
 
客户细分(聚类)
 
流失预测(逻辑回归)
 
2 .风险管理
 
客户信用风险评分(SVM，决策树，神经网络)
 
市场风险评分建模(逻辑回归和决策树)
 
运营风险评分建模(SVM)
 
欺诈检测(决策树，聚类，社交网络)
 
五、数据模型评价的方法
 
 
数据建模
 
1AUC值判别法
 
AUC小于0.7识别能力很弱
 
AUC在0.7-0.8之间识别能力可接受
 
AUC在0.8-0.9之间识别能力卓越
 
AUC大于0.9模型出现意外
 
2KS判别法
 
KS值大于0.2就表示具有较好的可预测性
 
PS：网舟科技长期专注于金融保险、通信、航空、互联网、旅游酒店等行业的电子渠道大数据运营，为客户提供全球领先的电子渠道转型咨询、大数据挖掘和应用定制服务，助力客户互联网转型，提升数字化运营和数据营销能力。