维度建模（一）

维度建模简介

一、维度建模

• 维度建模是分析数据的首选技术，主要基于以下两方面：
  • 以商业用户可理解的方式发布数据
  • 提供高效的查询性能
• 3NF
  • 3NF主要用于减少数据冗余，会将数据化分成多个不同的实体，每个实体构成一张关系表
  • 3NF业界又称 实体-关系 模型，实体-关系图（ER图或ERD）表示了表间的相互关系
  • ERD既可以用于描述3NF模型，也可以用于描述维度模型，因为二者都包含可连接的表关系
  • 不可以将ER模型简单的归为3NF模型，3NF模型可称为 规范化模型
  • 主要用于操作型过程，对于分析型过程来说太过复杂
• 维度建模特点：
  • 不要求必须满足3NF
  • 包含的信息与3NF相同
  • 以一种用户可理解的，利于查询、灵活多变的方式对3NF进行包装
• 三种模型及区别

  • 概念模型：真实世界中对问题域内的事物的描述，不是对软件设计的描述

    • 常用 实体-关系 图来表示
    • E-R图主要由实体、属性、关系三个要素构成
    • 此时可以没有属性，只包含实体和关系的描述

  • 逻辑模型：是对概念模型的进一步分解和细化，描述概念模型需要的具体信息和功能

    • 需要对实体的属性进行补全

  • 物理模型：对真实数据库的描述，即表、字段、数据类型、长度、主键、外键、索引、是否可为空、默认值等

    • 实体对应表，属性对应字段，关系对应主外键关联

  • 三者区别：

对象	概念模型	逻辑模型	物理模型
实体	实体	实体	表
属性	属性（不需要完整定义实体属性）	属性（需要完整定义实体属性）	字段（定义字段的字段名、数据类型、长度、可否为空、默认值等）
关系	一对一、一对多、多对一	关系	外键
关系	一对多、多对一	实体	关系表
关系	多对多	实体	关系表
主键	无需确定主键	无需确定主键	需确定主键

1.1 星型模式与OLAP多维数据库

• 关系型数据库实现的维度模型由于结构类似星型结构，被称为星型模式，由一张事实表关联多张维度表
• 多维数据库实现的维度模型通常称为联机分析处理（OLAP）数据库，采用索引和预聚合实现高查询性能
• 星型模式和多维数据库在维度上有公共的逻辑设计，但在物理实现上存在差异
• 星型模式通常是OLAP数据的良好物理基础，也是备份与恢复的良好基础

1.2 事实表

• 存储业务过程可度量的事件记录，“事实”表示某个业务度量
• 每行对应一个事件，每行数据的细节级别称为粒度
• 维度建模的原则之一，同一张事实表中所有度量必须有相同的粒度，物理世界的每一个度量事件与表中一行存在一对一的关系
• 度量事实数据量巨大，不应将他们为不同组织存储到多个位置，而是让不同组织的用户访问同一批数据，保证数据的一致性
• 可加性：数值类型是最实用的可加类事实，完全可加事实（销售金额、销售件数）、半可加事实（账户余额不能按时间累加）、不可加事实（单价价格、比率完全不可累加，可分解为可加的组件实现聚合）
• 可以使用文本记录度量，但是很少采用，通常用来表示某事件的描述，设计时应尽量将其抽象为维度
• 粒度分类：事务、周期快照、累积快照
• 事实表存有多个外键与维度表关联，所有外键与维度表的主键能够正确匹配时，满足参照完整性
• 主键称为组合键，为所有外键的集合

1.3 维度表

• 也称查找表，保存维度的属性值，与事实表关联确定事件的维度属性

• 用来描述 “谁、什么、何处、何时、如何、为什么”

• 通常含有多列用来描述属性，属性应是实际使用的词汇而非代码或缩写

• 用单一主键与事实表进行关联，实现参照完整性

• 对于某些有业务意义的操作码，可将其按不同属性拆分为多个维度属性，而非强制让用户使用码值进行判断过滤

• 对于一个数字量到底是度量还是维度，需要根据所处业务环境判断。通常连续的数值一般可认为是度量，来自不大表的离散数字一般可认为是维度

• 维度表通常不需要满足3NF规范化，可以存在层级数据（如商品品牌、分类）的冗余，以便于查询

• 如果将维度表设计为符合规范化的形式，由事实表通过维度表关联另一张维度表获取维度属性，则为雪花模式

1.4 事实表与维度表的连接

• 星型模型：一张事实表记录度量值，通过外键与多个维度表关联获取维度属性
• 雪花模型：一张事实表，多张维度表，且维度表存在多层，即事实表通过维度表去关联其他维度表
• 星座模型：多张事实表公用某些维度表

二、Kimball的DW/BI架构

• 操作型原系统：数据源
• ETL
  1. 数据从操作型系统导入到数据仓库环境
  2. 数据清洗：消除拼写错误、解决领域冲突、处理错误元素、解析为标准格式；合并来自不同系统的数据；建立诊断元数据
  3. 实际加载数据到展示区域的维度模型
• 支持商业智能决策的展现区：用于组织、存储数据，支持用户、报表制作及其他分析型商业智能应用（BI）的查询
  1. 采用维度建模存储数据，围绕业务过程度量事件构建
  2. 包含原子的、强聚集性能的、最细粒度的数据
  3. 使用公共的、一致的维度建立维度结构
• 商业（BI）应用：简单的查询应用、数据挖掘或建模应用

三、其他DW/BI架构

3.1 独立数据集市架构

• 数据以部门为基础来部署，主要解决部门内部需求，不需要考虑企业级的信息共享和集成
• 不同部门即使对同一数据源感兴趣，由于部门业务的差异，存在不同的业务规则和标识，集市数据几乎是不可复用的

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

• 数据获取：数据从操作型系统获取，在ETL系统处理
• 处理后的原子数据存储在满足3NF规范化的企业数据仓库中（EDW），与Kimball架构不同，EDW强制使用3NF规范化模型
• Inmon架构也包含维度结构，但分析数据库通常以部门为中心，且包含聚集数据