数据建模

一 数据仓库的概要

1 数据仓库的起因

在建设数据仓库之前，数据散落在企业各部门应用的数据存储中，它们之间有着复杂的业务连接关系，从整体上看就如一张巨大的蜘蛛网:结构上错综复杂，却又四通八达。在企业级数据应用上单一业务使用方便，且灵活多变;但涉及到跨业务、多部门联合应用就会存在:

1数据来源多样化，管理决策数据过于分散;

2数据缺乏标准，难以整合;

3数据口径不统一，可信度低;

4缺乏数据管控体系，数据质量难以保证。

如果企业在数据建设方面没有一个整体的规划，而采取自然演化的方式，那么在未来数据应用的过程中，将不得不面对以下问题:

1数据缺乏可信性:缺乏统一的维度;数据算法上存在差异;抽取的多层次;外部数据问题;无起始的公共数据源;
2 生产率低:需要根据全部数据生成企业报表;定位数据需要浏览大量文件;抽取程序很多，并且每个都是定制的，不得不克服很多技术上的障碍。
3 数据转化为信息的不可行性:数据没有集成化;缺乏将数据转化为信息所需的历史数据。

基于以上这些的问题，就产生了建立企业级数据仓库的必要性。

2 数据仓库的定义

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的(随着时间流逝发生变化)的数据集合。它主要支持企业管理人员决策分析。
数据仓库收集了企业相关的内部和外部各个业务系统数据源、归档文件等一系列历史数据，最后转化成企业需要的战略决策信息。

3 数据仓库的特点

• 面向主题的:普通的操作型数据库主要面向事务性处理，而数据仓库中的所有数据一般按照主题进行划分。主题是对业务数据的一种抽象 ，是从较高层次上对信息系统中的数据进行归纳和整理。面向主题的数据可以划分成两部分—-根据原系统业务数据的特点进行主题的抽取 和确定每个主题所包含的数据内容。例如客户主题、产品主题、财务主题等;而客户主题包括客户基本信息、客户信用信息、客户资源信 息等内容。分析数据仓库主题的时候，一般方法是先确定几个基本的主题，然后再将范围扩大，最后再逐步求精
• 集成性:面向操作型的数据库通常是异构的、并且相互独立，所以无法对信息进行概括和反映信息的本质。而数据仓库中的数据是经过数 据的抽取、清洗、切换、加载得到的，所以为了保证数据不存在二义性，必须对数据进行编码统一和必要的汇总，以保证数据仓库内数据 的一致性。数据仓库在经历数据集成阶段后，使数据仓库中的数据都遵守统一的编码规则，并且消除许多冗余数据。
• 稳定性:数据仓库中的数据反映的都是一段历史时期的数据内容，它的主要操作是查询、分析而不进行一般意义上的更新(数据集成前的 操作型数据库主要完成数据的增加、修改、删除、查询)，一旦某个数据进入到数据仓库后，一般情况下数据会被长期保留，当超过规定 的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析，一般不进行任何修改操作，是为了企业高层人员决策分析之用。
• 反映历史变化:数据仓库不断从操作型数据库或其他数据源获取变化的数据，从而分析和预测需要的历史数据，所以一般数据仓库中数据 表的键码(维度)都含有时间键，以表明数据的历史时期信息，然后不断增加新的数据内容。通过这些历史信息可以对企业的发展历程和 趋势做出分析和预测。数据仓库的建设需要大量的业务数据作为积累，并将这些宝贵的历史信息经过加工、整理，最后提供给决策分析人 员，这是数据仓库建设的根本目的。

4 数据仓库的优势

• 数据整合后信息流简化
• 共享数据利用率提高
• 数据集中管理，来源唯一
• 形成业务单一视图，数据标准化
• 数据管控体系，数据质量得以保证

5 数据仓库的组成

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

6 数据仓库发展阶段

7 数据仓库建设特征要素

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

8 数据仓库与其他数据管理系统的区别

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

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

9 数据仓库与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和DW面向不同的用户，为不同的需求产生，因此都有不可替代的作用，两者相互结合、相互补充。ODS在三层体系结构中扮演着承上启下 的作用:

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

10 数据仓库与数据集市

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

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

二 数据仓库架构

1 数据设计方法

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

2 自顶向下的实现

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

3 自底向上的实现

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

4 两者结合的折中方案

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

5 数据仓库架构争论

​ 关于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)。设计方法如下图:

