数据仓库架构和建设方法_数据库建设项目中的数据架构

1.3.3.数据仓库组成

• 多种多样的数据源
• 数据抽取、转换、导入（ETL）
• 操作型的数据和分析型的数据
• 主题模型
• 数据集市
• 报表、查询、EIS工具(主管信息系统---服务于组织的高层经理的一类特殊的信息系统能够迅速、方便、直观（用图形）地提供综合信息)
• OLAP工具
• 数据挖掘工具
• 元数据
• 数据质量管理
• 数据标准化
• 信息发布

1.3.4.数据仓库进化阶段

1.3.5.数据仓库建设特征要素

• 数据仓库项目不是技术主导型项目，是一个大的集成项目，更注重方法和流程
• 数据仓库项目需要持续的建设
• 数据仓库项目需要持续的持续的成熟评估和改进的建议
• 不同阶段的实施方法需要技术和业务紧密结合的组织架构的支撑
• 数据仓库项目需要坚持不懈的推动业务的参与
• 数据仓库这种长周期大型项目需要建立有效的管理机制

1.4.数据仓库与其它数据管理系统的区别

1.4.1.数据仓库和数据库的区别

    数据仓库和数据库的不同：数据库是面向应用的、事务型的数据处理，一般来说具有实时性较高，数据检索量较小，只存储当前数据，访问频率高，要求的响应时间短，面对多为普通用户，且数量较大的特点。而数据仓库主要是面向主题的、分析型的数据处理，具有实时性要求不高，数据检索量较大，存储大量历史数据和当前数据，访问频率中低，响应时间较长，主要针对特殊用户群体，用户量较小的特点。其中事务型和分析型处理数据是有区别的：

• 事物型处理数据一般来说对性能要求较为严格，数据是事务驱动的，主要面向应用，存储的一般都是即时性、细节性的数据，数据是可更新的。
• 分析型处理数据一般来说对查询性能要求较高，数据是分析驱动的，主要面向决策分析，存储的一般都是历史、汇总性的数据，数据一般不会更新。

1.4.2.数据仓库与ODS区别

1、ODS定义

     ODS是这样一种数据存储系统，它将来自不同数据源的数据（各种操作型数据库、外部数据源等）通过ETL过程汇聚整合成面向主题的、集成的、可更新的、当前或接近当前的、企业全局一致的数据集合（主要是最新的或者最近的细节数据以及可能需要的汇总数据），用于满足企业准实时的OLAP操作和企业全局的OLTP操作，并为数据仓库提供集成后的数据，将数据仓库系统中的ETL过程下沉到ODS中完成以减轻数据仓库的压力。

2、ODS特点

• 面向主题的---进入ODS的数据是来源于各个操作型数据库以及其他外部数据源，数据进入ODS前必须经过 ETL过程；
• 集成的---ODS的数据来源于各个操作型数据库，同时也会在数据清理加工后进行一定程度的综合；
• 可更新的---可以联机修改。这一点区别于数据仓库；
• 当前或接近当前的---“当前”是指数据在存取时刻是最新的，“接近当前”是指存取的数据是最近一段时间得到的。

3、ODS与DW的区别

    ①存放的数据内容不同：ODS中主要存放当前或接近当前的数据、细节数据，可以进行联机更新。DW中主要存放细节数据和历史数据，以及各种程度的综合数据，不能进行联机更新。ODS中也可以存放综合数据，但只在需要的时候生成。
    ②数据规模不同：由于存放的数据内容不同，因此DW的数据规模远远超过ODS。
    ③技术支持不同：ODS需要支持面向记录的联机更新，并随时保证其数据与数据源中的数据一致。DW则需要支持ETL技术和数据快速存取技术等。
    ④面向的需求不同：ODS主要面向两个需求：一是用于满足企业进行全局应用的需要，即企业级的OLTP和即时的OLAP；二是向数据仓库提供一致的数据环境用于数据抽取。DW主要用于高层战略决策，供挖掘分析使用。
    ⑤使用者不同：ODS主要使用者是企业中层管理人员，他们使用ODS进行企业日常管理和控制。DW主要使用者是企业高层和数据分析人员。

4、ODS在数据仓库建设中的作用

    大型数据仓库的建设中一般采用三层体系结构，如下图：

     ODS和DW面向不同的用户，为不同的需求产生，因此都有不可替代的作用，两者相互结合、相互补充。ODS在三层体系结构中扮演着承上启下的作用：

