数据库设计理论
- 格式:doc
- 大小:64.00 KB
- 文档页数:23
数据库设计中的范式理论数据库是当今信息技术领域中最为重要的组成部分之一,而数据库的设计则是数据库系统中最为核心的部分。
在数据库设计中,范式理论是最为重要的基础理论之一。
范式理论主要是用来规范数据库中数据的存储方式,以达到数据冗余最小化的目的。
本文将从范式的概念、范式的种类以及它们之间的关系来详细探讨数据库设计中的范式理论。
一、范式的概念范式是数据库设计中最为重要的一个概念。
范式是一个规范,它定义了数据库中数据的存储方式。
它描述了如何将数据有效地组织在数据库表中,从而使得数据在存储、查询、更新等方面都更加高效。
范式的主要目的是降低数据冗余和维护数据一致性。
二、范式的种类根据数据中存在的依赖关系,范式分为第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)等。
1. 第一范式(1NF)第一范式(1NF)是最基本的范式。
它要求所有字段都是原子性的,即所有字段不能再分解成更小的数据项。
此外,1NF 还要求每个字段的值都是不可重复的。
在1NF 中,每个属性都具有原子性,即一个属性不能分解为其他属性。
如果一个属性具有可分解性,就需要将其分解为两个或多个单一属性。
2. 第二范式(2NF)第二范式(2NF)是在1NF 的基础上得出的。
2NF 要求数据库表中的每个非主键属性都完全依赖于主键,而不是仅依赖于主键的某个子集。
如果没有与主键存在部分依赖,数据库表就是符合2NF 的。
3. 第三范式(3NF)在2NF 的基础上有一种范式叫做第三范式(3NF)。
3NF 要求数据库表中的每个非主键属性都不传递依赖于主键。
如果一个非主键属性依赖于另一个非主键属性,那么应将其作为另一个表中的属性。
4. 巴斯-科德范式(BCNF)巴斯-科德范式(BCNF)是比3NF 更为严格的范式。
在BCNF 中,对于任何一个函数依赖关系X->Y,要么X是一个超码,要么Y是X的子集。
换句话说,BCNF 要求表中的所有列都依赖于主键,且不存在主键的任何非超码属性。
数据库设计中的范式理论解析在数据库设计中,范式理论起着至关重要的作用。
范式是用于规范数据库中关系模式的一组准则,旨在减少数据冗余,并确保数据的一致性和完整性。
本文将解析数据库设计中的范式理论,详细介绍不同范式的要求和优势。
1. 第一范式(1NF)第一范式要求每个属性都是原子性的,不可再分。
也就是说,数据库中的每个列都应该是不能再分的单一数据项。
例如,如果一个表中有一个“姓名”字段,那么该字段不能包含多个姓名。
1NF的优势在于提供了最基本的数据结构,确保了数据项之间的唯一性。
2. 第二范式(2NF)第二范式建立在第一范式的基础上,进一步要求表中的非主键属性完全依赖于主键。
也就是说,数据库中的每个非主键列必须完全依赖于主键,而不能只依赖于主键的一部分。
2NF的优势是消除了冗余数据,减少了数据的插入、更新和删除操作的复杂性。
3. 第三范式(3NF)第三范式要求表中的非主键属性不依赖于其他非主键属性。
也就是说,一个表中的每个非主键列都只应该依赖于主键和其他非主键列。
3NF的优势在于提高了数据的一致性和可靠性,避免了数据冗余、插入异常和更新异常。
4. 泛化和反范式设计泛化是指将一组相关的实体抽象成一个更高级别的通用实体。
通过泛化,可以减少数据冗余,并简化复杂的数据模型。
但是,过度的泛化可能导致数据丢失和查询性能下降。
反范式设计是在特定情况下,为了提高查询性能而违反范式的规则。
反范式设计可能包括冗余数据和非完全依赖的属性。
虽然反范式设计可以提高查询性能,但也增加了数据一致性的风险。
5. 范式理论的选择在实际的数据库设计中,选择合适的范式是一个权衡和综合考虑的过程。
较低范式(如1NF或2NF)可能导致更高的数据冗余,但提供了更快的查询性能。
较高范式(如3NF)可以减少冗余,但也要求更复杂的查询。
因此,根据实际需求和性能要求,可以根据具体情况选择合适的范式。
在设计过程中,我们可以根据表的复杂性和关系之间的依赖关系来决定使用哪个范式。
关系数据库的规范化理论与数据库设计在当今数字化的时代,数据成为了企业和组织的重要资产,而关系数据库作为存储和管理数据的重要手段,其设计的合理性直接影响着数据的质量、完整性和可用性。
关系数据库的规范化理论是指导数据库设计的重要原则,它能够帮助我们避免数据冗余、更新异常等问题,从而提高数据库的性能和可靠性。
首先,我们来了解一下关系数据库的基本概念。
关系数据库是由一组二维表组成的,每张表都有一个唯一的表名,表中的每一行称为一个元组,代表一个实体;每一列称为一个属性,代表实体的一个特征。
通过在不同的表之间建立关联,我们可以实现数据的查询和操作。
那么,什么是规范化理论呢?规范化理论是一种用于设计关系数据库的方法和原则,其目的是通过对关系模式进行分解和优化,消除数据冗余和更新异常,确保数据的一致性和完整性。
规范化理论主要包括第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。
第一范式要求表中的每个属性都是不可再分的原子值。
例如,如果有一个“联系人信息”表,其中包含“地址”这个属性,如果地址又分为“省”“市”“区”“详细地址”等子属性,那么就不满足第一范式,需要将其拆分成多个属性。
第二范式要求在满足第一范式的基础上,每个非主属性都完全依赖于主键。
举个例子,如果有一个“订单”表,主键是“订单号”,而“客户姓名”和“客户地址”等非主属性只依赖于“客户编号”,而不是“订单号”,那么就不满足第二范式,需要将其拆分成两个表,一个是“订单”表,一个是“客户”表。
第三范式要求在满足第二范式的基础上,每个非主属性都不传递依赖于主键。
比如说,有一个“员工”表,主键是“员工编号”,“部门名称”依赖于“部门编号”,而“部门编号”又依赖于“员工编号”,这就不满足第三范式,需要将“部门名称”这个属性移到“部门”表中。
规范化理论在数据库设计中具有重要的意义。
通过规范化设计,可以减少数据冗余,节省存储空间。
想象一下,如果一个客户的信息在多个表中重复存储,不仅浪费空间,而且当客户信息发生变化时,需要在多个地方进行更新,容易导致数据不一致。
数据库设计中的多值依赖理论与实践分析在数据库设计中,多值依赖理论是一种重要的概念,可以帮助我们理解数据之间的关系,并有效地规范数据库的结构。
本文将介绍多值依赖的概念、分类以及如何在实际数据库设计中应用多值依赖理论。
首先,让我们了解一下多值依赖的概念。
多值依赖是指一个关系中的一个属性集合对于另一个属性集合的依赖关系。
具体来说,如果一个属性集合的取值仅确定了另一个属性集合的部分取值,而不是全部取值,那么我们可以称这种关系为多值依赖。
多值依赖可以分为两种类型:完全函数依赖和部分函数依赖。
完全函数依赖是指在一个关系中,如果某个属性集合A的所有属性都对另一个属性B形成依赖,同时去掉A中的任何一个属性都会导致这个依赖关系不再存在,那么我们可以说A完全函数依赖于B。
部分函数依赖是指在一个关系中,如果某个属性集合A的一部分属性对另一个属性B形成依赖,同时去掉A中的任何一个属性都会导致这个依赖关系不再存在,那么我们可以说A部分函数依赖于B。
在实际数据库设计中,多值依赖理论有助于避免冗余数据和数据更新异常。
通过正确地建立关系模式,可以减小数据库的存储空间、提高查询效率,也可以提高数据的一致性和完整性。
在设计关系模式时,我们通常遵循以下几个原则:1. 第一范式(1NF):关系模式中的属性不可再分。
2. 第二范式(2NF):关系模式的非主属性完全依赖于候选键。
3. 第三范式(3NF):关系模式中不存在传递依赖。
基于以上原则,我们可以进行多值依赖的分析和处理。
首先,我们需要找出关系模式中存在的多值依赖,可以通过以下方法进行:1. 通过调查、分析和需求了解,识别出关系模式中的属性集合和它们之间的依赖关系。
2. 通过已有的数据和样本数据,进行数据分析和处理。
例如,可以利用数据挖掘算法识别出存在的多值依赖。
一旦发现了多值依赖,我们可以通过以下几种方法来处理它们:1. 分解:将多值依赖的关系模式拆分成多个关系模式,以消除冗余数据。
数据库范式理论在数据库设计和管理中,范式理论是一个重要的概念。
它是由埃德加·科德(Edgar F. Codd)在20世纪70年代提出的,目的是规范化数据库结构,使之更高效、更易于维护和使用。
本文将介绍数据库范式理论的基本概念和原则,并探讨其在实际应用中的重要性。
一、范式理论的基本概念数据库范式理论是一套规则、原则和标准,用于规范化数据库的结构。
根据范式理论的要求,数据库应该满足一定的条件和约束,以确保数据的一致性、完整性和可靠性。
范式理论主要涉及到三个基本概念:函数依赖、关系键和范式。
函数依赖是指一个属性(或属性集合)的值决定了另外一个属性(或属性集合)的值。
在数据库设计中,函数依赖可以帮助我们确定关系表的键和相关属性之间的依赖关系。
关系键是一个或多个属性的组合,用于唯一地标识一个关系表中的元组。
范式是一种规则,用于检测和评估数据库设计是否符合范式理论的要求。
目前,最常用的范式有第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
二、范式理论的原则范式理论的设计原则是为了使数据库结构更高效、更灵活、更易于扩展和维护。
以下是范式理论的主要原则:1. 第一范式(1NF):确保每个属性都是不可再分的,即每个属性都是原子的,不包含重复的值或值集合。
这样可以避免数据冗余和数据异常。
2. 第二范式(2NF):在满足1NF的基础上,通过确定关系键和非关键属性之间的完全函数依赖关系,消除非关键属性对关系键的部分依赖。
这样可以避免数据冗余和更新异常。
3. 第三范式(3NF):在满足2NF的基础上,消除非关键属性之间的传递函数依赖关系。
这样可以避免数据冗余和插入异常。
三、范式理论的重要性范式理论在数据库设计中起着重要的作用,具有以下几个方面的重要性:1. 数据一致性:范式理论要求数据库结构满足一定的条件和约束,确保数据的一致性。
合理的数据库设计可以减少数据冗余和不一致,提高数据的准确性和可靠性。
2. 数据完整性:范式理论强调关系键的重要性,通过关系键唯一地标识数据库中的元组,保证数据的完整性。
第四章关系数据库设计理论练习题一、选择题1、关系规范化中的删除操作异常是指A、不该删除的数据被删除.B、不该插入的数据被插入。
C、应该删除的数据未被删除。
D、应该插入的数据未被插入.2、关系数据库规范化是为解决关系数据库中()问题而引入的。
A、插入异常、删除异常和数据冗余;B、提高查询速度。
C、减少数据操作的复杂性。
D、保证数据的安全性和完整性。
3、假设关系模式R(A,B)属于3NF,下列说法中()是正确的。
A、R一定消除了插入和删除异常;B、R仍可能存在一定的插入和删除异常。
C、R一定属于BCNF;D、A和C都是.4、关系模式的分解A、唯一B、不唯一.5、设有关系W(工号,姓名,工种,定额),将其规范化到第三范式正确的答案是()A、W1(工号,姓名),W2(工种,定额);B、W1(工号,工种,定额),W2(工号,姓名);C、W1(工号,姓名,工种),W2(工种,定额)。
D、以上都不对.6、设学生关系模式为:学生(学号,姓名,年龄,性别,平均成绩,专业),则该关系模式的主键是()A、姓名;B、学号,姓名;C、学号。
D、学号,姓名,年龄.7根据数据库规范化理论,下面命题中正确的是()A、若R∈2NF,则R∈3NFB、若R∈1NF,则R不属于BCNFC、若R∈3NF,则R∈BCNFD、若R∈BCNF,则R∈3NF8、关系数据库设计理论中,起核心作用的是A、范式;B、模式设计;C、函数依赖。
D、数据完整性.9、设计性能较优的关系模设称为规范化,规范化的主要理论依据是()A、关系规范化理论。
B、关系运算理论;C 、关系代数理论;D 、数理逻辑。
10、规范化理论是关系数据库进行逻辑设计的理论依据。
根据这个理论,关系数据库中的关系必须满足:其每一属性都是( )A 、互不相关的;B 、不可分解的C 、长度可变的;D 、互相关联的。
11、规范化过程主要为克服数据库逻辑结构中的插入异常、删除异常以及( )的缺陷。
关系数据库的规范化理论与数据库设计E.F.CODD提出的数据库规范化理论1.1“不好”的关系模式中存在的问题可能存在的问题:数据冗余更新异常插入异常删除异常数据依赖:是可以作为关系模式的取值的任何一个关系所必须满足的一种约束条件,是通过一个关系中各个元组的某些属性值之间的相等与否体现出来的相互关系。
数据依赖包括:函数依赖和多值依赖和其他1.2函数依赖1.21函数依赖的定义设R(A1,A2,……..An)是一个关系模式,X,Y是{A1,A2……..An}的子集,若只要关系r是关系模式R的可能取值,则r中不可能有两个元组在X中的属性值相等,而在Y中的属性值不相等,则称”X函数决定Y”或”Y函数依赖于X”,记做X→Y。
(ps:一些属性决定另一些属性称为函数决定)只能根据语义来判断。
相关的属性:若X->Y, 但Y不属于X, 则称X->Y为非平凡依赖,否则为平凡依赖。
若X->Y, 则称X为决定元素。
若X->Y,Y->X, 则记做X←>Y若Y不函数依赖于X, 记做X不函数决定Y在关系模式R中,如果X->Y,并且对于X的任意一个真子集X` 都有X` 不函数决定Y,则称Y对X完全函数依赖,记做X__f__Y若X->Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记做X__p___Y若X—>Y(Y不包含于X),Y不函数决定X,Y函数决定Z,则称Z 对X传递函数依赖。
把关系模式表示为R<U,F>,其中U是一组属性,F是属性组U上的一组数据依赖,当且仅当U上的一个关系r满足F时,r称为关系模式R<U,F>的一个关系。
1.22 函数依赖的逻辑蕴含设R<U,F>是一个关系模式,X,Y是U中的属性组,若在R<U,F>的任何一个满足F中函数依赖的关系r上,都有函数依赖X->Y成立,则称F逻辑蕴含X->Y。
(ps:即是函数依赖组隐含决定的其他函数依赖关系)如关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体称作F的闭包,记做F+ .1.23 码设K为关系模式R<U,F>中的属性或属性组,若K->U在F闭包中,而找不到K 的任何一个真子集K` ,能使K`->U在F闭包中,则称K为关系模式R的候选码,当候选码多于一个时,选定其中一个做主码。
数据库设计中的范式理论与数据冗余数据库设计中的范式理论与数据冗余是数据库设计中常用的概念和原则,对于提高数据存储效率、数据一致性和数据完整性有重要意义。
范式理论是数据库设计中的基本原则和规范,旨在通过消除冗余数据以提高数据存储效率和数据一致性。
范式理论主要包括一些基本的范式,如第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。
第一范式(1NF)要求每个属性都是原子性的,即一个属性不可再分。
这样可以避免数据冗余和数据不一致的问题。
例如,一个学生表应该包含学生的姓名、学号、性别等属性,而不应该将姓名和性别合并为一个属性。
第二范式(2NF)要求表中的每个非主键属性完全依赖于主键。
这样可以避免数据冗余和数据不完整的问题。
例如,一个订单表应该包括订单号、产品号、客户号等属性,而不应该将客户的姓名和电话号码存储在订单表中,以避免重复存储客户的信息。
第三范式(3NF)要求表中的每个非主键属性不依赖于其他非主键属性。
这样可以进一步消除数据冗余和提高数据库的更新操作效率。
例如,一个订单表应该包括订单号、产品号、客户号等属性,而不应该将产品的价格和数量存储在订单表中,而是应该通过引入一个产品表,在产品表中存储产品的价格和数量。
范式理论的目标是通过消除冗余数据来提高数据存储效率、数据一致性和数据完整性。
然而,过度追求范式可能会导致性能下降和复杂的查询操作。
因此,在进行数据库设计时,需要根据具体应用场景的需求来选择合适的范式。
数据冗余是指在数据库中存储了重复的数据。
数据冗余可能会导致数据的不一致和浪费存储空间的问题。
例如,对于一个学生表,如果将学生的姓名和班级信息存储在多个表中,可能会导致当学生的姓名或班级信息发生变化时,需要更新多个表的数据,从而增加了数据维护的复杂性。
在数据库设计中,适当的数据冗余可能是必要的,以提高查询操作的效率和减少查询的复杂性。
例如,一个电子商务网站的商品表中,可以存储商品的名称、价格和库存数量等信息,避免每次查询都需要联合多个表进行关联操作。
数据库的设计理论第一节,关系模式的设计问题一概念:1. 关系模型:用二维表来表示实体集,用外键来表示实体间的联系,这样的数据模型,叫做关系数据模型。
关系模型包含内涵和外延两个方面:外延:就是关系或实例、或当前值。
它与时间有关,随时间的变化而变化。
(主要是由于元组的插入、删除、修改等操作引起的)内涵:内涵是与时间独立的,它包括关系属性、以及域的一些定义和说明。
还有数据的各种完整性约束。
数据的完整性约束分为静态约束和动态约束。
静态约束包括数据之间的联系(称为数据依赖),主键的设计和各种限制。
动态约束主要定义如插入、删除和修改等操作的影响。
通常我们称内涵为关系模式。
2. 关系模式:是对一个关系的描述,二维表的表头那一行称为关系模式,又称为表的框架或记录类型。
关系模式的定义包括:模式名、属性名、值域名和模式的主键。
关系模式仅仅是对数据特征的描述。
关系模式的一般形式为 R ( U , D , DOM , F )R 是关系名。
U 是全部属性的集合。
D 是属性域的集合。
DOM 是 U 和 D 之间的映射关系,关系运算的安全限制。
F 是属性间的各种约束关系,也称为数据依赖。
关系模式可以表示为:关系模式(属性名1,属性名2 ,……,属性名n )示例:学生(学号,姓名,年龄,性别,籍贯)。
当且仅当 U 上的一个关系 r 满足 F 时,r 就称为关系模式 R(U,F)上的一个关系,R是关系的型,r 是关系的值,每个值称为R 的一个关系。
关系数据库模式:一个数据库是由多个关系构成的。
一个关系数据库对应多个不同的关系模式,关系数据库模式是一个数据库中所有的关系模式的集合。
它规定了数据库的全局逻辑结构。
关系数据库模式可以表示为:S = { Ri < Ui , Di , DOM , Fi > | i = 1,2,…, n }3. 关系子模式关系子模式是用户所用到的那部分数据的描述。
外模式是关系子模式的集合。
4. 存储模式存储模式及内模式。
关系数据库理论的主要内容:(1)数据依赖。
数据依赖起着核心的作用。
(2)范式。
(3)模式的设计方法。
如何设计一个合理的数据库模式:(1)与实际问题相结合。
泛关系模式:把现实问题的所有属性组成一个关系模式泛关系:泛关系模式的实例称为泛关系。
泛关系模式中存在的问题:a 数据冗余b 更新异常,c 插入异常d 删除异常。
(2)数据库设计理论:借助近代代数工具,把抽象的数据理论同实际问题结合起来。
理论基础:数据依赖(数据的相关性)。
二,关系模式及其评价。
1 . 关系数据库设计的核心:关系模式的设计。
2 . 关系模式的设计:按照一定的原则,从数量众多的而又互相关联的数据中构造出一组即能较好的反映现实世界,而又有良好的操作性能的关系模式。
3. 关系模式的优劣、评价、改进:冗余度高修改困难插入问题删除问题这些问题的产生原因是:属性间的约束关系太强,即数据间的依赖关系太强。
解决的方法:将关系模式分解为一组较理想的关系模式。
第二节函数依赖一,函数依赖 Functional Dependency函数依赖是数据依赖的一种,反映属性或属性之间的依存、互相制约的关系,既反映现实世界的约束关系。
二,函数依赖的定义设 R ( U ) 是属性 U 上的一个关系模式,X 和 Y 均为 U = { A1,A2 ,…An} 的子集,r 为 R 的任一关系,如果对于 r 中的任意两个元组 u 和 v ,只要有U[X] = V[X] , 就有U[Y] = V[Y] ,则称 X 函数决定 Y ,或称Y 函数依赖于X,记作:X → Y 。
三,函数依赖的语义范畴:1. 语义:数据所反映的现实世界事务本质的联系。
2.根据语义来确定函数依赖型的存在与否。
3.函数依赖反映属性之间的一般规律,必须在关系模式 F 的任何一个关系 r 都满足约束条件。
回顾概念键:由一个或多个属性组成。
设 R (U) 为一个关系模式,F 为 R 的函数依赖集,X 为属性集U的子集。
(1)超键:能唯一标识元组的属性集。
如果 X → U ∈ F ,则 X 是 R 的超键。
(2)候选键:不含有多余属性的超键a X 是 R 的超键。
b 且不存在 X 的真子集 Y ,使得 Y → U ∈ F+则称 X 是 R 的候选键(3)主键:用户选作元组标识的一个候选键。
(4)主属性:包含任何一个候选键的属性。
(5)非主属性:不包含任何一个候选键的属性。
(6)外键:如果关系 R 的某一个属性组不是该关系本身的候选键,而是另一个关系的候选键,则称该属性组是R的外来关键码,或称为外键(外码)。
如何确定候选码?(1)如果有属性不在函数依赖集中出现,那么它必定包含在候选码中。
(2)如果有属性不在函数依赖集中任何函数依赖的右边出现,那么它必定包含在候选码中。
(3)如果该属性或属性组能唯一标识元组,则它就是候选码。
根据对数据库的语义描述,确定其中候选码,同时还可以写出该关系模式的函数依赖集。
四,函数依赖的关系属性间的关系决定函数依赖关系。
设 X 和 Y 都是 U 的子集:1 X 和 Y 的联系是 1 :1 则 X → Y , Y → X .2 X 和 Y 的联系是 M :1 ( M > 1 ) 则 X → Y .3X 和 Y 的联系是 M :N ( M ,N > 1 ) 则,X、Y之间不存在函数依赖。
五函数依赖图: FD 图。
六完全函数依赖和部分函数依赖在 R (U) 中,如果 X → Y ,并且对于 X 的任何真子集 X ` ,都不存在 X` → Y ,则称 Y 完全依赖于 X ,记作X → Y ( 箭头上加个 F 表示 FULL 完全函数依赖 )否则,如果 X → Y ,且 X 中存在一个真子集 X`, 使得 X` → Y ,则 Y 部分函数依赖 X 。
X → Y ( 箭头上面加一个P,表示 PART,部分函数依赖 )七平凡函数依赖和非平凡函数依赖设 X , Y 均为某关系的属性集,并且 X → Y ,若 Y 包含于 X ,则称 X → Y 为平凡函数依赖( Y 是 X 的子集)。
若 Y 不包含于 X ,则称 X → Y 为非平凡函数依赖(Y不是X的子集)第三节函数依赖的蕴涵与公理体系一,函数依赖的逻辑蕴含定义:设有关系模式 R ( U ),及其函数依赖集 F,如果对于 R 的任何一个满足 F 的关系 r ,函数依赖 X → Y 都成立,则称 F 逻辑蕴含 X → Y 或称X → Y 可以由 F 推出,记作:例题:关系模式 R = ( A, B, C ) ,函数依赖集 F = { A→B , B→C }则 F 逻辑蕴含 A→C记作:二,F 闭包定义:若 F 为关系模式 R ( U ) 的函数依赖集,我们把 F 以及所有被 F 逻辑蕴含的函数依赖的集合称为 F 的闭包,记作 F+。
F+ = { X→Y | F ╠ X→Y }三,Armstrong 公理F1 自反律:若Y 包含于X ,则 X → Y (Y 是 X 的子集)F2 增广律:若 X→Y为F所蕴含,则 XZ→YZ 在R上成立。
F3 传递律:若 X→Y,Y→Z在R上成立,则 X→Z 在R上成立。
F4 伪增律:Z是W的子集,X→Y为F所蕴含,则 XW→YZ 在R上成立。
F5 伪传律:若 X→Y,YW→Z为F所蕴含,则 XW→Z 在R 上成立。
F6 合并律:若 X→Y , X→Z 为F所蕴含,则 X→YZ 在 R 上成立。
F7 分解律:若 Z 是Y的子集,X→Y为F所蕴含,则 X→Z在R上成立。
四,属性集的闭包定义:若 F 为关系模式 R ( U ) 的函数依赖集,X 是 U 的子集,则由Armstrong 公理推导出来的所有 X → Ai 所形成的属性集 { Ai | i=1,2,…,n } 称为 X 关于 F 的闭包记为 X +。
属性集闭包的举例:设: R = ABC , F = { A→B, B→C } 当X分别是 A , B , C ,时,求 X+解:当 X = A 时,X+ = ABC当 X = B 时,X+ = BC当 X = C 时,X+ = C定理:X → Y 能根据 Armstrong 推理规则导出的充要条件是:只要 Y 是 X+的子集,则 X → Y 。
只要 X → Y ,则 Y 一定是 X+的子集。
定理: Armstrong 公理的完备性定理函数依赖推理规则系统(自反律、增广律、传递律)是完备的。
函数依赖公理体系Armstrong 公理体系由于Armstrong公理的完备性,Armstrong公理及其推论构成了一个完备的逻辑推理体系,称为Armstrong公理体系:A ,一套形式推理规则。
B ,利用这些推理规则可以求出给定关系模式的关键字。
C ,而且可以从关系模式的一组已知函数依赖出发,求得它蕴含的所有函数依赖。
D ,或者对于给定的 F 和 X → Y ,判断 X → Y 是否在 F+中。
E ,是关系规范化理论的依据。
计算 X+的算法1)依据:若 F 为关系模式 R ( U ) 的函数依赖集,X , Z , W 是 U的子集,对于任意的 Z → W ∈ F , 若 Z 是 X 的子集,则 X→XW2)算法的实现输入:关系模式 R 上的子集 X ,R 上的函数依赖 F输出:X 关于 F 的闭包 X+3)算法:a.令 X (0) = φ , X+ = X ;b. 如果 X(0) ≠ X+ ,置 X(0) = X+,否则,转到 d ;c.对于 f 中的每个未被访问过的函数依赖Y → Z ,若 Y 包含于 X+ ,则令X+ = X+ ∪ Z ,为被访问过的函数依赖设置访问标志,转 b ;d.输出 X+结论判定函数依赖 X → Y 是否能由 F 导出的问题,可以转化为求 X+的闭包,并判定 Y 是否是 X+子集的问题。
即求闭包的问题可以转化为求属性集的问题。
判定给定函数依赖 X → Y 是否蕴含与函数依赖集 F 算法实现:输入:函数依赖集 F ,函数依赖 X → Y输出:若 X → Y ∈F+,输出真,否则输出假。
四,函数依赖的等价和覆盖定义:设 F 和 G 是关系模式 R ( U ) 上的两个函数依赖集,如果F+= G+,则称 F 等价于 G ,亦称 F 覆盖 G 或者 G 覆盖F ,记作:F ≡ G定理1 , 设 F 和 G 是关系模式 R ( U ) 的两个函数依赖集,那么 F+ = G+ 的充分必要条件是:定理2,设 F 和 G 是关系模式 R ( U ) 的两个函数依赖集,那么 F+ = G+的充分必要条件是定理3 ,每个函数依赖集 F 都可以被一个右部只有单属性的函数依赖集 G 所覆盖。
五,最小函数依赖集设 F 是函数依赖集,如果 F 满足(1)F中每个函数依赖 X→Y的右边均为单个属性。