数据库设计与关系理论

❶ 数据库概述里的数据库结构的3级模式，与关系理论中的关系模式，是否指的一个东西

不是，三级模式是指，外模式，概念模式，内模式。用户级对应外模式，概念级对应概念模式，物理级对应内模式。关系理论的关系模式是指二维表的设计。

❷ 什么是数据库的概念设计、逻辑设计、物理设计，以及三者的关系

1、概念设计：

对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。

所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。

2、逻辑设计：

主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

3、物理设计：

根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

4、三者关系：

由上到下，先要概念设计，接着逻辑设计，再是物理设计，一级一级设计。三者一环扣住一环，缺一不可，概念设计是前提，逻辑设计是纽扣，将概念设计和物理设计紧密联系起来，物理设计的结果就是传说中的“物理数据库”也就是最后的结果。三者密不可分，缺一不可。

(2)数据库设计与关系理论扩展阅读

数据库设计的基本步骤：

1、需求分析阶段：准确了解与分析用户需求（包括数据与处理），是整个设计过程的基础，是最困难、最耗费时间的一步。

2、概念结构设计阶段：是整个数据库设计的关键,通过对用户的需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。从实际到理论。

3、逻辑结构设计阶段：将概念结构转换为某个DBMS所支持的数据模型,对其进行优化。优化理论。

4、数据库物理设计阶段：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。选择理论落脚点。

5、数据库实施阶段：运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果,建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。理论应用于实践。

6、数据库运行和维护阶段：数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。理论指导实践，反过来实践修正理论。

主要特点：

1、 实现数据共享：数据库服务器数据共享包含所有用户可同时存取数据库中的数据，也包括用户可以用各种方式通过接口使用数据库，并提供数据共享。

2、 减少数据的冗余度：同文件系统相比，由于数据库实现了数据共享，从而避免了用户各自建立应用文件。减少了大量重复数据，减少了数据冗余，维护了数据的一致性。

3、数据的独立性：数据的独立性包括逻辑独立性（数据库中数据库的 逻辑结构和 应用程序相互独立）和物理独立性（数据物理结构的变化不影响数据的逻辑结构）。

4、数据实现集中控制：文件管理方式中，数据处于一种分散的状态，不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理，并通过 数据模型表示各种数据的组织以及数据间的联系。

5、数据一致性和可维护性，以确保数据的安全性和可靠性主要包括：安全性控制：以防止数据丢失、错误更新和越权使用；完整性控制：保证数据的正确性、有效性和相容性；并发控制：使在同一时间 周期内，允许对数据实现多路存取，又能防止用户之间的不正常交互作用。

6、故障恢复：由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。

❸ 《数据库设计与关系理论》epub下载在线阅读全文，求百度网盘云资源

《数据库设计与关系理论》（戴特）电子书网盘下载免费在线阅读

资源链接：

链接：

书名：数据库设计与关系理论

作者：戴特

出版社：东南大学出版社

出版年份：2013-1

页数：260

内容简介：

《数据库设计与关系理论(影印版)(英文版)》的每一章都包含一组练习，它或者展示了如何把理论知识应用到实践中，或者提供了更多的信息，或者要求你验证一些简单的理论结果。如果你非常熟悉数据库的关系模式，并且你希望深入了解数据库设计，那么此书就完全适合你。

❹ .数据库设计分为几个阶段,各阶段的任务是什么

按照规范的设计方法，一个完整的数据库设计一般分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库的实施、数据库运行与维护六个阶段：

各阶段的任务如下：

1、需求分析：分析用户的需求，包括数据、功能和性能需求；

拓展资料：

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂，因此最佳设计不可能一蹴而就，而只能是一种"反复探寻，逐步求精"的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。

❺ 关系数据库规范化理论的基础和内容

一个关系数据库模式由一组关系模式组成，一个关系模式由一组属性名组成。关系数据库设计，就是如何把已给定的相互关联的一组属性名分组，并把每一组属性名组成关系的问题。然而，属性的分组不是唯一的，不同的分组对应着不同的数据库应用系统，它们的效率往往相差很远。
为了使数据库设计合理可靠，简单实用，长期以来，形成了关系数据库设计的理论——规范化理论。
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的内容，已超出了本课程教学大纲的要求，在此不再介绍。

❻ 关系数据库设计理论主要包括几个方面的内容,其中起核心作用的是什么

