自己对数据建模理解

       维度建模是数据仓库建设中的一种数据建模方法，将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文，Kimball 最先提出这一概念

Kimball数据仓库的另一位开拓者。提倡多维模型

优点：容易快速建立，快速得到投资回报，灵活

缺点：不利于维护，产生冗余，有些数据集市不容易集成

维度建模一种逻辑设计技术，该技术试图采用某种直观的标准框架结构来表现数据，并且允许高性能存取。维度模型是用来设计向最终用户交付的数据库的一种快速交付技术

维度建模与实体-关系建模有很大的区别，实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术，适合数据库。维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术，适合数据仓库。

第三范式就是指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。

维度建模是面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型

描述：按照事实表，维度表来构建数据仓库，数据集市。

每个模型捕获事实数据表中的事实，以及那些事实在链接到事实数据表的维度表中的特性。由这些排列产生的架构称为星型模式或雪花模式。

用于维度表和事实表的连接

建模优势(优点)

       维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。

维度建模是可预测的标准框架。允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件，这些数据主要在表现和性能方面起作用。

星型连接模式的可预测框架能够忍受不可预知的用户行为变化。

具有非常好的可扩展性，以便容纳不可预知的新数据源和新的设计决策。可以很方便在不改变模型粒度情况下，增加新的分析维度和事实，不需要重载数据，也不需要为了适应新的改变而重新编码。较好的扩展性意味着以前的所有应用都可以继续运行，并不会产生不同的结果。

缺点

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

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

建模原则

1. 载入详细的原子数据到维度结构中

维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。

1. 围绕业务流程构建维度模型

业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。

1. 确保每个事实表都有一个与之关联的日期维度表

原则2中描述的可测量事件总有一个日期戳信息，每个事实表至少都有一个外键，关联到一个日期维度表，它的粒度就是一天，使用日历属性和非标准的关于测量事件日期的特性，如财务月和公司假日指示符，有时一个事实表中有多个日期外键

维度模型设计的方法

      

维度模型设计流程图 

维度分类

缓慢变化维

在现实世界中,维度的属性并不是静态的,它会随着时间的流失发生缓慢的变化.代理关键字可以用来处理缓慢变化维.

       类型一、

       字段值发生变化时覆盖原来的值。 

       类型2、

字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期 ，版本号，是否当前值。

类型3

每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。

还有一个混合类型：就是把上面三种混合用

一致性维度

一致性维度的范围是总线架构中的维度,即可能会在多个数据集市中都存在的维度.在后台建立好的维度同步复制到各个数据集市,这样所有数据集市的这部分维度都是完全相同的.建立新的数据集市时,需要在后台进行一致性维度处理,根据情况来决定是否新增和修改一致性维度,然后同步复制到各个数据集市.这是不同数据集市维度保持一致的要点.

在同一个集市内,一致性维度的意思是两个维度如果有关系,要么就是完全一样的,要么就是一个维度在数学意义上是另一个维度的子集.例如建立月维度的话,月维度的各种描述必须与日期维度中的完全一致.

维度保持一致后,事实就可以保存在各个数据集市中.虽然在物理上是独立的,但在逻辑上由一致性维度使所有的数据集市是联系在一起,随时可以进行交叉探察等操作,也就组成了数据仓库.

退化维度

一般都是事务的编号,如订单编号、发票编号等.这类编号需要保存到事实表中,但是不需要对应的维度表.退化维度经常会和其他一些维度一起组合成事实表的主键,在分析中可以用来做分组使用.

渐变维度

大多数维度值是随着时间改变的,有必要记录维度的历史变化信息.渐变维（SCD）是一种在多维数据仓库中实现维度历史的技术,有三种不同的SCD技术.

(1) SCD1:通过更新维度记录直接覆盖已存在的值,它不维护记录的历史.一般用于修改错误的数据. 

(2) SCD2:在源数据发生变化时,给维度记录建立一个新的"版本"记录,从而维护维度历史.SCD2不删除、修改已存在的数据. 

(3) SCD3:通常用作保持维度记录的几个版本.它通过给某个数据单元增加多个列来维护历史.SCD3可以有效维护有限的历史,而不像SCD2那样保存全部历史.SCD3 很少使用,只适用于数据的存储空间不足并且用户接受有限维度历史的情况.

 

星型模型：星形模式(Star Schema)是最常用的维度建模方式.星型模式是以事实表为中心,所有的维度表直接连接在事实表上,像星星一样.

       星形模式的维度建模由一个事实表和一组维表成

       特点：

       维表只和事实表关联,维表之间没有关联;

       每个维表主键为单列,且该主键放置在事实表中,作为两边连接的外键;

