Mysql--数据库三大范式

基本概念

实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，比如说“老师与学校的关系”。

属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。

元组：表中的一行就是一个元组。

分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。

码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。

全码：如果一个码包含了所有的属性，这个码就是全码。

主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。

非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。

函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

范式的主要目的：减少数据冗余，但并非越严格约好，也并非一定要完全遵守，视需求以及性能而定，可适当冗余；

第一范式：确保每列原子性

第一范式：目标是确保每列的原子性，一个字段表示一个含义
（把字段拆分到不可拆开）

但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，所以需要进行第二范式的学习。

第二范式：非键字段必须依赖于键字段

（第二范式：在满足第一范式的前提下，要求每个表只描述一件事情）
2NF在1NF的基础之上其改进是，消除了非主属性对于码的部分函数依赖。

必备知识点

函数依赖：
我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。

第三范式：消除传递依赖

( 第三范式：在满足第二范式的前提下，除了主键以外的其他列消除传递依赖。)
消除传递依赖：也就是每个非主属性都不传递依赖于候选键，判断传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。

反3NF

注意：一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
规范化和性能的关系 ：性能比规范化更重要