Mysql范式设计

Mysql范式设计

      目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。

满足最低要求的范式是第一范式(1NF)。一般说来,数据库只需满足第三范式(3NF)就行了。

 第一范式(1NF):

      第一范式就是无重复的列,是指数据库表的每一列都是不可分割的基本数据项。

 第二范式(2NF):

     在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。(注:后面的范式都是以前面的范式为基础

每个表中都有一个标志属性来性确定每个对象(注:把表看作一个类,则每一行都可以看成这个类的对象),这个唯一属性列被称为主关键字或主键、主码。

要求实体的属性完全依赖于主关键字。

    关系数据库 :

  在一个给定的应用领域中,所有实体及实体之间联系的关系的集合构成一个关系数据库。

关系数据库中,关系模式是型,关系是值。

 

     函数依赖:

  设X,Y是关系R的两个属性集合,当任何时刻R中的任意两个元组中的X属性值相同时,则它们的Y属性值也相同,则称X函数决定Y,或Y函数依赖于X。

 

<!-- 导入 在此 参考资料--><!-- end 参考资料-->

 第二范式(2NF)要求实体的属性完全依赖于主关键字(注:这里的依赖应该都是指函数依赖)。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。

 

 例:选课关系 SCI(SNO,CNO,GRADE,CREDIT)其中SNO为学号, CNO为课程号,GRADEGE 为成绩,CREDIT 为学分。 由以上条件,关键字为组合关键字(SNO,CNO)
  在应用中使用以上关系模式有以下问题:
  a.数据冗余,假设同一门课由40个学生选修,学分就 重复40次,也就是说表要有40行。  
  b.插入异常,如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程和学分存入。 
  c.删除异常,若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则此门课程及学分记录无法保存。


  原因:非关键字属性CREDIT仅函数依赖于CNO,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。

  解决方法:分成两个关系模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新关系包括两个关系模式,它们之间通过SC1中的外关键字CNO(注:cno是sc1的外键同时也是c2的主键)相联系,需要时再进行自然联接,恢复了原来的关系

这样的话,不管 SC1有几行,C2都只是根据课程的个数而定。

第三范式:

第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。即两个表中不能含同一个属性。

### MySQL 数据库设计中的范式概念及应用 #### 什么是数据库范式? 数据库的设计范式是指在关系型数据库中,数据表设计应遵循的一些基本原则和规则。这些原则定义了一张数据表的设计结构需要达到的标准级别[^1]。 #### 范式的分类及其作用 数据库范式通常分为多个层次,常见的有第一范式(1NF)、第二范式(2NF)、第三范式(3NF),以及更高级别的BC范式、第四范式(4NF)等。每一级范式都建立在其前一级的基础上,并进一步减少冗余性和提高一致性。 - **第一范式 (1NF)** 表格中的每一个单元格必须是一个不可分割的原子值。这意味着表格中的列不允许再嵌套子列表或其他复杂的数据结构。 - **第二范式 (2NF)** 在满足第一范式的基础上,消除非主属性对候选键的部分函数依赖。即确保所有的非主属性完全依赖于整个主键,而不是部分依赖于某个组成主键的一部分[^2]。 - **第三范式 (3NF)** 在满足第二范式的基础上,消除传递依赖。也就是说,如果 A → B 并且 B 不是 A 的超集,则 B 应该被移除到另一个表中。 - **BC范式 (BCNF)** BC范式是在第三范式基础上的一个更强约束条件。它要求对于任何非平凡的函数依赖 X → Y,X 都应该是超级键。即使不存在传递依赖的情况下,也可能违反此规范[^3]。 #### 多值依赖与更高范式 当涉及到多值依赖时,可能会遇到更高的范式需求。例如,在某些情况下,尽管一个表可能已经达到了 BC 范式的要求,但由于存在多值依赖而导致更新异常等问题。此时可以通过分解表来解决这些问题,从而实现第四范式甚至第五范式设计目标。 #### 实际案例分析 考虑这样一个场景:我们需要记录课程、教师和教材之间的关联关系。最初我们可以构建一个包含 `课程ID`、`教师ID` 和 `教材ID` 的单一表,并将其设置为联合主键。然而这种设计方案虽然能够满足 BC 范式,但如果未来想要单独更改某门课所使用的书籍而无需指定具体的授课老师,则会面临困难。因此合理的做法是将这个复杂的多值依赖拆分成两个独立的关系表来进行管理。 ```sql -- 创建课程与教材的关系表 CREATE TABLE Course_Books ( Course_Name VARCHAR(100), Book_Name VARCHAR(100), PRIMARY KEY(Course_Name, Book_Name) ); -- 创建课程与教师的关系表 CREATE TABLE Course_Teachers ( Course_Name VARCHAR(100), Teacher_Name VARCHAR(100), PRIMARY KEY(Course_Name, Teacher_Name) ); ``` 上述 SQL 片段展示了如何通过分离原本紧密耦合的信息来优化数据库结构,使得后续操作更加灵活高效。 --- ### § 1. 如何判断一张数据表是否符合特定级别的范式?有哪些工具可以帮助完成这项工作? 2. 当我们在实际项目开发过程中发现现有数据库不符合较高水平的范式时,应该采取哪些措施对其进行重构? 3. 如果考虑到性能因素,在什么情况下可以适当放宽对严格范式的要求? 4. 对于初学者来说,学习并掌握不同范式之间差异的最佳方法是什么? 5. 使用 MySQL 中 varchar 类型存储字符串长度的具体含义是什么? 它是如何随着版本变化而改变的呢?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值