从0开始数据仓库--数据表范式

定义：
数据库范式是一种用于减少冗余，提高数据一致性和可维护性的规则

一、核心概念

• 函数依赖：X 确定 Y，记作 X→Y
• 候选码：能唯一标识一行的最小属性集
• 主属性：出现在候选码中的属性
• 非主属性：不出现在任何候选码中的属性
• R()： 「单个关系模式 R」

在关系模式r中范式可以分为5类

1NF:所以列不可以在分，即属性必须原子，不能再分。

以下是一个不满足第一范式的案例：

user表：

上表可见TEL手机号中存在多个值信息，没有做到列不可再分
正确结构为：

user表：

2NF：必须完全依赖不能部分依赖，即其他表关联user表中要完全依赖主键

非联合主键都满足第二范式
user表：

(USER_ID + TEL) 确定唯一一条数据，其他字段关联user表时要用 (USER_ID + TEL) 关联

ID非业务主键(只做展示不做使用)
F(
SEX → SEX_NAME,
(USER_ID，TEL)→ NAME、SEX
)
存在部分依赖 USER_ID -> SEX

正确格式：

user

user_contact

sex_dict

• user：候选码是 USER_ID（单属性），天然无部分依赖；
• user_contact：候选码是 (USER_ID, TEL)，非主属性 PHONE_BILL 依赖完整候选码，无部分依赖；
• sex_dict：候选码是 SEX（单属性），天然无部分依赖。

3NF：必须直接依赖，不能有传递依赖：即字段

F(
NAME -> DEPT ,
DEPT -> DEPTNAME
)
存在传递依赖 _NAME -> DEPT ->DEPT_NAME

BCNF:所有函数依赖的左边，必须是候选码。

F(
NAME -> AGE ,
NAME -> GENDER
)
所有列都依赖最左边的NAME

4NF：消除多值依赖:即一对多里，不要把两个互不相关的 “多” 塞在同一张表里。

上表可以看到人员信息存在左眼和右眼视力一对多的情况，如果用户只想要获取年龄会还须二次处理

正确处理方法为：

或者单独创建一张维度表

5NF: 消除连接依赖:拆到不能再拆

一张表如果能无损拆成三张及以上更小的表，就拆干净，不要再合并回去（项目上不要使用）。

范式优点
当我们遵守范式规则如果要更改那个表的维度值编码信息，可以直接变更拆封的表内的码值信息

范式缺点
范式并不是越多越好在OLAP数据仓库中我们要进行反范式化使其性能提高，查询代码更加简洁（表结构拆的越细，编写业务指标时关联表的次数就会越多，代码维护起来就更加费力）

范式习题：

1. R (学号，姓名，班级，班级名，性别，年龄)

F(
学号 -> 年龄,
学号 -> 性别,
学号 -> 班级,
班级 -> 班级名
)
上述结构满足第几范式，候选码是什么

1. 现有关系模式：R(A，B，C，D，E，F)，
   其中AB为候选码，存在函数依赖B→C，A→D，D→E，D→F
   R（X，Y，Z），F = { Y→Z，XZ→Y}
   写出满足BCNF格式的关系模式

2. 现有一个json数据，请你针对该数据设计一张数据表：(各项目都有2次考核机会，如第一次不合格会有第二次成绩)
   姓名，年龄，身高，体重，性别，民族， 班级， 导员，肺活量，跳远成绩，50m, 1000m, 是否合格