数据库设计理论

合集下载

数据库设计中的范式理论

数据库设计中的范式理论

数据库设计中的范式理论数据库是当今信息技术领域中最为重要的组成部分之一,而数据库的设计则是数据库系统中最为核心的部分。

在数据库设计中,范式理论是最为重要的基础理论之一。

范式理论主要是用来规范数据库中数据的存储方式,以达到数据冗余最小化的目的。

本文将从范式的概念、范式的种类以及它们之间的关系来详细探讨数据库设计中的范式理论。

一、范式的概念范式是数据库设计中最为重要的一个概念。

范式是一个规范,它定义了数据库中数据的存储方式。

它描述了如何将数据有效地组织在数据库表中,从而使得数据在存储、查询、更新等方面都更加高效。

范式的主要目的是降低数据冗余和维护数据一致性。

二、范式的种类根据数据中存在的依赖关系,范式分为第一范式(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. 数据库设计的步骤数据库设计通常包括以下几个步骤:- 需求分析:明确数据库的需求,包括数据类型、数据量、数据关系等。

- 概念设计:根据需求分析结果,设计数据库的概念结构,主要包括实体、属性和关系等。

- 逻辑设计:将概念设计转化为逻辑模型,通常使用ER图或UML 类图表示。

- 物理设计:将逻辑模型转化为物理模型,确定数据存储结构和索引等细节。

- 实施与维护:根据物理设计结果,创建数据库,进行数据导入、备份和恢复等操作。

2. 数据库设计的原则数据库设计应遵循以下原则:- 数据库的一致性:确保数据库中的数据不重复、不冗余。

- 数据库的完整性:保证数据的完整性,防止数据丢失或损坏。

- 数据库的性能:优化数据库查询和更新操作,提高系统性能。

- 数据库的安全性:采取措施保护数据库免受未授权访问和数据泄露的风险。

二、范式理论的基本概念范式理论是数据结构中的一个重要理论框架,主要用于规范化数据库中的数据。

下面介绍数据库设计中常用的三个范式:第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。

1. 第一范式(1NF)第一范式要求数据库表中的每个字段具有原子性,即每个字段不可再分。

同时,每个字段在表中的位置也是固定的。

2. 第二范式(2NF)第二范式要求数据库表中的每个非主键字段完全依赖于主键,即非主键字段不能部分依赖于主键。

如果存在部分依赖,需要将其拆分为多个表。

3. 第三范式(3NF)第三范式要求数据库表中的每个非主键字段不依赖于其他非主键字段,即非主键字段之间不存在传递依赖关系。

数据库课件第4章关系数据库(RDB)规范化设计理论

数据库课件第4章关系数据库(RDB)规范化设计理论


3. 完全函数依赖与部分函数依赖
完全函数依赖: 在关系模式R(U)中,如果X→Y,并且对于X的任何一 个真子集X′,都有X′ Y,则称Y完全函数依赖于X, 记作X f Y。 部分函数依赖: 若X→Y,但Y不完全函数依赖于X,则称Y部分函数依 p Y。 赖于X,记作X



例8: 学生(学号,姓名,所在系,系主任姓名,课程号,成绩) 学生关系模式存在的部分函数依赖: p (学号,课程号) 姓名 p 所在系 (学号,课程号) p (学号,课程号) 系主任姓名
教师姓 名
李林 78号
住址
课程号
C1
课程名
N1
李林
李林 汪佳 吴仪
78号
78号 59号 79号
C2
C3 C4 C5
N2
N3 N4 N5
师帆
76号
C6
N6

⑷当执行数据插入时,DB中的数据不能产生插入 异常现象 所谓“插入异常”是指希望插入的信息由于不 能满足数据完整性的某种要求而不能正常地被 插入到DB中的异常问题。 比如:上例中插入一个尚未安排授课的新进教师 信息. 原因: 因多种信息混合放在一个表中,可能造成因一 种信息被捆绑在其他信息上而产生的信息之间 相互依附存储的问题,使得信息不能独立插入。
第4章
关系数据库(RDB)规范化理论
4.1 关系模式规范化的必要性 4.2 数值依赖 4.3 范式与规范化 、关系分解原则






RDB规范化理论的目的是要设计“好的”RDB模式。要设计 好的关系模式,必须是关系满足一定的约束条件,此约束 形成了规范。 范式(Normal Form):衡量DB规范的层次或深度,DB规范化 层次由范式来决定。简记作NF. 根据关系模式满足的不同性质和规范化的程度,将关系模 式分为第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、 BC范式、第四范式(4NF)、第五范式(5NF),范式越高规范 化程度越高。 规范化:低级关系模式通过模式分解转换为若干高级范式 的关系模式集合的过程。 规范化是在RDB中减少数据冗余的过程。

关系数据库设计理论(关系模式、函数依赖、范式)

关系数据库设计理论(关系模式、函数依赖、范式)

函数依赖关系是属性间的一种多对一的关系。 函数依赖关系是属性间的一种多对一的关系。 如果X →Y, X←Y, 是一对一关系。 如果X →Y,且X←Y,则X和Y是一对一关系。
如学号与身份证号。 如学号与身份证号。
7.2
函数依赖
SQL Server 2000
三、函数依赖的几种特例
1、平凡函数依赖与非平凡函数依赖 、 如果X→Y, 如果X→Y,且Y X→Y 若Y 由于Y 由于Y 称为非平凡函数依赖。 X,则X→Y 称为非平凡函数依赖。
7.1
关系模式的评价
SQL Server 2000
教学(学号,姓名,年龄,系名,系主任,课程名,成绩) 教学(学号,姓名,年龄,系名,系主任,课程名,成绩)
学号 98001 98001 98002 98002 98003 98003 99001 姓名 李华 李华 张平 张平 陈兵 陈兵 陆莉 年龄 21 21 22 22 21 21 23 系名 计算机 计算机 计算机 计算机 数学 数学 物理 系主任 王民 王民 王民 王民 赵敏 赵敏 王珊 课程名 C语言 高等数学 C语言 高等数学 高等数学 离散数学 普通物理 成绩 90 80 65 70 95 75 85
7.1
关系模式的评价
SQL Server 2000
对于有问题的关系模式, 对于有问题的关系模式,可以通过模式分解的方法使之 规范化, 规范化,上述关系模式如果分解为如下三个关系则可以克服 以上出现的问题。 以上出现的问题。 学生(学号,姓名,年龄,系名) 学生(学号,姓名,年龄,系名) 系(系名,系主任) 系名,系主任) 选课(学号,课程名,成绩) 选课(学号,课程名,成绩) 如何分解关系模式,分解的依据是什么? 如何分解关系模式,分解的依据是什么?下二节将讨论 这些问题。 这些问题。

