目录
自顶向下分析需求与自底向上设计概念结构：需求分析是自顶向下，概念结构是自底向上
（1）平凡函数依赖和非平凡函数依赖：X->Y，Y是X子集，平凡依赖
（2）完全函数依赖和部分函数依赖：X->Y，X子集->Y，Y部分依赖
（3）传递函数依赖和非传递函数依赖：X->Y，Y->Z，Y-x->X，X传递决定Z
2、第二范式（2NF）：所有非主属性都完全依赖于任一候选键，候选键->非主属性，候选键子集-x->非主属性
一、数据库设计方案
数据库设计是数据库应用系统开发的重要内容。在实现数据库之前，必须有明确的设计方案。
1. 数据库应用架构设计：单用户、集中、CS、分布
在不同应用需求场景中，数据库的应用架构方式是不同的。
数据库应用架构可分为单用户结构、集中式结构、客户／服务器结构和分布式结构。
2. 数据库结构设计：概念、逻辑、物理
数据库结构设计一般分为概念层、逻辑程、物理层设计，设计模型分别为概念数据模型、逻辑数据模型和物理数据模型。
3. 数据库应用访问方式设计：访问方式
数据库应用对数据库访问可以有多种方式，如直接本地接口连接访问、基于标准接口连接访问、基于数据访问层框架连接访问。
数据库结构设计模型
概念数据模型：概念，不考虑实时细节
（Concept Data Model，CDM）是一种面向用户的系统数据模型，它用来描述现实世界的系统概念化数据结构。
使数据库设计人员在系统设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析业务数据以及数据之间
的联系等，描述系统的数据对象及其组成关系。
逻辑数据模型 ：逻辑表示
(Logic Data Model，LDM)是在概念数据模型基础上，从系统设计角度描述系统的数据对象组成及其关联结构，并考虑这些数据对象符合数据库对象的逻辑表示。
物理数据模型：具体实现
（Physical Data Model，PDM）是在逻辑数据模型基础上，针对具体DBMS所设计的数据模型。
它用于描述系统数据模型在具体DBMS中的数据对象组织、存储方式、索引方式、访问路径等实现信息。
数据库建模设计过程
1）数据需求分析阶段
- 从现实业务获取数据表单、报表、查询、业务规则、数据
- 更新的说明
- 分析系统的数据特征、数据类型、数据取值约束
- 描述系统的数据关系、数据处理要求
- 建立系统的数据字典
2）数据库设计阶段
- 数据库模型结构设计（概念数据模型、逻辑数据模型、物理数据模型）
- 数据库索引、视图、查询设计
- 数据库表约束设计
- 数据库触发器、存储过程设计
3）数据库实现阶段
- 数据库创建
- 数据模型物理实现
4）数据库测试阶段
- 数据库数据上线
- 数据库系统测试
2.设计策略
- 自底向上设计
- 自顶向下设计
- 自内向外设计
- 混合策略设计
自顶向下分析需求与自底向上设计概念结构：需求分析是自顶向下，概念结构是自底向上
概念模型（CDM）：数据结构、数据操作和完整性约束
CDM是一组严格定义的模型元素的集合，
这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，
其中包括了数据结构、数据操作和完整性约束三部分。
① 数据结构表达为实体和属性;
② 数据操作表达为实体中的记录的插入、删除、修改、查询等操作;
③ 完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的完整性约束（如外键、联系、继承联系等）;
实体联系模型（ERM）：甲方用户要求
概念模型的用途
① 概念模型用于信息世界的建模
② 是现实世界到机器世界的一个中间层次
③ 是数据库设计的有力工具
④ 数据库设计人员和用户之间进行交流的语言
对概念模型的基本要求
① 较强的语义表达能力
② 能够方便、直接地表达应用中的各种语义知识
③ 简单、清晰、易于用户理解
ER模型及基本概念：现实对象
实体(Entity)
概念：一个现实世界中有别于其它对象的对象。
注意：可以是具体的、也可以是抽象的。
示例：某某学生、某某老师、某门课程
属性（Attribute）
概念：实体的特征或性质，即实体用若干属性来描述。
示例： 学生的学号、姓名、生日、年龄、性别、住址等；
课程的课程号、课程名、学时、学分、开课学院等。
分类(按结构)：简单属性(不可再分)复合属性和子属性。
示例：复合—姓名(现用名、曾用名、英文名)；住址(省、
市、区、街道、门牌号、邮政编码)。
域(Domain)：取值范围
概念：属性的取值范围。
按域的取值分：单值、多值、导出和空值(NULL)等属性。
示例：
① 单值属性—性别（每个实体只有唯一确定的值）
② 多值属性—学位值(学士、硕士、博士)；
③ 导出属性—年龄（是出生日期计算出年龄）。
键：唯一标识属性
用于唯一标识集合中的每个实体的一组属性。
示例：学生的学号；课程的课程号；选课的学号及课程号
键的分类(按属性个数)：简单键、复合键。
① 由单个属性构成的键，称为简单键
② 由两个或两个以上属性构成的键，称为复合键
候选键(Candidate Key)：有多种选择作为键的属性或属性集，且属性集的任何属性都不可缺少，如缺少任意属性，就不能成为键。
主键(Primary Key)：当存在多个候选键时，需选定一个作为实体的主键。是描述实体的唯一标识。示例：学生的身份证号、学号等。
实体型（Entity Type）：实体名+属性
概念：用实体名及其属性名集合来抽象和刻画同类实体称为实体型
示例：学生（学号、姓名、生日、年龄、性别、住址）
实体集（Entity Set）：实体集合
概念：同一类型实体的集合称为实体集
示例：一个学校所有学生构成的集合，称为学生实体集
注意：在不影响理解的情况下，可以将实体、实体型、实体集都简称为实体
实体、属性及标识符的表达：唯一标识
实体类型中的每个实体包含唯一标识它的一个或一组属性，
这些属性称为实体类型的标识符（Identifier），
如“学号”是学生实体类型的标识符，“学号”、“课程号” 共同组成“成绩”实体类型的标识符。
有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。
主流数据库建模工具Power Designer
Power Designer是一种面向软件开发生命周期的建模工具，它提供软件需求模型、业务流程模型、数据库模型、面向对象模型、自定义模型的开发支持。
Power Designer的数据建模工具特点：
• 功能强大的软件开发生命周期建模工具
• 支 持 目 前 主 流 的 数 据 库 管 理 系 统 （ 如 Oracle 、 SYBASE 、SQL Server、DB2、MySQL、PostgreSQL等）
• 支持目前多种客户端开发工具
• 满足大、中、小型数据库建模设计
Power Designer可建立的数据模型
| 概念数据模型 |
从用户角度所建模的系统数据对象及其关系，它帮助用户分析信息系统的数据结构关系 |
| 逻辑数据模型 |
从系统分析员角度所建模的系统数据对象逻辑结构关系，它帮助开发人员分析信息系统的逻辑数据结构。 |
| 物理数据模型 |
从系统设计人员角度所建模的系统数据物理存储及结构关系，它针对设计者具体定义信息系统的数据库表结构。 |
Power Designer各个数据模型之间的关系
使用PowerDesigner工具进行数据库建模
(1) 创建工程
(2) 创建数据库模型
(3) 创建实体（或实体型）
(3) 给实体命名
(3) 给实体添加属性
(3) 属性添加完成
PowerDesigner创建实体
ER模型及基本概念
联系（Relationship）
概念：反映为实体内部的联系和实体之间的某种关系。
- 实体内部的联系通常是指组成实体的各属性之间的联系
- 实体之间的联系通常是指不同实体集之间的联系
示例：选课是学生与课程之间的联系。
联系的属性：联系也可有描述属性，记录联系的信息而非实体的信息。
示例：选课的成绩和修课学期；零售的商品数量。
联系的识别：联系由参与的实体唯一确定。
示例：选课(学号、课程号)
两个实体之间可能有多个不同的联系；
一个联系所关联的是同一个实体集中的两个实体
实体间联系的类型
1.一对一联系（one-to-one，1:1）
定义:设联系R关联实体A和B。如果对应A中的每个实体，B中有且仅有一个实体与之关联,则称R是一对 一联系 ，
简记作1 :1联系。
示例：一个班级只有一位班主任,一个班主任只做一个班班主任
2. 一对多联系（one-to-many，1:N）
定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，则称R是一对多联系型，简记作1 :N联系
示例：一个班级中有若干名学生，每个学生只在一个班级学习
3. 多对多联系（many-to-many，M:N）
定义:如果对应A中的每个实体，B中有n个实体(n≥0)与之关联，如果对应B中的每个实体，A中有m个实体(m≥0)与之关联，则称R是多对多联系，简记作M:N联系
示例：一门课程同时有若干个学生选修,一个学生可以同时选修多门课程
(4) 添加联系
(4) 修改联系类型
弱实体(Weak Entities):没有键的实体
前面所讲的实体总存在键。但实际情况中，并不总是如此。
概念：不存在键的实体，称为弱实体。
不同弱实体的属性值可能完全相同，因此，难以区别。
为此，弱实体型需要与一般的实体相关联。
识别实体型与识别联系：弱实体通过关系结合实体识别
假如联系R关联弱实体A和一般实体B，
A的弱实体可以通过与实体B相结合来加以区别，
则B称为弱实体A的识别实体，R称为弱实体A的识别联系。
示例：弱实体和识别联系用粗线条
弱实体(Weak Entities)
① 识别实体与弱实体必须参与的是1:n联系，该联系即为该弱实体的识别联系
② 弱实体型必须完全参与识别联系。
③ 部分键（Partial Key）：弱实体的某些属性与识别实体的键共同区分弱实体。这些弱实体属性称为弱实体的部分键。
ER模型描述概念分层
在某些应用中，需要将实体集划分为若干子类，分类后形成层次关系，最上层为超类（Super class），下层即为子类。
示例：研究生和本科生都是学生的子类。
表示：研究生ISA（is a）学生、本科生ISA学生。ISA为这种类层次的联系。
子类属性：除可继承超类属性外还可有自己独特的属性。
注意：有时还可按其他标准分类，可根据管理的需要来定。
示例：员工分资深员工（Senior Employee）与非资深（Junior）员工。
注意：调整布局的逻辑清晰美观
三、E-R 模型的设计实例
设计一个企业职工管理数据库，主要功能有：
人事管理（人事部门）
工资管理（财务部门）
项目管理（科研部门）
第1步 设计局部 E-R 模型
（1）确定局部范围
可以按部门划分。
（2）确定实体集
人事部门：职工、部门、职务
财务部门：职工、工资
科研部门：职工、项目
（3）确定实体集的属性
人事部门：职工（职工号、姓名、性别、出生日期、工资）
部门（部门号、部门名称、部门电话、负责人）
职务（职务编码、职务名称、职务津贴）
财务部门：职工（职工号、姓名、性别、出生日期、职务）
工资（工资号、基本工资、津贴、保险、实发工资）
科研部门：职工（职工号、姓名、性别、出生日期、职务）
项目（项目号、名称、起始日期、鉴定日期）
（4）确定联系集
人事部门：职工与部门的联系（分工）
职工与职务的联系（担任）
财务部门：职工与工资的联系（领取）
科研部门：职工与项目的联系（参与）
（5）确定联系集的属性
人事部门： 职工与职务的联系有一个属性（任职时间）。
（6）画出各局部的 E-R 模型
人事管理的局部 E-R 模型
人事部门：职工（职工编号、姓名、性别、出生日期、工资）
部门（部门号、部门名称、部门电话、负责人）
职务（职务编码、职务名称、职务津贴）
工资管理的局部 E-R 模型
财务部门：职工（职工号、姓名、性别、出生日期、职务）
工资（工资号、基本工资、津贴、保险、实发工资）
项目管理的局部 E-R 模型
科研部门：职工（职工号、姓名、性别、出生日期、职务）
项目（项目号、名称、起始日期、鉴定日期）
2、组合局部 E-R 模型为全局 E-R 模型
消除各局部E-R模型之间的冲突
① 命名冲突: 包括同名异义或异名同义等。
② 属性冲突: 包括属性的数据类型、取值范围等。
③ 结构冲突
例如：在工资管理中，工资是实体，而在人事管理中，工资却是属性，合并前应去掉该属性。
在人事管理中，职务是实体，而在工资和项目管理中，职务却是属性，合并前应去掉该属性。
确定公共实体
如：职工实体。
有两个重复的属性，
该去掉哪一个？
局部 E-R模型以公共实体为中心，两两合并。
3、消除冗余，优化全局 E-R 模型
（1）实体和联系尽量减少
1 : 1 联系的或具有相同键的两个实体集根据实际情况可以合并。如 职工和工资。
（2）属性尽量减少
去除冗余的属性。
如 工资和职务两个实体都有津贴属性；
工资实体的实发工资属性可以由其他属性计算出来；
（3）实体间的联系没有冗余
改进后 E-R 模型
通过PowerDesigner将概念模型转化为逻辑模型
检查模型的正确性
通过PowerDesigner转化的逻辑模型
通过PowerDesigner转化物理模型
由物理模型生成SQL语句如下，可以copy到文本编辑器
为什么要对关系模式进行优化？
如何对关系模式进行优化？
一、实例-假设有如下表
教师学生关系模式
| Tid |
Tname |
Dlevel |
Course |
Sid |
Sname |
Semester |
Score |
| 101 |
罗晓 |
教授 |
编译技术 |
S201 |
张珍 |
2010-2011-2 |
90 |
| 102 |
杨勋 |
副教授 |
数据库 |
S201 |
张珍 |
2010-2011-1 |
80 |
| 102 |
杨勋 |
副教授 |
数据库 |
S202 |
刘景 |
2010-2011-1 |
85 |
| 102 |
杨勋 |
副教授 |
数据库 |
S203 |
张柳 |
2010-2011-1 |
83 |
| 103 |
邓英超 |
讲师 |
C语言 |
S204 |
李秀 |
2008-2009-1 |
88 |
| 101 |
罗晓 |
教授 |
编译技术 |
S205 |
傅伟相 |
2010-2011-2 |
70 |
假设数据语义: （1）教师可以在不同学期上同一门课程；
（2） 一个教师可为多位学生上课，而一个学生可选多门课程；
（3）同一门课，一个学生在某学期只能选一个教师。
根据上述语义（Tid,Course,Sid,Semester）作为该模式的主键
假设教师、学生、课程信息没有在其它表中存储
上述教师学生模式可能存在的问题
(1) 插入异常(Insert Anomaly)
如果教师新来工作，由于还没排课，学生为空，由于主键属性不能为null，导致而不能插入教师信息
(2) 删除异常(Delete Anomaly)
① 删除时删掉了其他信息；
② 删除一个元组却删除了多个元组。
(3) 冗余(Redundancy)
表现： ① 某种信息在关系中存储多次；
(4) 更新异常(Update Anomaly)
表现：① 更新一条记录却要求更新多个记录。
解决方案：
除了1:1联系的实体可以包含在一个表中，其它实体应或联系单独建立关系表中。
将上表中的两个实体及联系分解，形成三张关系表
分析为何存在这些问题
数据语义在关系模式中的体现
具体表现：在关系模式的属性间的依赖关系，此即数据依赖。
数据依赖（Data Dependency）：指通过关系模式某些属性的取值能够决定另一些属性的取值。
数据依赖分类：函数依赖、多值依赖和连接依赖
数据依赖决定因素：由现实系统中属性间相互联系的语义决定。
异常现象产生的根源：关系模式中属性间存在的这些依赖关系。
根源的体现及解决：一般来讲，关系必须含有主键和候选键。
主键值决定其他属性值，候选键的值不能重复。如果将各种数据集中于一个模式中，一般都会造成异常。
解决异常的方法，是利用规范化理论，对关系模式进行相应的分解，以消除这些异常。
规范化就是对所有的属性进行重新组合，使关系的结构更简洁、更规范。
规范化的目的是：
优化关系模式，提高数据管理的效率。
三、规范化的几个概念
1、属性的几个概念
（1）简单属性和复合属性:可不可以再分
关系模型只支持简单属性。
（2）单值属性和多值属性
关系模型只支持单值属性。
（3）基本属性和导出属性
如出生日期和年龄；
基本工资、津贴、保险和实发工资，等等。
（4）属性之间的联系
① 1:1
② 1:n
③ m:n
如 学号和联系电话。
如 班号和学号。
如 学号和课程号。
2、键的几个概念
① 单键:由一个属性组成的键称为单键。
② 多键:由关系表中的多个属性组成的键称为多键。
③ 全键:由关系表中的全部属性组成的键称为全键。
3、函数依赖：就是函数的映射关系
函数依赖是属性之间的约束关系。
定义：设X、Y是关系表R的属性（组），
如果对于R的所有元组都有：X的每一具体值都只有一个Y的值与之对应，则称X函数决定Y，或Y函数依赖于X，记作X
Y。
换句话说，如果知道了X的值，就可以在表中确定与之对应的Y的值（只有一个）。
函数依赖等价定义
假设R是一关系模式，U是R的属性集合，X、Y⊆U，r是R的一个关系实例，元组t∈R。则用t[X]表示元组t在属性集合X上的值。XY表示X和Y的并集。
函数依赖定义：
设R是一个关系模式，U是R的属性集合，X和Y是U的子集。对于R的任意实例r，r中任意两个元组t1和t2，如果t1[X]=t2[X] 则t1[Y]=t2[Y]，那么称X函数地确定Y，或Y函数地依赖于X，记作：X→Y，X称为决定子(Determinant)。
函数依赖关心的问题：
是一个或一组属性的值决定其他属性的值。
| 学号 |
姓名 |
班号 |
学院 |
课程号 |
课程名 |
联系电话 |
| 14101 |
张三 |
99141 |
自动化 |
A101 |
高等数学 |
136xxxxxxxx |
| 14101 |
张三 |
99141 |
自动化 |
A204 |
计算机网络 |
136xxxxxxxx |
| 14122 |
李四 |
99141 |
自动化 |
A101 |
高等数学 |
130xxxxxxxx |
| 14213 |
王五 |
99142 |
自动化 |
A101 |
高等数学 |
138xxxxxxxx |
| 08113 |
赵六 |
99081 |
计算机 |
A107 |
大学物理 |
137xxxxxxxx |
| 08218 |
钱七 |
99082 |
计算机 |
A204 |
计算机网络 |
133xxxxxxxx |
如果X、Y是 1 : 1 的联系，则X<->Y
如 学号 联系电话，即知道了学号，就可以在表中确定其联系电话；
同样地，知道了联系电话，也可以在表中确定其学号。
如果X、Y是 n : 1 的联系，则X->Y。
如 学号 班号，即知道了学号，就可以在表中确定其班号；
相反地，如果知道了班号，却无法确定学号。
如果X、Y是 m : n 的联系，则X和Y不存在函数依赖关系。
如 学号和课程号没有函数依赖关系。即知道了学号，无法在表中确定课程号；
同样地，如果知道了课程号，也无法确定学号
（1）平凡函数依赖和非平凡函数依赖：X->Y，Y是X子集，平凡依赖
定义：设X、Y是关系表R的属性（组），且X->Y，
若Y⊆X，则称为平凡依赖，否则称为非平凡依赖。
如 （学号，姓名）->姓名，而姓名 ⊆（学号，姓名），因此，这就是平凡依赖。
即知道了学号、姓名，就可以确定姓名，这是再平凡不过的道理。
（2）完全函数依赖和部分函数依赖：X->Y，X子集->Y，Y部分依赖
定义：设X、Y是关系表R的属性（组），且X->Y，
若X存在某个子集X1，使X1->Y成立，则称Y部分依赖于X，
否则称Y完全依赖于X。
如 （学号，姓名）->班号，而 学号->班号，
因此，班号部分依赖于（学号，姓名）。
（3）传递函数依赖和非传递函数依赖：X->Y，Y->Z，Y-x->X，X传递决定Z
定义：设X、Y、Z是关系表R的属性（组），若X->Y，Y->Z，且Y不属于X，
则称X传递决定Z，或Z传递依赖于X，否则称Z非传递依赖于X 。
如 学号->班号，班号->学院，因此，学院传递依赖于学号，或 学号传递决定学院。
Armstrong公理系统：函数映射系统
问题提出：在关系模式的规范化处理过程中，不仅要知道一个给定的函数依赖集合，还要知道由给定的函数依赖集合所蕴涵（或推导出）的所有函数依赖的集合。为此，需要有效而完备的公理系统，Armstrong公理系统即是这样的系统。
Armstrong公理：为从已知的函数依赖推导出其他的函数依赖，Armstrong提出了一套推理规则，称为Armstrong公理(Armstrong’sAxioms)。
Armstrong公理包含如下三条推理规则：
- (1) 自反律(Reflexivity) ：若Y⊆X⊆U，则X→Y。
- (2) 增广律(Augmentation) ：若X→Y，Z⊆U，则XZ→YZ。
- (3) 传递律(Transitivity) ：若X→Y和Y→Z，则X→Z。
引理 1：Armstrong公理是正确的，即由已知函数依赖，根据Armstrong公理所推导的函数依赖总是成立的。
引理 2：如下三条推理规则是正确的：
- (1) 合并规则(Union)：如果X→Y，X→Z，则X→YZ。
- (2) 伪传递规则(Pseudo Transitivity)：如果X→Y，YW→Z，则XW→Z。
- (3) 分解规则(Decomposition)：如果X→Y，Z⊆Y，则X→Z。或：如X→YZ，则X→Y，X→Z。
多值依赖：X可以决定一组Y的值
（MultiValued Dependency，缩写为MVD）
设R(U)是属性集U上的关系模式，X、Y、Z是U的子集，且Z=U−X−Y，
多值依赖X→→Y成立当且仅当对R(U)的任一关系r，
任给的一对（x，z）值有一组Y的值，这组值仅仅取决于x值而与z值无关。
称X多值决定Y或Y多值依赖于X
例如，在关系模式TEACH中有C→→T
直观上看，若X→→Y，则X的一个值唯一决定一组Y值，且这组值与X、Y之外的属性值无关
多值依赖的另一等价定义：
多值依赖X→→Y成立当且仅当对R(U)的任一关系r，
若存在元组s、t使得s[X]=t[X]，则必存在元组w、v∈r（w、v可以与s、t相同），
使得w[X]=v[X]=t[X]，而w[Y]=t[Y]，w[Z]=s[Z]，v[Y]=s[Y]，v[Z]=t[Z]。
交换s、t的Y值所得新元组仍在r中
图直观显示，x决定一组y值，这组值与z无关
由前面例子，可看出X、Y、Z之间有下述关系：
多值依赖的性质：
（1）对称性：若 X→→Y， Z=U−X−Y，则 X→→Z。
（2）函数依赖可看成是多值依赖的特例：若 X→Y，则 X→→Y
（3）若U=XY（表示X ∪ Y），则 X→→Y显然成立。
（这种多值依赖无任何实际意义，故称为 平凡的多值依赖 ）
多值依赖与函数依赖的区别
（1）函数依赖X→Y的有效性仅取决于X、Y，与X、Y之外的属性无关：
X→Y在πXY（R）上成立 <-> X→Y在π W（R）上成立
其中W满足 XY ⊆ W ⊆ U（U是关系模式R的属性集）。
多值依赖X→→Y的有效性与X、Y之外的属性范围有关：
若X→→Y在U上成立，则在W（ XY ⊆ W ⊆ U）上也成立，但反之不然。
可缩小范围但不一定能扩大范围
三、关系模式规范化理论
1、第一范式（1NF）：关系表R不存在复合属性及多值属性
定义：如果关系表R不存在复合属性及多值属性，
即：属性是不可再分，则称R满足第一范式，记作R∈1NF。
对于不满足1NF的表，其解决办法：
① 将复合属性用各子属性代替，称为简单属性
② 将含有多值属性的表分解成两张表，一张表由主键和简单属性构成，另外一张表由多值属性和主键。
2、第二范式（2NF）：所有非主属性都完全依赖于任一候选键，候选键->非主属性，候选键子集-x->非主属性
定义：如果关系表R满足1NF，且所有非主属性都完全依赖于任一候选键，
则称R满足第二范式，记作R∈2NF。
即R中不存在非主属性对键的部分函数依赖。
看看以下关系表是否满足2NF？
其中：学号和课程号构成主键
如果不是2NF,如何解决？
学号
姓名
班号
学院
课程号
课程名
成绩
14101
张三
99141
自动化
A101
高等数学
80
14101
张三
99141
自动化
A204
计算机网络
83
14122
李四
99141
自动化
A101
高等数学
91
14213
王五
99142
自动化
A101
高等数学
76
08113
赵六
99081
计算机
A107
大学物理
88
08218
钱七
99082
计算机
A204
计算机网络
69
INF转化为2NF
① 将部分依赖的非主属性和它所依赖的属性构成新的模式
② 将完全依赖的非主属性与候选键构成新模式
将上述的表分解为如下三张表
可以写成如下关系模式：
（1）学生表（学号,姓名,班号,学院）
（2）课程表（课程号,课程名）
（3）选课表（学号,课程号,成绩）
| 学号 |
姓名 |
班号 |
学院 |
| 14101 |
张三 |
99141 |
自动化 |
| 14122 |
李四 |
99141 |
自动化 |
| 14213 |
王五 |
99142 |
自动化 |
| 08113 |
赵六 |
99081 |
计算机 |
| 08218 |
钱七 |
99082 |
计算机 |
| 学号 |
课程号 |
成绩 |
| 14101 |
A101 |
80 |
| 14101 |
A204 |
83 |
| 14122 |
A101 |
91 |
| 14213 |
A101 |
76 |
| 08113 |
A107 |
88 |
| 08218 |
A204 |
69 |
| 课程号 |
课程名 |
| A101 |
高等数学 |
| A204 |
计算机网络 |
| A107 |
大学物理 |
3、第三范式（3NF）
定义：如果关系表R满足1NF，且所有非主属性都非传递依赖于R的任一候选键，
则称R满足第三范式，记作R∈3NF。
即R中不存在非主属性对键的传递函数依赖。
推论：若R不存在非主属性，则一定满足3NF。
看看以下关系表是否满足3NF？
如果不是，如何解决？
学号
姓名
班号
学院
14101
张三
99141
自动化
14122
李四
99141
自动化
14213
王五
99142
自动化
08113
赵六
99081
计算机
08218
钱七
99082
计算机
如何将1NF转化3NF
如果不满足2NF，则先按照前面方法转化2NF，然后继续下一步；
如果满足2NF，则将传递依赖的属性及其中间属性移出构成新表；
将不存在传递依赖的属性及候选键构成新表。
将上述的表分解为如下两张表
可以写成如下关系模式：
（1）学生表（学号,姓名,班号）
学号
姓名
班号
14101
张三
99141
14122
李四
99141
14213
王五
99142
08113
赵六
99081
08218
钱七
99082
（2）班级表（班号,学院）
班号
学院
99141
自动化
99142
自动化
99081
计算机
99082
计算机
4、改进的3NF（BCNF）
定义：如果关系表R满足1NF，且R的任一函数依赖关系的左部都是R的一个候选键，
则称R满足BCNF，记作R∈BCNF。
即R中不存在主属性对键的传递函数依赖或部分依赖。
推论1：R中所有非主属性对所有键都是完全依赖。
推论2：R中所有主属性对不包含它们的键都是完全依赖。
推论3：R中没有哪个属性完全依赖于非键属性。
定理： 若R满足BCNF，则一定满足3NF，但满足3NF并不一定就满足BCNF。
BCNF范式示例
假设一个教师只能讲一门课程，一门课有多个教师讲，一个学生可以选多门不同的课
学生
教师
课程
丁一
袁老师
数据库
马二
李老师
计算机网络
马二
袁老师
数据库
张三
王老师
计算机网络
张三
赵老师
数据库
李四
袁老师
数据库
王五
李老师
计算机网络
候选键有： （学生，教师）
（学生，教师）→课程
教师→课程
如果不是BCNF，如何解决？
BCNF范式的规范化
①如果不满足3NF，则先转化为3NF，然后继续下一步；
②如果满足3NF，则将部分依赖的主属性和它所依赖的主属性构成新表；然后将左端的候选键构成新表。
将上述的表分解为如下两张表
可以写成如下关系模式：
（1）学生表（学生,教师）
学生
教师
丁一
袁老师
马二
李老师
马二
袁老师
张三
王老师
张三
赵老师
李四
袁老师
王五
李老师
（2）授课表（教师,课程）
教师
课程
袁老师
数据库
李老师
计算机网络
王老师
计算机网络
赵老师
数据库
5、第四范式（4NF）
定义：如果关系表R满足第一范式，且R的任一非平凡的多值依赖X->->Y（X不包含Y），
X含有键，则称R满足第四范式，记作R∈4NF。
若R∈ 4NF，则必有R∈BCNF。
若R∈ BCNF，则不一定有R∈4NF。
若R中没有非平凡多值依赖，则必有R∈4NF。
看看以下关系表是否满足4NF？如何解决？
仓库
保管员
货品
101仓库
王xx
洗衣粉
101仓库
王xx
香皂
101仓库
陈xx
洗衣粉
101仓库
陈xx
香皂
102仓库
刘xx
微波炉
102仓库
刘xx
电吹风
102仓库
李xx
微波炉
102仓库
李xx
电吹风
102仓库
张xx
微波炉
102仓库
张xx
电吹风
4NF范式的规范化
对于U=X+Y+Z，如果有X→→Y，则将U分解XY和XZ两张表
将上述的表分解为如下两张表
可以写成如下关系模式：
（1）管理表（仓库,保管员）
仓库
保管员
101仓库
王xx
101仓库
陈xx
102仓库
刘xx
102仓库
李xx
102仓库
张xx
（2）存储表（仓库,货品）
仓库
货品
101仓库
洗衣粉
101仓库
香皂
102仓库
微波炉
102仓库
电吹风
四、规范化程度
规范化的过程
对关系模式分解，把一个低一级关系模式分解成若干个高一级的关系模式。
规范化与操作效率
片面追求高级的模式，会使数据库操作效率降低
通常情况，满足3NF就达到基本规范要求。
规范化过程：
1NF 去除复合属性和多值属性；
2NF 去除非主属性对键的部分函数依赖；
3NF 去除非主属性对键的传递函数依赖；
BCNF 去除主属性对键的传递函数依赖；
4NF 去除非平凡多值依赖。
三、反规范化处理
规范化减少了数据冗余，易于保证数据的完整性，但规范化也会导致数据库性能降低，因此，在利用规范化设计数据库时要平衡两者的关系。
规范化带来结构的完整和精确性，但同时也可能带来负面的效果。
也正是基于此，人们提出了反规范化设计的基本思想。
所谓的反规范化，就是适当降低甚至抛弃范式约束，不再要求一个表只表述其表自身，而是适当冗余性添加带有某种依赖关系的数据。
反规范化处理的主要手段有如下2种：
（1）增加冗余列或派生列
如果应用系统的常用操作需要关联其他表中的数据，则在进行表设计时，
应直接将该列融入当前表中，使其冗余存在，称为冗余列。
（2） 表的合并和分割
执行反规范化设计，表的数量往往也就会减少，而这也就降低了表连接运算的压力，
可以有力提升性能。
但反规范化的使用也会带来以下问题：
（1）数据冗余的存在
（2）降低了数据库的完整性
反规范化是把双刃剑，并不具有普遍意义，需要就事论事，用不好会伤及自身