数据库设计

1.范式

数据库的范式是一组规则。在设计关系型数据库时,需要遵守不同的规范要求,这些要求称为范式。关系型数据库有六种范式,通常只需要满足第三范式即可。第一范式(1NF),第二范式(2NF),第三范式(3FN)

2.第一范式

数据库表的每一列只能是不可分割的最小原子项,而不能是数组,集合,对象等非原子数据。

例如:设计一个学生表

错误示范:

学校这一列设为字符型,把"学校名,学校地址,学校电话"拼接在一个名为"学校"的字符里。需要时再进行分割。

这种情况就是不满足第一范式,不满足每一列都是不可再分的最小原子项。要明确一点,这种操作在MySQL语法上是可以跑通的,但是是错误的设计!!!

正确设计:

3.第二范式

在满足第一范式的基础上,不存在非关键字段对任意候选键的部分函数依赖。

++即普通字段依赖复合主键的一部分,必须是复合主键的表++

候选键:所有主键。例如以下学生成绩表,有"学号+课程表"作为身份标识

非关键字段:不属于候选键的列

部分函数依赖:知道学号,就可以知道学生姓名,年龄,性别

(非关键字段:姓名------依赖了主键的一部分:学号------而不是依赖整个主键:学号+课程名)

知道课程名,就可以知道学分

完全函数依赖:知道学号+课程号,才可以知道成绩

(成绩依赖全部主键)

错误设计:

后果:

1.数据冗余。

一张表中有多个数据重复出现,造成了大量的数据冗余

2.更新异常。

如果要更新MySQL的学分,就要修改很多条记录,如果有一条漏改,就会造成数据逻辑崩溃。

再比如"张三"改名为"张小三",那么就要修改大量记录。如果是在正确设计下,就只需要改学生表中的一条数据即可。

3.插入异常

4.删除异常

正确设计:

4.第三范式

在满足第一、第二范式的基础上,不存在非关键字段,对任一候选键依赖

++即普通字段依赖一个主键。可以是单主键的表++

错误设计:

ID决定学院

学院决定学院电话

这就叫传递依赖,不符合第三范式

正确设计:

相关推荐
2603_965148111 小时前
如何解析JSON数据?API返回的商品信息处理教程
开发语言·数据库·python·自动化·json·api
ltl1 小时前
RocksDB 经典故障排查:L0、compaction 与 write stall
数据库
xfhuangfu2 小时前
Oracle中建立到CDB和PDB的连接
数据库·oracle·rpc
小小龙学IT2 小时前
DuckDB 深度实战:用 C++ 在进程内跑一个「分析型数据库」
数据库·c++
NineData2 小时前
DTCC 2026 预告|NineData CEO& 创始人叶正盛:面向 AI Agent 的数据库 DevOps 与数据复制实践
数据库·人工智能·数据库开发·devops·ninedata·数据库技术·dtcc
J_bean3 小时前
MySQL 事务是否必须手动开启?
数据库·mysql·数据库事务·自动提交·手动提交
J_bean3 小时前
MySQL InnoDB 如何检测死锁、判定死锁、处理死锁
数据库·mysql·死锁·死锁检测·处理死锁·死锁判定
浪子明X4 小时前
从 MongoDB 文档到关系模型:构建可重跑、可对账的数据迁移流水线
数据库·mongodb·oracle
杜子不疼.4 小时前
国产数据库撑起固井软件自主化:金仓 × 中海油服「海恒 Cemsol」落地解析
数据库
隔窗听雨眠4 小时前
GBase 8s并发控制深度解析:封锁机制、隔离级别与死锁处理全攻略
服务器·数据库·oracle