01-深究数据库E-R模型设计
参考资料(变量命名): https://fanyi.phpstudyhelper.com/ （推荐，可选格式）
参考资料(变量命名): https://unbug.github.io/codelf/ （不稳定不如直接翻译）
参考资料(E-R图): https://dbdiagram.io/d (在线E-R图绘制，语法简单)
参考资料(表设计)：https://open.yesapi.cn/list.html （为了更好的设计+结合业务）
1 数据库设计概述
1.1 何为数据库设计？
数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。
数据库设计概述图：
数据库是信息系统的核心和基础，它把信息系统中大量的数据按一定的模型组织起来，并提供存储、维护、检索数据的功能，最终使信息系统可以方便、及时、准确地从数据库中获得所需的信息。即数据库的设计目标是：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境，这里的高效率代表的是冗余少、易维护和便于使用。
数据库设计大致可分为如下几个阶段：
需求分析 → 概念设计 → 逻辑设计 → 物理设计 → 数据库实现 → 运行与维护阶段。
数据库设计阶段：
总而言之，数据库设计是一个不断迭代和逐步求精的过程。而在这个过程中，重中之重的阶段为概念设计与逻辑设计。
1.2 必须要明确的几个概念
关系：关系型数据库关系的数据结构就是一张二维表，通俗的讲，二维表名称就是关系名。
属性：二维表中的列称为属性（字段），每个属性都有一个属性名。
值域：二维表中属性的取值范围称为值域，每个属性都有一个值域。
关系模式：二维表的结构称为关系模式。设关系名为 R，其属性为 A1，A2，…，An，则关系模式可以表示为：R(A1,A2,…,An)，一个具体的例子：职工（职工号，姓名，性别，部门）。
候选码：如果一个属性集的值能唯一标识一个关系的元组而又不含多余的属性，则称该属性集为候选码。在一个关系上可以有多个候选码。
主属性：包含在任一候选码中的属性。
非主属性：不包含在任一候选码中的属性。
主键：有时一个关系有多个候选码，可以选择其中一个作为主键。每个关系有且只有一个主键。
外键：如果关系模式 R 中的属性 K 是其他关系模式的主键，那么 K 在关系模式 R 中称为外键。
2 需求分析
需求分析阶段就是分析用户的需要与要求，它是设计数据库的起点，需求分析的结果能否准确地反映用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
需求分析的主要任务就是要通过详细调查现实世界中要处理的对象，来充分了解明确用户的各种需求，最终确定系统的功能，并且必须充分考虑系统在今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
需求分析阶段的最终产物是要有明确的系统需求分析报告，一般会包括数据流图、功能模块图、数据字典等内容，并且它是指导开展数据库设计后续阶段活动的重要依据。
3 概念设计
3.1 现实世界向机器世界的过渡
概念设计是设计形成一个独立于 DBMS 的概念数据模型，用来表述数据与数据之间的联系，它直接面向现实世界，因而很容易被用户所理解，方便用于数据库设计者与用户的交流。该阶段先设计与用户具体应用相关的数据结构——用户视图，然后再不断对视图进行集成修改，最终得到一个能正确、完整地反应该单位数据及联系并满足各种处理要求的数据模型，之后再把概念模型转换成具体机器上 DBMS 支持的数据模型。
概念模型的位置层次：
概念结构设计的特点：
- 能真实、充分地反映现实世界；
- 易于理解；
- 易于更改；
- 易于向关系、网状、层次等各种数据模型转换。
概念设计的阶段的主要描述工具就是 E-R 模型（Entity-Relationship Model）。
3.2 E-R 模型
3.2.1 实体和属性
实体是 E-R 模型的基本对象，是对现实世界中各种事物的抽象。它可以是物理存在的事物，例如人、汽车等；也可以是抽象的概念，例如学校、部门等。
属性是不可分割的数据单位，用于描述实体所具有的特征，例如教师实体具有姓名、性别、地址等属性。
能够唯一表示实体的属性集称为码。
在 E-R 模型中，实体一般是长方形来体现，而属性则是椭圆形，如果属性是主码（主键），则在属性名称下用画下划线来表示。如下图所示。
教师实体：
这张图描述了一个教师的实体对象以及它拥有的姓名、性别等属性，是对现实世界信息的直观描述。
某些属性还可以划分具有独立意义的子属性，那这类属性就称为复合属性。例如人的姓名可划分为“姓”和“名”；地址属性可以划分为邮政编码、省名、市名、区名和街道这些子属性，而街道又可划分为街道名和门牌号，其层次结构如下：
复合属性的层次结构：
复合属性的用途有两个：
- 准确模拟现实世界的复合信息结构；
- 当用户需要把复合属性作为一个整体使用又需要单独使用各子属性时，属性的复合结构就显得十分重要。
例如发邮件时称呼对方可能只需要复合属性“姓名”中的“姓”就足够了。
属性按照取值的个数还可以分为单值属性和多值属性。单值属性是指此属性对于同一个实体只能取一个值，大多数的属性都属于单值属性，例如同一个人只能具有一个年龄和一种性别。但是在某些情况下，实体的属性可能取多个值，这时候的属性就称为多值属性，例如人的联系方式信息就是一个多值的，有的人有 1 个电话，有的人有 2 个或者 3 个等等，或者可以分为移动电话联系方式、固定电话联系方式和邮件联系方式等。
注意：多值属性的描述与单值属性不一致，它采用双线椭圆表示，并且在实际开发过程中，如果有多值属性出现，一般要将其另归为实体或联系。
多值属性的描述方式：
实体属性之间可能具有某种联系，例如人的年龄属性和出生日期有一种相互依赖关系，根据出生日期可以推导出人的年龄，就称年龄为导出属性或派生属性。导出属性不仅可以从另外的属性中导出，也可以从相关的实体导出。例如一个公司实体的员工数量属性的值可以通过累计该公司所有员工数得到。
还有一种属性称为可选属性，即并不是所有的属性都必须有值，有些属性的可以没有值，这就是可选属性，在椭圆的文字后用“（O）”来表示。
3.2.2 实体型和键
同一类实体构成实体类或实体集，实体类的特征用实体型来表示，实体型本质上是一个具有相同属性的实体集合，由一个实体型名字和一组属性来定义，用于描述一组实体的公共结构，该实体集合中的任一实体称为该实体型的一个实例。
例如，一个公司有上千名员工，需要在数据库中存储每个员工的信息，而这些员工的信息又都是类似的，如姓名、年龄等是这些员工相同的属性，只不过对于不同的员工其具体的属性值不同而已，此时就可以把这些类似的实体抽象为一个实体型，如：员工（员工编号、姓名、部门、性别、年龄、职称）。
由此看来，实体型这一概念也就是上文所提到的关系模式，只是换了个马甲而已，实体型名字也就是关系模式名字。
为了区别实体型中的不同实体，又引入了“键”的概念，它要求对于不同的实体，“键”的值必须不同，例如不同的员工必须要有一个不同的“员工号”来作为区别。一个实体型可以有多个键，例如“人”的姓名和生日属性是一个键，而身份证号属性是另一个键。
实体型的每个简单属性都具有一个可能的取值范围，称为值域，例如“人”的年龄值域可以为 1-150 的整数范围。
3.2.3 实体间的联系
（1）联系的种类
现实世界中，事物内部或事物之间总是有联系的，联系反映了实体内部或实体之间的关系。
联系的度数指的是一个联系所涉及的实体数。比如：单实体联系、两实体联系和多实体联系。
比较常见的为两实体联系，两个实体之间可能存在以下联系：
一对一联系（1 : 1），例如部门和负责人之间的联系，一个部门有一个负责人，一个负责人负责一个部门；一对多联系（1 : n），例如部门和员工之间的联系，一个部门有多个员工，而每个员工只属于一个部门；多对多联系（m : n），例如项目和员工之间的联系，一个项目可以需要多个员工参加，而一个员工也可以参加多个项目。
联系一般使用菱形来进行描述，上面的这几种联系可用如下 E-R 图来表示。
两实体间的联系：
单实体联系也可分为一对一、一对多、多对多联系，如员工和员工之间的“领导”关系就是一对多联系，员工与员工之间的配偶关系是一种一对一联系。
单实体间的联系：
一般地，两个以上的实体之间也存在一对一、一对多和多对多的联系。例如学生选课系统中有三个实体：学生、教师、课程，此时它们之间的联系如下：
三个实体间的联系：
它表示一个教师可以教授多门课程，一个课程可以被多个教师教授；一个学生可以选择多门课程，一门课程可被多个学生选择，学生在选课的同时选择教师。
（2）联系的存在性
除了上面联系的种类之外，还要考虑一个实体在一个联系中的存在性。存在性在转换成逻辑模式后表现为某个属性是否可以为空值，空值为不明确的值，在 DBMS 中用 NULL 表示。
一般的，联系有如下几种存在性：
- 强制存在：在
连线上划“1”，表示最小的基数为1。如果联系一端的实体的实例对于该联系的其他实体的实例必须存在，则称该实体为强制的。 - 可选存在：
连线上划“0”，表示最小基数为0。如果联系一端的实体的实例对于该联系的其他实体的实例不要求一定存在，则称该实体为可选的。 - 未知存在：
连线上不划“1”或“0”，表示目前不知道是强制还是可选的。
例如上述员工参加项目的 E-R 图，可以补充完善其联系的存在性：
标示联系存在性：
它表示一个项目至少要有一个员工参加（强制性的），而一个员工可能不参加任何一个项目（可选的）。
3.2.4 高级 E-R 构造
高级 E-R 构造指的是对 E-R 模型的扩充，简称 EER 模型（extend-ER），EER 模型包括了 E-R 模型的所有概念，此外，它还包括泛化层次、汇集层次和弱实体等概念。
（1）泛化层次
泛化层次涉及到子类、超类、泛化和特化等概念，让先来了解一下。
子类和超类
在很多应用中，一个实体型的实体需要进一步划分为多个子集合，并要明确表示出来。例如，实体型教师的成员实体可以分为教授、副教授、讲师和助教 4 个实体集合，这些集合都是教师实体集合的子集合（可定义为子实体型），称之为实体型教师的子类，而实体型教师称为这些子实体型的超类。
子类与超类之间的关系称为 IS-A 关系，子类的成员必须是超类的成员，否则不能在数据库中出现，但是超类的某些成员可以不属于任何子类。
这一概念和 Java 继承关系中的子类与父类概念是很类似的。
泛化（归纳）
泛化也称为归纳，它是将几个实体中的某些公共属性概括出来，提升为一个高一层次的超类，而原先的实体类则变为子类，子类除了它自己的属性以外还继承超类的属性。
泛化层次可分为互斥泛化层次和重叠泛化层次两种。互斥泛化层次是指子类之间是互斥的，即一个实例不可能出现在两个以上的子类中，互斥泛化层次在泛化层次图中的圆圈中写入字母 D（Disjoint）; 重叠泛化层次在泛化层次图中的圆圈中写入字母 O（Overlapping）。
例如，实体型飞机、火车和汽车可以泛化出超类运输工具，图中的双线表示运输工具实体型的每个实体必须属于一个子类，即表示子类完全包含了超类，超类中的每一个实例，子类中都有该实例，这种情形称为完全性限制。
特化（演绎）
特化是泛化的逆过程，它也称为演绎，是根据超类而演绎出子类的过程。例如，实体型教师可以演绎形成子类教授、副教授、教师和助教，这个过程是按照教师职称对教师实体的分类，它还可以使用不同的分类规则进行多种演绎。例如，可以按照教师的专业对教师实体进行演绎，得到文科教师、理科教师和外语教师等等。
（2）汇集层次
汇集（Aggregation）是另一种重要的信息抽象手段，描述了整体和部分之间的联系，即实体之间“…是…的一部分（is part of）”的联系，或者“……是由……组成的”。
汇集层次中没有继承，所以也不以超类、子类来称呼相关的实体，而是称为父实体和成份实体。
汇集的概念类似于面向对象概念中的聚合关系。例如，一个教室由房间、门窗、电脑、投影仪等等组合而成，它们之间没有继承关系。
（3）弱实体
在实际领域中经常存在这样一些实体型，它们没有自己的键（即所有属性都不足以形成主键），这种实体型的实体不能独立存在，必须要依赖于一个强实体，则称这种实体型为弱实体型。在 E-R 图中用双线框表示弱实体。
弱实体型的不同实体的属性值可能完全相同，难以区别，所以它才需要与一般的实体型进行关联，目的就是用来区分不同的弱实体。
如在人事管理系统中，职工家属的信息就是以职工的存在为前提的，家属实体是弱实体，子女与职工的联系是一种依赖联系。又如，学生家长是一种弱实体，因为只有学生实体存在，家长实体才会存在。
上图就表示了家属实体是弱实体，不能单独存在必须依赖与职工实体，这里的标示的依赖信息为存在依赖（E）和标识依赖（ID）：
存在依赖：若某个实体 X 的存在依赖于另外一个实体 Y 的存在而存在，则称 X 存在依赖于 Y。这是一种特殊的联系，用 E 表示，并用箭头表示方向，其中 X 称为弱实体，用双框表示，称 Y 为 X 的父实体。
标识依赖：如果一个实体不能用它自己的属性来唯一标识，即没有自己的主键，而只能用与其他实体的联系来标识，则称该实体标识依赖于其他实体。这也是一种特殊的联系，用 ID 表示，并用箭头表示方向。
3.3 概念设计方法与步骤
常用设计方法和策略，总体策略和方法可以归纳为 4 种。
（1）自顶向下：首先定义全局概念结构的框架，然后逐步细化。
（2）自底向上：首先定义各局部应用的概念结构，然后将它们集成起来，最终得到全局概念结构。
（3）逐步扩张：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
（4）混合策略：将应用划分为相对独立的不同功能，针对每一种功能设计相应的局部 E-R 模型，最终通过归纳合并，消去冗余和不一致，形成全局 E-R 模型。
最常用的策略是自底向上法，即先进行自顶向下的需求分析，再进行自底向上的概念设计，如下图所示。
正如上图所示，一般会根据需求中的一个独立的小模块进行概念模式的设计，然后再对这些局部视图进行集成，最终汇总成一个符合需求分析要求的全局概念模式。
自底向上概念结构设计步骤：
- 抽象数据并设计局部视图；
- 集成局部视图，得到全局概念结构。
3.4 局部 E-R 模型设计
按照上述的概念设计策略，一般情况下会先按照需求模块进行局部 E-R 模型的构建，然后在集成汇总为全局 E-R 模型。
局部 E-R 模型设计首先要确定局部 E-R 图描述的范围，一般要遵循独立性原则和规模适度原则。
独立性原则指的是划分在一个范围内的应用功能具有独立性与完整性，与其他范围内的应用有最少的联系。规模适度原则是指局部 E-R 图规模应适度，一般以 6 个左右的实体为宜。
建立 E-R 模型的步骤：区分实体和属性 → 找出汇集层次 → 找出泛化层次 → 找出弱实体 → 定义联系。
（1）区分实体和属性
实体要有描述信息。如果一个对象有多个描述信息，则应考虑将其作为实体；但如果一个对象只有一个描述信息，则应考虑将其作为属性。
如果某些非标识属性有多个值与实体对应，即属性的多个值与标识属性的一个值对应，则称其为多值属性。将多值属性归为另一个实体
将属性归到它最直接描述的实体中。例如属性“办公楼名”应归到实体部门中，而不是归到实体职工中。
（2）找出汇集层次
对基本实体进行分析，如有某个实体是由其他实体组成，则将它们构造成一个汇集层次，通常的做法是将已有的实体汇集出一个新实体。
（3）找出泛化层次
一旦完成了基本实体的划分，就可以用泛化和特化（两者都要用）来构造类层次，如果基本实体有了变化，则要重新考虑有关的泛化层次和新产生的泛化层次。要做好泛化和特化的工作，经验起着重要的作用。
（4）找出弱实体
对于弱实体，建议在建立泛化层次后再考虑，比如说一个公司的职工家属相对于公司就是一种弱实体存在。
（5）定义联系
上述工作完成之后就可以来定义实体之间的联系了。当然泛化层次、汇集层次等也是特殊类型的联系，只是做泛化、汇集等分析时通常会产生新实体，而普通的联系是指实体之间发生作用，不会产生新实体也不会减少实体。这就是为什么要到最后才考虑联系的原因。应该说定义联系是ER模型的关键，大部分的信息关联都是由联系表述出来的。
注意：联系应该是最后分析定义的阶段，在区分实体和属性的时候不要过早考虑联系。
实体之间有多个联系是可能的，但不要表示相同的概念，否则将会出现联系的冗余。冗余联系是指表示相同概念的多个联系，从 E-R 图生成关系模式时，冗余联系会导致生成的关系模式不规范，有过多的冗余。
此外，多个实体之间存在联系也是可能的，这就是多实体联系，例如上文的学生选课就是一个多实体联系的实例。
（6）建立 E-R 模型注意的几点原则
在创建 E-R 模型的过程中，一般要遵守以下几点原则：
- 属性是不可分割的；
- 每个实体有唯一的标识，而联系没有标识，一般联系的标识依赖于相关实体的标识；
- 每个子类有唯一的超类，子类本身不定义标识，而从超类中继承标识；
- 不允许弱实体作为子类，但可作为超类；
- 实体名、联系名和属性名在一个 E-R 图（局部或全局）中应唯一；
- 相同实体之间的多个联系应是可区别的。
3.5 E-R 模型的集成
由于局部 E-R 模型反映的只是局部子功能对应的数据视图，且局部 E-R 图之间可能存在不一致之处，还不能作为逻辑设计的依据，此时可以进行 E-R 模型的集成，去掉不一致和重复的地方，最终合并为全局视图。
局部 E-R 模型的集成方法有如下两种：
- 多元集成法：一次性将多个局部 E-R 图合并为一个全局 E-R 图；
- 二元集成法：用累加的方式一次集成两个局部 E-R 图。
在实际应用中一般根据系统的复杂程度选择集成的方法，并可以混合选择使用。无论采用哪种集成方法，每次集成都分为两个阶段：
- 合并：消除局部 E-R 图之间的不一致，生成初步 E-R 图；
- 优化：消除（或减少）数据冗余，生成全局 E-R 图。
视图集成最好由一个人完成，或始终在一个人主持下完成，否则不但旧的问题解决不了，新的问题也会不断产生。
下面就这两个阶段的内容进行展开叙述。
（1）合并
由于各个局部应用所面临的问题不同，且通常是由不同的设计人员进行局部 E-R 图的设计，这就导致各个局部 E-R 图之间必定存在许多不一致的地方，即存在冲突。合理地消除冲突，形成一个能为全系统中所有用户共同理解和接受的统一的概念模型，成为合并局部 E-R 模型的主要工作。
冲突主要分为三类：属性冲突、命名冲突和结构冲突。
属性冲突
① 属性域冲突，即属性值的类型、取值范围不一致。例如，员工的工号是使用数值型还是字符型。
② 属性取值冲突。例如，学生的成绩有的以百分制计，有的以五分制计。
这类冲突是由于用户在业务上的约定而引起，必须由用户协商解决。
命名冲突
命名冲突可能发生在实体、属性和联系上，常见的为属性冲突。
① 同名异义：不同意义的对象在不同的局部应用中具有相同的名字。例如，“单位”既可以表示人员所在部门，也可以作为长度、重量等度量的属性。
② 异名同义：同一意义的对象在不同的局部应用中具有不同的名字。例如学校的“系别”与“学院”实际上是同一实体。
这类冲突通常可以采取行政手段进行协商解决。
结构冲突
① 同一对象在不同局部应用中具有不同的身份。例如局部模型A中的某实体在另一局部模型B中被设计为属性，这就造成了结构上的冲突。
解决方法：将实体转化为属性或将属性转化为实体，保持结构的统一。
② 同一对象在不同局部应用中的属性组成不完全相同。例如，对同一类“员工”这一对象，在局部模型A中其属性为工号、姓名、性别、年龄4个属性，而在另一局部模型B中的属性为工号、姓名、所在部门3个属性组成。
解决方法：对实体的属性取其在不同局部应用中的并集，并适当设计好属性的次序。
③ 相同实体之间的联系在不同局部模型中不一致。例如，在局部应用A中实体E1和E2是一对多联系，而在局部应用B中却是多对多联系。
解决方法：根据应用语义对实体联系的类型进行综合或调整。
（2）优化
数据冗余和联系冗余是E-R模型的主要冗余问题，能被其他数据推导（派生）出来的数据就是冗余数据，能被其他联系推导（派生）出来的联系就是冗余联系。例如，员工实体同时具有“出生年月”和“年龄”属性，“年龄”可以从“出生年月”中推导出来，因此是冗余数据。
冗余的存在容易破坏数据的完整性，造成数据库的维护困难，应予以消除。可以利用多种方法来消除冗余，在关系型数据库中更常用规范化理论来进行分析。
4 逻辑设计
概念设计阶段得到的 E-R 模型是针对用户的概念模型，它独立于具体的 DBMS，而逻辑设计阶段的主要任务就是将其转化为具体 DBMS 所支持的数据模型。
逻辑设计阶段
这里以关系型数据库模型进行讨论，其逻辑结构设计阶段主要分为：将 E-R 图转化为关系数据模型、关系模式的规范化和优化。
4.1 将 E-R 图转化为关系数据模型
数据关系模型是一组关系模式的集合，将 E-R 图转化为关系数据模型实际上是要将实体、属性和联系转化为关系模式。一般有如下转化原则。
（1）转化实体
一个实体转化为一个关系模式，实体属性就是关系属性，实体的码（主键）就是关系的码。
例如，一个职工的关系模式为“职工（职工号、姓名、性别、年龄、职称、部门）”。
（2）转化弱实体
如果存在弱实体，则一个弱实体转化为一个关系模式，并以其依赖的强实体的码作为该关系的码。
例如，职工的家属是弱实体，则可转化成关系模式：家属（职工号，家属名，家属关系）。
（3）转化汇集层次
对于汇集层次，将基数为1的成份实体的键加入到其父实体中作为外部键，将父实体的键加入到基数为M的成份实体中，作为其外部键。
（4）转化泛化层次
对于泛化层次，将每个超类的键作为其子类的键和外部键。
（5）转化多值属性
如果存在多值属性，则多值属性要转化成一个独立的关系，并以其实体的码作为该关系的码。
例如，职工的联系方式是个多值属性，那么可以转化成“职工联系方式（职工号，联系方式）”。
（6）转化联系
一个 1:1 联系 可以转化为一个独立的关系模式，但更常用的是把联系与任意一端对应的关系模式合并。
如果转化为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转化为关系的属性，每个实体的码均是该关系的候选码。
如果把联系与一端实体的关系模式合并，具体选择哪一端需要根据应用环境确定，但应以尽量减少连接操作为目标。
例如，一个负责人管理一个部门：
一个 1:n 联系 可以转化为一个独立的关系模式，但更常用的是把联系与 n 端对应的关系模式合并。
如果转化为一个独立关系模式，则与该联系相连的各实体的码以及联系本身的属性均转化为关系的属性，而关系的码为 n 端实体的码。
在实际应用中比较常用的转化方式是把联系与 n 端实体的关系模式合并。例如，对于一个部门由多个员工组成：
可以转化为关系模式：部门（部门号，部门名称）、员工（工号，姓名，性别，部门号）。
一个 m:n 联系 转化为一个独立的关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，关系的码为各实体码的组合。
例如学生选课操作：
选课联系可以转化为模式：选课（学号，课程号，课程成绩），其中的课程成绩是联系中带的属性。
4.2 关系模式的规范化
通常情况下，数据库逻辑设计的结果（关系模式）并不唯一，为了进一步减少关系模式中的存在的异常、提高应用系统的性能，规范化理论是重要理论基础和有力工具。
4.2.1 搞清楚什么是函数依赖
在进行下面内容之前，先来看如下 3 种函数依赖的概念。假设：R(U) 是属性集 U 上的一个关系模式，X、Y 是 U 的子集。
函数依赖：用 X→Y 表示，称为“X 决定 Y”或者称为“Y 函数依赖于 X”。例如：{工号} → {职工姓名}。
完全函数依赖：如果“Y 函数依赖于 X”，且对于 X 的任一真子集 X’，都不能决定 Y，那么称“Y 完全函数依赖于 X”。例如：（学号，课程号，成绩）关系模式中，存在函数依赖 {学号，课程号} → 成绩，并且 {学号，课程号} 的任意真子集，都不能决定成绩，所以这个函数依赖即为完全函数依赖。
传递函数依赖：如果X→Z，Z→Y，且 Z 不包含 X，那么称“Y 传递函数依赖于 X”。假设有关系模式：（学号，学生姓名，班级，班主任），由学号可以得到学生所在班级，而又班级又可得到班主任，反之则不成立，所以此模式中存在传递函数依赖：{学号} → {班主任}。
4.2.2 学会求解候选
如果要对关系模式进行规范化处理，那么首先必须要明确什么是候选码、主属性、非主属性等概念。又因为根据定义，属于候选码的属性就是主属性，不属于候选码的属性就是非主属性，所以最重要的一点就是学会求解关系模式中的候选码。
设有关系模式 R，U 是组成该关系的属性名的集合，F 是属性间函数依赖关系的集合。
现在假设有：R，且 U = {A, B, C , D , E}; F = {A→B , AC→D , CD→E , E→C}，来求解此关系模式的候选码。
由上述信息可得出：UL = {A}, UR = {B}, UB ={C, D, E}。
其中 UL 表示仅在函数依赖集 F 中各依赖关系式左边出现的属性的集合，若 UL 非空，则 UL 中的任一属性必定包含在关系模式 R 的候选码中；UR 表示仅在函数依赖集 F 中各依赖关系式右边出现的属性的集合，若 UR 非空，则 UR 中的任一属性必定不包含在关系模式 R 的任一个候选码中；UB = U -UL - UR ，它表示在依赖关系式左右两边都出现的属性的集合。
结合本例，A 属性只出现在依赖关系的左侧，所以它一定包含在候选码中，而 B 属性只出现在依赖关系的右侧，所以它一定不包含在候选码中，其余的为左右两侧都有出现，所以它们可能包含在候选码中也可能不包含在候选码中。所以还要继续如下步骤。
如果 UL+ = U，即 UL 的闭包是该关系模式的整个属性集合，那么 UL 就为关系模式 R 唯一的候选码，而如果 UL+ ≠ U，那就要将 UL 依次与 UB 中的属性组合进行闭包求解了。
还是依照本例，UL = {A}，则 UL+ = {A, B}，即由属性 A 并根据 F 中的依赖关系只能推导出来属性 B（因为 F 中存在 A→B），所以此闭包结果为 {A, B} ≠ U（闭包运算其实就是由当前元素可以推导出的元素总集合），所以此时还需要 UL 中的元素与 UB 中的元素依次组合再继续求解，如下：
(AC)+ = {A, B, C, D, E} = U，所以 AC 为此关系模式的一个候选码，从而 ACD，ACE，ACDE 都不为候选码（为什么求解出来了 AC 后，就确定后面这几个不是候选码了？这还要死抠候选码的定义，见 1.2 内容）
(AD)+ = {A，B，D} ≠ U，所以 AD 不为候选码；
(AE)+ = {ABCDE} = U，所以 AE 为候选码，从而 ADE 不为候选码。
算法结束，所以当前关系模式的候选码为 AC 和 AE，那么主属性就为 A、C、E，非主属性为 B、D。
求解到了候选码、主属性和非主属性，就可以利用下面规范化理论的步骤，消除非主属性对码的不同函数依赖（主要是拆分模式），以此来达到不同的范式层次。
4.2.3 三大范式-规范化理论
通常把关系数据库的规范化过程中为不同程度的规范化要求设立的不同标准称为范式。根据关系模式满足的不同性质和规范化的程度，把关系模式分为 1NF（第一范式）、2NF、3NF、BCNF、4NF 和 5NF，它们是层层递进的关系，通常把模式 R 的第 n 范式简记为：R∈nNF。
经过上述函数依赖概念的了解以及学会候选码的求解之后，就可以根据范式的定义来对模式进行规范化处理：
第一范式 ：如果关系模式 R 的所有属性均为简单属性，即每个属性都是不可再分（原子性）的，则称R属于第一范式，记作 R∈1NF。
第二范式 ：如果关系模式 R∈1NF，且每个非主属性都完全函数依赖于 R 的码，则称 R 属于第二范式，记作 R∈2NF。
第三范式 ：如果关系模式 R∈2NF，且每个非主属性都不传递函数依赖于 R 的候选码，则称 R 属于第三范式，记作 R 属于 3NF。
BC 范式 ：如果关系模式 R∈1NF，且对于所有的函数依赖 X→Y（Y ∉ X），决定因素 X 都包含了 R 的一个候选码，则称 R 属于 BC 范式，记作 R∈BCNF。
如上几种范式的递进过程如下图所示。
4.3 关系模式的优化
为了提高数据库应用系统的性能，需要对关系模式进行修改、调整，通常采用合并与分解两种方法。
（1）合并
合并多个关系模式的主要是减小连接操作而提高查询效率。它一般的应用场景为多个关系模式具有相同的主键，并且这些关系模式主要处理多关系的查询操作。
（2）分解
为了提高数据操作效率和存储空间的利用率，可以对关系模式进行水平分解和垂直分解。
水平分解：把关系模式按照分类查询的条件分解成几个关系模式，这样可以减少应用系统每次查询需要访问的记录数，从而提高效率。
例如，某大学学生数据库存在关系模式：学生(学号，姓名，年龄，籍贯)，但是事实情况是多数查询一次仅涉及其中一类学生，则可以把学生按类别进行水平分割：本科生(…)；硕士生(…)；博士生(…)。
垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。
例如，职工情况的关系模式：职工(职工编号，姓名，性别，年龄，职务，工资，工龄，住址，电话)，但事实情况是经常查询前六项，较少使用后三项，则可以把此关系模式垂直分解：职工信息1(职工编号，姓名，性别，年龄，职务，工资)，职工信息2(职工编号，工龄，住址，电话)。
同时存在经常查询和非经常查询的属性，均可采用垂直分割的方法。其优点是减少数据传递量，提高查询速度。
5 物理设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。
数据库物理设计一般包含两个步骤：确定数据库的物理结构（存取方法和存储结构）、对物理结构进行评价（时间和空间效率）。
（1）确定数据库物理结构
① 确定数据的存储结构和存放位置
包括确定：
- 关系、索引、聚簇、日志、备份等；
- 考虑因素：存取时间、存储空间利用率和维护代价。
根据应用情况将易变部分与稳定部分、存取频率较高部分与存取频率较低部分分开存放，以提高系统性能。
② 设计合适的存取路径；
③ 确定系统配置，DBMS产品一般都提供了一些系统配置变量和存储分配参数。
（2） 评价物理结构
① 评价内容
对数据库物理设计过程中产生的多种方案的时间效率、空间效率、维护代价和各种用户需求进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
② 评价方法
定量估算各种方案的存储空间、存取时间以及维护代价，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构，如果该结构不符合用户需求，则需要修改设计。
6 数据库实现
数据库的逻辑和物理结构设计好以后，就要在实际的计算机系统中建立数据库并试运行了，这个阶段的主要工作有如下几点。
- 建立数据库结构；
- 数据装载；
- 编制与调试应用程序；
- 数据库试运行；
- 整理相关文档。
7 数据库运行和维护
数据库经过试运行后，如果符合系统设计的目标，就可以正式投入运行了。在数据库运行过程中，应用环境、数据库的物理存储等会不断发生变化，这时应由 DBA 不断地对数据库设计进行评价、调整、修改，概括起来，数据库维护工作包括以下内容。
（1）数据库的转储和恢复
转储和恢复是系统正式运行后最重要的维护工作之一。DBA 要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。
（2）数据库的安全性、完整性控制
DBA 必须根据用户的实际需要授予不同的操作权限。在数据库运行过程中，由于应用环境的变化，对安全性的要求也会发生变化，DBA 需要根据实际情况修改原有的安全性控制。
由于应用环境的变化，数据库的完整性约束条件也会变化，需要 DBA 不断修正，以满足用户要求。
（3）数据库性能的监督、分析和改进
在数据库运行过程中， DBA 必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
利用监测工具获取系统运行过程中一系列性能参数的值，通过仔细分析这些数据，判断当前系统是否处于最佳运行状态，如果不是，则需要通过调整某些参数来进一步改进数据库性能。
（4）数据库的重组织和重构造
重组织的形式分为全部重组织和部分重组织（只对频繁增、删的表进行重组织），它指按原设计要求重新安排存储位置、回收垃圾、减少指针链等，以提高系统性能，但其不会修改原设计的逻辑和物理结构。
重构造主要指部分重构造（若变化太大，重构无用），它的主要工作是根据新环境调整数据库的模式和内模式，比如：增加新的数据项、改变数据项的类型、改变数据库的容量、增加或删除索引、修改完整性约束条件。重构造的实质是修改数据库的部分模式和内模式。