•  一方面ODS在原来独立的各个DB的基础上建立了一个一致的、企业全局的、面向主题的数据环境，使原有的DB系统得到改造。
• 另一方面ODS使DW卸去了数据集成、结构转换等一系列负担，对DW的数据追加通过ODS完成，大大简化的DW的数据传输接口和DW管理数据的复杂度
• ODS系统的建设，弥补了DB~DW两层体系结构的不足，但是ODS并不是必需的，当企业并不需要操作型集成信息时，基于DB~DW两层体系结构是较优的，如果需要，那么DB~ODS~DW三层体系结构则是较优的。

1.4.3.数据仓库与数据集市

1、数据集市定义

   数据集市是一组特定的、针对某个主题域、某个部门或者某些特殊用户而进行分类的数据集合，也可以说是小型的数据仓库。

2、数据仓库与数据集市的区别

    数据仓库是企业级的，能为整个企业各个部门的运行提供决策支持手段；而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据,因此是部门级的，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。

2.数据仓库架构

2.1.数据设计方法

    数据仓库建立之前，就必须考虑其实现方法，通常有自顶向下、自底向上和两者结合进行的这样三种实现方案。

2.1.1.自顶向下实现

    自顶向下的实现需要在项目开始时完成更多计划和设计工作，这就需要涉及参与数据仓库实现的每个工作组、部门或业务线中的人员。要使用的数据源、安全性、数据结构、数据质量、数据标准和整个数据模型的有关决策一般需要在真正的实现开始之前就完成。

2.1.2.自底向上实现

    自底向上的实现包含数据仓库的规划和设计，无需等待安置好更大业务范围的数据仓库设计。这并不意味着不会开发更大业务范围的数据仓库设计；随着初始数据仓库实现的扩展，将逐渐增加对它的构建。现在，该方法得到了比自顶向下方法更广泛的接受，因为数据仓库的直接结果可以实现，并可以用作扩展更大业务范围实现的证明。

2.1.3.两者结合的折中实现

    每种实现方法都有利弊。在许多情况下，最好的方法可能是某两种的组合。该方法的关键之一就是确定业务范围的架构需要用于支持集成的计划和设计的程度，因为数据仓库是用自底向上的方法进行构建。在使用自底向上或阶段性数据仓库项目模型来构建业务范围架构中的一系列数据集市时，您可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务。在这种方法中，可以把数据集市理解为整个数据仓库系统的逻辑子集，换句话说数据仓库就是一致化了的数据集市的集合。

2.2.数据仓库架构争论

    关于Inmon 和 Kimball的大辩论：Ralph Kimball 和 Bill Inmon 一直是商业智能领域中的革新者，开发并测试了新的技术和体系结构。在BI/DW领域中，围绕“哪一种数据仓库架构（Data Warehouse Architecture）最佳？”的争论一直没有休止，这个问题同时也是企业在建立DW时需要决策的关键问题：Bill Inmon的集线器架构/企业信息工厂架构（Hub and Spoke / CIF – Corporate Information Factory）与 Ralph Kimball的数据集市/数据仓库总线架构（Data Mart Bus Architecture/Data Warehouse Bus Architecture）则是DW架构的争论焦点。

• Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、非易变的、随时间变化的用于支持管理的决策过程的数据集合”；他通过“面向主题”表示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。 Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源和工作。下图是他的设计方法图解：
  
   
• Ralph Kimball 说“数据仓库仅仅是构成它的数据集市的联合”，他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。每个数据集市将联合多个数据源来满足特定的业务需求。通过使用“一致的”维，能够共同看到不同数据集市中的信息。Kimball 的数据仓库结构也就是著名的数据仓库总线(BUS)。设计方法如下图：
  

