大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
一、关系数据库设计理论
1、设计一个合适的关系数据库系统的关键是关系数据库模式的设计，即应构造几个关系模式， 每个模式有哪些属性，怎样将这些相互关联的关系模式组建成一个适合的关系模型，关系数据库 的设计必须在关系数据库设计理论的指导下进行。
2、关系数据库设计理论有三个方面的内容：函数依赖、范式和模式设计。函数依赖起核心作用， 它是模式分解和模式设计的基础，范式是模式分解的标准。
【例1】设计一个学生课程数据库，其关系模式SDSC(Sno, Sname, Age, Dept，DeptHead, Cno,Grade)，各属性含义为学号、姓名、年龄、系、系主任姓名；课程号、成绩。根据实际情况， 这些属性语义规定为：
（1）一个系有若干学生，一个学生只属于一个系。
（2）一个系只有一个系主任。
（3）一个学生可以选修多门课程，一门课程可被多个学生选修。 （4）每个学生学习每门课程有一个成绩
从上述语义规定和分析表中数据可以看出，(Sno, Cno)能唯一标识一个元组，所以，(Sno, Cno)为该关系模式的主码，但在进行数据库操作时，会出现以下问题。
（1）数据冗余（2）插入异常（3）删除异常（4）修改异常
由于存在上述问题，SDSC不是一个好的关系模式。为了克服这些异常，将S关系分解为学生关系S (Sno, Sname, Age, Dept)，系关系D(Dept，DeptHead)，选课关系SC(Sno, Cno,Grade)，这三个关系模式的实例如表2、表3、表4所示。
二、规范化
规范化的基本思想是尽量减小数据冗余，消除数据依赖中不合适的部分，解决插入异常、删除异常和更新异常等问题，这就要求设计出的关系模式要满足一定条件。在关系数据库的规范化过程中，为不同程度的规范化要求设立的不同标准或准则称为范式。满足最低要求的称为第一范式，简称1NF，在第一范式基础上满足进一步要求的成为第二范式2NF，以此类推。
1971年至1972年，E.F.Codd系统地提出了1NF、2NF、3NF的概念，讨论了关系模式的规
范化问题。 1974年，Codd。和Boyce又共同提出了一个新范式，即BCNF。1976年有人提出了4NF，后又有人提出了5NF
各个范式之间的集合关系可以表示为：
5NF4NFBCNF3NF2NF1NF
如下图所示：
1、第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域
。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
2、第二范式（2NF）
在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。
例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
3、第三范式（3NF）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式
（2NF）。
数据库范式而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
4、巴斯-科德范式（BCNF）
Boyce-Codd Normal Form（巴斯-科德范式），在3NF基础上，任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）
巴斯-科德范式（BCNF）是第三范式（3NF）的一个子集，即满足巴斯-科德范式（BCNF） 必须满足第三范式（3NF）。通常情况下，巴斯-科德范式被认为没有新的设计规范加入，只是 对第二范式与第三范式中设计规范要求更强，因而被认为是修正第三范式，也就是说，它事实上是对第三范式的修正，使数据库冗余度更小。这也是BCNF不被称为第四范式的原因。某些书上， 根据范式要求的递增性将其称之为第四范式是不规范，也是更让人不容易理解的地方。而真正的第四范式，则是在设计规范中添加了对多值及依赖的要求。
【目的原则】
规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空问，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
【反范式（了解）】
规范化的优点是明显的，它避免了大量的数据冗余，节省了存储空间，保持了数据的一致性。当一个库里的数据经常发生变化时，达到3NF的库可以使用户不必在超过两个以上的地方更改同 一个值。那么是不是只要把所有的表都规范为3NF后，数据库的设计就是最优的呢?这可不一定。范式越高意味着表的划分更细，一个数据库中需要的表也就越多，用户不得不将原本相关联的数据分摊到多个表中。当用户同时需要这些数据时只能采用连接表的形式将数据重新合并在一起。同时把多个表联接在一起的花费是巨大的，尤其是当需要连接的两张或者多张表数据非常庞大的时候，表连接操作几乎是一个噩梦，这严重地降低了系统运行性能。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/170930.html原文链接：https://javaforall.net