雪花模型：雪花模式的维度表可以拥有其他维度表的,使用的是规范化数据,减少了数据冗余.由于这种模型维护成本比较高,而且性能方面需要关联多层维表,性能也比星型模型要低.

星座模式: 星座模式是星型模式延伸而来,星型模式是基于一张事实表的,而星座模式是基于多张事实表的,而且共享维度信息.

前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到.在业务发展后期,绝大部分维度建模都采用的是星座模式.

维度建模的主要是4个主要决策：

1、选择业务过程

业务过程是通常表示的是业务执行的活动，与之相关的维度描述和每个业务过程事件关联的描述性环境。

通常由某个操作型系统支持，例如：订单系统。

业务过程建立或获取关键性能度量。

一系列过程产生一系列事实表。

2、声明粒度

粒度传递的是与事实表度量有关的细节级别。

精确定义某个事实表的每一行表示什么。

对事实表的粒度要达成共识。

3、确认维度

健壮的维度集合来粉饰事实表。

维度表示承担每个度量环境中所有可能的单值描述符。

4、确认事实

不同粒度的事实必须放在不同的事实表中。

事实表的设计完全依赖物理活动，不受最终报表的影响。

事实表通过外健关联与之相关的维度。

查询操作主要是基于事实表开展计算和聚合。

其中粒度是非常重要的，粒度用于确定事实表的行表示什么，建议从关注原子级别的粒度数据开始设计，因为原子粒度能够承受无法预估的用户查询，而且原子数据可以以各种可能的方式进行上卷，而一旦选择了高粒度，则无法满足用户下钻细节的需求。

事实是整个维度建模的核心，其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展，生成一份能够支撑可预知查询需求的模型宽表，而且最后的查询也是落在事实表中进行。

注意：

1.维度表的唯一主键应该是代理健而不是来自系统的标示符，也就是所谓的自然健，因为自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，而代理健可以提高关联效率并将关系数据库设计和业务的解耦。

2.维度表和事实表关联的每个连接应该基于无含义的整数代理健。

3.固定深度层次在维度表中应该扁平化，规范化的雪花模型不利于多属性浏览，而且大量的表和连接操作会影响性能。

4.非完全独立的维度应该合并为一个维度，将同一层次的元素标示为事实表中不同维度是错误的，会增加查询和存储负担，最后变成蜈蚣表，例如：日维度、周维度、月维度等可以合并为一个周期维度。

在讨论维度建模之前，关注数仓和BI的基本目标是非常有意义的，在做日常的数据需求的时候，经常会遇到如下几个痛点：

收集了海量数据，不知道如何去做ETL；

不同来源的数据该如何去聚合；

如何方便业务人员快速方便的获取数据；

如何定义重要的数据指标；

如何确保数据准确性；

数据如何支持决策；

基于上面的痛点，就需要搭建一套DW/BI系统（当然现在市面上有很多类似的产品，例如：如：QuickBI、GrowingIO、神策、猛犸等等），但是对于公司而言，适合自己的才是最好的，大部分公司选择自己搭建或者利用开源的软件（例如MateBase），这个系统必须满足：

DW/BI系统能够方便的存储信息（或者说能跟现在主流的数据库打通）。也就是说系统展现的内容必须是容易理解的，对于业务人员必须直观而且好操作，数据结构和标示必须符合业务思维过程和词汇，用户能够以各种形式切割和分析数据，同时能够快速的将查询结果反馈。

DW/BI系统必须以一致性的形式展现信息（指标的唯一性）。也就是说数据必须是可信的，同一指标定义在不同的数据源中，所含的意义必须相同，既同名同意性。

DW/BI系统能够适应变化（模块的低耦合）。当用户需求、业务维度需要调整的调整的时候，设计的DW模型必须能够兼容这些变化，已经存在数据和指标不应该被破坏或修改，就算一些指标的调整，也要以适当的方式描述变化，并对用户完全透明。

DW/BI系统必须保证数据安全（数据安全）。能展示的数据必须是统计的结果数据，一些详单展现和下载必须和平台的权限系统挂钩，避免数据泄漏。

DW/BI系统成功的标示是业务群体接收并使用，而且必须配套一个展现模块的监控系统，能够让产品方知道各个模块的使用情况，对一些访问量比较少的模块可以适当的调整和优化。