下载文档原格式
简述关系模式规范化
关系模式规范化是一种技术，是按照一定的规则将关系模式进行重新组织和整理的过程。
其宗旨在于提高系统的完整性和弹性，将数据结构按照一定的高低规则排列，使其冗余度降至最低。
关系数据模式(Relational Data Model)是一种结构化的数据模式，在逻辑数
据库系统中被用作描述数据库的数据结构(RDM亦被称为 E-R模型)。
关系模式是一种关系数据模式，可以将关系型数据库中彼此有一定联系的实体之间构建出一个逻辑关系，其中存储在数据库中的信息元素彼此联系起来，形成一条完整的记录。
它可以表示多个实体之间的一个强耦合的逻辑关系，其中的实体之间的数据结构是精确和完整的，可以很容易的进行提取和检索。
关系模式规范化有三个主要阶段：第一阶段是简单规范化(简单的冗余度消除);第二阶段是必要的规范化;第三阶段是高级规范化。
简单规范化阶段是关系模式规范化的最初阶段，主要是针对关系模式中冗余性和破坏单一原则(第一范式)引起的错误进行发现和消除，所以这一阶段的操作就是将冗余性数据移入另外的表格中。
必要的规范化阶段是对关系模式规范化的关键阶段，在该阶段，根据一定的规则移除掉第一范式中不充分函数依赖(也称为不完全函数依赖)，通过这种方式可以完全实现第二范式，也就是把所有非主属性完全依赖于主属性。
高级规范化阶段涉及重新把已经规范化的模式进步进一步抽象化，使之达到第三范式甚至第四范式水平，也就是非主属性完全的依赖于主属性，同时剔除掉冗余数据。
关系模式规范化是将关系模式按照一定的规则组织和整理的过程，有利于提升模式的完整性和弹性，降低其冗余度，它主要包括简单规范化、必要规范化和高级规范化三个阶段，是一种十分重要的数据库。
数据库设计的六个阶段详解
数据库设计的阶段
数据库设计可以分为6个阶段
1. 系统需求分析阶段
2. 概念结构设计阶段
3. 逻辑结构设计阶段
4. 物理结构设计阶段
5. 数据库实施阶段
6. 数据库运⾏和维护阶段
各阶段的任务
系统需求分析
对现实世界要处理的对象进⾏详细的调查，通过对原系统的了解，收集⽀持新系统的基础数据并对其进⾏处理，在此基础上确定新系统的功能。
1. 调查分析⽤户活动
2. 收集和分析需求数据，确定系统边界信息需求，处理需求，安全性和完整性需求
3. 编写系统分析报告
两种⽅法：⾃顶向下，⾃底向上
概念结构设计
将需求分析数据抽象成局部E-R模型，再将局部E-R模型集成为全局E-R模型
逻辑结构设计
将概念模型转换成特定DBMS所⽀持的数据模型的过程
由初始关系模式设计到关系模式规范化再到模式评价
物理结构设计
对于给定的逻辑数据模型，选取⼀个最适合应⽤环境的物理结构
数据库实施
根据逻辑设计和物理设计的结果，在计算机上建⽴起实际的数据库结构、装⼊数据、进⾏测试和试运⾏的过程。
数据库运⾏和维护
主要有以下三项内容：
1. 维护数据库的安全性和完整性
2. 监测并改善数据库性能
3. 重新组织和构造数据库。
数据库的设计⽅法、规范与技巧⼀、数据库设计过程 数据库技术是信息资源管理最有效的⼿段。
数据库设计是指对于⼀个给定的应⽤环境，构造最优的数据库模式，建⽴数据库及其应⽤系统，有效存储数据，满⾜⽤户信息要求和处理要求。
数据库设计中需求分析阶段综合各个⽤户的应⽤需求（现实世界的需求），在概念设计阶段形成独⽴于机器特点、独⽴于各个DBMS产品的概念模式（信息世界模型），⽤E-R图来描述。
在逻辑设计阶段将E-R图转换成具体的数据库产品⽀持的数据模型如关系模型，形成数据库逻辑模式。
然后根据⽤户处理的要求，安全性的考虑，在基本表的基础上再建⽴必要的视图（VIEW）形成数据的外模式。
在物理设计阶段根据DBMS特点和处理的需要，进⾏物理存储安排，设计索引，形成数据库内模式。
1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。
需求分析的重点是调查、收集与分析⽤户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的⽅法：调查组织机构情况、调查各部门的业务活动情况、协助⽤户明确对新系统的各种要求、确定新系统的边界。
常⽤的调查⽅法有：跟班作业、开调查会、请专⼈介绍、询问、设计调查表请⽤户填写、查阅记录。
分析和表达⽤户需求的⽅法主要包括⾃顶向下和⾃底向上两类⽅法。
⾃顶向下的结构化分析⽅法（Structured Analysis，简称SA⽅法）从最上层的系统组织机构⼊⼿，采⽤逐层分解的⽅式分析系统，并把每⼀层⽤数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。
系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。
数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，⽽不是数据本⾝。
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(⾄少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，⾼峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流⼊的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取⽅式｝ 处理过程描述＝｛处理过程名，说明，输⼊:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对⽤户需求进⾏综合、归纳与抽象，形成⼀个独⽴于具体DBMS的概念模型，可以⽤E-R图表⽰。
数据库设计与规范化的基本概念及方法第一章：引言随着信息技术的快速发展，大量的数据被不断地产生和积累，如何高效地管理这些数据成为了各个行业的重要挑战。
数据库设计与规范化是建立和维护高效数据库系统的关键环节。
本章将对数据库设计与规范化的基本概念及方法进行介绍。
第二章：数据库设计的概念2.1 数据库设计的定义数据库设计是指根据用户需求、组织结构和数据特点，利用数据库管理软件对数据库进行结构化设计，包括数据模型的选择、数据结构的设计以及数据操作规则的定义等。
2.2 数据库设计的目标数据库设计的主要目标是满足用户需求，提供高效可靠的数据存储和查询功能。
同时，数据库设计还应考虑数据的一致性、完整性、可扩展性和安全性等方面的要求。
2.3 数据库设计的步骤数据库设计的一般步骤包括需求分析、概念设计、逻辑设计和物理设计。
需求分析阶段主要确定用户需求和数据特点；概念设计阶段将需求转化为概念模型；逻辑设计阶段将概念模型转化为关系模型；物理设计阶段将关系模型映射为具体的物理存储结构。
第三章：数据库规范化的概念3.1 数据库规范化的定义数据库规范化是指通过一系列的规范化步骤，将非规范化的数据库模式转化为满足某种规范化要求的数据库模式的过程。
3.2 数据库规范化的目的数据库规范化的主要目的是消除冗余数据，提高数据库的灵活性，减少数据更新异常的可能性，从而提高数据库的效率和可靠性。
3.3 数据库规范化的级别数据库规范化按级别分为一般规范化和高级规范化。
一般规范化包括第一范式（1NF）、第二范式（2NF）和第三范式（3NF）；高级规范化包括第四范式（4NF）和第五范式（5NF）。
第四章：数据库规范化的方法4.1 功能依赖分析功能依赖是指在关系模型中，某个属性的值依赖于其他属性的值。
通过功能依赖分析，可以确定属性之间的依赖关系，为后续的规范化提供依据。
4.2 规范化步骤规范化的一般步骤包括分解、消除冗余和合并。
分解是指将一个关系模式分解为多个关系模式；消除冗余是指通过调整关系模式的结构，消除冗余数据；合并是指将分解后的关系模式合并为满足某种规范化要求的关系模式。
关系数据库设计目录第1章简介 (1)第2章函数依赖 (1)2.1 函数依赖的定义 (1)2.2 关系的键码 (2)2.3 超键码 (3)2.4 函数依赖规则 (3)2.4.1 分解/合并规则 (3)2.4.2 平凡依赖规则 (3)2.4.3 传递规则 (4)第3章模式设计 (4)3.1 问题的提出 (4)3.2 问题的根源 (5)3.2.1 完全依赖和部分依赖 (5)3.2.2 传递依赖 (6)3.3 解决的途径 (7)3.3.1 第1范式（1NF） (7)3.3.2 第2范式（2NF） (7)3.3.3 第3范式（3NF） (8)3.3.4 BC范式（BCNF） (8)3.4 分解的原则 (9)3.5 分解的方法 (12)3.5.1 模式分解的两个原则 (12)3.5.2 模式分解的3种方法 (13)3.5.3 把关系模式分解成BC范式的方法总结 (14)3.6 关系模式规范化小结 (15)第4章多值依赖 (16)4.1 属性独立性带来的冗余 (16)4.2 多值依赖的定义 (17)4.3 第4范式 (18)4.4 分解成第4范式 (18)第5章总结 (19)第1章简介关系数据库是由一组关系组成，所以关系数据库的设计归根到底是如何构造关系，即如何把具体的客观事物划分为几个关系，而每个关系又有哪些属性组成。
在我们构造关系时，经常会发现数据冗余和更新异常等现象，这是由于关系中个属性之间的相互依赖性和独立性造成的。
关系模型有严格的数学理论基础，并形成了关系数据库的规范化理论，这为我们设计出合理的数据库提供了有利的工具。
第2章函数依赖2.1 函数依赖的定义为了便于了解函数依赖（functional dependency）的概念，先看一个具体的关系实例。
例：考虑学生关系Student，该关系中涉及的属性包括学生的学号（Sno）、姓名（Sname）、所在系（Sdept）、系主任姓名（Mname）、课程名（Cname）和成绩（Grade）。
学生关系Student的实例如表1所示。
表 1 学生关系Student实例在这个实例中，我们可以看到属性之间存在某些内在的联系：由于一个学号值对应一个学生，一个学生只在一个系，因而当“学号”确定之后，姓名及所在系也就唯一确定了。
属性中的这种依赖关系类似于数学中的函数。
因此说Sno 函数决定Sname和Sdept，或者说Sname和Sdept函数依赖于Sno，记作Sno→Sname，Sno→Sdept。
下面给出函数依赖的严格定义：如果关系R的两个元组在属性A1，A2，…An上一致（也就是，两个元组在这些属性所对应的各个分量具有相同的值），则它们在另一个属性B上也一致。
那么，我们就说在关系R中属性B函数依赖于属性A1A2…An。
这种依赖正式记作A1A2…An→B，也就是说“A1，A2，…An函数决定B”。
其中，A1A2…An称为决定因素。
如果一组属性A1，A2，…An函数决定多个属性，比如说：A1A2…An→B1A1A2…An→B2…A1A2…An→Bm则可以把这一组依赖关系简记为：A1A2…An→B1B2…Bm例：在上例中，我们可以列举关于Student关系的以下四个函数依赖：Sno→SnameSno→SdeptSdept→MnameSno Cname→Grade由于前面的两个依赖的左边完全相同，都是Sno，用简写的形式可以把它们汇总在一行中：Sno→Sname Sdept根据函数依赖的传递规则，从Sno→Sdept和Sdept→Mname可以导出Sno→Mname。
这一点我们从感性认识上也很容易理解，一个学号对应唯一的学生，而一个学生只能有唯一的系主任。
另一方面，Sno→Cname就是错误的，它不是函数依赖，原因显而易见，如第1元组和第2元组，它们的Sno分量相同，但Cname分量却不同。
2.2 关系的键码我们已经了解了键码的概念，下面从函数依赖角度给出定义。
如果一个或多个属性的集合{A1，A2，…An}满足如下条件，则称该集合为关系R的键码（key）：（1）这些属性函数决定该关系的所有其他属性。
也就是说，R中不可能有两个不同的元组，它们在A1，A2，…An上的取值是相同的。
（2）{A1，A2，…An}的任何真子集都不能函数决定R的所有其他属性，也就说，键码必须是最小的。
例：在学生的关系中，属性集{Sno，Cname}构成Student关系的键码。
有时一个关系有多个键码。
例：在Student关系中我们可以加上属性身份证号（Idno），则关系中存在两个键码{Sno，Cname}和{Idno，Cname}。
2.3 超键码包含键码的属性集称为“超键码”（superkey），是“键码的超集”的简称。
因此，每个键码都是超键码。
但是，某些超键码不是键码。
例：在学生关系中有许多超键码，不仅键码{Sno，Cname}本身是超键码，而且该属性集的任何超集，如{Sno，Cname，Grade}，{Sno，Sname，Cname}都是超键码。
2.4 函数依赖规则假设已知某关系所满足的函数依赖集，在不知道该关系的具体元组的情况下，通常可以推断出该关系必然满足的其他某些函数依赖。
例：如果已知关系R拥有属性A，B和C，它满足如下函数依赖：A→B和B→C，则断定R也满足依赖A→C。
下面介绍3个函数依赖规则。
2.4.1 分解/合并规则（1）我们可以把一个函数依赖A1A2…An→B1B2…Bm用一组函数依赖A1A2…An→Bi（i=1,2,…,m）来替代。
这种转换成为“分解规则”（splitting rule）。
（2）我们也可以把一组函数依赖A1A2…An→Bi（i=1,2,…,m）用一个依赖A1A2…An→B1B2…Bm来替代。
这种转换称为“合并规则”（combining rule）。
2.4.2 平凡依赖规则对于函数依赖A1A2…An→B1B2…Bm，（1）如果B是A的子集，则称该依赖为平凡依赖。
（2）如果B中至少有一个属性不在A中，则称该依赖为非平凡的。
（3）如果B中没有一个属性在A中，则称该依赖为完全非平凡的。
平凡依赖规则：函数依赖A1A2…An→B1B2…Bm等价于A1A2…An→C1C2…Ck，其中C是B的子集，但C不在A中出现。
我们称这个规则为“平凡依赖规则”（trivial dependency rule）。
若函数依赖满足平凡依赖规则，则该依赖为完全非平凡依赖。
2.4.3 传递规则传递规则使我们把两个函数依赖级联成一个新的函数依赖。
如果A1A2…An→B1B2…Bm和B1B2…Bm→C1C2…Ck在关系R中成立，则A1A2…An→C1C2…Ck在R中也成立。
这个规则就称为传递规则（transitive rule）。
第3章模式设计关系数据库设计理论主要用于知道数据库的逻辑设计，确定关系模式的划分，每个关系模式所包含的属性从而使得由一组关系模式组成的关系模式作为一个整体，既能客观描述各种实体，又能准确反映各种实体之间的联系，还能实地体现出实体内部属性之间的相互依存与制约。
3.1 问题的提出在设计数据库模式的时，特别是从面向对象的ODL设计或从E-R设计直接向关系数据库转换时，很容易出项的问题是冗余性，即一个事实在多个元组中重复。
而且，我们发现造成这种冗余的最常见的原因是，企图把一个对象的单指和多值特性包含在一个关系中。
例：在2.1节，当我们把学生的单指信息（如所在系）和多值特性（如课程集）存储子啊一起的时候，就导致了信息的冗余。
表 2 学生关系Student实例当我们企图把太多的信息存放在一个关系中时，就会出现数据冗余和更新异常等问题。
主要表现如下：（1）数据冗余。
信息可能在多个元组中不必要的重复。
如学生所在的系和系主任。
（2）修改异常。
我们可能修改了一个元组的信息，但另一个元组的相同信息却没有修改。
比如，计算机系的主任换了一个人，可能由于粗心，只修改了第1元组，而没有修改第2和第3元组。
于是出现数据不一致。
然而重新设计关系Student从而出现这种错误是完全可能的。
（3）删除异常。
如果一组属性的值变为空，带来的副作用可能是丢失一些信息。
比如，如果我们从学生晓雪的课程集中删除了自动化设计，那么数据库里就没有这个学生的课程信息了。
由于课程名和学号共同组成该关系的键码，而建立数据库时，键码属性不能为空，于是，关系Student中的晓雪的元组就会消失，同时消失的还有与晓雪有关的其他属性信息。
（4）插入异常。
刚开学，学生尚未选课，使得键码属性值缺少课程名，结果导致学生的基本情况（学号、姓名、所在系）甚至系主任姓名都不能插入。
这显然不符合道理。
3.2 问题的根源关系的键码函数决定该关系的所有其他属性，由于键码能唯一的确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。
换句话说，一个关系中的所有属性都函数依赖于该关系的键码。
当我们进一步分析时，就会发现不同的属性在关系模式中所处的地位和扮演的角色是不同的。
再深入分析，又会发现不同的属性对键码函数依赖的性质和程度是有区别的。
有的属于直接依赖，有的属于间接依赖（通常称为传递依赖）。
当键码由多个属性组成时，有的属性函数依赖于整个键码属性集，而有的属性只函数依赖于键码属性集中的一部分属性。
3.2.1 完全依赖和部分依赖V （V是W的真子集）而函数依赖V→A成立，对于函数依赖W→A，如果存在W则称A部分依赖（partial dependency）于W，否则，若不存在这种V，则称A完全依赖（full dependency）于W。
从上述定义中可以得出一个结论：若W为单属性，则不存在真子集V，所以A必然完全依赖于W。
例：我们结合学生关系的例子具体说明完全依赖和部分依赖对冗余或异常有没有影响。
关系模式Student（Sno，Sname，Sdept，Mname，Cname，Grade）中（Sno，Cname）为键码，函数依赖集如下：Sno→Sname，SdeptSdept→MnameSno→MnameSno，Cname−→−P Sname，Sdept，MnameSno，Cname−→−F Grade可以看出属性Sname，Sdept和Mname都函数依赖于Sno，而部分依赖于键码，上面用P标记。
属性Grade则完全依赖于键码，上面用F标记。
观察表2关系Student的实例，就会注意到：对键码完全依赖的属性Grade没有任何的冗余，每个学生的每门课程都有特定的成绩（当然，两门课程的成绩完全相同是有可能的，但这并不意味着冗余）。
对键码部分依赖的属性Sname，Sdept和Mname由于只函数依赖于Sno，因此，当一个学生选修几门课时，这些数据就会多次重复出现，造成大量数据冗余；另一方面，当对一个学生的基本情况（学号、姓名、所在系）进行更新时，又会出现前面讨论过的异常。
