![d80bc4d57890cc0b1ddfc91faecc9647.png](https://i-blog.csdnimg.cn/blog_migrate/b71e620a5a94cb523c71d22172866989.jpeg)
首先要了解范式是什么
规范化是组织数据库中的数据的过程。
包括根据设计规则创建表并在这些表之间建立关系,这些规则旨在通过消除冗余和不一致的依赖性来保护数据并使数据库更灵活。
自己的理解:如果是学生信息表就存只关于学生的信息,课程信息表就存课程相关的信息。不要混在一起,这样容易造成数据冗杂,浪费空间,还会在查询数据时造成混乱。
数据库范式_百度百科baike.baidu.com![7d2e72899487c13dd8008b6858d799e1.png](https://i-blog.csdnimg.cn/blog_migrate/fc392ca49ded5fd58693f09ff8b4dc48.png)
1NF - 第一范式
First normal form - Wikipediaen.wikipedia.org应该满足的条件包括:
-列名不重复
-列代表单一属性
-列里的数据是相同性质的(比如列名是出生日期,你就只能存出生日期,不能加上姓名)
-列里只存在单一的值
-存储数据的顺序不用在意
-Identify each set of related data with a primary key.
总体来说,就是数据表种的每一列都是不可拆分的最小单元
下面个例子,一个列名下面包含两组以上数据
![12928bd73d41c4641f0233c089446fac.png](https://i-blog.csdnimg.cn/blog_migrate/db09edb4a2dd452e757ccf1e36d67429.png)
根据第一范式的规则,规范化,我们先列单独一个表,把列的信息全部列出来,之后我们得到:
![c06bb7cee31f8a9681bb07fb31de353d.png](https://i-blog.csdnimg.cn/blog_migrate/f8d25b88f58772c721b915507784bae4.png)
再来一个例子(参考的网站我都贴在后面,大家可以进行自主学习):
![803c581b2b659248c42b383661aa6e7d.png](https://i-blog.csdnimg.cn/blog_migrate/3e4942e2bb0de973d888a0d773e78a7b.jpeg)
2NF 第二范式-
Second normal form - Wikipediaen.wikipedia.org-首先满足第一范式的规则
-关系不得包含任何部分依存关系
自己的理解,就是要求表里的每个列都依赖于整个主键,而不是部分的键。
每个列都和主键相关。
举个例子:顾客的地址信息不仅需要存在在顾客信息表里,其他地方也同样需要,例如订单的信息同样需要包含顾客地址信息。不用把地址信息重复存在于各个表中,而是用外键关联到其他表格。
什么是依存关系:一个信息可以决定另外一个信息
下面一个例子,“标题”列取决于“名称”和“日期”列。在这种情况下,标题的确定可以仅仅取决于名称。通过名称我们已经可以确定标题了。但是这个表格中,日期和名字构成了复合键键,导致标题的确定又部分取决于日期列。去除这种依存关系,需要删除课程详细信息并形成一个单独的表格。现在,课程详细信息基于整个关键。我们将不使用复合键。
![263083d338557cccd9a8df9f7a69974b.png](https://i-blog.csdnimg.cn/blog_migrate/12dceaa155fe3a7c5d570e169680c54f.jpeg)
![bdf9297c86d0f797209c6e9ffa623829.png](https://i-blog.csdnimg.cn/blog_migrate/f6253e08102380ee0bbec11e76d0bf58.png)
理论化的东西,需要结合实际,从例子里理解可能会更高效一些:
再来个例子:有许多课程的费用相同
COURSE_FEE无法单独确定COURSE_NO或STUD_NO的值;
COURSE_FEE和STUD_NO不能决定COURSE_NO的值;
COURSE_FEE和COURSE_NO不能决定STUD_NO的值;
因此,
COURSE_FEE将是非主要属性(non-prime attribute 这里有待验证翻译),因为它不属于一个唯一的候选键{STUD_NO,COURSE_NO};
但是,COURSE_NO-> COURSE_FEE,即COURSE_FEE依赖于COURSE_NO,也就是知道了课程编号,我们就知道了课程费用。课程编号可以称为candidate key(主键的候选者)。
(这里插一嘴,介绍一下主键和候选键的区别:
候选键-候选键可以是任何可以作为数据库中唯一键的列或列的组合。一个表中可以有多个候选键。每个候选键都可以作为主键。
主键–主键是唯一标识记录的一列或多列组合。主键只能是一个候选键。一个表可以具有多个候选键,这些候选键在表的单列或多列组合中是唯一的。他们都是主键的候选者。)
Non-prime attribute COURSE_FEE依赖于candidate key,这是部分依赖依存的关系,此关系不能存在2NF中,我们要拆分表。
要将以上关系转换为2NF,
我们需要将表拆分为两个表:
表1:STUD_NO,COURSE_NO
![e5d627739f23256f71679a2aec93e92d.png](https://i-blog.csdnimg.cn/blog_migrate/5df37238abeb1f1a1a408f8c729dbe33.png)
表2:COURSE_NO,COURSE_FEE
![39d041eba98ec086f78f226f11d5819f.png](https://i-blog.csdnimg.cn/blog_migrate/a42cd93ac712e603a34f63bd137ddcb7.png)
3NF 第三范式-
Third normal form - Wikipediaen.wikipedia.org-首先满足3NF中的规则要求:表中的每一列只与主键直接相关而不是间接相关,每一列都只直接依赖于主键。
例子例子:表employee中: empID确定员工的部门ID,部门ID确定部门名称。因此,部门名称列间接依赖于empID列。因此,它满足传递依赖。这不能采用第三范式。
![9e740e7324c7858ba04321e70924b1a0.png](https://i-blog.csdnimg.cn/blog_migrate/f9559570b33921c7c14839b3655f1bce.jpeg)
把表拆分了,员工信息表,课程信息表,部门信息表:
![9038b67e517bd60c69abaa52620dfd7e.png](https://i-blog.csdnimg.cn/blog_migrate/47aadd968f161576f10d8e79a0084e7d.jpeg)
好的,先介绍到这里,最常见的就是上面的三大范式。
满足三大范式,就基本满足了数据库对规范化的要求啦。
后面的范式,需要额外的复杂操作,但不会影响数据库的功能性。先码到这里~
3.5NF -
Boyce–Codd normal form - Wikipediaen.wikipedia.org4NF -
Fourth normal form - Wikipediaen.wikipedia.org自己的理解:数据库规范化是一个过程,针对每个数据库都执行这个过程。
NF(Normal Forms): 进行数据库设计并应用一组正式标准和规则的过程。
![29c7c25ea661298ed143a13c0c3b8164.png](https://i-blog.csdnimg.cn/blog_migrate/97d6f2cbd49d86a6a14106e9e863cfda.png)
虽然这个图里画出了6NF,但是关于SQL的规范理论还在发展当中,对6NF存在不同的意见及讨论。
参考的网站:
1NF, 2NF, 3NF and BCNF in Database Normalizationwww.studytonight.com What is Normalization? 1NF, 2NF, 3NF & BCNF with Exampleswww.guru99.com![2929a8172892cdf3d87acd28eebb1ef1.png](https://i-blog.csdnimg.cn/blog_migrate/29ba11c2740bf8bae34fa9583e8ba30d.png)
![bf7f4a6e86141fa07e3d5cfbb782a572.png](https://i-blog.csdnimg.cn/blog_migrate/193d39e3ad066acf7dca39908e569dbf.png)