在数据库的函数依赖里，闭包(closure)是什么意思？谢谢~

闭包就是由一个属性直接或间接推导出的所有属性的集合，例如：

f={a->b,b->c,a->d,e->f}

由a可直接得到b和d，间接得到c，则a的闭包就是{a,b,c,d}

课程（课程号，课程名，学分）

授课（授课教师号，教师名）

时数（课程号，授课教师号，授课时数）

1NF:字段不可分;

2NF:有主键，非主键字段依赖主键;

3NF:非主键字段不能相互依赖;

解释:

1NF:原子性 字段不可再分,否则就不是关系数据库;

2NF:唯一性 一个表只说明一个事物;

3NF:每列都与主键有直接关系，不存在传递依赖;

首先，求闭包的算法：

输入：有限的属性集合U，它上面的函数依赖集F，

和U的一个子集X。

输出：X关于F的属性闭包X+ 。

方法: (1)置初始X(0)= X(1)=X;

(2)如果X(0)X(1)，置X(0)=X(1)，否则转向(4)；

(3)对F中的每一个函数依赖YZ,若 YX(1)，

置X(1)=X(1)Z，并转(2) ；

(4) 输出X(1)，即为X+ 。算法终止。

下面，利用上面算法解题，

X(0)=Φ，X(1)=D

因为x(0) ≠x(1),所以令X（0）=D

由D->HG得X（1）=D U HG=DHG

因为x(0) ≠x(1),所以令X（0）=DHG

因为此时没有关于DHG的函数依赖了，所以X（1）=DHG不变

此时X(0)= X(1)所以D的闭包等于DHG

以上为初学者必须掌握的基本算法（应该还有其他的，我们老师只讲了这种滴~）

其实根本不用这么复杂，熟悉了可以直接写结果

X(0)=D

由D->HG得X（1）=D U HG=DHG

因为此时没有关于DHG的函数依赖了，所以X（2）=DHG不变

X（1）=X（2）循环结束，D的闭包等于DHG

（望采纳哦~~~~~）

BCNF范式在3NF基础上消除对主码子集的依赖。

以仓库管理关系表为例：仓库号，存储物品号，管理员号，数量。首先该表满足第三范式，也就是说一个管理员只在一个仓库工作，一个仓库能够存储多种物品。表中存在有如下依赖关系：

(仓库号，存储物品号)——>(管理员号，数量)

(管理员号，存储物品号)——>(仓库号，数量)

由以上依赖关系可以得知(仓库号，存储物品号)和(管理员号，存储物品号)为表关系中的候选码。

表中唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况，因此其不符合BCNF。

解决方法：把仓库管理关系表分解为两个关系表仓库管理表(仓库号，管理员号)和仓库表(仓库号，存储物品号，数量)，这样这个数据库表是符合BCNF的，并消除了删除异常、插入异常和更新异常。

扩展资料：

巴斯-科德范式（BCNF）是第三范式（3NF）的一个子集，即满足巴斯-科德范式（BCNF）必须满足第三范式（3NF）。通常情况下，巴斯-科德范式被认为没有新的设计规范加入，只是对第二范式与第三范式中设计规范要求更强，因而被认为是修正第三范式。

也就是说，它事实上是对第三范式的修正，使数据库冗余度更小。这也是BCNF不被称为第四范式的原因。某些书上，根据范式要求的递增性将其称之为第四范式是不规范，也是更让人不容易理解的地方。而真正的第四范式，则是在设计规范中添加了对多值及依赖的要求。

-数据库范式

利用分解规则，将所有的函数依赖变成右边都是单个属性的函数依赖。从题目来看，F中的任何一个函数依赖的右部仅含有一个属性：{A→B，B→A，B→C，A→C，C→A}

第二步去冗余的的顺序不同，产生结果也会不同，故最小函数依赖集合不止一个，还可发现另一个最小（极小）函数依赖集合为：{A→B，B→A，A→C，C→A}

给定一个数集A，假设其中的元素为x。现对A中的元素x施加对应法则f，记作f（x），得到另一数集B。假设B中的元素为y。则y与x之间的等量关系可以用y=f（x）表示。函数概念含有三个要素：定义域A、值域C和对应法则f。其中核心是对应法则f，它是函数关系的本质特征。

扩展资料：

函数的对应法则通常用解析式表示，但大量的函数关系是无法用解析式表示的，可以用图像、表格及其他形式表示。

函数与不等式和方程存在联系（初等函数）。令函数值等于零，从几何角度看，对应的自变量的值就是图像与X轴的交点的横坐标；从代数角度看，对应的自变量是方程的解。

另外，把函数的表达式（无表达式的函数除外）中的“=”换成“<”或“>”，再把“Y”换成其它代数式，函数就变成了不等式，可以求自变量的范围。

——函数

以class2为例，如果你只需要一个class2实例，那么把它在class1成员中声明为共享成员即可。

Shared c2 As New Class2()

然后调用它的函数，

c2func()

如果class2的这个函数不依赖于class2实例，那么直接将这个函数用Shared声明，

Public Shared Function func() As xxx

'xxxxx

End Function

然后在class1中引入，

Imports class2

直接调用即可。

func()

我想第二种更符合你的情况。

[标准答案]

1、

grant

select

on

职工

when

user（）=

name

to

all；

这里假定系统的

grant语句支持when子句和user（）的使用。用户将自己的名字作为id。

reovke

select

on

职工

when

user（）=

name

from

all；

这里假定用户将自己的名字作为id，且系统的reovke语句支持when子句，系统也支持user（）的使用。

2、

create

view

部门工资统计（最高工资，最低工资，平均工资）

as

select

max(工资)，min（工资），avg(工资)

from

职工

group

by

部门号；

grant

select

on

部门工资统计

to

扬兰；

revoke

select

on

部门工资统计

from

扬兰；

1第一范式：存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B。如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的。

那么符合第一模式的特点就有：有主关键字、主键不能为空、主键不能重复,、字段不可以再分。例如：

StudyNo   |   Name   |   Sex   |   Contact

20040901      john         Male      Email:kkkk@eenet,phone:222456

20040901      mary         famale    email:kkk@fffnet phone:123455

以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分

所以变更为正确的是：

StudyNo   |   Name   |   Sex   |      Email         |      Phone

20040901      john         Male       kkkk@eenet       222456

20040902     mary          famale      kkk@fffnet      123455

2第二范式：存在非主属性对码的传递性依赖 R(A,B,C) A是码 A -->B ,B-->C。如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。所以第二范式的主要任务就是：满足第一范式的前提下，消除部分函数依赖。

StudyNo   |   Name   |   Sex   |         Email         |      Phone    |   ClassNo  | ClassAddress

01                  john        Male       kkkk@eenet     222456      200401            A楼2

01                   mary       famale    kkk@fffnet       123455      200402            A楼3

这个表完全满足于第一范式,主键由StudyNo和ClassNo组成，这样才能定位到指定行。但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress，所以要变为两个表：

表一

StudyNo   |   Name   |   Sex   |      Email         |      Phone |   ClassNo

01            john         Male       kkkk@eenet  222456   200401     

01           mary         famale    kkk@fffnet    123455      200402    

表二

ClassNo  | ClassAddress

200401      A楼2

200402      A楼3

3第三范式

不存在非主属性对码的传递性依赖以及部分性依赖 ，

StudyNo   |   Name   |   Sex   |      Email         |      bounsLevel   |   bouns

20040901      john         Male       kkkk@eenet   优秀                    $1000

20040902     mary         famale    kkk@fffnet       良                         $600

这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖，更改为：

StudyNo   |   Name   |   Sex   |      Email         |      bouunsNo

20040901      john         Male       kkkk@eenet   1

20040902     mary         famale    kkk@fffnet       2

bounsNo   |   bounsLevel   |   bouns

1                   优秀                $1000

2                 良                   $600

这里可以用bounsNo作为主键，基于两个原因

（1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？

（2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以一般优先使用与业务无关的字段作为关键字。

一般满足前三个范式就可以避免数据冗余。

扩展资料：

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。

参考链接：

-数据库范式