SQL基础随记3 范式 键

SQL基础随记3 范式 键

什么是范式？哈，自己设计会使用但是一问还真说不上来。遂将不太明晰的概念整体下

 

什么是 & 分类

范式（NF），一种规范，设计数据库模型时对关系内部各个属性之间的联系的合理化程度的不同等级的规范要求。

分类：

• 1NF、2NF、3NF、BCNF（巴斯科德范式）、4NF、5NF（完美范式）

低阶范式是高阶范式的基础，范式等级越高冗余度越低，使用时越容易进行join

 

键

• 超键：能唯一表示元组（元组也就是一行数据，一条记录）的属性的集合。超键可能包含多余属性。如身份证号+学生id+姓名
• 候选键：不包含多余属性的超键。候选键可能不唯一，身份证号或学生id都可以当做候选键。
• 主键
• 外键

属性

• 主属性：任意候选键的属性就是主属性
• 非主属性

依赖

• 依赖：一个或一组属性的值决定其他属性的值
• 完全依赖：某个非主属性于所有主属性
• 部分依赖
• 传递依赖：若存在 "A>>B>>C"的依赖关系，则C传递依赖于A

 

Each NF

• 1NF：表中任何属性都是原子性的（不可拆分的），所有 RDBMS都满足。

• 2NF：任意一个非主属性都要与主属性/候选键完全依赖，消除非主属性对候选码的部分依赖。

  若不满足2NF会造成

  • 数据冗余

  • 增删改异常

    不满足2NF举例

    球员id决定球员姓名等球员个人信息

    比赛id决定比赛时间、比赛场地等比赛信息

    若将上述所有属性放在一张表中就会造成

    • 数据冗余：异常比赛有n个球员参加，那么记录该场比赛n个球员信息时，对应的比赛信息就多余了n-1次

    • 增删改异常：仅根据球员id或比赛id进行操作时，

      增：不知道另一个主属性导致无法插入

      删：会删除另一个主属性以及其对应的信息

      改：修改信息时，有改信息的所有记录都要修改

• 3NF：在第二范式的基础上，任意一个非主属性都不传递依赖于候选键

  不满足3NF但满足2NF举例

  表1：球员id、球员姓名、球队名称、主教练姓名

  球员姓名、球队名称、主教练姓名都可以由球员id决定

  但是主教练姓名也可以通过球队名称决定，这就出现了传递依赖

  如果我们将表1拆分成

  表2：球员id、球员姓名、球队名称

  表3：球队名称、主教练名称

  则满足3NF

 

致命总结

在第一范式的基础上，根据"非主完全依赖主属性"对所有属性进行划分并给每张表加id就满足第二范式，再细分属性消除传递依赖加上FOREIGN KEY就满足第三范式

BCNF、4NF、5NF查询效率极低，很少用到，开发效率和查询效率都很感人。

 

反范式

一般情况下，业务界面会显示用户姓名而不是用户ID，因此常常需要将user表与其他表连接查询。因此当数据量较大时可以将user id 与 use name 在其他常用表中“冗余"，这样可以只进行单表扫描。而不用在大数据量的情况下再连接查询。

反范式在OLAP场景比较常用，详见此处，另见此处

 

 

反范式设计与数据仓库

数据仓库与数据库的区别：

• 数据库用于捕获数据，数据仓库用于分析数据
• 数据库对增删改实时性要求强，需要存储在线的用户数据。数据仓库一般是历史数据
• 数据库要尽量避冗余，数据仓库的设计上更偏向反范式设计，因为历史数据往往很多。连接查询会大幅度拖慢速度。