数据库 | 数据库设计
source link: https://jiac3366.github.io/2021/12/20/%E6%95%B0%E6%8D%AE%E5%BA%93/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
数据库 | 数据库设计 | jiaccc
SQL范式设计——围绕非主属性/主属性是否对于候选键是直接依赖？
码 = 候选键(唯一确定记录的键)= 所有主键——其包含的所有属性都叫主属性
2NF：消除了非主属性对于候选键的部分依赖。
3NF：消除了非主属性对于候选键的传递依赖。
BCNF：消除主属性对于候选键的部分与传递依赖。
1NF：字段不可拆分，任何的 DBMS 都会满足第一范式
2NF：表中非主属性要和表的候选键有完全依赖关系
即两个对象不能掺和在一起，2NF 告诉我们一张表就是一个独立的对象3NF：任何非主属性都不传递依赖于候选键——保证只能由候选键直接决定非主属性，非主属性不能决定非主属性
不能存在非主属性 A 依赖于非主属性 B，非主属性 B 依赖于候选键的情况。
eg：现在有一张学生选课表，包含的属性有学号、姓名、课程名称、分数、系别和系主任
学生和课程要分开 –>不是同一个对象，违反2NF
分成Student(学号,姓名,系别)和Course(课程号，课程名称)
2个对象中间加个表关联: SC(学号,课程号,分数)要分成Student(学号,姓名,系别)和Sdept(系别,系主任)，因为学生决定系别，系别又决定系主任–>违反3NF
非主属性系主任会传递依赖于学号
BCNF：在 3NF 的基础上消除了主属性对候选键的部分依赖或者传递依赖关系。
第22章反范式设计：通过空间换时间，提升查询的效率
在数据量大情况下 直接在评论表中加入用户名字段 就不用查询2个表
使用场景：冗余信息有价值或者能大幅度提高查询效率的时候，数据仓库在设计上更偏向采用反范式设计。
如订单中的收货人信息，包括姓名、电话和地址等需要保存记录，但用户可以轻易修改这些信息缺点：1.让数据库的设计更加复杂。2.增加系统的维护成本。
比如用户每次更改昵称的时候，都需要执行存储过程来更新，如果昵称更改频繁，会非常消耗系统资源
杂谈：候选键就像这一行数据的老大，它能唯一决定这行记录。当然，这条记录有可能有多个老大，候选键中不包含的属性就是小弟们，2NF规定，老大与小弟们的关系，要么1对多，要么多对1，否则就不符合2NF。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK