目录一、数据库设计了解为主少数记背二、范式软性约定不是硬性规定三、三大范式简单了解实践中体会1. 第一范式1NF列必须是“原子数据”2. 第二范式2NF消灭“部分函数依赖”3. 第三范式3NF消灭“传递依赖”四、总结一、数据库设计了解为主少数记背“数据库设计以了解为主不需要死记硬背少数关键地方要记住”。后面开发写多了表、写多了代码自然能找到更优解——别一开始就死磕理论实践出真知~二、范式软性约定不是硬性规定范式是设计数据库表的基本规范和约定就像写代码的“最佳实践”“指导方针”。它和create table语法不同create table是硬性的语法规定必须严格遵守范式是软性的约定日常开发遵守到第三范式即可其他高阶范式一般不用考虑。三、三大范式简单了解实践中体会日常开发常见场景遵守到第三范式就够用了。下面逐个拆解结合课堂截图理解1. 第一范式1NF列必须是“原子数据”第一范式的核心是数据表的每一列都是不可分割的原子数据项不能是集合、数组、对象这类“非原子数据”。MySQL 本身没有数组/对象这样的类型所以建表时要注意列的“原子性”。举两个反例反例1class表设计成(classId, name, studentId)其中studentId用逗号分隔比如1,2,3,4。这违反了第一范式——因为studentId列可以拆分成多个独立的学生ID不是“原子”的。反例2学生表的“学校”列直接存“学校名学校地址学校电话”比如“XX大学XX路XX号123456”。这也能继续拆分所以也违反第一范式。2. 第二范式2NF消灭“部分函数依赖”第二范式的前提是满足第一范式然后要求不存在非关键字段对任意候选键的“部分函数依赖”。先明确几个概念候选键可以理解成主键一条记录的身份标识可以是单个列也可以是多列组合联合主键。非关键字段不属于候选键的列。部分函数依赖不必通过完整的候选键就能确定一个记录比如只靠学号就能确定学生姓名。完全函数依赖必须通过完整的候选键才能确定一个记录比如成绩需要“学号课程名”一起确定。来看一个“学生课程成绩表”例子这个表的候选键是“学号 课程名”因为只有这两个组合能唯一确定一条记录。但存在很多问题学生姓名、年龄、性别只依赖“学号”部分依赖不用看课程名就知道是谁学分只依赖“课程名”部分依赖不用看学号就知道是哪门课的学分成绩依赖“学号课程名”完全依赖必须两者结合才知道成绩。这种“部分依赖”会导致数据冗余比如李四的姓名和年龄每次选不同课程都要存一次重复了和维护灾难比如改李四的年龄要改所有他选课的行漏改就会歧义。所以第二范式的约束是消灭部分依赖——通常做法是拆分表比如把学生信息单独放“学生表”课程信息放“课程表”成绩放“分数表”。3. 第三范式3NF消灭“传递依赖”第三范式的前提是满足第二范式然后要求不存在非关键字段对候选键的“传递依赖”。简单说就是“非关键字段不能依赖另一个非关键字段”。比如如果 A→BB→C那么 A→C 就是传递依赖A是候选键B、C是非关键字段C依赖BB依赖A所以C传递依赖A。比如上表1.只要 id 确定了,学号,姓名,年龄,性别,还有学院信息都明确了~~那就是直接的依赖~~2.但是关于学院电话和学院地址对于Id来说其实是传递依赖学院确定了,学院电话和学院地址就确定了~~同学确定了,学院就确定了这其实是--不科学的设计~~四、总结本篇博客记住几个点范式是软性约定不是语法硬规日常到第三范式足够第一范式抓“原子性”列不可拆第二范式抓“完全依赖”消灭部分依赖避免冗余和维护问题第三范式抓“传递依赖”进一步精简实践出真知写多了表自然能找到更优解~