数据库设计规范化的理论研究与应用

数据库设计规范化的理论研究与应用
表 ( T e a c h e r I D,T e a c数据 库 的分析 与设 计一 般分为 “ 需 求 分
际上 ,第三范式就是要求不要在数据库中存储
S e x ,Ag e ,Bi r t h d a y ,T P a s s wo r d ,T i t l e l D)为
图 1系部信 息表 的 S p e c N a m e 字段规 范化设计
先满足 1 NF 。2 NF要求实体的属性完全依赖于 主关键字。所谓完全依赖是指 不存在仅依赖主 关键字一部分的属性,如果存在 ,那么这个属 性和主关键字的这一部分应 该分离 出来形成一 个新 的实体 ,新实体与原实体之间是一对 多的 【 关键词】数据库设计 规 范化 应用 关系 。 ( 4 )第 三 范式 ( 3 NF )。如 果一个 数据 表 己经满足第二范式,而且该数据表 中的任 何 两个非主键字段的数值之间不存在函数依赖 关
Ti t l e l D)
班 级 信 息 表 ( C l a s s l D,Cl a s s Na me ,
De p t l D,T e a c h e r l D, De p t S e t Da t e)


觳 l
S s
c h a r ( 4 ) 专 业编号
C l a a r ( 2 0 )  ̄ 专业名称
捌媾冁 C r a r ( 2 0 )  ̄ 系统名称・
胁 S s 哟 t e x t ,  ̄
截耩 +
融m
t ∞ r
系统 编码 ( 外键) +
都 应 满 足 一 定 的规 范 。 系 部 信 息 表 ( De p t l D,De p t Na me ,
S p e c Na me , De p t S c r i p t )

数据库原理与设计-第四章

数据库原理与设计-第四章

练习:
1、在关系R(R#,RN,S#)和S(S#,SN,SD)中,R的主键
是R#,S的主键是S#,则S#在R中称为 外键

2、用户选作元组元组标识的一个侯选键称为 主键

3、关系模式的任何属性( A )。
A、不可再分
B、可再分
C、命名在该关系模式中可以不惟一 D、以上都不是
4、一个关系数据库文件中的各条记录( B )
练习:
1、分别建立表dept1和emp1,并在二者之间定义关联。
表名
列名
数据约束
约束
DEPT1
Dno NAME
Decimal(3) VARCAHR(10)
PRIMARY KEY
LOC
VARCHAR(20)

表名 EMP1
列名 数据类型
Eno
Decimal(4)
NAME VARCHAR(10)
Salary Decimal(6,2)
Dno
Decimal(3)
约束
UNIQUE
FOREIGN KEY 级联删除
2、增加约束
(1)值唯一; (2)可有一个且仅有一个空值。
唯一约束既可以在列级定义,也可以在表 级定义。
【例4-4】示例。
(1)建立employee表,在employee表中定义一个phone字段, 并为phone字段定义指定名称的唯一约束。
CREATE TABLE employee ( empno DECIMAL(2) PRIMARY KEY, name VARCHAR(8), age DECIMAL(3), phone VARCHAR(12), deptno DECIMAL(2), CONSTRAINT emp_phone UNIQUE(phone) );

自考04735数据库原理及应用关系模式设计理论

自考04735数据库原理及应用关系模式设计理论

自考04735数据库原理及应用关系模式设计理论要求、目标:了解关系数据库规范化理论及其在数据库设计中的作用,重点是函数依赖和范式,要求掌握这些概念并能运用它们来进行模式分解。

一、关系模式的设计准则1.数据冗余:同一个数据在系统中多次重复出现。

2.关系模式设计不当引起的异常问题:数据冗余、操作异常(包括修改异常、插入异常和删除异常)3.关系模式的非形式化设计准则1)关系模式的设计应尽可能只包含有直接联系的属性,不要包含有间接联系的属性。

