【mysql数据库建模】建模方法论
一、数据库建模的整体步骤
需求分析->结构设计和行为设计->数据库实施->数据库运行与维护
二、模型结构设计的思路
三、好的数据模型的判定
1.对真实世界的抽象和表达要正确并且完整；
2.需要使用标准化的建模语言，使数据模型能够清晰的表达设计的思想，让人容易理解并不产生歧义
3.数据模型的框架稳定并且灵活，能够一定程度上容纳未来的变化
4.根据需求的实际情况，不要随意的逆规范化，要尽可能的减少数据冗余
5.需要充分考虑潜在的性能问题，尤其要根据数据库产品的特点，避免使用数据库产品的短处。
6.要不仅仅站在当前项目的视角去构筑模型，需要从企业的全局视角出发，比如方便其他系统访问，可以很方便的外部数据接口，命名规则术语定义和企业标准保持一致，等等。
四、数据库三范式和BCNF(第四范式)
1、概念
第一范式：设R为任一给定关系，如果R中每个列与行的交点处的取值都是不可再分的基本元素，则R为第一范式。 （单元格存储的值为最小单元，不可分割）
第二范式：设R为任一给定关系，若R符合范式一 （1NF）， 且其所有非主属性都完全函数依赖于候选关键字，则R为第二范式。 （消除部分函数依赖，除了联合唯一索引键的其他属性，完全依赖联合唯一索引键，）
第三范式：设R为任一给定关系，若R为2NF， 且其每一个非主属性都不传递函数依赖于候选关键字，则R为第三范式。（消除传递函数依赖，表中的非主属性都是一个类型的数据）
应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：
- 减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）
- 消除异常（插入异常，更新异常，删除异常）
- 让数据组织的更加和谐…
2、函数依赖,完全函数依赖,部分函数依赖,传递函数依赖概念
2.1、函数依赖概念
函数关系 y = f(x)，[ f(x)->y ] 在x的值确定的情况下，y的值一定是确定的。
(图1)
对于上述表中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。
所以我们可以说【姓名】 函数依赖于 【学号】，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说 【学号】函数依赖于 【姓名】
表中其他的函数依赖关系还有如：
- 系名 → 系主任学号 → 系主任
- （学号，课名） → 分数
但以下函数依赖关系则不成立：
- 学号 → 课名
- 学号 → 分数
- 课名 → 系主任
- （学号，课名） → 姓名
2.2、完全函数依赖
在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作
图1
例如： 学号 F→ 姓名 （学号，课名） F→ 分数 （注：因为同一个的学号对应的分数不确定，同一个课名对应的分数也不确定）
2.3、部分函数依赖
假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，
例如：（学号，课名） P→ 姓名
2.4、传递函数依赖
假如 Z 函数依赖于 Y，且 Y 函数依赖于 X （感谢 @百达 指出的错误，这里改为：『Y 不包含于 X，且 X 不函数依赖于 Y』这个前提），那么我们就称 Z 传递函数依赖于 X ，记作
3、码，主属性，非主属性
3.1、码
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码） 例如：对于上图表，（学号、课名）这个属性组就是码。该表中有且仅有这一个码。（假设所有课没有重名的情况）
3.2主属性，非主属性
主属性：包含在任何一个码中的属性成为主属性。例如：上图的表结构，主属性就有两个，学号 与 课名。
非主属性：除去所有的主属性，剩下的就都是非主属性了。
4、三范式规范化的过程示意
数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
4.1、第一范式
1NF的定义为：符合1NF的关系中的每个属性都不可再分。表1所示的情况，就不符合1NF的要求。
《表1》
实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：
《表2》
4.2、第二范式
但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：
《表3》
对于表3，主属性就有两个，学号 与 课名。
首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：
- 第一步：找出数据表中所有的码。
- 第二步：根据第一步所得到的码，找出所有的主属性。
- 第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
- 第四步：查看是否存在非主属性对码的部分函数依赖。
对于表3，根据前面所说的四步，我们可以这么做：
【第一步】：
- 查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
- 查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
- ……
- 查看所有包含了六个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
看起来很麻烦是吧，但是这里有一个诀窍，就是假如A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）
图4表示了表中所有的函数依赖关系：
这一步完成以后，可以得到，表3的码只有一个，就是 （学号、课名） 。
【第二步】：主属性有两个：学号 与 课名
【第三步】：非主属性有四个：姓名、系名、系主任、分数
【第四步】：
- 对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
- 对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
- 对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。
- 所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。
为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，这个过程叫做”模式分解“。模式分解的方法不是唯一的，以下是其中一种方法：
- 选课（学号，课名，分数）
- 学生（学号，姓名，系名，系主任）
我们先来判断以下，选课表与学生表，是否符合了2NF的要求？
- 对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。
- 对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。
表4表示了模式分解以后新的数据
《表4》
所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。
4.3、第三范式
3NF在2NF的基础之上，要消除非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
接下来我们看看表4中的设计，是否符合3NF的要求。
- 对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
- 对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
- 选课（学号，课名，分数）
- 学生（学号，姓名，系名）
- 系（系名，系主任）
对于选课表，符合3NF的要求，之前已经分析过了。
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。
新的函数依赖关系如图6
《图6》
经过模式分解后，新的表结构如下
结论
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。
4.4、BCNF范式（第四范式）
要了解 BCNF 范式，那么先看这样一个问题：
若：
某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；
一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？
答：已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
码：（管理员，物品名），（仓库名，物品名）
主属性：仓库名、管理员、物品名
非主属性：数量
- ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
- ∴ 此关系模式属于3NF。
基于此关系模式的关系（具体的数据）可能如图所示：
好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：
- 先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
- 某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。
- 如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。
从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。
造成此问题的原因：存在着主属性对于 码的部分函数依赖 与 传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。
解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
- 仓库（仓库名，管理员）
- 库存（仓库名，物品名，数量）
这样，之前的插入异常，修改异常与删除异常的问题就被解决了。
以上就是关于 BCNF 的解释。
问：关于码的定义，如果除K之外的所有属性都完全函数依赖于K时才能称K为码，那么在判断2NF时又怎么会存在非主属性对码的部分函数依赖这种情况？
答 ：在“码”的定义中，除 K 之外的所有属性应该看成是一个集合 U（也就是一个整体），也就是说，只有 K 能够完全函数决定 U 中的每一个属性，那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性，而不能完全函数决定另外一部分属性，那么 K 不是码。
比如有关系模式 R (Sno, Sname, Cno, Cname, Sdept, Sloc, Grade)，
其中函数依赖集为 F=
{
- Sno → Sname,
- Sno → Sdept,
- Sdept → Sloc，
- Sno → Sloc,
- Cno → Cname,
- (Sno, Cno) → Grade
}
那么 R 中的码只能是 (Sno, Cno)，Sno 或 Cno 并不能完全函数决定除 Sno / Cno 之外的所有其他属性（其实就是不能决定 Grade )，所以单独的 Sno 与 Cno 并不能作为码。
所以可得到主属性：Sno, Cno
非主属性：Sname, Cname, Sdept, Sloc, Grade
R 中存在非主属性 Cname 对于码 (Sno, Cno) 的部分函数依赖 (Cno → Cname) 。
（还有很多别的例子就不一一列举了）。所以 R 不符合 2NF 的要求。