Bill Inmon: 就是集中式的体系结构 (3NF-EDW) 主要使用范式建模
		通过范式模型构建一个符合三范式的集中式的数据中心EDW层，此层次的表一般不对BI和应用开放，而是基于DW的数据构建数据集市DM层来对外服务，DM层的数据一般也采用范式建模，不过随着对分析决策的需求，融入了维度建模的思想
Ralph Kimbal: 就是著名的数据仓库总线(BUS)结构

6 数据仓库架构选型

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

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

7 仓库变迁的例子

​ 如某著名互联网公司初期数据仓库建设的过程中基本采用了Inmon提倡的数据仓库建设方法，采用了DataSource–>ODS→EDW→DM(数据集市,主题域数据)的结构。即由ODS层完成各部门数据源的集成，在ODS的基础上建设了覆盖公司所有业务的包含众多主题的统一的数据仓库，然后由这个统一的数据仓库作为唯一的数据 源，为各部门的数据集市提供数据支持.如下图:

datasource -->  ods --> edw --> dm --> app/rpt

采用上面方案的建设背景是,公司业务形式上单一,规划建设比较容易,而且数据组希望建设一个标准的数据仓库,但公司各个部门发展速度较快,业务变化快,Inmon模式下的EDW规划复杂,建设周期长,不能快速响应各个部门的需求,所以该方案不能适应公司的发展,从而采用了kimball的变种模式,如下:

datasource --> ods --1> edw (edw<-->dm)  --> app
									 --2> dm (edw<-->dm) --> qpp

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

三 数据仓库建设中的数据建模

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

首先我们需要解决三个问题:1什么是数据模型;2为什么需要数据模型;3如果创建数据模型

1 什么是数据模型

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

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

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

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

2 为什么需要数据模型

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

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

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

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

3 如何创建数据模型

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

业务建模 --> 领域概念(主题域)建模 --> 逻辑建模 --> 物理建模

1 业务建模

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

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

2 领域概念(主题域)建模

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

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

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

3 逻辑建模

从定义上讲，逻辑模型是以概念模型为基础，对概念模型的进一步细化、分解。逻辑模型通过实体和实体之间的关系描述业务的需求和系统实现的技术领域，是业务需求人员和技术人员沟通的桥梁和平台。

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

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

4 物理建模

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

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

4 数据仓库建模方法

1 实体建模法

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

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

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

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

• 实体:指领域建模中特定的概念主题，指发生业务关系的对象;

• 事件:指概念主体之间完成一次业务流程的过程，指特定的业务过程;

• 说明:主要是针对实体和事件的特殊说明。

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

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

2 范式建模法

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

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

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

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

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

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

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

3 维度建模法

维度建模是kimball最先提出的。其最简单的描述就是:按照事实表，维表来构建数据仓库、数据集市。这种方法最被人广泛知晓的名字就是星型建 模。(其余的还有雪花模型,星座模型,宽表模型)

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

优点

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

缺点

1: 由于在构建星星模型之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化
，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些预处理的过程中，往往会导致大量的数据冗余。
2: 如果只是单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模
的方法。**第二点存疑**

四 维度建模

1 维度建模技术

​ 维度建模是DW/BI系统的核心，他是ETL系统的目标、数据库的结构、支持用户查询和制作报表的模型。建模要实现3个主要设计目标，分别是:

• 能尽可能简洁的向用户展示需要的信息;

• 能尽快返回查询结果给用户;

• 能提供相关信息，以便精确的跟踪潜在的业务过程。

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

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

为了精确跟踪潜在的业务过程，需要采用各种设计模式，以创建出精确捕获和跟踪业务模型。维度模型由一个或者多个中心事实表和与其相关的维度构成。

2 维度建模的几种模式

1 星型模型

以事实表为中⼼，所有的维度表直接连在事实表上，最简单最常⽤的⼀种
星形模式的维度建模由⼀个事实表和⼀组维表成，且具有以下特点：
	a. 维表只和事实表关联，维表之间没有关联；
	b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
	c. 以事实表为核⼼，维表围绕核⼼呈星形分布；

2 雪花模型

雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的(就是对星型的维表进行规范化处理进一步分解到附加维表中)，虽然这种模型相⽐星型更规范⼀些，但是由于这种模型不太容易理解，维护成本⽐较⾼，⽽且性能⽅⾯需要关联多层维表，性能也⽐星型模型要低。所以⼀般不是很常⽤。

对维表规范化的常用方法:  把低基数的属性从维度表中移除并形成单独的表。
如主键列具有唯⼀值，所以有最⾼的基数，⽽像性别这样的列基数就很低。