关系数据库设计理论主要包括三个方面内容,其中起核心作用的是数据依赖。

❼ 数据库设计中，关系模式的规范化理论是应用在什么阶段

数据库 data base 为满足某一部门中多个用户多种应用的需要，按照一定的数据模型在计算机系统中组织、存储和使用的互相联系的数据集合。 带有数据库的计算机系统，除具备一般的硬件、软件外，必须有用以存储大量数据的直接存取存储设备、管理并...

❽ SQL关系数据库设计理论中提到的超健和候选键的概念怎么理解，很抽象。

超键就是指一组字段可以唯一确定一条数据，而候选键是最简洁的超键，也就是只有必要字段，
举例来说明，假如有一个班级，班级中没有同名的学生，有如下一张表。
std_id last_name first_name gender score
10001 张 三 男 85
10002 李 四 男 86
10005 妹 子 女 95
10006 李 三 男 88
这张表里，因为我们前面说到这个班级里没有同名的学生。
因此last_name+first_name就是一个超键，因为可以唯一确定一行数据，同时也是一个候选键，因为这两个字段去掉任何一个都不再能唯一确定一行数据。
更明显的区别在于，last_name+first_name+gender还是一个超键，但是已经不再是候选键了，因为在确定唯一一条数据的时候，gender不是必要的字段。
也就是说候选键是可以唯一确定一条数据的必要字段的最小集合，而候选键加上任何的额外字段都是超键。
在上面的例子中，std_id自己就是一个候选键，std_id+任何额外的字段都是候选键。
同时从习惯而言，一般会把这种std_id字段定义为主键，主键并不一定只是一个字段，如果我们上面的表增加一列班级id(class_id)，同时加入每个班级中的std_id都是从10001开始的话，我们就可以用class_id+std_id来作为主键。
自己的理解，希望可以帮到题主。

❾ 在关系数据库设计理论中,起核心作用的是什么

数据库 data base 为满足某一部门中多个用户多种应用的需要，按照一定的数据模型在计算机系统中组织、存储和使用的互相联系的数据集合。 带有数据库的计算机系统，除具备一般的硬件、软件外，必须有用以存储大量数据的直接存取存储设备、管理并控制数据库的软件——数据库管理系统(DBMS)、管理数据库的人员——数据库管理员 (DBA)。这样的数据、硬件、软件和管理人员的总体构成数据库系统。数据库仅是数据库系统的一个组成部分。 数据库系统的功能和特征 数据库系统由文卷系统发展而来。与文卷系统相比，这种系统具有数据、体系和控制三个方面的主要特征。 数据特征 在文卷系统中虽然程序与数据之间可用存取方法进行转换,但文卷还是与应用程序对应的,即数据仍面向应用。每一应用各自建立自己的一组文卷。不同的应用若涉及相同的数据，则这些数据分别纳入各自的文卷之中。文卷的各种记录之间没有建立联系，因而数据冗余度大。增加新的应用，必须同时增加新的文卷。因此，文卷系统中的文卷是无结构的、不易扩充的信息集合。数据库则不仅描述数据本身，而且描述数据之间的联系。它的数据结构反映了某一部门的整体信息结构，数据冗余度小、易于扩充新的应用，因而是面向数据总体结构的信息集合，可为多个用户共享。 体系特征 一切数据都有逻辑和物理两个侧面。在数据库系统中，数据逻辑结构的描述称为逻辑模式。逻辑模式又分为描述全局逻辑结构的全局模式(简称模式)和描述某些应用所涉及的局部逻辑结构的子模式。数据物理结构的描述称为存储模式。这两种模式总称为数据库模式。 数据库系统中，用户根据子模式编制程序。子模式与模式模式与存储模式之间有软件进行映射。因此,程序与数据之间具有两级独立性：物理独立性和逻辑独立性。数据的存储模式改变，而模式可以不改变，因而不必改写应用程序,这称为物理独立性。模式改变时,子模式可能不改变，也就不必改写应用程序，这称为逻辑独立性。由于数据库系统具备比较高的程序与数据的独立性，可以使程序员在编制应用程序时集中精力考虑算法逻辑，不必过问物理细节，而且可以大大减少应用程序维护的工作量。 控制特征 数据库数据数量庞大，结构复杂，又为多个用户所共享。因此，必须由数据库管理系统在定义、建立、运行以及维护时进行统一管理和控制，以保证数据库数据的安全性、完整性和并发操作的一致性。此外，还必须有数据库管理员专门负责对数据库的管理、控制监督和改进。 由于数据库系统具有上述特征，它的出现使信息系统的研制从围绕加工数据的程序为中心，转变到围绕共享的数据库来进行。这便于数据的集中管理，有利于应用程序的研制和维护。数据减少了冗余度和提高了相容性，从而提高了作出决策的相容性。因此，大型复杂的信息系统大多以数据库为核心，数据库系统在计算机应用中起着越来越重要的作用。 研究课题 数据库研究的课题，主要涉及三个领域。 数据库管理系统软件的研制 DBMS是数据库系统的基础。研制DBMS的基本目标，是扩大功能，提高性能和可用性，从而提高用户的生产率。70年代以来，研制的重点是探索关系数据库管理系统的设计，内容包括关系数据语言、查询优化、并发控制和系统性能等。另一类课题是对DBMS标准化的研究，即研究一个统一的DBMS体系结构的规范。 数据库设计 这是在计算机系统具有的数据库管理系统的基础上，按照应用要求以及计算机系统所提供的数据模型和功能，设计一个结构良好、使用方便、效率较高的，以数据库为核心的应用信息系统。这一领域主要的研究课题，是数据库设计方法学和设计工具的探索。例如，运用软件工程的方法和工具指导数据库设计；研究数据库设计各个阶段中完备的方法和工具；以关系数据库的规范化理论为指南进行数据库逻辑设计等。 数据库理论 主要研究关系数据库理论。关系数据库理论研究的意义，一方面在于它为数据库学科奠定了理论基础;另一方面它为数据库设计提供了判别标准,从而成为数据库设计的有力指南。研究的主要内容是关系的规范化理论。关系规范化理论已应用于数据库设计的各个阶段。 发展 数据库技术是计算机科学中发展最快的领域之一，新的领域越来越多。 分布式数据库系统 随着70年代后期分布计算机系统的发展，相应地研究成功分布式数据库系统。分布式数据库系统是一个在逻辑上完整，而在物理上分散在若干台互相连接的结点机上的数据库系统。它既具有分布性又具有数据库

