03 维度建模的原则

星型模式的优势2

优化浏览




在数据库模式中，表与表连接的目的在于寻找 到需要的数据 如果连接的路径复杂，那么在数据库中浏览数 据将是缓慢而艰难的 如果连接路径简单、直接，则浏览数据会更快 星型模型的优势之一在于它优化对数据库的浏 览
时间
产品 缺陷
组件
供应商
问题
星型模式的优势3

最适于查询处理
实际销售价格 MSRP销售价格 零配件价格 全价 经销商附加部件 经销商信用 经销商发票 首付款数量 制造商收益 金额数量 模型名称 模型年份 部件风格 生产线 产品目录 外部颜色 内部颜色 第一个模型的年 份 时间维度表 付款方式维度表 客户人口统计维度表 经销商维度表
事实表 数据结构，From 信息包表
产品维度表（由属性组成） 数据结构，From 信息包表
从需求到数据设计

维度建模基础


我们已经通过信息包表构造了事实表和维度表。 问题：

这些表在维度模型中如何安排？ 它们在模型中的关系如何？ 如何标记这些关系？ 查询和分析有哪些类型？

通过多个维度表的维度属性，查询事实表中 的指标就是典型的查询与分析。

维度表的内容:维度表的集合是星型模式中的关键 部分

维度表键：唯一地确定表的每行 文本属性（很少有计算的数值数据）描述性的 信息。用户使用此描 述构造他们的查询。 非规范化：规范化意味着更多的表，为了高效 查询，查询最好直接从维度表中获得一个属性， 然后直接查询事实表
Customer Customer_Key Name Customer_ID Billing Address Billing City Billing State Billing ZIP Shipping Address
代理键的优势



保证源系统中的键的意外管理变化不会影响DW 允许DW整合多个源系统中具有不同键的相同数据 （Eg. 顾客） 允许在维度表中添加源系统不存在的行（Eg. DimTime表中的“日期未知”） 提供跟踪属性随事件变化的方法 与大型字符或GUID键相比，整型的代理键可提高查询 与处理性能 代价：ETL中的查找——代理键管道

事实表是数据仓库数据库中最大的表

所占存储空间：大于等于95% 关系事实表对应AS中的”度量组”
不含事实的事实表

一些业务过程没有任何实际度量的事件，如发生 事件，系统就添一项，否则，系统没有任何记 录。——事实表表示事件的时候

Example：需要用“1”表示出勤了么？No
日期维 学生维 教师维 教室维

Eg. 商店面积 、产品包装尺寸或重量
星型模式

事实表的内容与特点
事实表：键＋指标＋退化的维度
Order Measures
Product_key Order_date_key Salesperson_key Customer_key Order_Dollars Cost Margin_Dollars Quantity_Sold Order_number Order_Line

事实表主键的选择



Chapter Ten 维度建模的原则

Contents


从需求到数据设计 星型模式 星型模式的键 星型模式的优势
星型模式的表关系

从前面的讨论可以得出的结论
星型模式是一种关系模型，非规范化的 关系 维度表与事实表之间是1：N的关系


更复杂的模型： 维度表与维度表的多对多关系 维度表与事实表的多对多关系
星型模型的优势1

用户容易理解


OLTP用户使用预先定义好的UI或者查询语句与系统进 行交互，用户不需了解数据模型。 （OLTP中表的连接 关系可能要穿越规范化的N个表才能了解到表之间的关 系）。 OLAP是用户驱动的，用户必须清楚数据模型。 星型模型容易被用户理解，完全按照与用户相同的理 解关系的方式定义了连接路径。星型模型这种优势不 仅仅体现在后期使用、理解方面，在前期的开发阶段 也便于和用户进行交流。

雇员、 顾客、 产品 、商店


OLTP中，底层数据结构在设计是采用规范化技术，这 些方法将重复属性移至自身所属的表中，从而删除冗 余数据。 将业务对象的所有属性（包含层次结构）重新合并到 单个维度表中的操作称为反规范化。

