## **避免数据库操作异常** **插入异常**： >[danger]如果某实体随着另一个实体的存在而存在，即缺少某个实体时无法表示另一个实体，这个表就存在插入异常：     如:当仓库中的商品和管理员存在一张表的时候；当不存在商品的时候无法表示管理员 **更新异常**： >[danger]如果更改表所对应的某个实体实例的单独属性时需要将多行更新那么就说这个表存在更新异常 如:当换了管理员时则表中所有行的管理员都要修改 **删除异常**： >[danger]如果删除表的某一行来反映某实体实例失效导致另一个不同实例信息丢失，那么这个表中就存在删除异常 只要存在插入异常。就会存在更新和删除异常 ## **范式：** * **范式种类：** 第一、第二、第三、BC、第四、第五这些范式   * **目的：** 就是为了避免数据的冗余和插入/删除/更新的异常 **函数依赖**： >[danger]若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y属性依赖于X，写作 X → Y 如：学生姓名函数依赖于学号，写作 学号 → 姓名   但是存在相同姓名，所以学号函数不依赖姓名 **码**:一个表中,可以唯一决定一个元组的属性“集合”。而主键则是可以唯一决定元组的‘某个属性’ 例如：在成绩表中（学号，课程号）合起来叫一个码，而分开看学号是主键，课程号也是主键 **非主属性**：不属于码的属性 **主属性**：属于码的属性 **候选键**：指每个都不一样的、非空的那几个属性，有着潜在的主键意义。 比如一个表中的课程号学号，系别号等等。    #### **范式详解** >[danger]**1NF**（第一范式）是所有关系型数据库的最基本要求 >第一，二，三范式解决的是非主属性的关系。 **1NF**：列不可分就满足1NF了 就是原子性，字段不可再分割。 下面这个就不符合1NF     **2NF**：不存在部分依赖，（如果依赖于主键，则需要依赖于所有主键比如 (A,B)→C，不能存在依赖部分主键的情况） 另一种解释：每个表中的非主属性完全依赖于码 |sid|buyer-id|buyer-name|seller-id|seller-name|goods-id|goods-name|amount| | --- | --- | --- | --- | --- | --- | --- | --- | |1|89|lisi|13|wangwu|45|华为|mate-82| 可以看到里面有四个主键：sid, buyer-id, seller-id, goods-id。对于seller-name属性，它仅依赖于seller-id，跟buyer-id之类的没有任何关系，所以它对于主键的依赖是“部分依赖”，并不符合2NF。简单点说，就是**不要把不相关的东西放到一个表里**面     意义：不相关的东西不要放在一起，用多个小表连接来代替大表，减少修改时候的负担    **3NF**：不存在传递依赖，比如A→B→C。（在2NF基础上消除了传递依赖）一个数据库表中不包含已在其它表中已包含的非主关键字信息 消除非主属性之间的依赖关系，只保留非主属性与码的依赖关系 比如对于一张数据库，里面的元素有son, person, father, grand-father， 依赖关系是son -> person, person -> father, father -> grand-father，明显有一个链表式的传递，3NF中禁止此类依赖的出现     意义：避免查询路径过长而导致询问时间过长或者更新异常。以上面的家族关系为例，如果我想查询某位同学曾曾曾曾曾……曾祖父是谁，按照非3NF的依赖，则需要进行多次查询，而对于满足3NF的依赖，只需要进行一次查询。效率大大提高    **BC范式**： 解决部分主键依赖于非主键部分。每个表中只有一个候选键 BC 范式解决的是主属性的关系； ``` 第二范式：就是完全依赖，没有部分依赖；【非主属性不能依赖于主键的一部分，要完全依赖于主键】 第三范式：没有传递依赖。【非主属性之间的依赖】 BC范式： 解决部分主键依赖于非主键部分。每个表中只有一个候选键 ``` 范式这两章没听太懂，可以看一下这个https://zhidao.baidu.com/question/98317025.html?fr=ala0