2.3.数据仓库架构选型

    数据仓库架构的选取，与其所处的企业环境和业务的发展有着密切的关系：Inmon提倡的数据仓库建设方法，需要数据仓库建设人员自顶向下进行建设，数据仓库开发人员需要在数据仓库建设之前对企业各业务线进行深入的调研，有着非常全面的了解，然后根据企业各业务特点进行主题域划分。这种建设方式建设周期比较长，规划设计比较复杂，但是一旦建成，这个集中式的体系结构将提供更强的一致性和灵活性，并且从长远来看将真正节省资源和工作；Kimball提倡的数据仓库仅仅是构成它的数据集市的联合，各部门或业务可以根据自身的发展，建设符合自身主题的数据集市，并持续丰富完善这些数据集市。在应对企业级数据需求时，将这些数据集市的维度信息进行统一整理规范，然后通过一致的维度信息，将这些数据集市连接起来，使数据集市形成一个覆盖企业所有部门或业务的数据仓库，对外提供服务。

    根据企业发展阶段和业务发展的速度建议：传统的、业务成熟的企业可以考虑采用Inmon方法建设数据仓库；业务复杂而且差异较大、发展速度又非常快的企业可以考虑Kimball方法建设数据仓库。 

2.4.企业发展中的数据仓库建设变迁

       企业或新部门，在初期发展过程中业务量少、组织形式相对简单。使得数仓建设人员可以站在全局的高度，俯视整个公司的业务流程，对其进行梳理归类，并抽取数据模型。以自上而下的方式建设数据仓库。所以在初期数据仓库建设的过程中基本采用了Inmon提倡的数据仓库建设方法，采用了DataSource-->ODS→EDW→DM-->APP的结构。即由ODS层完成各部门数据源的集成，在ODS的基础上建设了覆盖公司所有业务的包含众多主题的统一的数据仓库，然后由这个统一的数据仓库作为唯一的数据源，为各部门的数据集市提供数据支持。如下图：

        但是一旦企业或部门发展速度非常快，业务量急剧增大，而且业务的组织形式趋于复杂，不同的业务之间可能存在巨大的差距。数据仓库的建设如果再继续沿用自伤而下的方式就会带来很多困难，例如在Inmon模式下EDW规划复杂、建设周期长，不能非常快速的响应各部门的需求，所以该方案逐步不能适应公司的发展。为了适应企业的发展，经过数仓开发人员的不断探索尝试，基本上倾向于采用混合模式建设数据仓库，即采用Inmon+Kimball的变种模式，结构如下：

       从图上可以看出，与原有的架构最大的区别是：各部门数据集市的数据源并不是唯一的从EDW中获取，而是从各部门数据源所集成到的ODS层获取。但是有各部门数据集市也会涉及到跨部门的数据统计，所以这种公司级的数据应用还是从企业级数据仓库中获取。也就是各部门数据集市来支持各部门业务需求；企业级数据需求，从各部门数据集市或ODS层抽取公共模型进行建设（例如：公司级订单、用户等），并且在这里将各部门集市所依赖的公共维度进行统一，来支持公司级或跨部门的业务需求。

3.数据仓库建设中的数据建模

    数据模型是指实体、属性、实体之间的关系对业务概念和逻辑规则进行统一的定义，命名和编码，主要描述企业的信息需求和业务规则，是业务人员和开发人员沟通的语言，是数据仓库设计工作的第一步。

    首先我们需要解决三个问题：①什么是数据模型；②为什么需要数据模型；③如果创建数据模型；

3.1.什么是数据模型

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

    数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为以下几个层次：业务模型、领域模型（主题域模型）、逻辑模型、物理模型。因此整个数据仓库建模过程中，一般需要经历四个过程： 

• 业务建模：主要解决业务层面的分解和程序化；
• 领域（主题域）建模：主要是针对业务模型进行抽象处理，生成领域（主题域）概念模型；
• 逻辑建模：主要是将领域模型的概念实体以实体之间的关系进行数据库层次的逻辑化；
• 物理建模：主要解决逻辑模型的物理化以及性能等一些具体的技术问题。

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

3.2.为什么需要数据模型

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

• 简单的报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前段报表工具。
• 数据集市阶段：这个阶段主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需求，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
• 数据仓库阶段：这个阶段主要是按照一定的数据模型，对整个企业的数据进行采集整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对业务具有指导性的数据，同时为领导决策提供全面的数据支持。

    通过对数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。 一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：

• 进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者管理机构对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们业务部门的生产。
• 建设全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出部门之间的联系，帮助消灭各部门之间的信息孤岛的问题，更为重要的时，通过数据模型的建设，能够保证这个企业的数据一致性，各个部门之间数据的差异将会得到有效解决。
• 解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库的灵活性。
• 帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能偶很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快这个系统建设的速度。