反规范化包含规范化模型同样的信息与关系，没有丢失任何 信息，而表的复杂性降低了。
Chapter Ten 维度建模的原则
Chapter Ten 维度建模的原则

目标



理解需求定义如何影响数据设计 星型模式的基础知识 事实表与维度表中的内容 数据仓库中应用星型模式的优势
Chapter Ten 维度建模的原则

Contents


从需求到数据设计 星型模式 星型模式的键 星型模式的优势

例：查询2000年版本的Cherokee、在2001年1 月份由“ABC”经销商卖出的、客户已婚、并通 过建行提供三年贷款；符合以上条件的交易有 多少销售收益？

需要通过多个维度表中的属性分析所有这些事实。

一个查询中会用到每个商业维度表的部分或者 全部属性。
从需求到数据设计

维度建模基础 这些表在维度模型中如何安排？前提:
月份＝6
Salesperson Name Territory Name Region Name 销售代表＝Jenny
Chapter Ten 维度建模的原则

Contents


从需求到数据设计 星型模式 星型模式的键 星型模式的优势
维度表

维度是维度模型的基础，描述了参与业务的对象，每 个维度表联系着所有参与其中的业务过程。
•细长：表很长，但不宽，大量的记录 •键：所有维度表主键连接起来的组合键。 •稀疏的数据：事实表中可能会存在数据隔 断 退化的维度：数据元素既不是事实，也不是 维度，但对于分析有用。保留在事实表中。
事实的“可加和性” ——Sumable？


可加性非常重要，因为DW很少检索单个事实表记录 完全加和
从需求到数据设计

设计决策



选择处理过程：信息包表的主题 选择粒度：数据到底详细到什么程度？ 识别维度： 信息包表 选择事实 选择数据库的持久度：保存多旧的历史数据？
从需求到数据设计

维度建模基础


维度建模：将所需的商业维度合并到逻辑数据 模型中去。 信息报表是维度建模的基础：三类数据实体
Order Date
Date Month Quarter Year
Order Dollars Cost Margin Dollars Quantity Sold
Customer Name Customer Code Billing Address Shipping Address
Salesperson

指标或度量单位 商业维度 商业维度的属性

例:
维度
时间
年
信息主题：汽车制造商的销售
产品
模型名称 模型的年份 包装风格
付款方式
贷款类型
客户
年龄
经销商
名称 城市 州
层 季度 次 月 结 构 日
星期几 几号 季节 假日标志
条款（月） 性别 利息率 收入状况
产品线
产品分类 外表颜色 内部颜色 第一年
模型应该为数据访问提供最好的方式 解决方法： 这个模型必须以查询为中心 •将事实表放在中央，维度表安排在事实 表的四周能够满足这些要求。 它必须为查询和分析而接收优化 模型必须显示出事实表和维度表之间的相互作 •事实表位于星型中央，维度表分布在星 用 型的各个角上——星型模式 这个结构必须使每个维度都能有相等的机会与 事实表交互 模型应该允许沿着维度的层次结构下钻或上钻
课程维
日期键 课程键 教师键 学生键 教室键
跟踪学生出勤情况的事实表
粒度

事实表中包含信息的详细程度称为粒度。每个 事实表必须只有一种粒度。

最低粒度 事实表的基本层次是所有相应维度自然的最低层 次。

例：产品、日期、客户、销售代表为4个维度，则：事 实表中必须保存：单独的产品、特定的日期、特定的 销售代表和特定客户 一条记录

使用最低粒度的好处


可以频繁容易地从操作型系统抽取数据 很多数据挖掘需要最低层次 便于向下钻取 存储和维护的代价 实际处理中，我们构建汇总事实表来支持汇总数据查 询

使用最低粒度的缺点

Chapter Ten 维度建模的原则

Contents

从需求到数据设计 星型模式 星型模式的键 星型模式的优势