也就是,每个关系模式应只对应于一个实体类型或一个联系类型。

2)关系模式的设计应尽可能使得相应关系中不出现插入异常、删除和修改等操作异常现象。

3)关系模式的设计应尽可能使得相应关系中避免放置经常为空值的属性。

4)关系模式的设计应尽可能使得关系的等值连接在主键和外键的属性上进行,并且保证以后不会生成额外的元组。

4.习惯使用的一些符号:1)英文字母表首部的大写字母“A,B,C,…”表示单个的属性。

2)英文字母表尾部的大写字母“…,U,V,W,X,Y,Z”表示属性集。

3)大写字母R表示关系模式,小写字母r表示其关系。

4)关系模式的简化表示方法:R(A,B,C,…)或R(ABC…)5)属性集X和Y的并集简写为XY。

二、函数依赖1.函数依赖(FD)的定义:设有关系模式R(U),X和Y是属性集U的子集,函数依赖是形成X→Y的一个命题,只要r是R的当前关系,对r中任意两个元组t和s,都有t[X]=s[X]蕴涵t[Y]=s[Y],那么称FD X→Y在关系模式R(U)中成立。

说明:1)t[X]表示元组t在属性集X上的值,其余类同。

2)X→Y读作“X函数决定Y”或“Y函数依赖于X”。

3)FD是对关系模式R的一切可能的关系r定义的。

对于当前关系r的任意两个元组,如果X值相同,则要求Y值也相同,即有一个X值就有一个Y值与之对应,或者说Y值由X值决定。

例:设关系模式R(ABCD),在R的关系中,属性值间有这样的联系:A值与B值有一对多联系;C值与D值之间有一对一联系。

数据库设计中的多值依赖理论与实践分析

数据库设计中的多值依赖理论与实践分析

数据库设计中的多值依赖理论与实践分析在数据库设计中,多值依赖理论是一种重要的概念,可以帮助我们理解数据之间的关系,并有效地规范数据库的结构。

本文将介绍多值依赖的概念、分类以及如何在实际数据库设计中应用多值依赖理论。

首先,让我们了解一下多值依赖的概念。

多值依赖是指一个关系中的一个属性集合对于另一个属性集合的依赖关系。

具体来说,如果一个属性集合的取值仅确定了另一个属性集合的部分取值,而不是全部取值,那么我们可以称这种关系为多值依赖。

多值依赖可以分为两种类型:完全函数依赖和部分函数依赖。

完全函数依赖是指在一个关系中,如果某个属性集合A的所有属性都对另一个属性B形成依赖,同时去掉A中的任何一个属性都会导致这个依赖关系不再存在,那么我们可以说A完全函数依赖于B。

部分函数依赖是指在一个关系中,如果某个属性集合A的一部分属性对另一个属性B形成依赖,同时去掉A中的任何一个属性都会导致这个依赖关系不再存在,那么我们可以说A部分函数依赖于B。

在实际数据库设计中,多值依赖理论有助于避免冗余数据和数据更新异常。

通过正确地建立关系模式,可以减小数据库的存储空间、提高查询效率,也可以提高数据的一致性和完整性。

在设计关系模式时,我们通常遵循以下几个原则:1. 第一范式(1NF):关系模式中的属性不可再分。

2. 第二范式(2NF):关系模式的非主属性完全依赖于候选键。

3. 第三范式(3NF):关系模式中不存在传递依赖。

基于以上原则,我们可以进行多值依赖的分析和处理。

首先,我们需要找出关系模式中存在的多值依赖,可以通过以下方法进行:1. 通过调查、分析和需求了解,识别出关系模式中的属性集合和它们之间的依赖关系。

2. 通过已有的数据和样本数据,进行数据分析和处理。

例如,可以利用数据挖掘算法识别出存在的多值依赖。

一旦发现了多值依赖,我们可以通过以下几种方法来处理它们:1. 分解:将多值依赖的关系模式拆分成多个关系模式,以消除冗余数据。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

数据库的设计理论第一节,关系模式的设计问题一概念: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的右边均为单个属性。

(2)F中的任何一个函数依赖X→A ,其F-( X→A ) 都与 F 不等价。

(3)F中的任何一个函数依赖X→A , Z为X的真子集,( F -{ X→A } ) ∪{ Z →A } 都与F 不等价。

则称, F 为最小函数依赖集。

(2)是消除右侧冗余。

(3)是消除左侧冗余。

因为(2),(3)没有先后顺序,所以,最小函数依赖不是唯一的。

相关文档
最新文档