❿ 如何进行数据库的设计

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统
(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的
功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
(3)数据库设计是信息系统开发和建设的重要组成部分。
(4)数据库设计人员应该具备的技术和知识：
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识

二、数据库设计的特点
数据库建设是硬件、软件和干件的结合
三分技术，七分管理，十二分基础数据
技术与管理的界面称之为“干件”
数据库设计应该与应用系统设计相结合
结构（数据）设计：设计数据库框架或数据库结构
行为（处理）设计：设计应用程序、事务处理等
结构和行为分离的设计
传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计
如图：

三、数据库设计方法简述
手工试凑法
设计质量与设计人员的经验和水平有直接关系
缺乏科学理论和工程方法的支持，工程的质量难以保证
数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法
手工设计方
基本思想
过程迭代和逐步求精
规范设计法(续)
典型方法：
(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段
S.B.Yao方法：将数据库设计分为五个步骤
I.R.Palmer方法：把数据库设计当成一步接一步的过程
(2)计算机辅助设计
ORACLE Designer 2000
SYBASE PowerDesigner

四、数据库设计的基本步骤
数据库设计的过程(六个阶段)
1.需求分析阶段
准确了解与分析用户需求（包括数据与处理）
是整个设计过程的基础，是最困难、最耗费时间的一步
2.概念结构设计阶段
是整个数据库设计的关键
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
3.逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型
对其进行优化
4.数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
5.数据库实施阶段
运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果
建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
6.数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改
设计特点:
在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

设计过程各个阶段的设计描述：
如图：

五、数据库各级模式的形成过程
1.需求分析阶段：综合各个用户的应用需求
2.概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)
3.逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
4.物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

六、数据库设计技巧

1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。

2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则
4) 每个表中都应该添加的3 个有用的字段
dRecordCreationDate，在VB 下默认是Now()，而在SQL Server • 下默认为GETDATE()
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT • USER
nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因 •
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
为关联字段创建外键。 •
所有的键都必须唯一。 •
避免使用复合键。 •
外键总是关联唯一的键字段。 •
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。

索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。

4. 数据完整性设计（数据库逻辑设计）
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。