在雪花模式中，⼀个维度被规范化成多个关联的维度表，⽽在星型模式中，
每⼀个维度由⼀个单⼀的维度表所表⽰。⼀个规范化的维度对应⼀组具有层次关系的维度表，
⽽事实表作为雪花模式的⼦表，存在具有层次关系的多个⽗表。

3 星座模型(常用)

基于多张事实表，⽽且共享维度信息，即事实表之间可以共享某些维度表

数据仓库由多个主题构成，包含多个事实表，
⽽维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因⽽称作星系模式或者事实星座模式。
事实星座模式是数据仓库最长使⽤的数据模式，尤其是企业级数据仓库（EDW）。
这也是数据仓库区别于数据集市的⼀个典型的特征，
从根本上⽽⾔，数据仓库数据模型的模式更多是为了避免冗余和数据复⽤，套⽤现成的模式，
是设计数据仓库最合理的选择。在业务发展后期，绝⼤部分维度建模都采⽤的是星座模式。

4 宽表建模

​ 目的的在于方便后续使用，减少关联等操作，可直接用于数据分析、报表下钻等。宽表会尽量满足多维，多度量，在技术上也会使用退化维度（提前将维度冗余到表中，减少关联，考虑缓慢变化维的影响，也叫渐变维度）等操作。

比较点	维度建模	宽表
扩展性	维度表变更，事实表可能不影响	维度变更可能导致很多宽表都要调整
耦合度	事实表和维度表解藕，某些粒度上不会因为维度表失败而影响聚合表的产出	一个非重要任务失败会导致整个宽表无法产出
组织方式	任务及工作流易组织	因高耦合导致任务之间盘根错节，不利于组织任务和工作流
数据一致性	企业级数据仓库总线架构的基石	底层如果没有维度建模支撑，容易陷入混乱
易用性	维表需要多几个维表关联	宽表一时爽,维护hzc

鉴于以上的一些考量，在数仓层我们依然可以选择采用标准的维度建模的方式——星座模型。而宽表则可以存在于更靠后的数据集市层(dm)

3 事实表

一个客户把一个商品放入了购物车中 描述了一个业务的过程

那么，这一条数据，就是描述了这一个事实。这个认识对初学者来说还挺普遍的。但这个认识其实是错误的，在数据仓库领域中，事实这个术语，指的是数字型的度量。还是以一个客户把一个商品放入购物车中这么一条数据来举例，在这一条数据中，一定包含了以下信息：
1、商品种类
2、商品名称
3、商品单价
4、商品数量
商品种类与商品名称不是事实是维度，而商品单价与商品数量是事实。

事实是指数据中的数字型度量

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

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

可加型事实，半可加型事实，不可加型事实

可加型事实，指的是在所有维度加起来都有意义的数字型度量。
半可加型事实，指的是在特定维度下加起来有意义，另一些维度下加起来无意义的数字型度量。
不可加型事实，是指在所有维度下，加起来都没有意义的数字型度量。
如一下指标:
	1、订单用户id
	2、订单用户vip等级
	3、订单总额
	4、用户账户余额
订单总额是典型的可加型事实，在所有维度都可以进行统计。例如，直接对所有数据的订单总额相加，就是历史累计订单总额，如果对地区金额进行相加，就是各地区的历史订单总额，如果对当日的订单总额统计，加起来的就是当日订单金额。在所有维度下，相加都是有意义的。

用户账户余额是典型的半可加型事实，只有在用户维度下相加，得出的所有用户余额总额这个数字是有意义的，其他维度下相加是没有意义的。

vip等级是典型的不可加型事实，任何维度下，对vip等级的相加，结果都是没有意义的数字。

事实表的分类

事务事实表

​ 一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类健壮的维度确保对事务数据 的最大划分片和分块。事务事实表可以是稠密的，也可以是稀疏的，因为仅当存在度量时才会建立行。这些事实表总是包含一个与维度表 关联的外键，也可能包含精确的时间戳和退化维度建。度量数字事实必须与事务粒度保持一致。

周期性快照事实表

​ 事实表中的每行汇总了发生在某一标准周期，如某天、某月。粒度是周期性的，而不是个体的事务。周期快照事实表 通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的，因为即使周期内没有 活动发生，也会在事实表中为每个事实插入包含0或空值的行。

积累快照事实表

