理解什么是数据库规范化

数据库规范化是由Edgar Frank Codd提出的，他是IBM公司的一位计算机科学家，他在自己的论文《20世纪70年代大型共享数据银行数据关系模型》中首次提出这种说法。数据库规范化是一个过程，这个过程中需要对现存表结构进行修改，把表转化使遵循一系列先进的范式。它着重于消除开发人员和他们项目的“电子表格综合症”。电子表格综合症是指开发人员倾向于在尽可能少的表中挤下尽可能多的信息。

规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束集条件也越严格。
第一范式（1NF）
在关系模式R中中，如果每个属性值都是不可再分的原子属性，则称R是第一范式的关系[2]。例如：关系R（职工号，姓名，电话号码）中一个人可能有一个办公室电话和一个住宅电话号码，规范成为1NF的方法一般是将电话号码分为单位电话和住宅电话两个属性，即 R（职工号，姓名，办公电话，住宅电话）。1NF是关系模式的最低要求。
第二范式（2NF）
如果关系模式R是1NF且其中的所有非主属性都完全函数依赖于关键字，则称关系R 是属于第二范式的[2]。例：选课关系 SC（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）。在应用中使用以上关系模式有以下问题： （1）数据冗余，假设同一门课由40个学生选修，学分就重复40次；（2）更新复杂，若调整了某课程的学分，相应元组的CREDIT值都要更新，有可能会出现同一门课学分不同；（3）插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入；（4）删除异常，若学生已经结业，从当前数据库删除选修记录，而某些课程新生尚未选修，则此门课程及学分记录无法保存。以上问题产生的原因是非主属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。解决方法是将以上关系分解成两个关系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC中的外键CNO相联系，需要时再进行自然联接，恢复原来的关系
第三范式（3NF）
如果关系模式R是2NF且其中的所有非主属性都不传递依赖于码，则称关系R是属于第三范式的[1]。例如关系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各属性分别代表学号、姓名、所在系、系名称、系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但关系S肯定有大量的冗余，有关学生所在系的几个属性DNO，DNAME，LOCATION将重复存储，插入、删除和修改时也将产生类似以上例的情况。原因在于关系中存在传递依赖，即SNO -> DNO，DNO -> LOCATION, 因此关键字SNO对LOCATION函数决定是通过传递依赖SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。解决方法是将该关系模式分解为两个关系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），两个关系通过S中的外键DNO联系。
BC范式(BCNF)
如果关系模式R的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或者说关系模式R中，如果每个决定因素都包含关键字（而不是被关键字所包含），则R是BCNF[3]。 通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。

大致的讲主要是根据用户的需求，然后设计数据库的E-R模型，然后将E-R模型图转换为各种表，并对其进行数据库设计范式（范式因不同书籍有不同）的审核，然后进行数据库的实施，然后运行维护。

一句话来讲就是将用户的需求变成带有各种关系的表，以及其它的数据库结构，然后供编程使用

具体如下：

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下六个阶段

（1）需求分析。

（2）概念设计。

（3）逻辑设计。

（4）物理设计。

（5）数据库实施。

（6）数据库运行和维护。

5．1．1需求分析阶段

进行数据库设计首先必须准确了解与分析用户需求，包括数据与处理需求。需求分析是整个设计过程的基础，是最困难、最耗时的一步。作为“地基”的需求分析是否做得充分与准确，决定了在其上构建“数据库大厦”的速度与质量。需求分析做得不好，可能会导致整个数据库重新设计，因此，务必引起高度重视。

5．1．2概念模型设计阶段

在概念设计阶段，设计人员仅从用户角度看待数据及其处理要求和约束，产生一个反映用户观点的概念模式，也称为“组织模式”。概念模式能充分反映现实世界中实体间的联系，又是各种基本数据模型的共同基础，易于向关系模型转换。这样做有以下好处：

（1）数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。

（2）概念模式不受特定DBMS的限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。

（3）概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而能准确地反映用户的信息需求。

概念模型设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。如采用基于E-R模型的数据库设计方法，该阶段即将所设计的对象抽象出E-R模型；如采用用户视图法，则应设计出不同的用户视图。

5．1．3逻辑模型设计阶段

逻辑模型设计阶段的任务是将概念模型设计阶段得到的基本E-R图，转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。如采用基于E-R模型的数据库设计方法，该阶段就是将所设计的E-R模型转换为某个DBMS所支持的数据模型；如采用用户视图法，则应进行表的规范化，列出所有的关键字以及用数据结构图描述表集合中的约束与联系，汇总各用户视图的设计结果，将所有的用户视图合成一个复杂的数据库系统。

5．1．4数据库物理设计阶段

数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然，数据库的物理设计完全依赖于给定的硬件环境和数据库产品。在关系模型系统中，物理设计比较简单一些，因为文件形式是单记录类型文件，仅包含索引机制、空间大小、块的大小等内容。

物理设计可分五步完成，前三步涉及到物理结构设计，后两步涉及到约束和具体的程序设计：

（1）存储记录结构设计：包括记录的组成、数据项的类型、长度，以及逻辑记录到存储记录的映射。

（2）确定数据存放位置：可以把经常同时被访问的数据组合在一起，“记录聚簇（cluster）”技术能满足这个要求。

（3）存取方法的设计：存取路径分为主存取路径及辅存取路径，前者用于主键检索，后者用于辅助键检索。

（4）完整性和安全性考虑：设计者应在完整性、安全性、有效性和效率方面进行分析，作出权衡。

（5）程序设计：在逻辑数据库结构确定后，应用程序设计就应当随之开始。物理数据独立性的目的是消除由于物理结构的改变而引起对应用程序的修改。当物理独立性未得到保证时，可能会引发对程序的修改。

数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构，包括存储结构和存取方法。

5．1．5数据库实施阶段

根据逻辑设计和物理设计的结果，在计算机系统上建立起实际数据库结构、装入数据、测试和试运行的过程称为数据库的实施阶段。实施阶段主要有三项工作。

（1）建立实际数据库结构。对描述逻辑设计和物理设计结果的程序即“源模式”，经DBMS编译成目标模式并执行后，便建立了实际的数据库结构。

（2）装入试验数据对应用程序进行调试。试验数据可以是实际数据，也可由手工生成或用随机数发生器生成。应使测试数据尽可能覆盖现实世界的各种情况。

（3）装入实际数据，进入试运行状态。测量系统的性能指标，是否符合设计目标。如果不符，则返回到前面，修改数据库的物理模型设计甚至逻辑模型设计。

5．1．6数据库运行和维护阶段

数据库系统正式运行，标志着数据库设计与应用开发工作的结束和维护阶段的开始。运行维护阶段的主要任务有四项：

（1）维护数据库的安全性与完整性：检查系统安全性是否受到侵犯，及时调整授权和密码，实施系统转储与备份，发生故障后及时恢复。

（2）监测并改善数据库运行性能：对数据库的存储空间状况及响应时间进行分析评价，结合用户反应确定改进措施。

（3）根据用户要求对数据库现有功能进行扩充。

（4）及时改正运行中发现的系统错误。

是C
在关系数据库逻辑设计的时候我们要考虑的一个问题就是：如何构造一个适合于某一具体问题的数据模式。这就牵扯到数据库逻辑设计的工具——关系数据库的规范化理论。
关系模式的规范化就是根据一个关系属性间不同的依赖情况来区分其为第一，第二，第三，和第四范式，然后用直观的描述将具有不合适性质的关系转换为更合适的形式。

---