3.3.如何创建数据模型

    下面是数据仓库模型阶段划分：

 从上图可以看出，数据仓库的数据建模大致分为四个阶段：

3.3.1.业务建模

    从定义上来说，业务模型是最高层次的数据模型，主要完成：

• 划分整个单位的业务，一般按照业务部分的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系；
• 深入了解各个业务部门的具体业务流程并将其程序化；
• 提出修改和改进业务部门工作流程的方法并程序化；
• 数据建模的范围界定，这个数据仓库项目的目标和阶段划分。

3.3.2.领域概念（主题域）建模

    主题域模型数据仓库的主要主题和重要业务之间的关系。一般来说，在进行数据仓库系统设计和开发之前，设计开发人员和业务人员通过前期的业务建模，已经对主题域的划分达成共识，因为主题域模型反映的是核心的业务问题。主题域模型设计步骤如下：

• 在业务建模的基础上提取重要的业务数据主题，包括对业务数据主题的详细解释；
• 在业务数据主题的基础上进行数据主题域的划分，包括对数据主题域的详细解释；
• 划分主题域概念模型：根据数据主题域的划分，细化内部的组织结构和业务关系。

     主题域建模的流程大致可以划分成如下几个部分：在前一个阶段业务建模的过程中，已经对业务系统进行数据的梳理。根据各业务的特点列出数据主题详细的清单，并对每个数据主题都作出详细的解释，然后经过归纳、分类，整理成各个数据主题域，列出每个数据主题域包含哪些部分，并对每个数据主题域作出详细解释，最后划分成主题域概念模型。

3.3.3.逻辑建模

    从定义上讲，逻辑模型是以概念模型为基础，对概念模型的进一步细化、分解。逻辑模型通过实体和实体之间的关系描述业务的需求和系统实现的技术领域，是业务需求人员和技术人员沟通的桥梁和平台。    逻辑模型的设计是数据仓库实施中最重要的一步，因为他直接反应了业务部门的实际需求和业务规则，同时对物理模型的设计和实现具有指导作用。他的特点就是通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规则。    概念模型的主题域一般是从企业现有的信息系统和行业自身业务活动汇总的来的业务模型主题域。而逻辑模型除了在概念模型的基础上丰富和细化主题域，并且确定每个主题域包含哪些主题外，还需要：

• 分析需求，列出需求分析的主题，需求目标、维度指标、维度层次、分析的指标、分析的方法、数据的来源、关注的对象等。
• 选择用户感兴趣的数据，通过业务需求将需要分析的指标分离抽取出来，转化成逻辑模型需要的实体。
• 在实体中需要增加时间戳属性，因为实体中需要保存哥哥阶段的历史数据。通常情况下，如果实体为同一编码，则不需要增加时间戳属性。
• 需要考虑粒度层次的划分。数据仓库的粒度层次划分直接影响了数据仓库模型的设计，通常细粒度的数据模型直接从企业模型选取实体作为逻辑模型的实体，而粗粒度的数据模型需要经过汇总计算得到相应的实体。粒度决定了企业数据仓库的实现方式、性能、灵活性和数据仓库的数据量。
• 在粒度层次划分的基础上，还需要进行关系模式的定义，形成各个实体、实体属性、实体之间的关系等内容。同时在逻辑模型框架的基础上对实体的中英文名称、属性、属性的值域进行明确、完善和细化，真实反映业务逻辑关系和业务规则。

3.3.4.物理建模

     在逻辑模型的基础上，为应用生产环境选取一个合适的物理结构的过程，包括合适的存储结构和存储方法，称作物理模型的设计过程。逻辑模型转变为物理模型包括以下几个步骤：

• 实体名（Entity）变为表名（table）
• 属性名（attribute）转换为列明（column），确定列的属性（Property）
• 物理模型必须对列的属性进行明确的定义，包括：列名、数据类型
• 物理模型确定后，还可以进一步确定数据存放位置和存储空间的分配。

3.4.数据仓库建模方法

3.4.1.实体建模法

    实体建模并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

     虽然实体建模看起来好像有些抽象，其实理解起来很容易。即我们可以将任何一个业务划分成3个部分，实体，事件和说明。

    上图表述的是一个抽象的含义，如果描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述成一个业务过程，在这里可以抽象为一个具体“事件”，而“开车去”怎可以看成事件“上学”的一个说明。

    从上面列举的例子可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成3个部分：

