2023年7月27日发(作者：)

mysql数据库设计实例_Mysql数据库设计三范式实例解析三范式1NF:字段不可分;2NF:有主键，⾮主键字段依赖主键;3NF:⾮主键字段不能相互依赖;解释:1NF:原⼦性 字段不可再分,否则就不是关系数据库;2NF:唯⼀性 ⼀个表只说明⼀个事物;3NF:每列都与主键有直接关系，不存在传递依赖;第⼀范式(1NF)即表的列的具有原⼦性,不可再分解，即列的信息，不能分解, 只要数据库是关系型数据库(mysql/oracle/db2/informix/sysbase/sqlserver)，就⾃动的满⾜1NF。数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性 。通俗理解即⼀个字段只存储⼀项信息。关系型数据库: mysql/oracle/db2/informix/sysbase/sql server ⾮关系型数据库: (特点: ⾯向对象或者集合) NoSql数据库:MongoDB/redis(特点是⾯向⽂档)第⼆范式(2NF)第⼆范式(2NF)是在第⼀范式(1NF)的基础上建⽴起来的，即满⾜第⼆范式(2NF)必须先满⾜第⼀范式(1NF)。第⼆范式(2NF)要求数据库表中的每个实例或⾏必须可以被惟⼀地区分。为实现区分通常需要我们设计⼀个主键来实现(这⾥的主键不包含业务逻辑)。即满⾜第⼀范式前提，当存在多个主键的时候，才会发⽣不符合第⼆范式的情况。⽐如有两个主键，不能存在这样的属性，它只依赖于其中⼀个主键，这就是不符合第⼆范式。通俗理解是任意⼀个字段都只依赖表中的同⼀个字段。(涉及到表的拆分)看下⾯的学⽣选课表：学号课程成绩课程学分10001数学100610001语⽂90210001英语85310002数学90610003数学99610004语⽂892表中主键为 (学号，课程)，我们可以表⽰为 (学号，课程) -> (成绩，课程学分)， 表⽰所有⾮主键列 (成绩，课程学分)都依赖于主键 (学号，课程)。 但是，表中还存在另外⼀个依赖：(课程)->(课程学分)。这样⾮主键列 ‘课程学分‘ 依赖于部分主键列 '课程‘， 所以上表是不满⾜第⼆范式的。我们把它拆成如下2张表：学⽣选课表：学号课程成绩10001数学10010001语⽂9010001英语8510002数学9010003数学9910004语⽂89课程信息表：课程课程学分数学6语⽂3英语2那么上⾯2个表，学⽣选课表主键为(学号，课程)，课程信息表主键为(课程)，表中所有⾮主键列都完全依赖主键。不仅符合第⼆范式，还符合第三范式。再看这样⼀个学⽣信息表：学号姓名性别班级班主任10001张三男⼀班⼩王10002李四男⼀班⼩王10003王五男⼆班⼩李10004张⼩三男⼆班⼩李上表中，主键为：(学号)，所有字段 (姓名，性别，班级，班主任)都依赖与主键(学号)，不存在对主键的部分依赖。所以是满⾜第⼆范式。第三范式(3NF)满⾜第三范式(3NF)必须先满⾜第⼆范式(2NF)。简⽽⾔之，第三范式(3NF)要求⼀个数据库表中不包含已在其它表中已包含的⾮主键字段。就是说，表的信息，如果能够被推导出来，就不应该单独的设计⼀个字段来存放(能尽量外键join就⽤外键join)。很多时候，我们为了满⾜第三范式往往会把⼀张表分成多张表。即满⾜第⼆范式前提，如果某⼀属性依赖于其他⾮主键属性，⽽其他⾮主键属性⼜依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。 通俗解释就是⼀张表最多只存两层同类型信息。反三范式没有冗余的数据库未必是最好的数据库，有时为了提⾼运⾏效率，提⾼读性能，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的⼯作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提⾼查询效率，因为在数据库的操作中查询的⽐例要远远⼤于DML的⽐例。但是反范式化⼀定要适度，并且在原本已满⾜三范式的基础上再做调整的。以上就是本⽂的全部内容，希望对⼤家的学习有所帮助，也希望⼤家多多⽀持脚本之家。