​ 事实表汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程具有定义的开始点，标准中间过 程，定义的结束点，他们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。积累快照事实表中的一 行，对应某一具体的订单，当订单产生时会插入一行。当管道过程发生时，积累事实表行被访问并修改。这种对积累快照事实表行的一致 性修改在三种类型事实表中具有特性，除了日期外键与每个关键过程步骤关联外，积累快照事实表包含其他维度和可选退化维度的外键。 通常包含数字化的与粒度保持一致的，符合里程碑完成计数的滞后性度量。

总结:
	事务事实表 明细表
	周期性快照事实表 周期性的聚合表(月,周,活动日期范围)
	累计快照事实表 时间累计聚合事实表

实际在数仓建设中,尽管这三种类型普遍存在于我们的数据仓库内，但由于用户并不容易理解三种事实表类型的划分方式，因此按照明细表和聚合表的方式分层,更容易让用户找到需要的表。

4 维度表

维度是看待事实的角度。

如一个下单数据

时间维度,地域维度,商品分类维度,品牌维度,消费区间维度,是否首次下单维度,......只要想，可以在一条数据上扩充出非常多的维度。且维度还可以自由组合如 某月内地域下的消费区间维度,......

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

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

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

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

还需要了解:退化维度、多层次维度、非规范化扁平维度、雪花维度。OLAP对维度的划分有:强制维度、普通维度、衍生维度、层次维度。 需要掌握:一致性维度集成、缓慢变化维处理、层次维度处理

强制维度(kylin)、普通维度、衍生维度(kylin)、层次维度
强制维度: 用户有时会对某一个或几个维度特别感兴趣，所有的查询请求中都存在group by这个维度，那么这个维度就被称为强制维度
普通维度:
衍生维度:

1 退化维度

将维度退化到事实表中，减少事实表和维度表的关联,这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

因为事实表主键的成员一般都是维度值所组成,但退化维度虽然也属于主键值,但没有单独的维度表,所以叫退化维度。

维度退化在事实表中有利于使用，一般一个维度键都有对应的维表，如果退化在事实表中，可以减少关联次数，并且退化维可以用于group by操作，进行分组统计。

2 缓慢变化维SCD

​ 缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。

处理缓慢变化维的方法通常分为三种方式：

​ 第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。

​ 第二种方式是添加维度行(拉链表)。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。

​ 第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。如用户城市(cur_city,old_city)

3 层次维度以及处理

对于层级确定的: 可以用层次扁平化()(不定的预留层级,扩展性不高)
层级不定的: 桥接表(父id,子id,类目层级间隔) 类目维表 事实表

​ 维度属性之间的关系就引出了维度层次。维度往往存在层次关系,维度中的一些描述属性以层次方式或多对一的方式相互关联，可以理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。，维度中常常有这样的嵌入式层次结构。

​ 递归层次指的是某维度的实例值的层次关系。按照层级是否固定分为均衡层次结构和非均衡层次结构。其中具有固定数量级别的递归层次，称为均衡层次结构；数量级别不固定的递归层次称为非均衡层次结构

1 固定深度位置的层次
固定深度层次是一系列的多对一关系，如产品→品牌→类别→部门，对于商品而言，每个部门会有多个类别，每个类别又会有多个品牌，每个品牌下又会有多个产品。当固定层次定义完成后，层次类别就有了商定的名称，层级级别应作为不同的位置属性存在维表中，如产品→品牌→类别→部门，应有4个字段来分别对应层次的每一级别，而不是将该层次存储成一个字段。
与其他技术相比，固定层次关系是最好理解和导航（navigate）的层次关系，同时它也能提供快速且可预测的查询性能。如果层次关系不是多对一的关系，或者层次级别各不相同以致没有固定的商定名称，那么需要使用一下的不定层次技术
2 轻微参差不齐 / 可变深度层次
轻微参差不齐的层次虽然没有固定的层级级别，但深度的变化范围很小，如地理层次深度通常都在3~6层。对于这种情况而言，与其使用复杂的处理不可预测的可变层次的技术，不妨将其转换为固定深度的设计，同时用维度属性来确定最大的级别数，然后基于规则填充属性值。回填是填充属性的一种常用方式，他将属性向下虚拟，如二级、三级为空，则用一级属性值对二三级进行填充。阿里巴巴大数据之路(p181)对此进行了详细的案例介绍。
3 具有层次桥接表的参差不齐 / 可变深度层次
在数仓建模中，对于有层次关系的维度表，一种建模方式是建立父子表，该方式建表在层次深度可变时尤其有用，是一种紧凑而有效的建模方式。但是该方法也有缺点：在关系型数据库中，不定深度的层次很难建模和查询，用标准SQL很难对递归结构进行操作。尽管SQL扩展和OLAP访问语言对递归的父/子关系提供了一些支持，但是这种方式也很有局限性。
采用SQL扩展，在查询时，不能替换不同的参差不齐层次，不支持对自身层次结构的共享，同时也不支持随时间变化的参差不齐层次.
以上这些问题在关系型数据库中都可以通过对可变层次建立桥接表来解决。桥接表对可变层次中每一种可能的路径都保留一行，使得采用标准SQL就能完成对所有层次的遍历，而不需要其他语言扩展。

