Mysql之数据库设计规范

1. 三大范式

首先要明白”范式（NF）”是什么意思。按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

1.1 第一范式

消除一个字段包含多个数据库值，消除一个记录包含重复的组（单独的一列包含多个项目），即可满足1NF。符合1NF的关系中的每个属性都不可再分。如下表所示的情况，就不符合1NF的要求。

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。
但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表中的设计：

（1）每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的——插入异常。
（2）假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常
（3）假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。
（4）正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

1.2 第二范式

消除部分依赖性即可转化为2NF。部分依赖性表示一个记录中包括的字段只依赖于主键的一部分。解决部分依赖性的最简单方法是将复合主键分成两部分，每一部分表示一个单独的表。其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。

1.2.1 函数依赖

我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。
例如，对于上例表中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如：系名 → 系主任 学号 → 系主任 （学号，课名） → 分数 但以下函数依赖关系则不成立：学号 → 课名 学号 → 分数 课名 → 系主任 （学号，课名） → 姓名。

1.2.2 码

设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）

1.2.3 非主属性

包含在任何一个码中的属性成为主属性。

1.3 第三范式

消除可传递依赖性即可满足3NF。可传递依赖性表示记录中至少一个值不依赖主键，而是依赖于这个记录中的另一个字段。
符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

1.4 BCNF范式

要了解 BCNF 范式，那么先看这样一个问题：

如下：
某公司有若干个仓库；
每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；
一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量码：（管理员，物品名），（仓库名，物品名）主属性：仓库名、管理员、物品名， 非主属性：数量，不存在非主属性对码的部分函数依赖和传递函数依赖。此关系模式属于3NF。基于此关系模式的关系（具体的数据）可能如图所示：

好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。
从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。仓库（仓库名，管理员）库存（仓库名，物品名，数量）这样，之前的插入异常，修改异常与删除异常的问题就被解决了。以上就是关于 BCNF 的解释。
BCNF（Boyce-Codd Normal Form）可以看作更好的3NF。在满足第二第三范式的情况下，决定项内部也不能部分或传递依赖。简单点看就是：箭头左边的必须是码，不是码的就不是BCNF。

2. 数据库设计相关

2.1 数据规范化

关系模式满足的约束条件称为范式。范式由低到高分为：1NF、2NF、3NF、BCNF、4NF、5NF。
规范化：就是指把一个低一级的关系模式分解为高一级关系模式的过程。
规范化的基本思想：逐步消除不合适的函数依赖，使数据库中的各个关系模式达到某种程度的分离。
函数依赖：通俗的说，就像自变量x确定之后，相应的函数值f(x)也就唯一的确定了一样。
码：给定一个码能完全决定一个元组。一个关系可能有多个码，选其中一个做为主码。包含在任一码中的属性称为主属性。不包含在任何码中的属性称为非主属性。
第一范式（1NF）：如果关系中所有属性的值域都是简单域，其元素（属性）不可再分，是属性项不是属性组，那么关系模式属于第一范式。这一限制是关系的基本性质，所以任何关系都必须满足第一范式。
第二范式（2NF）：如果一个范式属于1NF，且所有的非主属性都完全的依赖主属性，称为第二范式。可以用分解的方法消除部分依赖的情况，而使关系达到2NF的标准。方法是从现有关系中分解出新的关系表，使每个表中所有的非关键字都完全依赖于各自的主关键字。
(消除部分依赖)
第三范式（3NF）：如果一个关系属于2NF，且每个非主属性不传递依赖于主属性，这种关系是3NF。从2NF中消除传递依赖，就是3NF。
(消除部分传递依赖)
BC范式（BCNF）：无论2NF还是3NF都没有涉及主属性间的函数依赖，所以有时仍会引起一些问题。
定义：如果关系模式属于1NF，且每一个函数依赖关系中的决定因素都包含码，则关系满足BC范式。主属性对不含他的码完全函数依赖，没有属性完全函数依赖于一组非主属性。
多值依赖和4NF：第四范式是BC范式的推广。
定义：关系模式R

2.2 数据库设计

2.2.1 常用方法：

(1)基于3NF的数据库设计方法：
在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将他们组织成一个单一的关系模式，然后再分析模式中不符合3NF的约束条件，用投影和连接的办法将其分解，使其达到3NF。
(2)LRA方法：逻辑记录存取法。
(3)基于实体联系（E-R）的数据库设计方法。
(4)基于视图概念的数据库设计方法。
(5)面向对象的关系数据库设计方法。
通常将数据库设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计4个阶段。

2.2.2 概念结构设计

