Ⅰ 对数据库模式进行规范化处理是在数据库设计的什么阶段
逻辑设计阶段。
因为开发到后面数据库用的地方多了，数据库动一动都是大改。
关系模式的规范化就是根据一个关系属性间不同的依赖情况来区分其为第一，第二，第三，和第四范式，然后用直观的描述将具有不合适性质的关系转换为更合适的形式。
(1)数据库非规范化处理扩展阅读：
如果关系模式在达到1NF的基础上，使每个非主属性都完全依赖于每个关系键，则该关系模式达到2NF的要求。
如果关系模式属于2NF，且每个非主属性都不传递依赖于关系的任何键，这该关系模式属于3NF的要求。
若关系符合1NF，且对于每个函数依赖X→Y，X必含有候选键，或者关系中的每个决定属性集都是候选键，则关系达到BCNF的要求。
Ⅱ 为什么数据库规范化处理
通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。
要求一：表中应该避免可为空的列。
虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。
所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。
一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。
二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。
要求二：表不应该有重复的值或者列。
为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。
所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
要求三：表中记录应该有一个唯一的标识符。
在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。
要求四：数据库对象要有统一的前缀名。
一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。
要求五：尽量只存储单一实体类型的数据。
这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。
遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。
以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。
Ⅲ 在数据库原理中，非规范化的关系可能会存在哪些问题
数据冗余，更新异常，插入异常，删除异常。
Ⅳ 什么是反规范化一个mysql数据库的好方法
1、关系型数据库：是建立在关系数据库模型基础上的数据库，借助于关系代数等概念和方法来处理数据库中的数据，同时也是一个被组织成一组拥有正式描述性的表格，该形式的表格作用的实质是装载着数据项的特殊收集体，这些表格中的数据能以许多不同的方式被存取或重新召集而不需要重新组织数据库表格。
2、关系代数：
在数学中，关系代数是支持叫做逆反(converse)的对合一运算的剩余布尔代数。激发关系代数的例子是在集合X上的所有二元关系的代数，带有R-S被解释为平常的二元关系复合。
Ⅳ 理解什么是数据库规范化
优点是降低冗余，利于保证数据的一致性和完整性；缺点是过度的规范化，易造成查询和统计时的效率下降，这主要是由于多表连接所造成的问题。适当的反规范化设计可以提高效率，但最好在那些数据不太发生变化的情况下使用。通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。要求一：表中应该避免可为空的列。虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。要求二：表不应该有重复的值或者列。为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入的字段。所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。要求三：表中记录应该有一个唯一的标识符。在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。要求四：数据库对象要有统一的前缀名。一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。要求五：尽量只存储单一实体类型的数据。这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。第一范式每个分量不可再分第一范式消除了非主属性对键的部分函数依赖,就是第二范式第二范式消除了任何属性对键的传递依赖,就是第三范式~
Ⅵ 数据仓库有4个特征分别是
数据仓库的特点：
数据仓库是面向主题的；操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。
数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库； 数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。 数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。 数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
数据仓库是不可更新的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询；
数据仓库是随时间而变化的，传统的关系数据库系统比较适合处理格式化的数据，能够较好的满足商业商务处理的需求。稳定的数据以只读格式保存，且不随时间改变。
汇总的。操作性数据映射成决策可用的格式。
大容量。时间序列数据集合通常都非常大。
非规范化的。Dw数据可以是而且经常是冗余的。
元数据。将描述数据的数据保存起来。
数据源。数据来自内部的和外部的非集成操作系统。
可以参考这篇文章：数据仓库(1)什么是数据仓库 - 知乎 (hu.com)
Ⅶ 数据库设计中什么时候要进行适当的反规范化
1�反规范的好处
是否规范化的程度越高越好?这要根据需要来决定，因为“分离”越深，产生的关系越多，关系过多，连接操作越频繁，而连接操作是最费时间的，特别对以查询为主的数据库应用来说，频繁的连接会影响查询速度。所以，关系有时故意保留成非规范化的，或者规范化以后又反规范了，这样做通常是为了改进性能。
例如帐户系统中的“帐户”表B－TB01，它的列busi－balance(企业帐户的总余额)就违反规范，其中的值可以通过下面的查询获得：
select busi－code,sum(acc－balance)
from B－TB06
group by busi－code
如果B－TB01中没有该列，若想获得busi－name(企业名称)和企业帐户的总余额，则需要做连接操作：
select busi－name,sum(acc－balance)
from B－TB01,B－TB06
where B－TB01.busi－code=B－TB06.busi－code
group by busi－code
如果经常做这种查询，则就有必要在B－TB01中加入列busi－balance，相应的代价则是必须在表B－TB06上创建增、删、改的触发器来维护B－TB01表上busi－balance列的值。类似的情况在决策支持系统中经常发生。
反规范的好处是降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，相应带来的问题是可能出现数据的完整性问题。加快查询速度，但会降低修改速度。因此决定做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点，好的索引和其它方法经常能够解决性能问题，而不必采用反规范这种方法。
2�常用的反规范技术
在进行反规范操作之前，要充分考虑数据的存取需求、常用表的大小、一些特殊的计算(例如合计)、数据的物理存储位置等。常用的反规范技术有增加冗余列、增加派生列、重新组表和分割表。
(1)增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如前面例子中，如果经常检索一门课的任课教师姓名，则需要做class和teacher表的连接查询：
select class－name,teacher－name
from class,teacher
where class.teacher－no=teacher.teacher－no
这样的话就可以在class表中增加一列teacher－name就不需要连接操作了。
增加冗余列可以在查询时避免连接操作，但它需要更多的磁盘空间，同时增加表维护的工作量。
(2)增加派生列指增加的列来自其它表中的数据，由它们计算生成。它的作用是在查询时减少连接操作，避免使用集函数。例如前面所讲的账户系统中的表B－TB01的列busi－balance就是派生列。派生列也具有与冗余列同样的缺点。
(3)重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。例如，用户经常需要同时查看课程号，课程名称，任课教师号，任课教师姓名，则可把表class(class－no,class－name,teacher－no)和表teacher(teacher－no,teacher－name)合并成一个表class(class－no,class－name,teacher－no,teacher－name)。这样可提高性能，但需要更多的磁盘空间，同时也损失了数据在概念上的独立性。
(4)有时对表做分割可以提高性能。表分割有两种方式：
1水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。
水平分割通常在下面的情况下使用。
·表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。
·表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。
·需要把数据存放到多个介质上。
例如法规表law就可以分成两个表active－law和inactive－law。activea－authors表中的内容是正生效的法规，是经常使用的，而inactive－law表则使已经作废的法规，不常被查询。
水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。
2垂直分割：把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。
如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O次数。其缺点是需要管理冗余列，查询所有数据需要join操作。
3�反规范技术需要维护数据的完整性
无论使用何种反规范技术，都需要一定的管理来维护数据的完整性，常用的方法是批处理维护、应用逻辑和触发器。
批处理维护是指对复制列或派生列的修改积累一定的时间后，运行一批处理作业或存储过程对复制或派生列进行修改，这只能在对实时性要求不高的情况下使用。
数据的完整性也可由应用逻辑来实现，这就要求必须在同一事务中对所有涉及的表进行增、删、改操作。用应用逻辑来实现数据的完整性风险较大，因为同一逻辑必须在所有的应用中使用和维护，容易遗漏，特别是在需求变化时，不易于维护。
另一种方式就是使用触发器，对数据的任何修改立即触发对复制列或派生列的相应修改。触发器是实时的，而且相应的处理逻辑只在一个地方出现，易于维护。一般来说，是解决这类问题的最好的办法。
Ⅷ 学会如何应用数据库——数据库规范化技巧 （1）
简介在设计数据库时，最重要的步骤是要确保数据正确分布到数据库的表中。使用正确的数据结构，可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称是“数据库规范化”。 本文简要介绍数据库规范化的基本概念和一些需要注意并力求避免的常见问题。 理解您的数据在设计表之前，应明确您打算如何处理数据，还要了解随着时间的推移数据会发生什么样的变化。您所做的假设将会影响最终的设计。 您需要什么样的数据？ 设计应用程序时，关键要了解设计的最终结果，以便确保您准备好所有必需的数据并知道其来源。例如，报表的外观、每个数据的来源以及所需的所有数据是否都存在。对项目损失最大的莫过于在项目后期发现重要报表缺少数据。 知道需要什么样的数据后，就必须确定数据的来源。数据是否从其他数据源中导入？数据是否需要清理或验证？用户是否需要输入数据？ 明确所需数据的类型和来源是数据库设计的第一步。 您打算如何处理这些数据？用户是否需要编辑这些数据？如果需要，应如何显示数据以便于用户理解和编辑？有没有验证规则和相关的查找表？要求对编辑和删除保留备份的数据输入有没有相关联的审核问题？需要为用户显示哪些摘要信息？是否需要生成导出文件？了解这些信息后，就可以想象字段之间是如何相互关联的了。 数据之间如何相互关联？将数据分组放入相关字段（例如与客户相关的信息、与发票相关的信息等），每个字段组都代表要建立的表。然后考虑如何将这些表相互关联。例如，哪些表具有一对多关系（例如，一个客户可能持有多张发票）？哪些表具有一对一关系（这种情况下，通常会考虑将其组合到一个表中）？ 随着时间的推移数据会发生什么样的变化？设计表之后，常常会由于没有考虑时间的影响而导致以后出现严重问题。许多表设计在当时使用时效果非常好，但是，常常会因为用户修改数据、添加数据以及随时间的推移而崩溃。开发人员经常会发现需要重新设计表的结构来适应这些变化。表的结构发生变化时，所有相关的内容（查询、窗体、报表、代码等）也必须随之更新。理解并预测数据会随时间推移发生哪些变化，可以实现更好的设计，减少问题的发生。 学习如何使用查询了解如何分析和管理数据同样很重要。您应该深刻理解查询的工作原理，理解如何使用查询在多个表之间链接数据，如何使用查询对数据进行分组和汇总，以及如何在不需要以规范化格式显示数据时使用交叉表查询。 好的数据设计的最终目标就是要平衡两个需要：既要随着时间的推移有效地存储数据，又要轻松地检索和分析数据。理解查询的功能对正确设计表很有帮助。 数据库规范化概念这部分介绍数据库规范化所涉及的基本概念，而不是对数据库规范化进行理论性的探讨。如何在您的实际情况中应用这些概念可能会随着应用程序需要的不同而有所变化。这部分的目的是理解这些基本概念、根据实际需要应用它们，并理解偏离这些概念将会出现哪些问题。 将唯一信息存储在一个地方大部分数据库开发人员都理解数据库规范化的基本概念。理想情况下，您希望将相同的数据存储在同一个地方，并在需要引用时使用 ID 来进行引用。因此，如果某些信息发生了变化，则可以在一个地方进行更改，而整个程序中的相应信息也会随之更改。 例如，客户表会存储每个客户的记录，包括姓名、地址、电话号码、电子邮件地址以及其他特征信息。客户表中可能包含唯一的 CustomerID 字段（通常是 Autonumber 字段），这个字段即该表的主键字段，其他表使用它来引用该客户。因此，发票表可以只引用客户的 ID 值，而不是在每张发票中存储客户的所有信息（因为同一个客户可能会持有多张发票），这样利用客户的 ID 值即可从客户表中查找客户的详细信息。使用 Access 中功能强大的窗体（使用组合框和子窗体），可以轻松地完成这项工作。如果需要修改客户信息（例如新增电话号码），只需在客户表中修改，应用程序中引用该信息的任何其他部分都会随之自动更新。 使用正确规范化的数据库，通过简单的编辑即可轻松处理数据随时间推移而发生的更改。使用未正确规范化的数据库，通常需要利用编程或查询来更改多条记录或多个表。这不仅会增加工作量，还会增加由于未正确执行代码或查询而导致数据不一致的可能性。 记录是免费的，而新字段非常昂贵理想的数据库应该只需要随着时间的推移添加新的记录，数据库表应该能够保存大量记录。但是，如果您发现需要增加更多字段，则可能会碰到设计问题。 电子表格专家经常会遇到上述问题，因为他们习惯于按照设计电子表格的方式设计数据库。设计经常随时间变化的字段（例如，年、季度、产品和销售人员）需要在将来添加新字段。而正确的设计应该是转换信息并将随时间变化的数据放在一个字段内，这样就可以添加更多记录。例如，只需创建“年”字段，然后在该字段中输入各记录相应的年份值即可，无需为每年创建一个单独的字段。 增加额外的字段可能会产生问题，因为表结构的变化会对应用程序的其他部分产生影响。在表中添加更多字段时，依赖该表的对象和代码也需要更新。例如，查询需要获取额外的字段，窗体需要显示这些字段，而报表则需要包含这些字段，等等。但是，如果数据已经规范化，则现有对象会自动检索新数据，并正确计算或显示这些数据。查询功能尤其强大，因为它允许您按“年”字段进行分组，以逐年显示摘要（不管表中包含哪些年份）。 但是，数据规范化并不意味着不能显示或使用随时间而变化或依赖时间的字段。需要浏览或显示这类信息的开发人员通常可以使用交叉表查询来达到这一目的。如果您不熟悉交叉表查询，应该学习如何使用它们。虽然它们与表有所不同（尤其是用户无法编辑交叉表查询的结果），但它们的确可以用于在数据表中显示信息（最多可以达到 255 个字段）。如果要在报表中使用它们，则会更加复杂，因为报表需要包含额外的或不断变化的字段名。这就是为什么大多数报表将数据作为独立的分组（而不是独立的列）显示的原因。对于那些别无选择的情况，您必须花时间去解决这个问题。希望所有人都能够理解这种决定会随着时间的变化对其他资源产生的影响。 这就是为什么增加记录是免费的（这是数据库的巨大优势）而增加字段是如此昂贵的原因。
Ⅸ 什么是数据库中的规范化
规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束集条件也越严格。
第一范式（1NF）
在关系模式R中中，如果每个属性值都是不可再分的原子属性，则称R是第一范式的关系[2]。例如：关系R（职工号，姓名，电话号码）中一个人可能有一个办公室电话和一个住宅电话号码，规范成为1NF的方法一般是将电话号码分为单位电话和住宅电话两个属性，即 R（职工号，姓名，办公电话，住宅电话）。1NF是关系模式的最低要求。
第二范式（2NF）
如果关系模式R是1NF且其中的所有非主属性都完全函数依赖于关键字，则称关系R 是属于第二范式的[2]。例：选课关系 SC（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）。在应用中使用以上关系模式有以下问题： （1）数据冗余，假设同一门课由40个学生选修，学分就重复40次；（2）更新复杂，若调整了某课程的学分，相应元组的CREDIT值都要更新，有可能会出现同一门课学分不同；（3）插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入；（4）.删除异常，若学生已经结业，从当前数据库删除选修记录，而某些课程新生尚未选修，则此门课程及学分记录无法保存。以上问题产生的原因是非主属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。解决方法是将以上关系分解成两个关系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC中的外键CNO相联系，需要时再进行自然联接，恢复原来的关系
第三范式（3NF）
如果关系模式R是2NF且其中的所有非主属性都不传递依赖于码，则称关系R是属于第三范式的[1]。例如关系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各属性分别代表学号、姓名、所在系、系名称、系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但关系S肯定有大量的冗余，有关学生所在系的几个属性DNO，DNAME，LOCATION将重复存储，插入、删除和修改时也将产生类似以上例的情况。原因在于关系中存在传递依赖，即SNO -> DNO，DNO -> LOCATION, 因此关键字SNO对LOCATION函数决定是通过传递依赖SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。解决方法是将该关系模式分解为两个关系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），两个关系通过S中的外键DNO联系。
BC范式(BCNF)
如果关系模式R的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或者说关系模式R中，如果每个决定因素都包含关键字（而不是被关键字所包含），则R是BCNF[3]。 通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。
Ⅹ 关系数据库规范化理论的基础和内容
一个关系数据库模式由一组关系模式组成，一个关系模式由一组属性名组成。关系数据库设计，就是如何把已给定的相互关联的一组属性名分组，并把每一组属性名组成关系的问题。然而，属性的分组不是唯一的，不同的分组对应着不同的数据库应用系统，它们的效率往往相差很远。
为了使数据库设计合理可靠，简单实用，长期以来，形成了关系数据库设计的理论——规范化理论。
6.1 关系规范化的作用
规范化，就是用形式更为简洁，结构更加规范的关系模式取代原有关系模式的过程。
如果将两个或两个以上实体的数据存放在一个表里，就会出现下列三个问题：
Ø 数据冗余度大
Ø 插入异常
Ø 删除异常
所谓数据冗余，就是相同数据在数据库中多次重复存放的现象。数据冗余不仅会浪费存储空间，而且可能造成数据的不一致性。
插入异常是指，当在不规范的数据表中插入数据时，由于实体完整性约束要求主码不能为空的限制，而使有用数据无法插入的情况。
删除异常是指，当不规范的数据表中某条需要删除的元组中包含有一部分有用数据时，就会出现删除困难。
（以P98工资表为例）
解决上述三个问题的方法，就是将不规范的关系分解成为多个关系，使得每个关系中只包含一个实体的数据。
（讲例子解）
当然，改进后的关系模式也存在另一问题，当查询职工工资时需要将两个关系连接后方能查询，而关系连接的代价也是很大的。
那么，什么样的关系需要分解？分解关系模式的理论依据又是什么？分解完后能否完全消除上述三个问题？回答这些问题需要理论指导。下面，将加以讨论：
6.2 函数依赖
6.2.1属性间关系
实体间的联系有两类：一类是实体与实体之间联系；另一类是实体内部各属性间的联系。数据库建模一章中讨论的是前一类，在这里我们将学习第二类。
和第一类一样，实体内部各属性间的联系也分为1:1、1:n和m:n三类：
例：职工（职工号，姓名，身份证号码，职称，部门）
1、 一对一关系（1:1）
设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中至多有一个值与之对应，反之，对于Y中的任一具体值，X中也至多有一个值与之对应，则称X、Y两属性间是一对一关系。
如本例职工关系中职工号与身份证号码之间就是一对一关系。
2、一对多关系（1:n）
设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中可以找到多个值与之对应，而对于Y中的任一具体值，X中至多只有一个值与之对应，则称属性X对Y是一对多关系。
如职工关系中职工号与职称之间就是一对多的关系。
3、多对多关系（m:n）
设X、Y是关系R的两个属性（集）。如果对于X中的任一具体值，Y中有n个值与之对应，而对于Y中的任一具体值，X中也有m个值与之对应，则称属性X对Y是一对多（m:n）关系。
例如，职工关系中，职称与部门之间就是多对多的关系。
上述属性间的三种关系，实际上是属性值之间相互依赖与相互制约的反映，因而称之为属性间的数据依赖。
数据依赖共有三种：
Ø 函数依赖（Functional Dependency，FD）
Ø 多值依赖（Multivalued Dependency，MVD）
Ø 连接依赖（Join Dependency，JD）
其中最重要的是函数依赖和多值依赖。
6.2.2 函数依赖
函数依赖，是属性之间的一种联系。在关系R中，X、Y为R的两个属性或属性组，如果对于R的所有关系r 都存在：对于X的每一个具体值，Y都只有一个具体值与之对应，则称属性Y函数依赖于属性X。或者说，属性X函数决定属性Y，记作X→Y。其中X叫作决定因素，Y叫作被决定因素。
上述定义，可简言之：如果属性X的值决定属性Y的值，那么属性Y函数依赖于属性X。换一种说法：如果知道X的值，就可以获得Y的值，则可以说X决定Y。
若Y函数不依赖于X，记作：X→Y。
X Y
若X→Y，Y→X，记作：
前面学习的属性间的三种关系，并不是每种关系中都存在着函数依赖。
u 如果X、Y间是1:1关系，则存在函数依赖 X←→Y
u 如果X、Y间是1:n关系，则存在函数依赖： X→Y或Y→X（多方为决定因素）
u 如果X、Y间是m:n关系，则不存在函数依赖。
注意，属性间的函数依赖不是指R的某个或某些关系子集满足上述限定条件，而是指R的一切关系子集都要满足定义中的限定。只要有一个具体的关系r（R的一个关系子集）不满足定义中的条件，就破坏了函数依赖，使函数依赖不成立。
这里的关系子集，指的是R的某一部分元组的集合，例如：地测学院的学生关系中只包含了地测学院学生的数据，所以它是长安大学学生关系的一个子集。
6.2.3 码的定义
前面，我们对码进行了直观化的定义，下面用函数依赖的概念对码作出较为精确的形式化的定义：
设K是关系模式R（U，F）中的属性或属性组，K’是K的任一子集。若K→U，而不存在K’→U，则K为R的候选码（Candidate Key）
Ø 若候选码多于一个，则选其中的一个为主码（Primary Key）；
Ø 包含在任一候选码中的属性，叫做主属性（Primary Attribute）；
Ø 不包含在任何码中的属性称为非主属性（Nonprime Attribute）或非码属性（Nonkey Attribute）
Ø 关系模式中，最简单的情况是单个属性是码，称为单码（Single Key）；最极端的情况是整个属性组是码，称为全码（All－Key）。
前面已多次遇到单码的情况，下面是一个全码的例子：
签约（演员名，制片公司，电影名）
外码：设有两个关系R和S，X是R的属性或属性组，并且X不是R的码，但X是S的码（或与S的码意义相同），则称X是R的外部码（Foreign Key），简称外码或外键。
如：职工（职工号，姓名，性别，职称，部门号）
部门（部门号，部门名，电话，负责人）
其中职工关系中的“部门号”就是职工关系的一个外码。
在此需要注意，在定义中说X不是R的码，并不是说X不是R的主属性，X不是码，但可以是码的组成属性，或者是任一候选码中的一个主属性。
如：学生（学生号，姓名，性别，年龄…）
课程（课程号，课程名，任课老师…）
选课（学生号，课程号，成绩）
在选课关系中，（学生号，课程号）是该关系的码，学生号、课程号又分别是组成主码的属性（但单独不是码），它们分别是学生关系和课程关系的主码，所以是选课关系的两个外码。
关系间的联系，可以通过同时存在于两个或多个关系中的主码和外码的取值来建立。如要查询某个职工所在部门的情况，只需查询部门表中的部门号与该职工部门号相同的记录即可。所以，主码和外码提供了一个表示关系间联系的途径。
6.2.4 函数依赖和码的唯一性
由上述码的形式化定义，我们可以说：码是由一个或多个属性组成的，可唯一标识元组的最小属性组。
码在关系中总是唯一的，即一个码函数唯一地决定一行。如果码的值重复，则整个元组都会重复。否则，违反了实体完整性规则。而元组的重复则表示存在两个完全相同的实体，这显然是不可能的，所以码是不允许重复取值的。
所以，只有当某个属性或属性组能够函数决定关系中的每一个其它的属性，且该属性组的任何一个真子集都做不到这一点时，该属性或属性组才是该关系的码。
函数依赖是一个与数据有关的事物规则的概念。如果属性B函数依赖于属性A，那么若知道了A的值，则完全可以找到B的值。这并非是可以由A的值计算出B的值，而是逻辑上只能存在一个B的值。
6.3 关系模式的规范化
一、非规范化的关系
当一个表中存在还可以再分的数据项时，这个表就是非规范化的表。非规范化表存在两种情况：
Ø 表中具有组合数据项（P102表6-4）
Ø 表中具有多值数据项（P103表6-5）
例：
职工号
姓名
工资
基本工资
职务工资
工龄工资
1002
张三
1000
800
200
职工号
姓名
职称
系名
系办地址
学历
毕业年份
001
张三
教授
计算机
1305
大学
研究生
1963
1982
那么什么是规范化关系呢？
当一个关系中的所有分量都是不可再分的数据项时，该关系是规范化的。即当表中不存在组合数据项和多值数据项，只存在不可分的数据项时，这个表是规范化的。
二维表按其规范化程度从低到高可分为5级范式（Normal Form），分别称为1NF、2NF、3NF（BCNF）、4NF、5NF。规范化程度较高者必是较低者的子集，即：
1NF 2NF 3NF BCNF 4NF 5NF
二、第一范式（1NF）
定义1：如果关系模式R中不包含多值属性，则R满足第一范式（First Normal Form），记作：
R∈1NF
1NF是对关系的最低要求，不满足1NF的关系是非规范化的关系。
非规范化关系转化为规范化关系1NF方法很简单，只要上表分别从横向、纵向展开即可。如下表：
职工号
姓名
基本工资
职务工资
工龄工资
1002
张三
1000
800
200
1005
李四
1200
900
150
职工号
姓名
职称
系名
系办地址
学历
毕业年份
1002
张三
教授
计算机
1305
大学
1963
1002
张三
教授
计算机
1305
研究生
1982
1005
李四
讲师
信电
2206
大学
1989
上表虽然符合1NF，但仍是有问题的关系，表中存在大量的数据冗余和潜在的数据更新异常。原因是（职工号，学历）是右表的码，但姓名、职称、系名、系办地址却与学历无关，只与码的一部分有关。所以上表还需进一步地规范化。
三、第二范式（2NF）
定义1：设X、Y是关系R的两个不同的属性或属性组，且X → Y。如果存在X的某一个真子集X’，使X’ → Y成立，则称Y部分函数依赖于X，记作：X P→ Y（Partial）。反之，则称Y完全函数依赖于X，记作：X F→ Y （Full）
定义2：如果一个关系 R∈1NF，且它的所有非主属性都完全函数依赖于R的任一候选码，则R属于第二范式，记作：R∈2NF。
说明：上述定义中所谓的候选码也包括主码，因为码首先应是候选码，才可以被指定为码。
例如关系模式：
职工（职工号，姓名，职称，项目号，项目名称，项目角色）中
（职工号，项目号）是该关系的码，而职工号→姓名、职工号→职称、项目号→项目名称…
所以（职工号，项目号）P→ 职称、（职工号，项目号）P→ 项目名称
故上述职工关系不符合第二范式要求。它存在三个问题：插入异常、删除异常和修改异常。
其中修改异常是这样的，当职工关系中项目名称发生变化时，由于参与该项目的人员很多，每人一条记录，要修改项目信息，就得对每一个参加该项目的人员信息进行修改，加大了工作量，还有可能发生遗漏，存在着数据一致性被破坏的可能。
可把上述职工关系分解成如下三个关系：
职工（职工号，姓名，职称）
参与项目（职工号，项目号，项目角色）
项目（项目号，项目名称）
上述三个关系都符合定义2的要求，所以都符合2NF
推论：如果关系模式R∈1NF，且它的每一个候选码都是单码，则R∈2NF
符合第二范式的关系模式仍可能存在数据冗余、更新异常等问题。如关系
职工信息（职工号，姓名，职称，系名，系办地址）
虽然也符合2NF，但当某个系中有100名职工时，元组中的系办地址就要重复100次，存在着较高的数据冗余。原因是关系中，系办地址不是直接函数依赖于职工号，而是因为职工号函数决定系名，而系名函数决定系办地址，才使得系办地址函数依赖于职工号，这种依赖是一个传递依赖的过程。
所以，上述职工信息的关系模式还需要进一步的规范化。
四、第三范式（3NF）
定义1：在关系R中，X、Y、Z是R的三个不同的属性或属性组，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，则称Z传递函数依赖于X。
定义2：如果关系模式R∈2NF，且它的每一个非主属性都不传递依赖于任何候选码，则称R是第三范式，记作：R∈3NF
推论1：如果关系模式R∈1NF，且它的每一个非主属性既不部分依赖、也不传递依赖于任何候选码，则R∈3NF
推论2：不存非主属性的关系模式一定为3NF
五、改进的3NF——BCNF（Boyee－Codd Normal Form）
定义：设关系模式R（U，F）∈1NF，若F的任一函数依赖X→Y（Y X）中X都包含了R的一个码，则称R∈BCNF。
换言之，在关系模式R中，如果每一个函数依赖的决定因素都包含码，则R∈BCNF
推论：如果R∈BCNF，则：
Ø R中所有非主属性对每一个码都是完全函数依赖；
Ø R中所有主属性对每一个不包含它的码，都是完全函数依赖；
Ø R中没有任何属性完全函数依赖于非码的任何一组属性。
定理：如果R∈BCNF，则R∈3NF一定成立。
证明：（结合传递依赖的定义，用反证法）
注意：当R∈3NF时，R未必属于BCNF。因为3NF比BCNF放宽了一个限制，它允许决定因素不包含码。例如：
通讯（城市名，街道名，邮政编码）中：
F＝｛（城市名，街道名）→邮政编码，邮政编码→城市名｝
非主属性邮政编码完全函数依赖于码，且无传递依赖，故属于3NF，但邮政编码也是一个决定因素，而且它没有包含码，所以该关系不属于BCNF。
又如：
Teaching（Student，Teacher，Course） 简记为Teaching（S，T，C）
规定：一个教师只能教一门课，每门课程可由多个教师讲授；学生一旦选定某门课程，教师就相应地固定。
F＝｛T→C，（S，C）→T,(S，T) →C｝
该关系的候选码是（S，C）和（S，T），因此，三个属性都是主属性，由于不存在非主属性，该关系一定是3NF。但由于决定因素T没包含码，故它不是BCNF。
关系模式Teaching仍然存在着数据冗余问题，因为存在着主属性对码的部分函数依赖问题。
确切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝
所以Teaching关系可以分解为以下两个BCNF关系模式：
Teacher（Teacher，Course） Student（Student，Teacher）
3NF的“不彻底”性，表现在可能存在主属性对码的部分依赖和传递依赖。
一个关系模式如果达到了BCNF，那么，在函数依赖范围内，它就已经实现了彻底的分离，消除了数据冗余、插入和删除异常。
6.4 多值依赖和第四范式
一、多值依赖（Multivalued Dependency）
课程C
教员T
参考书B
物理
李勇
普通物理学
物理
李勇
光学原理
物理
李勇
物理习题集
物理
王军
普通物理学
物理
王军
光学原理
物理
王军
物理习题集
数学
李勇
数学分析
数学
李勇
微分方程
数学
李勇
高等代数
数学
张平
数学分析
数学
张平
微分方程
数学
张平
高等代数
计算数学
张平
数学分析
计算数学
张平
计算数学
计算数学
周峰
数学分析
计算数学
周峰
计算数学
课程C
教员T
参考书B
物理
李勇
王军
普通物理学
光学原理
物理习题集
数学
李勇
张平
数学分析
微分方程
高等代数
计算数学
张平
周峰
数学分析
计算数学
例：学校中某一门课程由多个教员讲授，他们使用相同的一套参考书，每个教员可以讲授多门课程，每种参考书可以供多门课程使用。下列是用一个非规范化的表来表示教员T，课程C和参考书B之间的关系。
把上表变换成一张规范化的二维表Teaching，如右表
关系模式Teaching（C，T，B）的码是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述语义规定，当某门课程增加一名讲课教员时，就要向Teaching表中增加与相应参考书等数目的元组。同样，某门课程要去掉一本参考书时，则必须删除相应数目的元组。
对数据的增、删、改很不方便，数据的冗余也十分明显。如果仔细考察这类关系模式，会发现它具有一种称之为多值依赖的数据依赖关系。
定义：设R（U）是属性集U上的一个关系模式，X，Y，Z是U的子集，且Z＝U-X-Y。如果对R（U）的任一关系r，给定一对（x，z）值，都有一组y值与之对应，这组y值仅仅决定于x值而与z值无关。则称Y多值依赖于X，或X多值决定Y，记作：X→→Y。――
例如，在关系模式Teaching中，对于一个（C，B）值（物理，普通物理学），有一组T值｛李勇，王军｝，而这组值仅仅决定于课程C上的值（物理）。即对于另一个（物理，光学原理），它对应的T值仍然是｛李勇，王军｝，所以T的值与B的值无关，仅决定于C的值，即C→→T 。
多值依赖的另一个等价的形式化定义为：
设关系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一个关系，t1、t2是r的任意两个元组。如果t1[X]=t2[X]，并在r中存在两个元组t3、t4，使得：
t3[X]=t4[X]=t1[X]
t3[Y]=t1[Y]，t3[Z]=t2[Z]，
t4[Y]=t2[Y]，t4[Z]=t1[Z]
成立，则X→→Y。
换句话说：如果X→→Y在R（U）中成立，则只要在R的任一关系r中存在两个元组t1、t2在X属性上的值相等，则交换这两个元组在Y（或Z）上的值后得到的两个新元组t3、t4也必是关系r中的元组。
定义中如果Z＝Ф（空集），则称X→→Y为平凡的多值依赖，否则为非平凡的多值依赖。
多值依赖具有如下性质：
1. 对称性：若X→→Y，则X→→Z，其中Z＝U-X-Y
2. 传递性：若X→→Y，Y→→Z，则X→→Z-Y
3. 若X→→Y，X→→Z，则X→→YZ
4. 若X→→Y，X→→Z，则X→→Y∩Z
5. 若X→→Y，X→→Z，则X→→Y-Z，X→→Z-Y
多值依赖与函数依赖相比，具有下面两个基本区别：
（1）多值依赖的有效性与属性集的范围有关
若X→→Y在U上成立，则在V（XY V U）上一定成立；反之则不然，即X→→Y在V(V U)上成立，在U上并不一定成立。这是因为多值依赖的定义中不仅涉及属性组X、Y，而且涉及U中的其余属性Z（Z＝U-X-Y）。
一般地说，在R（U）上若有X→→Y在V（V U）上成立，则称X→→Y为R（U）的嵌入型多值依赖。
而在关系模式R（U）中函数依赖X→Y的有效性，仅决定于X和Y这两个属性集的值。只要在R（U）的任何一个关系r中，元组在X和Y上的值使得X→Y成立，则X→Y在任何属性集V（XY V U）上也成立。
（2）若函数依赖X→Y在R（U）上成立，则对于任何Y’ Y 均有X→Y’ 成立。而多值依赖X→→Y若在R（U）上成立，却不能断言对于任何Y’ Y有X→→Y’ 成立。
多值依赖的约束规则：在具有多值依赖的关系中，如果随便删去一个元组，就会破坏其对称性，那么，为了保持多值依赖关系中的“多值依赖”性，就必须删去另外的相关元组以维持其对称性。这就是多值依赖的约束规则。目前的RDBMS尚不具有维护这种约束的能力，需要程序员在编程中实现。
函数依赖可看成是多值依赖的特例，即函数依赖一定是多值依赖。而多值依赖则不一定就有函数依赖。
二、第四范式（4NF）
定义：如果关系模式R∈1NF，对于R的每个非平凡的多值依赖X→→Y（Y X），X含有码，则称R是第四范式，即R∈4NF
课程C
教员T
参考书B
物理
李勇
普通物理学
物理
李勇
光学原理
物理
李勇
物理习题集
物理
王军
普通物理学
物理
王军
光学原理
物理
王军
物理习题集
数学
李勇
数学分析
数学
李勇
微分方程
数学
李勇
高等代数
数学
张平
数学分析
数学
张平
微分方程
数学
张平
高等代数
计算数学
张平
数学分析
计算数学
张平
计算数学
计算数学
周峰
数学分析
计算数学
周峰
计算数学
Teaching关系
关系模式R∈4NF时，R中所有的非平凡多值依赖实际上就是函数依赖。因为每一个决定因素中都含有码，所以R一定属于BCNF。
4NF实际上就是限制关系模式的属性间不允许有非平凡，而且非函数依赖的多值依赖存在。反过来说，4NF所允许的非平凡多值依赖实际上是函数依赖。
例题中的Teaching关系属于BCNF，但它不属于4NF。因为它的码是（C，T，B），关系中存在非平凡多值依赖C→→T ，C→→B，但C不包含码，而只是码的一部分。
课程C
参考书B
物理
普通物理学
物理
光学原理
物理
物理习题集
数学
数学分析
数学
微分方程
数学
高等代数
计算数学
数学分析
计算数学
计算数学
CB关系
课程C
教员T
物理
李勇
物理
王军
数学
李勇
数学
张平
计算数学
张平
计算数学
周峰
CT关系
要使Teaching关系符合4NF，必须将其分解为CT（C，T）和CB（C，B）两个关系模式。如右表：
从表中显而易见，符合BCNF的关系Teaching仍然存在着数据冗余，而分解后的关系CT和CB中只有平凡多值依赖，所以符合4NF，它们已经消除了数据冗余。可以说：BCNF是在只有函数依赖的关系模式中，规范化程度最高的范式，而4NF是在有多值依赖的关系模式中，规范化程度最高的范式。
如果关系模式中存在连接依赖，即便它符合4NF，仍有可能遇到数据冗余及更新异常等问题。所以对于达到4NF的关系模式，还需要消除其中可能存在的连接依赖，才可以进一步达到5NF的关系模式。
关于连接依赖和5NF的内容，已超出了本课程教学大纲的要求，在此不再介绍。