• 实体：指领域建模中特定的概念主题，指发生业务关系的对象；
• 事件：指概念主体之间完成一次业务流程的过程，指特定的业务过程；
• 说明：主要是针对实体和事件的特殊说明。

    由于实体建模法，能够很轻松的实现业务建模的划分。因此，在业务建模阶段和领域建模阶段，实体建模方法有着广泛的应用。一般在没有现成的行业建模的情况下，可以采用实体建模的方法，和客户一起清理整个业务的模型，进行领域概念的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。

    但是，实体建模也有着自己先天的缺陷，由于实体说明法只是一种抽象客观事件的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

3.4.2.范式建模法

     范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由inmon所提倡，主要解决关系型数据库中数据存储，利用的一种技术层面上的方法。目前，在关系型数据库中的建模方法，大部分采用的是三范式建模法。

    范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第三范式进行无损分解，这个过程也可以称为规范化。在数据仓库的模型设计中目前一般采用第三范式，他有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件：

• 每个属性值唯一，不具有多义性；
• 每个非主属性必须完全依赖于整个主键，而非主键的一部分；
• 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。 

    根据Inmon的观点，数据仓库模型的建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例化。

  从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍稍有一些不同，主要区别在于：

• 数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各个域模型定义。数据仓库的域模型的概念应该比业务系统的主题域模型规范更加广。
• 在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。

    范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也很明显，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足响应的需求。

3.4.3.维度建模法

    维度建模是kimball最先提出的。其最简单的描述就是：按照事实表，维表来构建数据仓库、数据集市。这种方法最被人广泛知晓的名字就是星型建模。

     上图就是这个架构中最典型的星型架构。星型模式之所以被广泛使用，在于针对各个维做了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对3NF的建模方法，星型模式在性能上占据明显的优势。

     同时，维度建模法的另外一个优势是：维度建模非常直观，仅仅围绕着业务模型，可以直观的反应出业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。

     但是维度建模的缺点也非常明显，由于在构建星星模型之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理的过程中，往往会导致大量的数据冗余。

     另外一个维度建模的缺点是：如果只是单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

4.维度建模

4.1.维度建模技术

      维度建模是DW/BI系统的核心，他是ETL系统的目标、数据库的结构、支持用户查询和制作报表的模型。建模要实现3个主要设计目标，分别是：能尽可能简洁的向用户展示需要的信息；能尽快返回查询结果给用户；能提供相关信息，以便精确的跟踪潜在的业务过程。

      维度建模能使任何事情尽可能简单，但绝不是简化。在数据仓库和商业智能中，维度模型是给用户显示信息的首选结构，其比典型的原系统规范化模型更便于用户理解。维度建模中表更少，信息分组为对用户有意义的、一致的业务类别。这些类别称为维度，有助于用户浏览模型，因为可以忽略与特定分析无关的全部类别。但是尽可能简洁并不意味着模型一定简单。模型必须反映业务，而业务通常都比较复杂，如果简化的过多，一般来说只表示了聚合数据，模型就会丢失对理解业务非常重要的信息。无论如何进行数据建模，数据内容在的复杂性都使大多数人最终愿意通过结构化报表和分析应用程序来访问DW和BI系统。

       维度建模能提供更好的查询性能，因为在创建维度时采用了反规范化的方法，通过预先连接各种层次结构和查询表，优化程序考虑的连接路径较少，创建的中间临时表更少。

       为了精确跟踪潜在的业务过程，需要采用各种设计模式，以创建出精确捕获和跟踪业务模型。维度模型由一个或者多个中心事实表和与其相关的维度构成。事实表位于中心，而维度环绕在其周围，类似于星型结构，因此又把维度模型成为星型模型。

4.1.1.事实表

      事实表是维度模型的基本表，存放有大量的业务性能度量值。应力图将从一个业务处理过程得到的度量值数据存放在单个数据中心。由于度量值数据压倒性的成为任何数据中心的最大部分，因此应该避免在企业范围内的不同地方存储其拷贝。用术语“事实”代表一个业务度量值。例如：商品销售记录每个商店每种产品的销售数量和销售额。在各维度值（日期、产品和商店）的交叉点就可以得到一个度量值。维度值的列表给出了一个事实表的粒度定义，并确定出度量值的取值范围是什么。

      事实表的设计中要解决几个重要问题：

