【维度建模】【第一章】维度建模简介

1. 维度建模的简介

　　维度模型通常不要求必须满足数据库的3NF，规范化的3NF对与数据仓库来说过于复杂，用户难以理解、检索。但维度模型包含的信息和3NF模型包含的信息基本一致，但为了查询性能的通常刻意不满足三范式。

　　1.3.1 星型模型与OLAP

　　关系数据库中实现的维度模型称为星型模型，其又一个事实表与多个维度表所构成，形状类似一个星。

  

 　　多维数据库中实现维度模型通常称为OLAP（online analytical processing）数据类似一个立方体，拥有多个维度。

              

　　

　　1.3.2用于度量的事实表

　　维度模型中的事实表存储企业业务过程时间的性能度量(通常是一个可累加的数字类型的值，例如次数，个数，金额）

　　维度建模核心原则之一，是同一个事实表中的所有度量必须具有相同的粒度。

　　事实表的粒度一般可以分为三类：事务、周期性快照、累积快照。

　　

　　1.3.3用于描述环境的维度表

　　维度表包含与业务度量时间有关的文本环境。它们用于描述“谁，什么，哪里，何时，如何，为什么”有关的事件，通常不满足第三范式

　　维度表通过有多列(包含多个属性)，且一般包括较少的行。

　　定义维度属性值的注意事项：

• 应该包含真实使用的词汇，避免使用令人疑惑的缩写或代码。
• 避免一个字段包含多重含义，例如code=0034，其中00代表业务类别，34代表国家。应尽可能的拆分信息到最小的粒度

　　如何区分一个数值型是事实属性还是维度属性

• 事实属性：分析该列是否是一种包含多个值或作为计算的参与者的度量，这种一般是事实属性。
• 维度属性：该列是对一个具体值的描述，一个常量、某一约束此时该属性一般是维度属性。

　　一般对维度表存储空间的权衡往往需要关注简单性和可访问性。

　　

　　1.3.4星型模型中维度与事实的连接

　　数据模型的简单性可以代码查询性能上的提升

　

　　1.4KimBall DW架构　　

      

　　核心元素：

• 数据源：
• ETL系统：
  • 通过增强和数据交换，采用清洗和整合上述任务的方法，增加数据的利用价值。
  • 另外还可以建立诊断元数据，逐步建立业务过程再工程以改进数据源的数据质量。
  • 通过元数据、发布报表、参数化查询应用告诉下游有哪些数据可用。
• 展示区：
  • 以维度模型展示数据
  • 包含最细粒度的原子数据，以满足用户无法预期的、不断变化、随意的查询 
  • 展示区的数据可以围绕业务过程度量事件来构建，这样可以自然的切分数据源，维度模型应该对应物理数据获取事件。
  • 必须使用公共的，一致性的维度建立维度结构。

　　

　　1.5其他的DW架构

　　1.5.1独立数据集市架构

　　分析性的数据以部门的级别进行部署，不需要考虑企业级的信息共享和集成。与kimball的dw架构的区别是，数据可能重复处理，然后由于部门的业务规则和标识不同，最终的数值可能没有几个能匹配的。

　　

　　1.5.2辐射状企业信息工厂Inmon架构

　　数据从数据源获取后经过ETL后的原子数据最终存放在符合第三范式的数据库中。这种规范化的、原子数据的仓库被称为CIF架构下的EDW（Enterprise Data Warehouse）

　　

　　1.5.3混合辐射架构

　　该架构利用了CIF架构中的EDW，但是此处的EDW完全与分析和报表用户隔离，它近作为kimball风格的展示区的数据来源，其中数据是有维度的，原子的，以过程为中心的，与企业数据仓库总线结构保持一致。

　　结构简述为：source --ETL--> edw(规范化，3NF) --ETL--> 展示区 -->BI系统

 

　　1.6数据建模的误解

• 维度模型不仅仅包含汇总的数据，由于不能预测用户提出的所有问题，因此需要保存最细粒度的数据。部分汇总的数据也只是针对公共查询时能提供一个更好的性能，并不能取代细节数据。

　　1.7使用维度建模的更多理由