概念结构设计常用的方法是实体分析法、属性综合法。
二元联系的类型与定义：二元联系指两个实体之间的联系。分为一对一、一对多、多对多3种。
（1）一对一联系：对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系。
（2）一对多联系：对于实体集A中的每一个实体，实体集B有n个实体（n>=0）与之联系，反之对于实体集B中的每一个实体，实体集A至多只有一个实体与之联系。则实体集A与实体集B有一对多关系，记为1:n。
（3）多对多联系：若对于实体集A中的每一个实体，实体集B有n个实体（n>=0）与之联系。反过来，对于实体集B中的每一个实体，实体集A有m个实体（m>=0）与之联系。则实体集A与实体集B具有多对多联系，记为m:n。
消除冗余联系：若出现两个或两个以上的联系表示的是同一概念，则存在着冗余的联系，具有冗余联系的E-R模型转换为关系模型可能会得到非规范化的关系，因此必须予以消除。
警惕连接陷阱：
连接陷阱是一种存在语义缺陷的联系结构，分为扇形陷阱、断层陷阱、深层扇形陷阱3种信息。
扇形陷阱：指由一个实体引出的两种不同类型的扇形联系，形成双扇形结构。

2.2.3.数据库物理设计

利用已确定的逻辑结构及DBMS提供的方法、技术。已较优的存储结构、数据存储路径、合理的数据存储位置及存储分配，设计一个高效可实现的物理数据库结构。

3. 模式

数据库三级模式结构：这是数据库管理系统内部的系统结构。

3.1 概念模式

只涉及行的描述，不涉及具体的值。概念模式的一个具体值称为模式的一个实例，同一模式可以有很多实例。概念模式反映的是数据库的结构及其联系，所以是相对稳定的。而实例反映的是数据库某一时刻的状态，所以是相对变动的。
概念模式不仅要描述记录类型，还要描述记录间的联系、操作、数据的完整性、安全性。但概念模式不涉及存储结构、访问技术等细节。

3.2 外模式

也称用户模式或子模式。是用户与数据库系统的接口，是用户用到的那部分记录的描述。由若干外部记录组成，用户使用DML（数据操作语言）操作外模式的外部记录。

3.3 内模式

也称存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。定义所有内部记录的类型、索引、文件的组织方式。记录的存储方式是顺序存储、B树存储、Hash方法存储等。
两级映像：模式/内模式映像、外模式/模式映像。
实体与记录：实体表示客观存在，能区别的事物。记录是字段的有序集合，一般一条记录描述一个实体。
属性与字段：属性描述实体某方面的特性，字段标记实体属性的命名单位。
码与记录码：码是唯一能区分实体的属性或属性集，记录码是唯一标识文件中的每条记录的字段或字段集。
实体集与文件：实体集是具有共同特性的实体的集合。文件是同一类记录的汇集。
实体型与记录型：实体型是属性的集合，记录型是记录的结构定义。

3.4 数据模型三要素

数据库结构的基础是数据模型，是用来描述数据的一组概念和定义。
数据模型三要素是数据结构、数据操作、数据的约束条件。
E-R模型：是实体-联系模型的简称。所采用的3个主要概念是实体、联系、属性。
实体：现实世界中可以区别其它对象的物体或事件。
联系：实体的联系分为实体内部的联系和实体与实体之间的联系。
两个不同实体之间的联系：
（1）一对一：指实体集E1中的一个实体最多只与实体集E2中的一个实体相联系。（1:1）
（2）一对多：表示实体集E1中的一个实体可与实体集E2中的多个实体相联系。（1:N）
（3）多对多：表示实体集中E1中的多个实体可与实体集E2中的多个实体相联系。（M:N）
两个以上不同实体集的联系：
两个以上不同实体集之间存在1：1：1、1：1：N、1：M：N和R：M：N
同一实体集内的二元联系：
同一实体集内的各实体之间也存在1：1、1：N和M：N的联系。
属性是实体某方面的特性。
派生属性可以从其它属性得来，例如：参加工作时间和工作年限，工作年限可以从当前时间和参加工作时间得到，这里工作年限就是一个派生属性。
概念模型中最常用的方法是实体-联系法，简称E-R方法。
扩充的E-R模型：
弱实体：这种实体对另一些实体有着很强的依赖关系，即一个实体的存在必须以另一个实体为前提。例如职工与家属的关系。
特殊化：一个实体集可以按照某种特征区分为几个子实体。例如：学生实体集可以分为研究生、本科生、大专生。我们称这种过程为特殊化，反之叫普遍化。
层次模型：采用树形结构表示数据与数据之间的联系。
网状模型：采用网状结构表示数据与数据之间的联系。
关系模型：在关系模型中以表格结构表达实体集，以及实体集之间的联系。
关系代数：
笛卡尔积：D1={0，1}、D2={a，b}。D1*D2={0,a}{0,b}{1,a}{1,b}。
关系的3种类型：
基本关系：实际存在的表，是实际存储数据的逻辑表示。
查询表：查询结果对应的表。
视图表：由基本表或其它视图表导出的表，由于它本身不独立存储在数据库中。数据库只存放它的定义，所以常称为虚表。
完整性约束：
完整性规则提供了一种手段来保证授权用户对数据库操作修改时不会破坏数据的一致性。
关系的完整性分为3类：
（1）实体完整性：规定基本关系R的主属性A不能取空值。
（2）参照完整性：在关系模型中实体与实体间的联系是用关系来描述的。这样自然就存在着关系与关系间的引用。
（3）用户定义完整性：反映某一具体应用所涉及的数据必须满足的语义要求，由应用环境决定。
5种基本的关系代数运算：并、差、广义笛卡尔积、投影、选择。
扩展关系运算：交、连接、除、广义投影、外连接。
SQL支持三级模式结构：视图对应外模式，基本表对应模式，存储文件对应内模式。