• 粒度（记录事实的细节级）：事实表中包含信息的详细程度称为粒度。强烈建议以原始来源中可能的最小细节级别构建事实表--通常称为原子级别。原子事实表提供了完整的灵活性，数据可以累积到现在或将来任何维度需要的任何聚合级别。每个事实表必须只有一种粒度。例如，如果在同一事实表中包含每月预测项和单独的销售订单项，就很容易引起混淆并产生危险。
• 相加性：事实的可加性是至关重要的，因为数据仓库应用几乎从不仅仅只检索事实表的单行数据。相反，往往一次性带回数百、数千乃至数百万行的事实，并且处理这么多行的最有用的事就是将它们加起来。但是有些事实是半加性质的，而另外一些是不可加性质的。半加性事实仅仅沿某些维度相加，而非加性事实根本就不能相加。对于非加性事实，如果希望对其进行总结就不得不使用计数或平均数，或者降为一次一行的打印出全部事实行。对这长达数十亿行的事实表来说，将是一个迟缓而乏味的工作。
• 文本度量值：度量事实在理论上可以是文本形式的，文本度量可以是某种事物的描述。但是设计者应该尽量将文本度量转换成维度，原因在于维度能够与其他文本维度属性更有效关联起来，并且消耗少的多的空间。不能将冗余的文本信息存放在事实表内。除非文本对于事实表的每行来说都是唯一的，负责他应该归属到维度表中。真正的文本事实在数据仓库中很少出现，因为文本事实具有像自由文本内容那样不可预见性，这几乎是不可能进行分析的。
• 键选择：多维数据建模中的键选择是一个难题。它包含性能和易于管理之间的权衡（trade-off）。键选择主要适用于维度。您为维度所选择的键必须是事实的外键。维度键有两种选择：您可以分配一个任意键，或者使用操作系统中的标识符。任意键通常只是一个序列号，当需要一个新键时，就分配下一个可用的号码。【为了使用操作系统中的标识符惟一地表示维度，您有时需要使用一个复合键。复合键就是由多个列组成的键。任意键是一列，通常比操作派生的键要小。因此，任意键通常可以更快地执行连接。】【键选择中的最后一个因素就是它对事实表的影响。在创建事实时，必须将每个维度的键分配给它。如果维度将带有时间戳的操作派生的键用于历史数据，那么在创建事实时，就没有附加工作。连接将自动发生。对于任意键或任意历史标识符，在创建事实时，就必须将一个键分配给事实。】【分配键的方式有两种。一种就是维护操作和数据仓库的键的转换表。另一种就是存储操作键，并且在必要时，存储时间戳作为维度上的属性数据。】【那么，选择就在任意键的更好性能和操作键的更易维护之间进行。性能提高多少和维护增加多少的问题就必须在您自己的组织中进行评估了。】【无论做出什么选择，都必须在元数据中用文档记录生成它们的过程。该信息对于管理和维护数据仓库的技术人员来说是必要的。如果您所使用的工具没有隐藏连接处理，那么用户可能也需要理解这一点。】
• 一致性事实：如果某些度量出现在不同的事实表中，需要注意，如果需要比较或计算不同事实表中的事实，应保证针对事实的技术定义是相同的。如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名，如果它们不兼容，则应该有不同的命名用于告诫业务用户。

    事实表的分类：事务事实表、周期快照事实表、积累快照事实表。

• 事务事实表：一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类健壮的维度确保对事务数据的最大划分片和分块。事务事实表可以是稠密的，也可以是稀疏的，因为仅当存在度量时才会建立行。这些事实表总是包含一个与维度表关联的外键，也可能包含精确的时间戳和退化维度建。度量数字事实必须与事务粒度保持一致。
• 周期性快照事实表：事实表中的每行汇总了发生在某一标准周期，如某天、某月。粒度是周期性的，而不是个体的事务。周期快照事实表通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的，因为即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或空值的行。
• 积累快照事实表：事实表汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程具有定义的开始点，标准中间过程，定义的结束点，他们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。积累快照事实表中的一行，对应某一具体的订单，当订单产生时会插入一行。当管道过程发生时，积累事实表行被访问并修改。这种对积累快照事实表行的一致性修改在三种类型事实表中具有特性，除了日期外键与每个关键过程步骤关联外，积累快照事实表包含其他维度和可选退化维度的外键。通常包含数字化的与粒度保持一致的，符合里程碑完成计数的滞后性度量。