4 具有路径字符属性的可变深度层次
	可以在维度中采用路径字符属性，以避免使用桥接表示可变深度层次。对维度中的每行，路径字符属性包含特定的嵌入文本字符，包含从层次最高点道特定唯独行所描述节点的完整路径描述。
	多层标准层次分析需求可以通过标准SQL处理，不必采用SQL语言扩展。然而，路径字符方法不能确保其他层次的快速替换，也无法保证共享自身层次。路径字符方法也难于构建可变路径层次的变化，可能需要重新标记整个层次。

1、2都属于层次扁平化的方式对有层次结构的维度做处理，是最简单且最常用的处理层次关系的方式。桥接表的优点很明显：在做统计分析时，不同于扁平化的层次结构，它需要预知层级、也不需要回填，适合解决更宽泛的分析问题。但是他的缺点也同样明显，复杂性高，使用成本高，对用户不友好

实例: 阿里巴巴大数据之路中提到过商品类目,它是个不定层次的维度,以商品类目为例,对其进行层次扁平化及桥接表的加工：

1 层次扁平化

在大数据之路的介绍中，将类目表扁平化后，拥有5个层级；为了将问题简化，我们略去四级和五级类目
类目表的维度包含：类目ID、类目名称、类目层次、一级类目ID、一级类目名称、二级类目ID、二级类目名称、三级类目ID、三级类目名称、是否叶子类目
数据如表所示：

类目ID	类目级别	是否叶子节点	一级类目	二级类目	三级类目
21	1	N	21	–	–
121456022	2	Y	21	121456022	–
50026576	2	N	21	50026576	–
50026579	3	N	21	50026579	50026579
…	…	…	…	…	…

假设我们当前要统计类目ID为21的最近一天GMV，可以将淘宝交易事实表通过叶子类目和类目ID关联后，限制一级类目ID= 21后进行统计分析,该做法会有3个问题：

1）针对某类目进行上钻/下钻前，必须知道其所属的类目层级，然后才能决定限制哪一级类目

2）假设分三级类目统计最近一天的GMV，由于某些叶子类目直接是一级类目或二级类目，和交易事实表关联后，其对应的三级类目为空，导致根据三级类目统计最近一天的GMV时，类目ID = 121456022无法统计到；

解决方式：回填。下游数据统计时，为了规避此问题，如果此类目对应的三级类目为空，则取二级类目，二级仍为空时，取一级类目

类目ID	类目级别	是否叶子节点	一级类目	二级类目	三级类目
21	1	N	21	21	21
121456022	2	Y	21	121456022	121456022
50026576	2	N	21	50026576	50026576
50026579	3	N	21	50026579	50026579
…	…	…	…	…	…

3）扁平化仅包含固定数量的级别，非均衡层次结构层级不定
解决方式：对于非均衡层次结构，可以通过预留级别的方式来解决，但扩展性较差

2 桥接表(重要)

以上三个问题都可以通过桥接表来解决，他不需要预先知道所属层级，不需要回填，也可以解决非均衡层次结构的问题。

类目桥接表如下表所示，它对可变层次中每一种可能的路径都保留一行

父类目ID	子类目ID	类目层级间隔
21	21	0
21	121456022	1
21	50026576	1
21	50026579	2
50026576	50026576	0
50026576	50026579	1
121456022	121456022	0

我们可通过桥接表连接事实表和维表，从而对数据进行分析，具体操作如下
不妨约定下列简写：类目表 - t1; 类目桥接表 - t2; 交易事实表 - t3；

a.下钻操作：假设针对类目21进行下钻操作，步骤如下:
1）限制 类目表的类目ID = 21，通过类目ID与类目桥接表的父类目ID关联，使两表建立连接 (t1.类目ID = t2.父类目ID)
2）再通过类目桥接表的子类目ID与交易事实表的类目ID关联，使两表建立连接 (t3.类目ID = t2.子类目ID)
此时，就可以针对订单事实进行下钻操作