星型模型是一种以查询为中心的结构 简单、清洗的连接路径以及星星模型本身的结构使得 查询在维度表和事实表之间顺利、流畅、高效



具有上钻下钻的能力：local
多级层次结构：满足不同用户不同的钻取结构 （各部门的层次划分的不一致性）

大量的属性：维度表很宽
更少的记录：相对事实表而言，维度是描述、 限制和约束

维度属性应用的两种方式。它们经常出现 在查询或报表中的By语句。

约束目标 报表中行或列的标签
事实表
从需求到数据设计

需求的定义完全驱动着数据仓库的数据设计。

需求定义文档 信息包表包括：

商业指标 商业维度 维度内的层次结构

信息包表是数据仓库逻辑数据设计的基础

数据设计就是集中所有的数据结构

一个数据结构是由一组数据元素结合而成的。 逻辑数据设计包括： 决定多种需要的数据元素以及将这些元素组合成数据结构 数据结构之间建立关系

订单额 、利润

半可加和：由其他事实派生（Derive）或计算 （Compute）而得，如“平均单价”

ETL过程中计算，存在事实表中 存在事实表的视图定义中 包含在AS数据库的定义中 不可交给用户处理

不可加和
退化的维度——AS中的“事实维度”



Eg.在一次购买中，收银台赋予的一个事务ID 即不是事实：没有以任何方式度量事件，不 可加 也不是维度：事务之外并不存在，没有自己 的描述属性 包含在事实表中：从分析角度来说是有用的， 可以使用它将购物篮中的所有行项关联起来， 用于DM

每个事实表都包含特定业务过程相关的度 量

Eg. 下单 、显示一网页 、处理一客户服务请求

事实表中的一条记录是一个度量事件 事件通常有数字值，用来量化大量的事件， 这些数字称为事实(Fact)

Eg. 定购数量、销量、呼叫持续时间

离散的描Βιβλιοθήκη Baidu信息的数字型数据不是事实， 它们用于约束查询而不是求和

事实表的主键

外键

每个维度表都与中央的事实表有着1:N的关系。 每个维度表的主键是事实表的外键。 一个单独的复合主键：其长度为4个维度表键长度的总和， 外键作为附件属性存在事实表中 一个生成的主键：与维度表的键无关的新生成的键，维度表 的主键作为附加属性存储在事实表中 连接的主键:最常用的方式！！！
代理机构
婚否
家庭大小 已拥有车辆数 家庭财产 拥有/租用
单独品牌标记
第一次操作日期
事实：实际销售价格、MSRP销售价格、配件价格、全价、经销商附加部
件、经销商信用、经销商发票、预付定金、收益、贷款
从需求到数据设计

维度建模基础

Example：将所有的信息集成在一起，显示了如何由信息包表构 造不同的维度表（就是关系、表）
DW关注的是经理如何管理业务问题 DW回答全局的问题 反映商业趋势 通过几个商业维度，衡量业务情况

星型模式

构建星型模式是数据仓库建模的基本数据 设计技术。
星型模式

一个简单的星型模式的回顾
Product Product Name SKU Brand Customer 产品名＝TV Order Measures 州＝Maine
维度表的主键——代理键

代理键（替代键、无意义键、人工键）

选择维度表主键的原则



避免维度表中的主键有内在的含义。传统的OLTP系 统中的主键都有内在含义，例如产品编码 不要用OLTP系统中的键作为维度表的主键
替代键是系统生成的简单的序列号码（通常是 整数），没有任何内在含义。OLTP中表的键一 般作为一个附加属性存放在维度表当中。

从需求到数据设计

维度建模基础

汽车销售商的星型模式
产品
时间
经销商
汽车销售 事实表
付款方式
客户
从需求到数据设计

维度建模基础——ER建模与维度建模的比较 OLTP中常用ER建模
数据一致性、较小的冗余性 适用于回答交易层面上的问题 一个OLTP系统是通向微观交易的窗口


DW中则采用维度建模