4.1.2.维度表

      维度表包含有业务的文字描述。在一个设计合理的维度模型中，维度表有许多列或者属性，这些属性给出对维度表的行所进行的描述。维度表倾向于将列数做的特别大，每个维度用单一的主关键字进行定义，主关键字是确保同与之相连的任何事实表之间存在应用完整性的基础。

      维度属性是查询约束条件、成组与报表标签生成的基本来源。例如，一个用户要按照“星期”和“商标”来查看销售额，那么“星期”与“商标”就必须是可用的维度属性。数据仓库的能力直接与维度属性的质量和深度成正比。在提供详细的业务用语属性方面所化的时间越多，数据仓库就越好。在属性列值的给定方面所花的时间越多，数据仓库就越好。在保证属性列值的质量方面所花的时间越多，数据仓库就越好。

     最好的属性是文本的和离散的。属性应该是真正的文字而不应是一些编码简写符号。例如：对于产品来说，典型的属性应该包括一个短描述、一个长描述、一个商标名、一个分类名、包装类型、尺寸以及大量其他产品特征等方面的内容。

    维度表时常描述业务中的层次关系。例如：产品划分为商标、然后是分类。产品维度的每行都存放有与产品有关的商标和分类。但是存放层次描述信息显得很冗余， 不过也是基于容易使用和查询性能方面的考虑才这样做的。不要受仅仅存储商标编码并为其建立一个单独的商标查询表的固有想法所限制，这种形式可以称为雪花。维度表一般是很不规范的，通常也非常小。既然维度表一般都很小，通过规范化或者雪花来提高存储效率的做法也起不了大作用，所以实际应用中，几乎总是用维度表的空间来换取简明性和可访问性。

    还需要了解：退化维度、多层次维度、非规范化扁平维度、雪花维度。OLAP对维度的划分有：强制维度、普通维度、衍生维度、层次维度。

    需要掌握：一致性维度集成、缓慢变化维处理、层次维度处理

4.1.3.事实与维度的融合

    由数字型度量值组成的事实表连接到一组填满描述属性的维度表上。这个星型特征结构通常被叫做星型连接方案。关于维度方案，应该注意第一件事就是其简明性与对称性。简明性是指用户可以很容易的理解和浏览数据；简明性也提升了性能上的好处，仓库在处理时首先对维度表进行过滤处理，然后用满足用户约束条件的维度表关键字的笛卡尔乘积一次性处理全部的事实表。

     维度表模型能够很自然的进行扩展以适应变化的需求。维度模型的可预订框架能够经受住无法预见的用户行为变化所带来的考验。每个维度都是平等的，所有维度都是进入事实表的对等入口。每个逻辑模型不存在内置的关于某种期望的查询形式方面的偏向，不存在这个月要问的业务问题相对于下个月来说具有优化方面的考虑。没有谁希望，如果业务用户采用新的方式进行业务分析，就要调整设计方案这样的事情发生。维度模型的事实与维度表如下：

 在设计过程中，最佳粒度或者原子数据具有最佳的维度。被聚合起来的原子数据是最有表现力的数据。原子数据应该成为每个事实表设计的基础。从而经受住业务用户无法预见的查询所引起的特别攻击。对于维度模型来说，完全可以向方案中加入新的维度，只要其值对于每个现有的事实行存在唯一性定义就行。同样，可以向事实表加入新的不曾预料到的事实，只要其详细程度与现有事实表处在一致的水平面上就可以了。可以用新的不曾预料到的属性补充先前存在的维度表，也可以从某个前向时间点的角度在一个更低的粒度层面上对现存维度进行分解。在每种情况下，可以简单的在表中加入新的数据行或者对现在表进行适当的修改。

     认识事实与维度表之间互补性的另外一种方式是在所形成的报表中了解他们。如上图，维度属性提供了生成报表标签的内容，而事实表则提供了报表的数字型取值。

     最后就像已经强调的那样，展示环节的数据应该是维度形式的。不过，维度模型与规范化模型之间存在着一种自然的关系。理解这种关系的关键在于认识到，单个规范化ER图通常分解为多个维度方案。为机构建立的大型规范化模型可以将电话销售、订购单、装货发票、顾客付款、产品利润等内容全部放在一个图中。在某种程度上讲，规范化ER图对自身就是一种伤害，原因在于他将许多从来就不会出现在单个数据集中的多个业务处理放在了单张绘制图中。可见，规范化模型看起来很复杂，是不足为奇的。

    如果有一张已经存在的规范化ER图，将它转换为一组维度模型的第一步是，将ER图分成一些分散的业务处理过程，然后分别单独建模。第二步是选出ER图中那些含有数字型与可加性非关键字事实的多对多关系，并将他们标记为事实表。最后一步是，将剩下的所有表复合成具有直接连接到事实表的单连关键字的平面表，这些表就成为维度表。