b.上钻操作：假设针对类目50026579进行上钻操作，步骤如下:

1）限制 类目表的类目ID =50026579，通过类目ID与类目桥接表的子类目ID关联，使两表建立连接 (t1.类目ID = t2.子类目ID)
2）再通过类目桥接表的子类目ID与交易事实表的类目ID关联，使两表建立连接 (t3.类目ID = t2.父类目ID)
此时，就可以针对订单事实进行上钻操作
从上面的例子可以看到层次桥接表解决了层次结构扁平化带来的一些问题，但是其加工逻辑复杂，使用逻辑复杂，而且由于事实表和桥接表的多对多关系而带来了双重计算的隐患。在实际应用中可以根据具体的业务需求来选择技术方案，比如在统计分析或报表中，一般都是按照固定级别进行，如按照一级类目统计GMV、按照省份统计GMV等，那么扁平化设计完全可以满足需求，而不必引入复杂的桥接表。很多时候，简单、直接的技术方案却是最好的技术方案。

桥接表的生成:

--方法一 union 对扁平化层次进行加工，将每层级的关系进行union，以层级最大=3为例
select
		父类目, 子类目, 类目层级间隔
from
(
		select  一级类目 as 父类目,  一级类目 as 子类目,  0 as 类目层级间隔  from 类目表  union all
		select  一级类目 as 父类目,  二级类目 as 子类目,  1 as 类目层级间隔  from 类目表  union all
		select  一级类目 as 父类目,  三级类目 as 子类目,  2 as 类目层级间隔  from 类目表  union all
		select  二级类目 as 父类目,  二级类目 as 子类目,  0 as 类目层级间隔  from 类目表  union all
		select  二级类目 as 父类目,  三级类目 as 子类目,  1 as 类目层级间隔  from 类目表  union all
		select  三级类目 as 父类目,  三级类目 as 子类目,  0 as 类目层级间隔  from 类目表
)t1
group by 父类目, 子类目, 类目层级间隔
;
--方法二 lateral view 的妙用 对于方法一,方式简单粗暴且直接，但是当层级很深时，方法一的代码就会变得巨长无比，假设有最深层次 = n，那么就需要将n*(n-1)段代码union起来，这个时候posexplode函数可以大大简化代码，只需要n段union在一起，看起来代码好像变长了，但是维护成本更低

select
	一级类目          as 父类目,
	leimu_list[pos]  as 子类目,
	pos              as 类目层级间隔
from
(
		select 
			split(concat_ws(',', 一级类目, 二级类目, 三级类目), ',')    as leimu_list
		from 类目表
)t1
lateral view posexplode(leimu_list)  t   as pos, leimu
group by 一级类目, leimu_list[pos], pos

union all

select
	二级类目          as 父类目,
	leimu_list[pos]  as 子类目,
	pos              as 类目层级间隔
from
(
		select 
			split(concat_ws(',', 二级类目, 三级类目), ',')    as leimu_list
		from 类目表
)t1
lateral view posexplode(leimu_list)  t   as pos, leimu
group by 二级类目, leimu_list[pos], pos

union all

select  三级类目 as 父类目,  三级类目 as 子类目,  0 as 类目层级间隔  from 类目表

4 一致性维度集成

​ 当不同的维度表的属性具有相同列名和领域内容时，称维度表具有⼀致性。利⽤⼀致性维度属性与每个事实表关联，可将来⾃不同事实表的信息集成到同⼀报表中。

5 雪花维度

（1）当维度表中的层次关系是规范的时，低粒度属性作为辅助表通过属性键连接到基本维度表，当这一个过程中包含多重维度层次时，建立的多级层级结构被称为雪花模式。
（2）雪花模式可以精确表示层次化的数据，但是会影响查询性能，应该避免使用雪花模式。
（3）扁平化的，非规范的维度表可以替代雪花模式精确的表示层次化的数据。

6 非规范化扁平维度

非规范化的多对一固定深度层次(类似商品->品牌->类别树状多对一关系)，将多层次维度打开为多个扁平的维度属性。以易用为主，不需要省空间而单独建层次的维度表。

5 事实表和维度表的融合

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

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

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

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

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

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

6 维度建模的过程

维度建模具有一定顺序，分别是:1业务处理2粒度3维度4事实。

1 业务处理

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

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

2 定义粒度

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

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

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

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

3 选定维度

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

4 确定事实

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

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

7 维度建模层次划分

​ 在物理建模这个过程中进行了层次划分，分别是:基础事实、轻度汇总层、集市宽表层。

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