3.4 索引

数据库中索引与书籍中索引类似，利用索引可以快速查找整本书信息，无需阅读整本书。
数据库索引可以使数据库程序无需对整个表进行扫描，就可以在其中找到所需数据。
索引分为：
聚集索引和非聚集索引。
聚集索引是指索引表中索引项的顺序与表中记录的物理顺序一致的索引。
视图创建遵循如下规定：
（1）子查询不允许有order by和distinct语句。
（2）with check option表示对update、insert、delete操作时保证更新、插入或删除的行满足视图定义的谓词条件（即满足子查询中的where后的条件表达式）。
（3）组成视图的属性列名或者全部省略或者全部指定。如果省略属性列名，则隐含视图由SELECT子查询目标列的主属性组成。
SQL的访问控制：数据库控制是控制用户的存储权限,由DBA来决定。
通过GRANT和REVORK将授权通知系统，并存入数据字典。

4. 规范化

规范化：将关系模式从低一级范式转化成高一级范式的过程。
5NF包含于4NF包含于BCNF包含于3NF包含于2NF包含于1NF。
1NF定义：关系模式R中的每个分量是不可再分的数据项，则关系模式R属于第一范式。1NF冗余度大、引起修改的不一致性、插入及删除异常。
2NF定义：若关系模式属于1NF，且每个非主属性完全依赖于码，则关系模式属于2NF。即1NF消除了非主属性对码的部分函数依赖。
3NF定义：2NF消除了非主属性对码的传递函数依赖，则称3NF。3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分函数依赖和传递依赖。
BCNF（巴科斯范式）：即3NF消除了主属性对码的部分和传递依赖，称为BCNF。
4NF：4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
如果只考虑函数依赖，BCNF是关系模式最高的规范化程度。如果考虑多值依赖，4NF是关系模式最高的规范化程度。

5. 事务管理

事务有4个特性ACID。
原子性（A）：要么全做，要么全不做。
一致性（C）：一个事务独立执行的结果，将保持数据的一致性，即数据不会因为数据的执行而遭受破坏。
隔离性（I）：一个事务的执行不能被其它事物干扰。
持久性（D）：一个事物一旦提交，对数据库的改变必须是永久的。
SQL中事物定义语句有3条：
BEGIN TRANSACTION：事务开始。
COMMIT：事务提交。
ROLLBACK：事务回滚。

6. 并发控制

并发控制主要技术是*，主要包含：排他锁（简称X锁或写锁）、共享锁（简称S锁或读锁）。
排他锁：若事务T对数据对象A加上X锁，则只允许T读取和修改A。其它事务不能对A加任何锁，直到T释放锁。
共享锁：若事务T对数据对象A加上S锁，则只允许T读取A，但不能修改A。其它事务只能再对A加S锁。保证其它事务可以读取A，但在T释放A上的S锁前不能修改A。
三级*协议：
一级*协议：事务在修改数据前必须先对其加X锁，直到事务结束才释放（结束包括commit或rollback）。一级*协议解决丢失更新的问题。
二级*协议：在一级协议的基础上，加上事务在读数据之前必须加S锁，读完后即可释放S锁。二级*协议解决读脏数据的问题。因为读完后即释放，所以不能保证可重复读。
三级*协议：在一级协议的基础上，加上事务在读数据之前必须加S锁，直到事务结束时释放S锁。除了防止丢失更新、读脏数据的问题，还进一步防止不可重复读。
活锁和死锁：
活锁：当事务T1*数据R，事务T2请求数据R于是T2等待。T1释放了R上的*，系统首先批准了T3的请求，T2继续等待，之后系统批准了T4的请求……依此类推，T2可能永久等待。这种现象称为活锁。
死锁：是指两个以上事务分别请求*对方已经*的数据，导致长期等待而无法继续进行下去的现象叫死锁。
并发调用可串行性：
多个事务并发执行，当且仅当其结果与某一次序串行地执行它们时的结果相同，我们称这种调度是可串行化调度。
给定一个并发调度，当且仅当它是可串行化的才认为是正确调度。
两段*协议：指所有事务必须分为两个阶段对数据项加锁和解锁。
第一阶段是获得*：事务可以获得任何数据项上的任何类型的锁，但不能释放。
第二阶段是释放*：事务可以释放任何数据项上的任何类型的锁，但不能申请。
事务是不能嵌套的，因为这违背了事务的原子性。事务是不能嵌套是指当且仅当当前没有事务在运行时，程序才能执行BEGIN TRANSACTION操作。
通过Resource授权来控制创建新关系的能力，具有Resource授权的用户在创建新关系后自动获得该关系上的所有权限。