4.2.维度建模过程

   维度建模具有一定顺序，分别是：①业务处理②粒度③维度④事实。

4.2.1.选取业务处理

    业务处理过程是机构中进行的一般都是有源系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。在选取业务阶段，数据模型设计者需要有全局和发展的视角，应该理解整体业务流程的基础上，从全局角度选取业务处理。

    要记住的重要一点是，这里谈到的业务处理并不是指业务部门或者职能。通过将注意力集中放在业务处理过程方面，就能在机构范围内更加经济的提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性的发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理和磁盘存储方面的负担。

4.2.2.定义粒度

    粒度定义意味着对各事实表行，实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。他给出了后面这个问题的答案“如何描述事实表的单个行？”

    粒度定义是不容轻视的至关重要的步骤。在定义粒度时应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子性数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。通过在最低层面上装配数据，大多原子粒度在具有多个前段的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切的知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。

    原子型数据可为分析方面提供最大程度的灵活性，因为他可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型细节性数据是稳如泰山的，并随时准备接受业务用户的特殊攻击。

    当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。聚集概要性数据作为调整的一种手段起着非常重要的作用，但他绝不能作为用户存取最底层面细节内容的替代品。遗憾的是，有些权威人士在这方面一直含糊不清，他们宣称维度模型只适合于总结性数据，并批判那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢的消失。

4.2.3.选定维度

    维度所引出的问题是：“业务人员将如何描述从业务处理过程得到的数据？”。应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见的例子包括：日期、产品、客户、账户和机构等。

4.2.4.确定事实

    他是设计过程的第四步也是最后一步，在于仔细确定那些事实要在事实表中出现。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。通常可以从以下三个角度来建立事实表：

• 针对某个特定的行为动作，建立一个以行为活动最小单元为粒度的事实表。最小活动单元的定义，依赖于分析业务需求。比如用户的一次网页点击行为、一次网站登录行为，一次电话通话记录。这种事实表，主要用于从多个维度统计，行为的发生情况，主要用于业务分布情况，绩效考核比较等方面的数据分析。
• 针对某个实体对象在当前时间上的状况。我们通过对这个实体对象在不同阶段存储他的快照，比如用户的余额、用户拥有的产品数等。通过这种可以统计实体在不同生命周期中的关键数量指标。
• 针对业务活动中的重要分析和跟踪对象，统计在整个企业不同业务活动中的发生情况。比如会员，可以执行或参与多个特定的行为活动。这种事实表是以上两种事实表的一个总计和归纳。它主要用于针对我们业务中的活动对象进行跟踪和考察。

4.3.数仓在维度建模层次划分

    经过长时间的探索，在物理建模这个过程中一般会进行层次划分，分别是：基础事实、轻度汇总层、集市宽表层。    

 

1. 基础事实层（detail）：基础层的数据粒度比较细，通常与ods层的粒度相似，只是在ods数据的基础上做了清洗、规范化和为了方便分析而作的一些整合，有可能需要结合维度表。
2. 轻度汇总层（aggr）：汇总层是根据各集市的数据需求，抽象出比较通用的数据，对明细层按照一些统计偏向（例如：口径、业务方向）进行汇总得到。
3. 集市款表层（topic）：集市宽表主要是在轻度汇总层的基础之上创建，由于轻度汇总层的数据有所偏向，所以按照这些事实表的粒度和公共维度，通过更高等级的视图将它们整合起来
4. 维度表：包括直接从业务方同步的维度表、根据事实表整理成的维度表以及直接生成的维度表等。

5.数据仓库一般架构