关系数据模型

数据结构

• 关系（表，实体）
• 属性（列，字段）
• 属性域（约束）
• 元组（行，记录）
• 键（超键，候选键，主键，外键）

主键选取原则

• 尽可能小、数字类型（如AUTO_INCREMENT）
• 不可修改（避免外键引用失效）
• 没有业务含义（避免随业务改变而修改）
• 可多列组成，但尽可能少

完整性约束

• 实体完整性（主键不为空）
• 参照完整性（外键值与主表某些记录的候选键值相同，或外键值全为空，即无关联）

业务规则：包括属性域和完整性规则（check）

关系数据库语言（SQL）：

• DDL（数据定义语言）：create，alter，drop，truncate，comment，rename
• DML（数据操纵语言）：select，insert，update，delete，merge，call，explain，lock
• DCL（数据控制语言）：grant，revoke
• TCL（事务控制语言）：commit，rollback，savepoint，set transaction

规范化（减少数据冗余度、提高更新效率，但联表过多降低查询性能）

• 1NF（原子性列）

mobile列可存放多个号码，应该拆分：

• 2NF（满足1NF条件下消除部分依赖）

上表中候选键{id, name, dept_no}，dept_name依赖dept_no、name依赖id，因此应该把表拆分为如下三个表：

部门表：

员工-部门表：

员工-号码表：

• 3NF（满足2NF条件下消除传递依赖）

上面的员工表中province、city依赖zip，而zip依赖id即为传递依赖，应把表再拆分成员工表和地区表：

员工表：

地区表：

优势

• 非冗余性
• 稳定性
• 一致性
• 灵活性

维度数据模型

事实表，维度表（规范化级别低于关系模型），数据粒度

构建流程

• 选择业务流程（UML）
• 声明粒度（订单/消费流水）
• 确认维度（日期：年/月/日）
• 确认事实（金额/数量）

维度规范化

把一个维度映射成多个维度表（维度-子维度连接，如地址表拆分为省份表-城市表-区域表）。

避免规范化处理的情况：

• 增加表数量使结构复杂
• 多表连接使查询复杂
• 不适合使用位图索引
• 降低查询性能

优势

• 易理解
• 高性能（非规范化，如原来有订单明细表和订单表，可以从订单明细状态中提取出订单状态维度表、再把订单表和订单明细表整合到一起）
• 可扩展

星型模型

以事实表为中心，多个维度表与事实表相连。

其中事实表包括：

• 事务事实表（如销售行为）
• 快照事实表（如用户月底余额）
• 累积事实表（如月总营收）

优点：
简化查询，简化业务报表逻辑，提升查询性能，快速聚合，便于向OLAP提供数据；但不能保证数据完整性（通过批处理和实时处理抵消），分析需求不灵活；

雪花模型

对星型模型的维度表再作规范化处理（如把机器的门店维度表拆分成门店表和门店地址表），比星型模型节省存储空间但同时降低查询性能，也可两者结合（底层使用雪花模型，配置视图模拟星型模型）。

Data Vault模型

由中心表（HUB）、链接表（Link）、附属表（Satelite）组成，综合了3NF和星型模型的优势；
存放原始数据（所有时间所有数据），不遵照任何业务规则，不同数据源的数据冲突时可存放多个版本数据，数据解析延迟到数据集市阶段。

• 中心表（如用户、机器、订单表等）：主键（系统生成的代理键）、业务主键（如用户id，机器id，可能用于多个系统，但只保留一份）、装载时间、数据源
• 链接表（中心表之间的链接关系，如订单-用户关联表）：主键、外键、装载时间、数据源
• 附属表（中心表和链接表的附属信息，如订单详情表）：主键、外键、装载时间、失效时间、数据源、属性xxx

特点

• 基于时间存储
• 依赖越少越好
• 与源系统越独立越好
• 适应源系统的数据变化、支持扩展
• ETL作业可反复执行
• 数据可追踪

构建流程

• 设计中心表
• 设计链接表
• 设计附属表
• 设计必要的PIT表

数据集市

存放单一主题（财务、销售部门等）、数据仓库/事务系统的少量数据源的粗粒度数据（汇总数据），只保留一段时间范围内（如数月），通常使用星型模型、雪花模型，存放的是ETL的输出数据。

数据仓库实施

• 定义范围
• 确定需求
• 逻辑设计
• 物理设计
• 装载数据
• 访问数据
• 管理维护