商务智能复习-数据仓库设计

发表于 2026-06-25 更新于 2026-06-29 分类于商务智能本文字数： 1.4k 阅读时长 ≈ 5 分钟

设计背景与核心理念

设计方法的起源

共同点：数据库设计的许多思想（如数据模型）可以应用于数据仓库。
不同点：
- OLTP (事务型)：需求明确，遵循传统的 SDLC (系统开发生命周期，需求驱动)。
- DW (分析型)：需求不明确，只能在装载部分数据后才能弄清，因此无法完全用需求驱动，而采用 CLDS (由数据驱动的生命周期)。

操作型数据库 vs. 数据仓库

维度	操作型数据库 (OLTP)	数据仓库 (DW)
处理类型	面向应用 (日常事务)	面向分析 (决策支持)
需求	确定、明确	不确定、不断变化
设计目标	事务处理性能 (高并发)	全局一致的数据环境 (历史、集成)
输入	事务相关数据	多种多样 (来自多个源系统)
设计方法	SDLC (系统生命周期)	CLDS (需求在后期明确)

数据仓库设计的三大原则

面向主题原则

核心思想：设计以用户决策的主观需求（主题）为起点，而非以客观操作客体为起点。
示例（商品销售主题）：
- 目的：决定何时订购何种商品到何地销售。
- 分析操作：分析销售额与商品类型、销售时间、商店位置的关系。
注：主题是较高层次的抽象，随设计推进不断完善。

数据驱动原则

核心思想：数据仓库的数据建立在已有数据库系统基础上，是已存在数据的抽取、综合与集成。
方法：从已有的操作型环境出发，按分析领域对数据及联系重新考察，识别现有数据与主题数据的“共同性”。

原型法设计原则

适用原因：需求不明确且不断变化。
开发方式：
- 从基本框架开始，不断循环、反馈，逐步求精。
- 先载入部分数据供分析员使用，根据反馈修改/添加数据。
- 迭代开发：依赖于上一个迭代的结果，最终融合为一个整体（需数据模型作为路标）。

数据仓库设计的三级数据模型

模型级别	描述	表示方法
概念模型	客观世界到机器世界的中间层，定义系统边界和主题。	E-R图
逻辑模型	主题的逻辑实现，定义粒度和分割策略。	关系模型 (二维表)
物理模型	逻辑模型在存储介质上的实现，优化性能。	存储结构、索引、分区

数据仓库设计的具体步骤

系统规划

明确主题：确定分析对象（主题），之后逐步扩充（原型法）。
技术准备：评估数据存取能力、模型重组能力；准备软硬件平台。

概念模型设计 (定义边界与主题)

确定系统边界：回答“做什么决策？需要什么信息？数据源在哪里？”
确定主要内容：包括公共码键、属性信息、主题间关系。
- 注：分析属性取值的变化频率（固定、半固定、经常变化）。

逻辑模型设计 (核心难点)

转换：将E-R图转换成二维表。
粒度划分 (重点)：
- 含义：数据单元的详细程度。越细粒度越小，越概括粒度越大。
- 层次：详细数据 -> 轻度总结 -> 高度总结。
- 示例：时间维度（天、周、月、季度、年）；商品维度（具体商品、小类、大类）。
数据分割：
- 目的：将逻辑统一的数据切分为可独立管理的小单元（如按时间分割），提高索引和扫描效率。
定义数据源与抽取规则：明确哪个源系统的哪个表对应哪个属性。

物理模型设计 (性能优化)

合并表：将频繁一起访问的表混合存放，减少I/O。
数据序列 (Array)：将有序数据物理上连续存放，一次I/O可读取多个。
引入冗余：将某些属性复制到多个表中，减少表连接（需保证一致性）。
表的物理分割：按访问频率或更新频率分割属性列（如图3-30所示）。
生成导出数据：预先计算统计值（年/月汇总）并存储，避免实时计算。
建立广义索引：记录“最”相关的统计结果（如“月销售额最高”的店），无需扫描全表。

数据仓库生成

建立数据模式 -> 编制抽取程序 -> 数据加载。

运行与维护

建立分析应用，在使用中理解需求改进主题，定期刷新数据以保持一致性。

从操作型数据到数据仓库的难点 (ETL)

集成问题 (严重缺乏集成)

问题表现：
1. 相同数据，不同名字。
2. 不同数据，相同名字。
3. 数据在此存在，别处不存在。
4. 相同名字，不同度量单位。
解决方案：进行编码转换、单位转换、字段名称转换（如图3-3）。

装载工作分类

装载档案数据 (历史数据)。
装载现有数据 (当前操作型数据)。
装载变化数据 (增量更新)：利用时间戳、DELTA文件、日志文件。

时基转换 (Time-basis Shift)

操作型：基于事务 (Transaction) 状态变化快。
数据仓库：基于快照 (Snapshot)，如每日余额 (Daily balance) 或每周余额。
数据量管理：需对数据凝缩 (Condensation)，否则海量数据无法达到仓库目标。