第三章数据库的逻辑结构与物理结构设计数据库的逻辑结构设计的主要任务是把概念层数据模型转换为组织层数据模型，即根据数据库的概念结构导出特定的数据库管理系统可以处理的数据库的逻辑结构。与数据库的逻辑结构相对应，本章我们称组织层的数据模型为逻辑模型。数据库的物理结构设计的主要任务是为逻辑模型选取一个最适合应用要求的物理结构。
本章主要介绍以下内容：
?逻辑模型
?关系模型
?关系规范化
?逻辑结构设计的任务
?数据库的物理结构设计
第一节逻辑模型
概念模型经过转换成为逻辑模型（也称为结构数据模型、组织层数据模型，常简称为数据模型）。它直接面向数据库的逻辑结构，直接与DBMS有关。
一、主要的逻辑模型
目前，数据库领域中主要的逻辑模型有层次模型、网状模型、关系模型和面向对象模型等。
1. 层次模型
层次模型（Hierarchical Model）是按照层次结构的形式组织数据库数据的数据模型，是数据库中使用较早的一种数据模型，其典型代表是IBM公司研制的、曾经被广泛使用的第一个大型商用数据库信息管理系统IMS（Information Management System）。
（1）数据结构。层次模型使用树形结构表示实体及实体间的联系。层次模型的基本特点是：有且只有一个结点没有父结点，这个结点称为根结点；根以外的其他结点有且只有一个父结点。
在层次模型中，树的结点是记录类型。上一层记录类型和下一层记录类型之间的联系是1:n的，用结点之间的连线表示。这种联系是父子之间的一对多联系。层次模型如图3-1所示。在层次模型数据库中查找记录，必须指定存取路径，即从根结点开始沿途所经过的路程。
在层次模型中，同一父结点的子结点称为兄弟结点，没有子结点的结点称为叶结点。如果要存取某一记录类型的记录，可以从根结点开始，按照有向树层次逐层向下查找，查找路径就是存取路径。任何一个给定的记录值只有按其路径查看时，才能显示其全部意义，没有一个记录值能够脱离父记录而独立存在。除根节点外，任何结点的父结点都是唯一的，因此只要知道每个结点的父结点，就可以知道整个模型的整体结构。
图3-1层次模型示例
（2）层次模型的优缺点。层次模型的优缺点，如表3-1所示。
表3-1层次模型的优缺点
2. 网状模型
网状模型的典型代表是DBTG系统，亦称CODASYL系统。这是20世纪70年代数据系统语言研究会(Conference on Data System Language, 简称CODASYL)下属的数据库任务组(Data Base Task Group,简称DBTG)提出的一个系统方案。DBTG系统虽然不是实际的软件系统，但是它提出的基本概念、方法和技术具有普遍意义，对于网状数据库系统的研制和发展起了重大的影响。
（1）数据结构。网状模型是用网状结构表示实体及其之间联系的模型。网状模型的特点如下：可以有一个以上结点无父结点；至少有一个结点有一个以上父结点。网状模型和层次模型在本质上是一样的，它们都是基本层次联系的集合。网状模型结点之间的联系不受层次的限制，可以任意发生联系，所以它的结构是结点的连通图，如图3-2所示。
图3-2网状数据模型
（2）网状模型的优缺点。网状模型的优缺点如表3-2所示。
表3-2网状模型的优缺点
3. 关系模型
关系模型是目前最重要、应用最广泛的一种数据模型。现在主流的数据库系统大都是基于关系模型的关系数据库系统（Relational Database System ）。关系模型是由美国IBM 公司San Jose 研究室的研究员E.F.Codd 于1970年首次提出的。20世纪80年代以来，计算机新推出的DBMS 几乎都支持关系模型。
（1）数据结构。在关系数据模型中，把二维表格称为关系，表中的列称为属性，属性的取值范围称为域，表中的一行称为一个元组，元组用关键字标识。关系模型是由若干关系模式组成的集合。在关系模型中用二维表表示实体集及其属性，用二维表描述实体集间的联系。
（2）关系模型的优缺点。关系模型的优缺点如表
3-3所示。
表3-3 关系数据模型的优缺点
关系模型自诞生以后发展迅速，深受用户的喜爱。而计算机硬件的飞速发展，更大容量、更高速度的计算机在一定程度上弥补了关系数据模型的缺点。因而，关系数据库始终保持其主流库的地位。本书后面章节所介绍的内容主要讲解关系数据库。
4. 面向对象模型
面向对象的概念最早出现在程序设计语言中，20世纪70年代末、80年代初开始提出了面向对象的数据模型（Object －Oriented Data Model ），面向对象模型是面向对象概念与数据库技术相结合的产物，用以支持非传统应用领域对数据模型提出的新需求。它的基本目标是以更接近人类思维的方式描述客观世界的事物及其联系，且使描述问题的问题空间和解决问题的方法空间在结构上尽可能一致，以便对客观实体进行结构模拟和行为模拟。
面向对象模型的基本概念有：对象、类、消息与封装、继承。
（1）对象（Object ）：对象是现实世界中的实体的模型化。现实世界中的任一实体都可
模型化为一个对象，每一个对象都有唯一的对象标识，把状态和行为封装在一起。
对象由状态和行为两部分组成，对象的状态是对象属性的集合。属性是用来描述对象的状态、组成及特性，属性既可以是一些简单的数据类型，也可以是一个对象，即对象可以嵌套。对象的行为是在对象状态上操作的方法的集合。方法用来描述对象的行为方式。方法的定义一般分为接口说明和实现两部分，接口说明与子程序的接口说明类似，用以说明方法的名称、参数和结果返回值的类型等。方法的实现是一段程序代码，用以实现方法的功能。
（2）类（Class）：具有相同属性集和方法集的所有对象构成一个类。任一个对象是某一类的一个实例。类可以由用户自定义，也可以从其他类派生出来，称为子类，原来的类称为超类（或父类），一个子类可以有多个超类，有的是直接的，也有的是间接的。超类和子类构成层次结构关系，称为类层次。如图3-3所示，研究生、本科生及专科生都是学生类的子类，博士研究生、硕士研究生是研究生的子类，学生和研究生是博士研究生及硕士研究生的超类，其中研究生是直接超类。
（3）消息（Message）与封装（Encapsulation）：由于每个对象是其状态与行为的封装，一个对象不能直接访问或改变另一对象的内部状态（属性）和行为（方法）。对象与外部的通信只能借助于消息，消息从外部传递给对象，调用对象的相应方法，执行相应的操作，再以消息的形式返回操作的结果，这是面向对象模型的主要特征之一。封装使方法的接口和实现分开，有利于数据的独立性，同时封装使对象只接受对象中所定义的操作，有利于提高程序的可靠性。
图3-3类层次
（4）继承（Inheritance）：子类可以继承其所有超类中的属性和方法，同时子类还要定义自己的属性和方法。如图3-3所示的硕士研究生继承了研究生的所有属性和方法。继承是面向对象模型中避免重复定义的机制之一，大大减少了信息冗余，而且作为一种强有力的建模工具，能以人类思维规律对现实世界提供一种简明准确的描述，同时也有利于软件的重用。
面向对象模型由于语义丰富，表达自然，因此面向对象数据库作为新一代数据库，在一些新的应用领域如CAD、CAM、CASE等得到了广泛重视和发展。
二、逻辑模型的三要素
逻辑模型是一种形式化的数据描述、数据间联系以及有关语义约束规则的方法。数据库专家E.F.Codd认为：一个基本数据模型是一组向用户提供的规则，这些规则规定逻辑结构
如何组织以及允许进行何种操作。通常一个数据库的逻辑模型由数据结构、数据操作和数据的约束条件三部分组成，这三部分又称为逻辑模型的三要素。
1. 数据结构
数据结构用于描述数据库系统的静态特性，是逻辑模型最基本的组成部分，规定了如何把基本的数据项组织成较大的数据单位，以描述数据的类型、内容、性质和数据之间的相互关系。
通常，在数据库系统中按照数据结构的类型来命名逻辑模型。例如，层次型数据结构、网状型数据结构和关系型数据结构的逻辑模型分别称为层次模型、网状模型和关系模型。数据结构是刻画一个逻辑模型性质最重要的方面。
2. 数据操作
数据操作用于描述数据库系统的动态特性，是指一组用于指定数据结构的任何有效的操作或推导规则。数据库中主要的操作有查询和更新两大类。逻辑模型必须定义这些操作的确切含义、操作符号、操作规则以及实现操作的数据库语言。
3. 数据的约束条件
数据的约束条件是一组完整性规则的集合，它定义了给定逻辑模型中数据及其联系所具有的制约和依存规则，用以限定相容的数据库状态的集合和可容许的状态改变，以保证数据库中数据的正确性、有效性和相容性。
完整性约束的定义对逻辑模型的动态特性做了进一步的描述与限定。因为在某些情况下，若只限定使用的数据结构及可在该结构上执行的操作，仍然不能确保数据的正确性、有效性和相容性。为此，每种数据模型都规定有通用和特殊的完整性约束条件。例如，关系模型中通用的约束规则是实体完整性和引用完整性。特殊的约束规则是用户定义的完整性。
第二节 关系模型
由于关系模型是目前最重要、应用最广泛的一种数据模型，而且当前大多数数据库系
统都是基于关系模型的关系数据库系统，因此本节详细讨论关系模型。
一、关系模型的数据结构
关系模型是以集合论中的关系概念为基础发展起来的数据模型。在关系模型中，基本元素包括关系、关系模式、属性、元组、域、关键字以及关系实例等。
1．关系
一个对象可以用一个或多个关系来描述。关系就是定义在它的所有属性域上的多元关系。设关系为R ，它有属性12,,,n A A A ，其对应的域分别为12,,,n D D D ，则关系R 可表示为：()1122/,/,,/n n R D A D A D A 或()12,,,n R A A A 。
上式是关系R 的描述，()1i A i n ≤≤是属性名，R 的值用r 或r (R )表示，n 是R 的属性的个数，称为关系的目。从形式上看，关系相当于一个二维表(Table)，如表3-4所示的学生信
息表就是一个关系，可表示为：学生（学号，姓名，性别，出生年份，入学年份，班级号）。
关系可以有三种类型：基本关系（又称为基本表或基表）、查询表和视图表。基本表是实际存在的表，它是实际存储数据的逻辑表示。查询表是查询结果对应的表。视图表是由基本表或其它视图表导出的表，是虚表，不对应实际存储的数据。
关系要满足以下四个条件：
（1）关系中的每一列都是不可再分的基本属性。如表3-4所表示的关系就满足这个条件。但如果将出生年份改为出生日期，出生日期下面再分出年、月、日三个子属性，则出生日期就不是基本属性，相应的关系就不满足这个条件。
（2）表中各属性不能重名。
（3）表中任意两个元组不能完全相同。
（4）表中的行、列次序无关紧要，可以任意交换。 2．关系模式
关系数据库就是支持关系模型的数据库系统。所以它以二维表形式来组织数据，由型和值两部分组成，关系模式是型，关系是值。关系模式是对关系的描述或定义，包括关系名、属性、属性对应的域集合、属性到域的映射以及属性之间数据的依赖关系。记为
(),,,R U D d o m F
。其中R 为关系名，U 为该属性的集合，即{}12,,,n U A A A = ；D
为域的集
合，{}
12,,,n D
D D D = ，即属性取值范围的集合；dom 为属性集U 到D 的映射，即属性与
域之间的对应关系；F 为属性集U 上的数据依赖关系。
通常，域的定义和映射直接说明为属性的类型和长度，而数据依赖关系将在第三节介绍，因此，通常把关系模式简化为R (U )。
关系模式和关系是型和值的关系。一个关系模式可以对应多个关系，但在某一特定的时刻关系模式总有一个关系与之对应，即关系是关系模式在某一时刻的状态或内容。一般说来，关系模式是相对稳定的，而关系的值是相对变化的。但在很多情况下，人们通常把关系模式和关系统称为关系。
当讨论数据库时，必须区分关系模式和关系实例的概念。关系模式是一种逻辑设计，包括了关系名和关系的属性，相对比较稳定。而关系实例是给定的关系模式中数据的快照，相对来说经常发生变化。在关系模型中，数据库设计包含了一个或多个关系模式。关系数据库模式是关系模式的集合，简称数据库模式。例如，在学生数据库中，若包括了三个关系模式Student, Class, Grade ，那么这三个关系模式的设计集合称为数据库模式。该数据库模式的设计过程如图3-4所示。
图3-4 数据库模式设计过程
3、属性
二维表中的列（Column ）称为属性(Attribute)，列中的值取自相应的域（Domain ），域是属性所有可能取值的集合。虽然关系数据模型采用了数学中关系的概念，但两者还是有些差别。在数学中，元组中的值是有序的，而在关系模型中对属性的次序是不作规定的，例如
),(21A A R 和),(12A A R 两种表示是等价的。
4、元组
表中的一行(Row)称为一个元组（Tuple ）。元组就是关系中的数据，元组的各分量分别对应于关系中的各个属性。当需要表示关系中的一个元组时，一般是把一个元组的各个分量按照属性的标准排列顺序列表在一个圆括号内，分量之间使用逗号分开。如表3-4中的元组可表示为：（050125，刘菲，女，1987，2005，05111）。
5、键(Key)
（1）候选键（Candidate key ）：如果关系的某一属性或属性组的值唯一地决定其他所有属性的值，即唯一地决定一个元组，而其任何真子集无此性质，则这个属性或属性组称为关系的候选键，或简称为键。在简单情况下，候选键只包含一个属性，而在极端情况下，候选键包含关系中的所有属性，称为全键（All-key ）。
（2）主键(Primary Key)：从侯选键中选定一个为主键（Prime Key ）。主键也称为关键字（Keyword ），用来识别和区分元组，它应该是唯一的，即每个元组的主键的值是不能相同的。在关系模式中，常在主键的属性下加下划线，以标出主键。包含在主键中的属性称为主属性(Prime Attribute)。未包含在任何候选键中的属性称为非主属性。例如在学生(学号，姓名，性别，出生年份，入学年份，班级号)关系中，｛学号｝是唯一的候选键，当然也是主键。因此学号是主属性。而姓名、性别等都是非主属性。
（3）外键（Foreign Key ）：如果关系中的属性或属性组不是本关系的键，而是引用其他关系的键，则称为此关系的外键。外键提供了表示实体之间联系的手段。当两个实体集之间存在一对多联系时，通常取一方关系中的键作为多方关系的外键。对于多对多联系，可从每个关系取一个键组成一个新的关系，用这种新关系表示多对多联系，这时外键为所在关系的主属性。例如，除学生关系外，再定义两个关系：课程(课程号，课程名，学分，开课时间，先修课程号)，选课(学号，课程号，成绩)。从语义可知，｛课程号｝是课程的主键，｛学号，课程号｝是选课的主键，同时学号与课程号也是选课的两个外键。
二、关系模型的数据操作
关系模型中数据操作的特点是集合操作方式。即操作的对象和结果都是集合。这种操作方式也称为一次一个集合的方式。关系模型中常用的数据操作包括查询操作和更新操作两大部分。查询操作有选择、投影、连接、除、并、交、差等；更新操作有插入、删除和修改。查询操作是关系模型中数据操作的主要内容。
关系模型中的关系操纵能力早期通常是用代数方法或逻辑方法来表示，分别称为关系代数(Relation Algebra)和关系演算(Relation Calculus)。关系代数是用对关系的运算来表达查询要求的方式。关系操作的结果仍为关系，可以再参与其他关系操作，由此可以构成对关系的各种复杂操作。关系演算用谓词来表达查询要求的方式。关系代数与关系演算均是抽象的查询语言，与具体的DBMS 中实现的实际语言并不完全一样，它们可用作评估实际系统中查询语言能力的标准或基础。除了关系代数与关系演算外，还有一种介于二者之间的SQL 语言，该语言将在第四章介绍，这里仅介绍关系代数。
关系代数的运算可分为两类：一类是基本运算，即传统的集合运算；另一类是专门运算，即专门针对关系数据库设计的运算。
1．传统的集合运算。
传统的集合运算包括并、差、交、笛卡尔积4种基本运算。
（1）并(Union)：设关系R 和S 是同一关系模式下的关系，则R 和S 的并是由属于R 或属于S 的元组组成的集合。记作}{S t R t t S R ∈∨∈= 。
（2）差(Difference)：设关系R 和S 是同一关系模式下的关系，则R 和S 的差是由属于
R 但不属于S 的元组组成的集合。记作}{S t R t t S R ?∧∈=-。
（3）交(Intersection)：设关系R 和S 是同一关系模式下的关系，则R 和S 的并是由既属于R 又属于S 的元组组成的集合。记作}{S t R t t S R ∈∧∈=
例3.1假设关系R 和S 如表3-5（a ）和(b)所示，则R 和S 的并、差、交运算如表3-5（c ）、（d ）、（e ）所示。
表3-5（a ）R （b ）S （c ）S R （d ）S R - （e ）S R
（4）笛卡尔积(Cartesian Product)：设关系R 和S 的列数分别为r 和s ，元组的个数分别为m 和n ，则关系R 和S 的笛卡尔积是一个)(s r +列的元组的集合。每个元组的前r 个分量来自关系R 的一个元组，后s 个分量来自关系S 的一个元组，且元组的数目有n m ?个，
记作},{S t R t t
t t t S R s
r s
r
∈∧∈∧==?。
例3.2 假设关系R 和S 如表3-6（a ）和(b)所示，则R 和S 的笛卡尔积S R ?如表3-6（c ）
所示。
2. 专门的关系运算
专门的关系运算包括选择、投影、连接和除法操作。
（1）选择操作(Selection)：选择是一种一元关系操作，它作用在一个关系R 上，按给定的选择条件F ，选出符合条件的元组，记作(){}true t F R t t R F =∧∈=)(σ，其中F 是一个逻辑表达式，取值为“true ”或“false ”。简记为：()R F σ。
例3.3 ①从学生关系中查找姓名是高明的学生。
②从学生关系中查找出生年份为1987的所有女生。 解：①σ姓名=’高明’(学生)
②σ
性别=’女’ AND 出生年份=1987(学生)
上述两个选择操作的结果如表3-7和3-8所示。
表3-7 例3.3①的操作结果
表3-8 例3.3②的操作结果
（2）投影操作(Projection)：投影也是一元关系操作。投影操作选取关系的某些列。关系R 在属性列m
i i i A A A ,,,2
1
上的投影记作：
}),,,({)(,,,212
1
R r A A A r R m
m
i i i
i i i A
A A ∈=∏
，简记为：??∏属性表(<关系名>)。 例3.4 从学生关系中查找所有学生的姓名和入学年份。 解：∏姓名，入学年份（学生） 结果如表3-9所示。
表3-9 例3.4的操作结果 表3-10 例3.5的操作结果
注意：投影操作后的关系可能会出现内容完全相同的若干个元组，而根据关系的要求不允许出现内容完全相同的元组，因此结果只能保留其中一个元组。
例3.5从学生关系中查找所有学生的入学年份和班级号。 解：∏入学年份，班级号（学生）
结果如表3-10所示（该表中去掉了内容完全相同的两个元组）。
投影操作可以和选择操作组合起来应用。例如，若要查找所有女生的姓名，则表示如下： ∏姓名(σ
性别=’女’(学生))
（3）连接操作(Join)：连接是二元关系操作，以符号 表示。它的定义为： R 连接条件
S =σ
连接条件
(R ×S )
连接与笛卡尔积的区别在于笛卡尔积包含两个关系的所有元组的组合，而连接只包含满足连接条件的元组的组合。如果连接条件为两个关系中的两个属性进行相等比较，则称为等值连接。若在等值连接中再要求两个关系中进行比较的分量必须是相同的属性组，并且在结果中去掉重复的属性列，则称为自然连接。在自然连接表示式中一般可以省略连接条件。
例3-6 假设有一选课表如表3-11所示。则表3-12为等值连接：学生
学生.课号=选课.课号
选课 的
结果，表3-13为自然连接：学生 选课的结果。
表3-12 学生
学生.课号=选课.课号
选课的操作结果
表3-11 选课 表3-13 学生 选课的操作结果
(4)除操作(Division)。首先引入像集(Image Set)的概念。设关系),(Z X R ，Z X ,是属性组，则R 中属性组X 上的值为x 的各元组在Z 分量上集合，称为x 在R 中的像集。记作
}][][{x X r R r Z r Z x =∧∈=
设有关系),(Y X R 和),(Z Y S ，Z Y X ,,为属性组，则R 与S 的除运算定义为R 中满足以下条件的元组在X 属性上的投影：关系R 中的元组在X 上分量值x 的像集x Y 包含S 在
Y 上投影的集合。记作
})(][{x y r r Y S R t X t S R ?∏∧∈=÷
例3-7 关系R 和S 如表3-14（a ）、（b ）所示，则R 和S 的除运算如表3-14（c ）所示。 在关系R 中，（A ，B ）可以取三个值{（A1，B1），（A2，B2），（A3，B2）} （A1，B1）的像集为{（C1，D1），（C2，D2），（C3，D3）} （A2，B2）的像集为{（C1，D1），（C2，D2）} （A3，B2）的像集为{（C1，D1），（C1，D2）} S 在（C ，D ）上的投影为{（C1，D1），（C2，D2）}
由此可以看出，（A1，B1）与（A2，B2）的像集包含了S 在（C ，D ）上的投影，所以
R S
÷的结果包含（A1，B1）与（A2，B2）两个元组。
二、关系模型的数据完整性约束
数据完整性是指数据库中存储的数据是有意义的或正确的。关系模型中的数据完整性规则是对关系的某种约束条件。关系模型的完整性约束主要包括三大类：实体完整性、参照完整性和用户定义的完整性。
1. 实体完整性
实体完整性规则要求：每个关系都必须有主健，各元组的主键的值不能相同，主键的属性（即主属性）值不允许取空值。所谓空值就是“不知道”或“无意义”的值。例如，当某一个学生选修了某一门课程后，便向表3-11所示的选课表插入一个元组，但在学生还未考试之前，成绩是不知道的，所以该元组的成绩属性的值为空值。空值一般用NULL表示。
之所以要求每个关系都必须有主健，是因为主健可以唯一地确定一个元组；如果两个元组的主键的值相同，则无法区分这两个元组；而如果某一元组的主键的值为空值，则说明存在某个无法识别的实体。
目前大多数DBMS支持实体完整性约束检查，但不是强制和彻底的，只有当用户在关系模式中定义了主键之后，DBMS才进行实体完整性约束检查，若用户不定义主键，则无从进行实体完整性约束检查。
2. 参照完整性
参照完整性也称为引用完整性。参照完整性约束是不同关系之间或同一关系的不同元组间的约束。
设FK是关系R的外键，它与关系S的主键PK相对应（即FK引用关系S的主键PK）。则参照完整性规则要求：对于R中每个元组在FK上的值或者取空值，或者等于S中某个元组的主键值。即外键要么是空值，要么是引用实际存在的主键值。
例3-8假设有以下两个实体（其中带下划线的为主键）：
学生（学号，姓名，性别，专业号）
专业（专业号，专业名）
显然，学生关系中的“专业号”引用了专业关系的主键“专业号”，即学生关系中的“专业号”为外键。根据参照完整性规则要求：学生关系中的“专业号”属性值或者是空值，
或者是专业关系中已存在的专业号。专业号为空值说明还未给该学生分配专业。如果给该学生分配专业，必须分配一个已存在的专业。
例3-9 从表3-11与表3-4可以看出，选课关系中的“学号”引用了学生关系的主键“学号”，即选课关系中的“学号”为外键，则按照参照完整性规则要求，选课关系中的“学号”属性值或者是空值，或者是学生关系中已存在的学号。但由于“学号”和“课程号” 是选课关系的主属性，按照实体完整性规则要求，它们均不能取空值。所以选课关系中的“学号”只能取学生关系中已存在的学号。
3. 用户定义的完整性
任何关系数据库系统都应该支持实体完整性和参照完整性。除此之外，不同的数据库应用系统根据其应用环境的不同，往往还需要一些特殊的约束条件，用户定义的完整性就是针对某一具体应用领域定义的数据库约束条件。它说明某一具体应用所涉及的数据必须满足的语义要求。例如：学生的“年龄”属性的值不能大于100或小于5，“性别”属性的值只能是“男”或“女”；选课的“成绩” 属性的值不能小于零；等等。一般情况下，用户定义的完整性实际上就是指明关系中属性的取值范围，即属性的域。因此，用户定义的完整性也称为域完整性。
第三节 关系规范化
在讨论了关系模型的基本概念与关系操作语言后，接下来要讨论针对一个具体问题，如何构造一个合适的关系模式。关系规范化理论为我们提供了判断关系模式好坏的理论标准。而这些标准是根据属性间的依赖关系，即函数依赖的概念给出的，因此，本节首先讨论函数依赖的概念，然后讨论规范化标准。
一、函数依赖的基本概念
1. 函数依赖
假设)(U R 是一个关系模式，U 是R 的属性集合，X 和Y 是U 的子集，即
U Y U X ??,。设21,t t 是关系R 中的任意两个元组，如果由][][21X t X t =可以推导出
][][21Y t Y t =。则称“X 函数决定Y ”或“Y 函数依赖于X ”，记作Y X →。
对于函数依赖，需要说明以下几点。
（1）函数依赖不是指关系模式)(U R 的某个或某些关系实例满足的约束条件，而是指
)(U R 的所有关系实例均要满足的约束条件。
（2）函数依赖和别的数据之间的依赖关系一样，是语义范畴的概念。例如，“姓名→年龄”这个函数依赖只有在没有同名人的条件下成立。如果有相同名字的人，则“年龄”就不再依赖于“姓名”了。
（3）若Y X →，则X 称为这个函数依赖的决定属性集（determinant ）。 2. 平凡函数依赖与非平凡函数依赖
在关系模式)(U R 中，X 和Y 是U 的子集，即U Y U X ??,，如果Y X →，但
X Y ?/，则称Y X →是非平凡函数依赖。若X Y ?，则称Y X →为平凡函数依赖。
对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明，平常所指的函数依赖一般都是指非平凡函数依赖。
3. 完全函数依赖与部分函数依赖
设X 、Y 是某关系的不同属性集，如Y X →，且不存在X X ?'，使Y X →'
，则称
Y 完全函数依赖（Full Functional Dependency ）于X ，记作Y X f
?→?
；否则称Y 部分函数依赖（Partial Function Dependency ）于X ，记作Y X p
?→?。
4. 传递函数依赖
设X 、Y 、Z 是某关系的不同的属性集，如果Y X →，Y X →//，Z Y →，则称Z 对
X 传递函数依赖（Transitive Functional Dependency ）。
为了综合说明以上概念，假定有如下关系,S (学号,姓名,性别,系名，系主任，课程号,课程名,成绩)，主键为（学号，课程号）。则函数依赖关系有：
（学号，课程号）→成绩，即（学号，课程号）函数决定成绩，或者说成绩函数依赖于（学号，课程号）。因为一个成绩必定依赖于一个学生选修的某一门课程。同时还有：学号→姓名，学号→性别，学号→系名，系名→系主任，课程号→课程名等函数依赖关系。
对于（学号，课程号）→成绩，由于学号→/成绩，课程号→/成绩（即学生学号或课程
号都不能唯一确定一个学生的成绩），所以有（学号，课程号）f
??
→成绩，即成绩完全函数依赖于学号和课程号。
对于（学号，课程号）→姓名，由于学号→姓名，因此有（学号，课程号）p
??
→姓名，即姓名部分函数依赖于学号和课程号。
由于学号→系名，并且有系名→/学号，系名→系主任，因此学号→系主任是传递函数依赖关系。
二、规范化
1. 为什么要对关系模式进行规范化
当设计完一个关系模式后，我们要考察它是否一个“好”的模式，或者说看它是否存在问题。下面通过一个例子，来分析一个设计不好的关系模式有可能会出现的问题。
例如：对于前面的关系S (学号,姓名,性别,系名，系主任，课程号,课程名,成绩)，存在如下问题：
（1）数据冗余。当一个学生选修多门课程时，就会导致姓名、性别、系名、系主任和课程名多次重复存储，造成数据冗余。
（2）数据修改复杂。由于数据存储冗余，当更新某些数据项时，可能一部分修改了，而另一部分字段修改，造成存储数据的不一致性。例如，当一个学生从计算机系转到信息管理系后，不但要修改系名,还要修改系主任，从而导致数据修改复杂化。
（3）数据插入异常。如果某个学生未选修课程，则其学号、姓名、性别等基本信息也无法插入，因为课程号为空，关系数据模式规定主键不能为空或部分为空，从而出现数据插入异常。
（4）数据删除异常。如果某个学生选修了一门课程，后来又不选了，则应当删除该学生此门课程的记录。但由于该学生只选修了一门课程，那么删除掉这条记录后，该学生的学号、姓名、性别等基本信息也删除了，从而出现删除异常。
之所以会出现以上几个问题，是因为这个关系模式没有设计好，使得某些属性之间存在着“不良”的函数依赖。解决上述问题的方法就是进行关系模式的合理分解，也就是进行关系模式的规范化。
2. 范式
对关系模式的规范化，就是要使它满足不同级别的范式。范式（Normal Forms, 记作NF）的概念是由E.F.codd在1971年提出的，他在1971年~1972年提出了第一范式（1NF）、第二范式（2NF）与第三范式（3NF）。1974年codd和Boyce又共同提出了BCNF。1976年Fagin提出了4NF，后来又有人提出了5NF。各范式之间的关系（如图3-5所示）表示为：?????
N F N F N F B C N F N F N F
12345
通过模式分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化(Normalization)。通常把某一关系R为第n范式，简记为nNF
R∈。Array
图3-5 各种范式之间的关系
1. 第一范式(1NF)
定义3.1对于关系模式R的任一关系r，若其每一属性值都是基本属性（或原子属性），则称R为满足第1范式的关系，记作NF
∈。
R1
在任何一个关系数据库系统中，第一范式是对关系模式的一个必须满足的要求，不满足第一范式的数据库模式不能称为关系数据库模式。因此，所给出的关系模式均满足第一范式。
2. 第二范式(2NF)
定义3.2若关系模式R属于第1范式，且每个非主属性都完全函数依赖于主键，则R 属于第二范式，记作2
∈。
R N F
例3.10对于前面给出的关系S，主键为(学号，课程号)。由于存在非主属性姓名、性别、课程名部分函数依赖于（学号，课程号）。因此，它不属于2NF。
可以通过模式分解的办法将非2NF的关系模式分解为多个满足2NF的关系模式。分解
步骤如下：
（1）首先用组成主键的属性集合的每个子集作为主键构成一个关系，对于关系S分解为如下3个子关系：
S1(学号，…)，其中（学号）为主键
S2(课程号，…)，其中（课程号）为主键
S3(学号，课程号，…)，其中（学号，课程号）为主键
（2）对于每个子关系，将依赖于此主键的属性放置到此关系中，则有：
S1(学号，姓名，性别，系名，系主任)，其中（学号）为主键
S2(课程号，课程名)，其中（课程号）为主键
S3(学号，课程号，成绩)，其中（学号，课程号）为主键
由于分解后消除了原关系模式S中的部分函数依赖，即S1、S2和S3三个关系模式都不存在部分函数依赖，因此S1、S2和S3都属于2NF。
对于上述分解后的关系S1，存储多少个学生，就需要将其所在的系名和系主任存储多少遍，出现数据冗余现象。其次，当组建一个新系时，如果该系还没有招生，虽然已有系名和系主任，但仍无法插入此系的信息，因为这时的学号为空，出现插入异常现象。
由此可以看出，满足第二范式的关系模式仍然可能出现异常操作。这是因为第二范式只要求每个非主属性完全依赖于主键，并未限定非主属性不能函数依赖于其他非主属性，从而也就允许传递依赖的存在。因此，还需要对满足第二范式的关系模式进一步判断与分解。
3. 第三范式(3NF)
定义3.3若关系模式R属于第二范式，且每个非主属性都不传递依赖于主键，则R属于第三范式。记作3
。
R N F
例3.11分解例3.10中的学生关系S1，使其满足3NF的要求。
解：由于在关系S1中，学号→系主任是传递函数依赖。因此，它不属于3NF。
将关系模式S1(学号，姓名，性别，系名，系主任)进一步分解，以便去掉传递依赖关系，分解的步骤如下：
（1）对于不是候选键的每个决定因子，从关系中删除依赖它的所有属性。在关系S1中，系名不是候选键，但是决定因子，从关系S1中删除依赖它的属性系主任，得到新的关系S11(学号，姓名，性别，系名)。
（2）新建一个关系，该关系中包含原关系中不是候选键的决定因子以及所有依赖该决定因子的属性，并将决定因子作为该关系的主键。对于关系S1，新建的关系为S12(系名，系主任)，主键为（系名）。
由于分解后消除了原关系模式中的传递依赖，因此S11和S12都满足3NF。
当按第三范式的要求把所有传递依赖都消除时，也应该把部分依赖消除。即若关系模式R属于第三范式，则每个非主属性对于主键既不存在部分依赖，也不存在传递依赖。把关
系模式分解到第三范式，可以在相当程度上减轻原关系中的异常和信息冗余，但不能保证完全消除关系模式中的各种异常和信息冗余。
4. BC范式(BCNF)
定义3.4设有关系模式NF
∈，F是R的函数依赖集，若F中的每个非平凡函数
R1
依赖)
→，X都含有主键，则称R是Boyce-Codd范式，记作BCNF X?
Y
(X
Y
R∈。
从BCNF的定义可以看出，BC范式既检查非主属性，又检查主属性，显然比第三范式限制更严。当只检查非主属性而不检查主属性时，就成了第三范式。因此，任何满足BC范式的关系都必然满足第三范式。
例 3.12设有关系模式)
C
Add，其中S表示街道名，C表示城市名，Z表示邮
S
(Z
,
,
政编码。根据语义，Add的函数依赖集}
C
F→
=，如图3-6所示，)
Z
→
S
Z
)
,
,
{(C
S
(C
,
是主键。
图3-6关系模式)
Add
,
S
C
,
(Z
解：NF
A d d?，因为存在非平凡函数依赖C
Z→。该关系模式∈，但B C N F
Add3
存在着异常问题，由于缺少键)
(S
C中的S，若要插入一个城市的邮编，但不知具体的街
,
道，该关系模式就不允许这样的操作。要消除异常，则必须转化为BCNF，将Add分解为S
SZ
Z
ZC两个关系模式，即把Z和C分开。
C
),
)
(Z
,
,
(
如果只考虑函数依赖，则属于BCNF的关系模式已达到最高规范化程度。而4NF与5NF 分别涉及到多值依赖和连接依赖，限于篇幅，这里不再讨论4NF与5NF。
第四节逻辑结构设计的任务
逻辑结构设计的任务是把在概念结构设计阶段设计好的E-R模型转换为具体的数据库管理系统支持的数据模型。本节以关系模型为例，介绍逻辑结构设计的任务，主要包括两个步骤：将E-R模型转换为关系模型和关系模型的优化。
一、E-R模型向关系模型的转换
进行数据库的逻辑设计，首选要将概念设计中所得的E-R图转换成等价的关系模式。将E-R图转换为关系模型实际上就是将实体、实体的属性和实体之间的联系转化为关系模式。其中实体和联系都可以表示成关系，E-R图中的属性可以转换成关系的属性。
1. 实体的转换
一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的主键就是关系的主键。例如，图3-7个给出了一个教务管理系统的E-R图。
图3-7 教务管理系统的E-R 图
图3-7所示的E-R 图中的4个实体学生、课程、教师、系分别转换成以下4个关系
模式：
学生（学号，姓名，性别，年龄） 课程（课程号，课程名，学分） 教师（教师号，姓名，性别，职称） 系（系名，电话） 2. 联系的转换
（1）一个1:1
联系可以转换为一个独立的关系模式，也可以与任意一端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的主键以及联系本身的属性转换为关系的属性，每个实体的主键均可以作为该关系的主键。如果是与联系的任意一端实体所对应的关系模式合并，则需要在该关系模式的属性中加入另一个实体的主键和联系本身的属性。一般情况下，1:1联系不转换为一个独立的关系模式。
图3-8 1:1联系示例
例如，对于如图3-8所示的E-R 图，如果将联系与经理一端所对应的关系模式合并，则转换成以下两个关系模式：
经理（工号，姓名，性别，部门号），其中工号为主键，部门号为引用部门关系的外键。 部门（部门号，部门名），其中部门号为主键。
如果将联系与部门一端所对应的关系模式合并，则转换成以下两个关系模式： 经理（工号，姓名，性别），其中工号为主键。
部门（部门号，部门名，工号），其中部门号为主键，工号为引用经理关系的外键。 如果将联系转换为一个独立的关系模式，则转换成以下三个关系模式： 经理（工号，姓名，性别），其中工号为主键。
部门（部门号，部门名），其中部门号为主键。
管理（工号，部门号），其中工号与部门号均可作为主键（这里将工号作为主键），同时也都是外键。
（2）一个1:n联系可以转换为一个独立的关系模式，也可以与n端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的主键以及联系本身的属性转换为关系的属性，n端实体的主键为该关系的主键。一般情况下，1:n联系也不转换为一个独立的关系模式。
例如，对于如图3-6所示的E-R图中的系与学生的1:n联系，如果与n端实体学生所对应的关系模式合并，则只需将学生关系模式修改为：
学生（学号，姓名，性别，年龄，系名），其中学号为主键，系名为引用系的外键。
如果将联系转换为一个独立的关系模式，则需增加以下关系模式：
系藉（学号，系名），其中学号为主键，学号与系名均为外键。
（3）一个m:n联系要转换为一个独立的关系模式，与该联系相连的各实体的主键以及联系本身的属性转换为关系的属性，该关系的主键为各实体主键的组合。
例如，对于如图3-6所示的E-R图中的学生与课程的m:n联系，需转换为如下的一个独立的关系模式：
选课（学号，课程号，成绩），其中（学号，课程号）为主键，同时也是外键。
（4）三个或三个以上的实体间的一个多元联系可以转换为一个关系模式，与该多元联系相连的各实体的主键以及联系本身的属性均转换为该关系的属性，关系的主键为各实体主键的组合。
此外，具有相同主键的关系模式可以合并。上述E-R图向关系模型的转换原则为一般原则，对于具体问题还要根据其特殊情况进行特殊处理。例如在第二章的例2.1所给出的图书管理情况的E-R图中，读者与图书是m:n的联系，按照上述转换原则，借阅联系需转换为如下的一个独立的关系模式：
借阅（借书证号，书号，借阅日期，还书日期），其中（借书证号，书号）为主键。但实际情况是：一个借书证号借阅某一本书，还掉以后还可以再借，这样就会在借阅关系中出现两个或两个以上的具有相同借书证号和书号的元组，由此可以看出，借书证号和书号不能作为该关系的主键，必须增加一个借阅日期属性，即（借书证号，书号，借阅日期）为主键。
在E-R图向关系模式的转换中可能涉及到命名和属性域的处理、非原子属性的处理、弱实体的处理等问题。
（1）命名和属性域的处理。关系模式的命名，可以采用E-R图中原来的命名，也可以另行命名。命名应有助于对数据的理解和记忆，同时应尽可能避免重名。DBMS一般只支持有限的几种数据类型，而E-R数据模型是不受这个限制的。如果DBMS不支持E-R图中某些属性的域，则应做相应的修改。
（2）非原子属性的处理。E-R数据模型中允许非原子属性，而关系要满足的四个条件中的第一条就是关系中的每一列都是不可再分的基本属性。因此，在转换前必须先把非原子属性进行原子化处理。
（3）弱实体的处理。图3-9是一个弱实体的例子，家属是个弱实体，职工是其所有者实体。弱实体不能独立存在，它必须依附于一个所有者实体。在转换成关系模式时，弱实体所对应的关系中必须包含所有者实体的主键，即职工号。职工号与家属的姓名构成家属的主键。弱实体家属对应的关系模式为：家属（职工号，姓名，性别，与职工关系）
二、关系模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用的需要对数据模型的结构进行适当的修改和调整，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，方法如下。
1. 实施规范化处理
考查关系模式的函数依赖关系，确定范式等级，逐一分析各关系模式，考查是否存在部分函数依赖、传递函数依赖等，确定它们分别属于第几范式。确定范式级别后，逐一考察各个关系模式，根据应用要求，判断它们是否满足规范要求。
2. 模式评价
关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。
模式评价的目的是检查所设计的数据库是否满足用户的功能与效率要求。确定加以改进的部分。模式评价包括功能评价和性能评价。
（1）功能评价。功能评价指对照需求分析的结果，检查规范化后的关系模式集合是否支持用户所有的应用要求。关系模式必须包括用户可能访问的所有属性。在涉及多个关系模式的应用中，应确保连接后不丢失信息。如果发现有的应用不被支持，或不完全被支持，则应改进关系模式。发生这种问题的原因可能是在逻辑结构设计阶段，也可能是在系统需求分析或概念结构设计阶段。
（2）性能评价。对于目前得到的数据库模式，由于缺乏物理设计所提供的数量测量标准和相应的评价手段，所以性能评价是比较困难的。只能对实际性能进行估计，包括逻辑记录的存取数、传送量以及物理设计算法的模型等。美国密执安大学的T.Teorey和J.Fry于1980
年提出的逻辑记录访问（Logical Record Access, LRA）方法是一种常用的模式性能评价方法。LRA方法对网状模型和层次模型较为实用，对于关系模型的查询也能起一定的估算作用。
3. 模式改进
根据模式评价的结果，对已生成的模式进行改进。如果因为系统需求分析、概念结构设计的疏漏导致某些应用不能得到支持，则应该增加新的关系模式或属性。如果因为性能考虑而要求改进，则可采用合并或分解的方法。
（1）合并。如果有若干个关系模式具有相同的主码，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的查询，那么可对这些关系模式按照使用频率进行合并。这样可以减少连接操作而提高查询效率。
（2）分解。为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。
水平分解是把关系的元组分为若干子集合，每个子集合定义为一个子关系模式。对于经常进行大量数据的分类条件查询的关系，可进行水平分解，这样可以减少应用系统每次查询需要访问的记录，从而提高了查询性能。
垂直分解是把关系的属性分解为若干子集合，每个子集合定义为一个子关系模式。垂直分解可以提高某些事务的效率，但也有可能使另一些不利因素不得不执行连接操作，从而降低了效率，因此是否要进行垂直分解要看分解后的所有事务的总效率是否得到了提高。垂直分解要保证分解后的关系具有无损连接性和函数依赖保持性。
经过多次的模式评价和模式改进后，最终的数据库模式得以确定。逻辑设计阶段的结果是全局逻辑数据库结果。对于关系数据库系统来说，就是一组符合一定规范的关系模式组成的关系数据库模型。
三、设计用户子模式
在将概念模型转换为逻辑模型后，即生成了整个应用系统的模式后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的子模式（也称为外模式）。
目前关系数据库管理系统一般都提供了视图概念，可以利用这一功能设计更符合局部用户需要的用户外模式。定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于用户外模式与模式是独立的，因此在定义用户外模式时应该更注重考虑用户的习惯与方便，具体包括：
（1）使用更符合用户习惯的别名。在合并各局部E-R图时，曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计整体结构时是必要的。
（2）针对不同级别的用户定义不同的外模式，以满足系统安全性的要求。
（3）简化用户对系统的使用。如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，以使用户使用系统时感到简单、直观、易于理解。
数据库表结构设计参考
表名外部单位表（DeptOut） 列名数据类型（精度范围）空/非空约束条件 外部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 交换类型变长字符串(50) N 交换、市机、直送、邮局单位邮编变长字符串(6) 单位标识(英文) 变长字符串(50) 排序号整型(4) 交换号变长字符串(50) 单位领导变长字符串(50) 单位电话变长字符串(50) 所属城市变长字符串(50) 单位地址变长字符串(255) 备注变长字符串(255) 补充说明该表记录数约3000条左右，一般不做修改。初始化记录。 表名外部单位子表（DeptOutSub） 列名数据类型（精度范围）空/非空约束条件 外部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 补充说明该表记录数一般很少 表名内部单位表（DeptIn） 列名数据类型（精度范围）空/非空约束条件 内部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 工作职责 排序号整型(4) 单位领导变长字符串(50) 单位电话（分机）变长字符串(50) 备注变长字符串(255)
补充说明该表记录数较小（100条以内），一般不做修改。维护一次后很少修改 表名内部单位子表（DeptInSub） 列名数据类型（精度范围）空/非空约束条件内部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 单位类型变长字符串(50) 领导、部门 排序号Int 补充说明该表记录数一般很少 表名省、直辖市表（Province） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 名称变长字符串(50) N 外键 投递号变长字符串(255) N 补充说明该表记录数固定 表名急件电话语音记录表（TelCall） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 发送部门变长字符串(50) N 接收部门变长字符串(50) N 拨打电话号码变长字符串(50) 拨打内容变长字符串(50) 呼叫次数Int 呼叫时间Datetime 补充说明该表对应功能不完善，最后考虑此表 表名摄像头图像记录表（ScreenShot） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 拍照时间Datetime N 取件人所属部门变长字符串(50) N 取件人用户名变长字符串(50) 取件人卡号变长字符串(50) 图片文件BLOB/Image
高校图书管理系统数据库物理结构设计 一、设计前要了解的信息(该部分不出现在设计说明书中) 1、数据库的查询事务 (1)按卡号查询读者信息及借书信息(查询读者借书信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (2)按姓名查询读者信息及借书信息(查询读者借书信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (3)按书名查询图书信息。 (4)按作者与出版社查询图书信息。 (5)按出版社统计图书信息。 (6)按书号查询图书被借信息(查询图书被借信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 (7)按书名查询图书被借信息(查询图书被借信息时涉及读者、图书与借还关系的连接操作,连接属性:卡号、书号)。 2、数据库的更新事务 (1)办理借书证(读者注册)。 (2)借书(增加借还记录、修改图书的库存数量)。 (3)还书(修改借还记录、修改图书的库存数量)。 3、查询事务的操作频率与性能要求 (1)按卡号查询读者信息及借书信息 操作频率:200次/天 性能要求:3s内完成 (2)按姓名查询读者信息及借书信息 操作频率:80次/天 性能要求:5s内完成 (3)按书名查询图书信息 操作频率:250次/天 性能要求:3s内完成 (4)按作者与出版社查询图书信息 操作频率:250次/天 性能要求:3s内完成 (5)按出版社统计图书信息 操作频率:1次/月 性能要求:10s内完成 (6)按书号查询图书被借信息 操作频率:10次/月
性能要求:6s内完成 (7)按书名查询图书被借信息 操作频率:10次/月 性能要求:6s内完成 二、设计结果 1、数据库名称 Book_Borrow 2、关系表 主键:lbdm 主键:kh 索引:xm(升序) check约束:性别的取值只能为男或女 default约束:性别默认为男
1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 （1）需求分析; （2）概念结构设计; （3）逻辑结构设计; （4）数据库物理设计; （5）数据库实施; （6）数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图（Data Flow Diaˉgram———DFD）是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢？在众多的分析方法中，结构化分析（Structured Analysis，简称SA方法）是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图，数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能，每个子功能继续分解，直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典（Data Dictionary，简称DD）则是对系统中数据的详尽描述，是各类数据属性的清单。对数据库应用系统设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合，它通常包括以下5个部分： （1）数据项，是数据最小单位。 （2）数据结构，是若干数据项有意义的集合。 （3）数据流，可以是数据项，也可以是数据结构。表示某一处理过程的输入输出。 （4）数据存储，处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 （5）处理过程。
1.帐类表（KIND） 无索引 序号中文名称英文名称类型备注 1 帐类编号K_SERIAL byte 2 帐类名称K_NAME text*10 本表系统自动建立，共划分为15种帐类,不可增删 帐类编号帐类名称备注 0 上期结存进货，不参加进货统计 1 购入进货，购入时必需输入供货单位名称 2 自制进货 3 投资转入进货 4 盘盈进货 5 领料出库，领料必需输入领料部门名称 6 调拨出库 7 报损出库 8 盘亏出库 9 退库对低值易耗品，在用品退为在用库存 10 直接报废对于低值易耗品，在用品转报废 11 领用对于低值易耗品，在用库存转在用 12 调拨对于低值易耗品，在用库存减少 13 报废对于低值易耗品，在用库存报废 14 直进直出进出库，购入与领料对库存无影响 2.物品表（GOODS） 序号索引名称索引域唯一? 主索引? 1 G_CODING +G_CODING Y N 2 G_SERIAL +G_SERIAL Y Y 序号中文名称英文名称类型备注 1 物品内部编号G_SERIAL INT->long 系统内部唯一标识该物品 2 物品编号G_CODING TEXT * 10 用户使用此编号访问物品 &3 物品名称G_NAME TEXT*40 非空 &4 物品单位G_UNIT TEXT*8 非空 &5 物品规格G_STATE TEXT*20
6 物品类别G_CLASS INT 取自表CLASS 7 备注G_REMARKS MEMO 8 最小库存量G_MIN CURRENCY 为零，即无最小库存 9 最大库存量G_MAX CURRENCY 为零，即无最大库存 10 库存数量G_QUANT CURRENCY 控制出库数量 11 虚拟库存数量G_VQUANT CURRENCY 出库时用 12 库存金额G_AMOUNT CURRENCY 3.类别表（CLASS） 序号索引名称索引域唯一? 主索引? 1 C_CODING +C_CODING Y N 2 C_SERIAL +C_SERIAL Y Y 序号中文名称英文名称类型备注 1 类别内部序号C_SERIAL INT 系统内部唯一标识该物品 2 类别编号C_CODING TEXT *10 用户使用该编号访问类别信息 3 类别名称C_NAME TEXT*20 非空 4 出库类型C_KIND BYTE 1.移动平均 2..先进先出 3.后进先出 4.实际计价 *5.月末平均 5 备注C_REMARKS MEMO *6 底标志C_BOTTOM BOOLEAN *7 类别级别C_LEVEL BYTE 4.供货单位、使用部门(DEPART) 序号索引名称索引域唯一? 主索引? 1 D_CODING +D_CODING Y N 2 D_SERIAL +D_SERIAL Y Y 序号中文名称英文名称类型备注 1 内部序号D_SERIAL INT 系统内部唯一标识该部门 >0 供货单位 =0 库房 <0 使用部门 2 单位编号D_CODING TEXT*10
第7章数据库设计 1．试述数据库设计过程。 答：这里只概要列出数据库设计过程的六个阶段：( l ）需求分析；( 2 ）概念结构设计；( 3 ）逻辑结构设计；( 4 ）数据库物理设计；( 5 ）数据库实施；( 6 ）数据库运行和维护。这是一个完整的实际数据库及其应用系统的设计过程。不仅包括设计数据库本身，还包括数据库的实施、运行和维护。设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 2 ．试述数据库设计过程各个阶段上的设计描述。 答：各阶段的设计要点如下：( l ）需求分析：准确了解与分析用户需求（包括数据与处理）。( 2 ）概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS 的概念模型。( 3 ）逻辑结构设计：将概念结构转换为某个DBMS 所支持的数据模型，并对其进行优化。( 4 ）数据库物理设计：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。( 5 ）数据库实施：设计人员运用DBMS 提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。( 6 ）数据库运行和维护：在数据库系统运行过程中对其进行评价、调整与修改。 3 ．试述数据库设计过程中结构设计部分形成的数据库模式。 答：数据库结构设计的不同阶段形成数据库的各级模式，即：( l ）在概念设计阶段形成独立于机器特点，独立于各个DBMS 产品的概念模式，在本篇中就是 E 一R 图；( 2 ）在逻辑设计阶段将 E 一R 图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式，然后在基本表的基础上再建立必要的视图( Vi 娜），形成数据的外模式；( 3 ）在物理设计阶段，根据DBMS 特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。 4 ．试述数据库设计的特点。 答：数据库设计既是一项涉及多学科的综合性技术又是一项庞大的工程项目。其主要特点有：( l ）数据库建设是硬件、软件和干件（技术与管理的界面）的结合。( 2 ）从软件设计的技术角度看，数据库设计应该和应用系统设计相结合，也就是说，整个设计过程中要把结构（数据）设计和行为（处理）设计密切结合起来。 5 ．需求分析阶段的设计目标是什么？调查的内容是什么？ 答：需求分析阶段的设计目标是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。调查的内容是“数据’夕和“处理”，即获得用户对数据库的如下要求：( l ）信息要求，指用户需要从数据库中获得信息的内容与性质，由信息要求可以导出数据要求，即在数据库中需要存储哪些数据；( 2 ）处理要求，指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理；( 3 ）安全性与完整性要求。 6 ．数据字典的内容和作用是什么？ 答：数据字典是系统中各类数据描述的集合。数据字典的内容通常包括：( l ）数据项；( 2 ）数据结构；( 3 ）数据流；( 4 ）数据存储；( 5 ）处理过程五个部分。其中数据项是数
一、数据库结构设计步骤 二、需求分析 三、概念结构设计 四、逻辑结构设计 五、数据库物理设计 数据库结构设计 一、数据库结构设计步骤 一般可将数据库结构设计分为四个阶段，即需求分析、概念结构设计、逻辑结构设计和物理设计。 下面各节分别介绍各阶段设计内容和具体方法。 二、需求分析 需求分析的任务是具体了解应用环境，了解与分析用户对数据和数据处理的需求，对应用系统的性能的要求，提出新系统的目标，为第二阶段、第三阶段的设计奠定基础。一般需求分析的操作步骤如下所述。 1．了解组织、人员的构成 子系统的划分常常以现有组织系统为基础，再进行整合，而新系统首先必须达到的目的是尽可能地完成当前系统中有关信息方面的工作，在原有系统中，信息处理总是由具体人来实施的。我们要了解组织结构情况、相互之间信息沟通关系、数据（包括各种报告、报表、凭证、单据）往来联系情况。 具体弄清各个数据的名称，产生的时间与传递所需时间与周期，数据量的大小，所涉及（传送）的范围，使用数据的权限要求，数据处理过程中容易发生的问题及其影响，各个部门所希望获得的数据的情况等。 然后了解每个人对每一具体数据处理的过程，基本数据元素来源于哪些地方、获取的途径、处理的要求、数据的用途，进而弄清数据的构成、数据元素的类型、性质、算法、取值范围、相互关系。 在上述调查基础上，首先画出组织机构及工作职能图。我们以一个学校的基层单位——某大学一个系的管理为例来简要说明。 系的组织机构及工作职能如图7.1所示。
图7．1 系管理体系结构图 作为管理层经常需要的信息和工作有： ．查询老师个人基本情况及打印相应内容 ．查询与统计科研项目情况及相关报表 ．查询与统计论文著作情况及相关报表 ．上级部门及其他部门来文管理与查询（要求能全文检索） ．系部发文管理 ．任务下达、检查及管理 ．信件、通知的收发及管理 ．日程安排调度及管理 ．设备仪器计划及管理 ．设备入库与库存情况管理与查询 ．设备借还领用管理及相应报表 ．耗材计划与领发管理及相应统计报表 ．图书管理及借还情况查询 ．学生毕业设计文档管理 ．专业与班组编制与查询 ．教学文档管理及查询（安排与检查，包括课表、考试日程安排、监考安排等）．学生成绩管理与查询和统计 ．教师、学生、实验室课表管理及查询 ．学生基本情况管理与查询（包括社会活动、奖惩、家庭情况及学校校友管理）
逻辑结构设计 逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换成 为与选用DBMS产品所支持的数据模型相符合的逻辑结构。 逻辑结构的步骤： （1）将概念结构转换为一般的关系、网状、层次模型； （2）将转换来的关系、网状、层次模型向特定的DBMS支持下的数据模型转换； （3）对数据模型进行优化。 如图： 概念结构基本E-R图 一般数据结构 关系、层次、网状 特定的DBMS支持 下的数据模型 优化的数据模型转换规则 DBMS的特点和 规则 优化方法 E-R图向关系模型的转换 E-R图向关系模型的转换要解决的问题是如何将实体型和实体间的联系转换为 关系模式，如何确定这些模式的属性和码。 关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体型、实体的属性和实体型之间的联系3个要素组成的。所以将E-R图 转换为关系模型实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式，这种转换一般遵循如下原则： 一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。 学生资料（用户名，姓名，户口，年龄，月基本消费，所在学校，所在年级，家庭所在地） 此为学生资料实体对应的关系模式。该关系模式已包含了联系“领导”所对应的关系模式。 学生（用户名，密码） 此为学生实体对应的关系模式。 日消费（用户名，日常用品，饮食，话费，学习用品，日期） 此为日消费实体对应的关系模式。 额外消费（用户名，消费金额，消费详情，日期） 此为额外消费实体对应的关系模式。 月消费统计（用户名，消费金额，月份） 此为月消费统计实体对应的关系模式。 建议（用户名，分析员用户名，分析结果，消费评价） 此为建议实体对应的关系模式。分析师用户名是关系的候选码。
数据库表结构设计参考． ）表名外部单位表（DeptOut 约束条件非空空数据类型（精度范围） /列名外部单位ID N 变长字符串(50) 主键 N 变长字符串类型 (50)
N 单位名称(255) 变长字符串 (50) 单位简称变长字符变长字符(255)单位全交换类交换、市机、直送、邮变长字符(50)N (6)单位邮变长字符 变长字符(50))单位标英整排序(4) (50)交换变长字符变长字符(50)单位领 变长字符单位电(50) 变长字符所属城(50) 变长字符(255)单位地 备(255) 变长字符 补充说300条左右，一般不做修改。初始化记录该表记录数 表外部单位子表DeptOutSu 数据类型（精度范围列非约束条 变长字符(50)外部子单IDN 外ID变长字符(50)N单位名N变长字符(255) 变长字符单位编(50) 该表记录数一般很补充说 表内部单位表DeptI
数据类型（精度范围非列约束条IDN(50)变长字符主内部单类N变长字符(50) (255)变长字符N单位名 (50)变长字符单位简 变长字符单位全(255) 工作职 排序整(4) 单位领导(50) 变长字符串 (50) 单位电话（分机）变长字符串 (255) 变长字符串备注． 条以内），一般不做修改。维护一次后很少修改补充说明该表记录数较小（100 内部单位子表（DeptInSub）表名 约束条件数据类型（精度范围）空列名/非空 (50) N 变长字符串内部子单位ID 变长字符串(50) 父ID N 外键 (255) 单位名称 N 变长字符变长字符(50)单位编领导、部变长字符(50)单位类 Int 排序 该表记录数一般很补充说 省、直辖市表Provinc表
数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能： （1）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 （2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：姓名+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息 组成结构：图书编号+图书名称+作者+出版社+价格 ……
数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天 组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用 （3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改 …… 处理过程 （1）处理过程名称：审核借书证 输入：借书证 输出：认定合格的借书证 加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例 1．标识图书管理系统中的实体和属性 参照数据字典中对数据存储的描述，可初步确定三个实体的属性为： 读者：｛卡号，姓名，性别，部门，类别、办卡日期，卡状态｝ 读者类别：{类别代码，类别名称，可借阅天数、可借阅数量，超期罚款额}
架构设计之-逻辑架构 逻辑架构=模块划分+接口定义+领域模型 逻辑架构关注职责划分和接口定义。不同粒度的职责需要被关注，它们可能是逻辑层、功能子系统、模块、关键类等。不同通用程度的职责要分离，分别封装到专门模块、通用模块或通用机制中。 图-1 逻辑架构的设计内容 【设计任务】一、模块划分 面对“技术复杂性”和“管理复杂性”这样的双重困难，以架构为中心的开发方法是有效的途径。软件架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节统统展开，从而有效地控制了“技术复杂性”。 通过 定义“如何划分模块、模块间如何通过接口交互”，架构提供了团队开发的基础，如图
2所示，可以把不同模块分配给不同小组分头开发，接口就是小组间合作的“契约”，每个小组的工作覆盖了“整个问题的一部门”。这样一来，模块的技术细节被局部化到了小组内部，内部的细节不会成为小组间协作沟通的主要内容，也就理顺了沟通的层次。另外，对“人尽其才”也有好处，不同小组的成员需要精通的技术各不相同。 图2 软件架构奠定团队开发基础 模块划分是架构师的看家本领，有多种手段可以促进合理划分模块： 1、从需求层面的“功能树”，启发“功能模块”的划分 2、水平分层，促进模块分解 3、通用模块和通用机制的识别 4、现代的用例驱动的模块划分过程 5、传统的模块化分思维 6、…… 【设计任务】二、接口定义 正确的设计思路是“协作决定接口”。架构师设计接口时，要考虑的重点是“为了实现软件系统的一系列功能，这个软件单元要和其他哪些单元协作、如何协作”。此时，可以使
用（一组）序列图辅助进行设计。 【设计任务】三、领域模型细化 逻辑架构设计的粒度，一般推荐设计到模块一级，但如下4种“关键类”可以在架构设计时就明确： 1、接口定义类 2、Facade实现类 3、核心控制类 4、另外，就是对系统可扩展性有根本影响的构成领域模型的那些类
1数据库的物理结构有哪几种文件组成？ 数据文件重做日志文件控制文件其他文件 2简要说明例程与数据库之间的联系与区别、 ORACLE数据库是安装在磁盘上的ORACLE数据库文件和相关的数据库管理系统的集合。磁盘上比较重要的文件包括数据文件，控制文件重做日志文件初始化参数文件口临文件。鬼档重做日志文件例程是由在内从中的一组后台京城和内存结构组成。 3说明数据库，表空间和数据文件之间的关系。 ORACLE数据库的逻辑结构和物理结构的对应关系，一个ORACLE数据库可以拥有多个表空间，每个表空间有多个段组成，每个段由若干个区间组成，每个区间包含多个ORACLE 数据块，每个ORACLE数据块包含多个OS屋里磁盘快。表空间有多个物理文件支持，具体存储表空间中的个对象。 4说明ORACLE 例程的系统全局区包括哪几部分？风别存储什么? 主要包括数据库缓冲存储区，崇左日志缓冲区共享池三部分。1用于存放最近访问的数据块。2数据进行的所有更改都存储在崇左日志缓冲区，这些记录在以后会备考摆到重做日志文件中。3共享池用于存放最近执行的SQL语句和数据字典信息，它的尺寸是由初始化参数SHARED_PLLL_SIZE来定义的。大池用于为大的内存需求提供内存空间，它的尺寸有初始化参数LARGE_POOL SIZE定义。 6有几种日志操作模式？扎那几种日志操作模式下会生成归档日志？ 7ORACLE罗技存储结构有哪几部分构成？ 由表空间，段，区间，ORACLE块构成。 8 ORACLE数据库系统中的进程主要由用户进程和服务器端进程，服务器端进程又可以分为后台进程和服务器进程两类。服务器端后台进程：数据库写入进程，日志写入进程，日志归档进程（不必要），检查带你进程，系统监控进程和进程监控进程 三章 ORACLE NET 是ORACLE网络产品的基础，他用需服务和他们的应用程序驻留在不同的计算机上，其主要功能是在客户机和服务器之间活在两个服务器之间建立网络绘画和传输数据。ORACLE数据库的系统可以配置为三种体系结构，分别是一层结构（终端+服务器，数据库与应用程序均保存在服务器中，终端只完成输入、输出任务，称臣为主从结构）二层结构（客户、服务器结构，体现了分布式思想）三层结构（客户机+应用服务器+数据库服务器，） ORACLE数据库中的用户权限可分为三类，分别是数据库系统特权，对象权限和列访问权限。系统特权允许用户执行特定的系统及操作或太特定的对象类型上执行特定的操作，如常见表空间，创建表和插入记录到人意表总，对象权限有九中类型，分别是插入，删除，更新，选择，修改，运行，参照引用，索引，读，写。列访问权限限定用户只能在木个标的木些列上执行INSERT,UPDA TE操作或允许用户参照饮用木些列的值。 角色：角色是一组相关权限的集合。 概要文件：是一个命名的资源限制的集合。也陈伟资源文件或配置文件，描述如何使用系统资源.DAB使用概要文件来限制用户对数据库和里程资源的使用，可以给每个用户分配概要文件，并且给所有没有专门的概要文件的用户分配一个默认概要文件，当把概要文件赋予某个用户时，系统就按照概要文件重的配置给用户分配资源。该药文件主要包括两个内容：（1）管理数据库系统资源的使用（2）管理数据库口令的使用及验证方式。 同义词：同义词是对一个表，试图，序列，存储过程与函数，包，实体化试图或其他同义词建立的别名。 在用户的概要文件中没有制定的所有资源限制，都将使用默认概要文件总的限制设置。每个
数据库设计 一、单项选择题 1、数据库设计的起点是（ B ）。 A、系统设计阶段 B、需求分析阶段 C、概念结构设计阶段 D、逻辑结构设计阶段 2、数据库设计的概念结构设计阶段，表示概念结构的常用方法和描述工具是 （ D ）。 A、层次分析法和层次结构图 B、数据流程图分析法和数据流程 C、结构分析法和模块结构图 D、实体-联系方法和e-r图 3、在关系数据库设计中，设计关系模式是数据库设计中的（ C ）阶段的任务。 A、需求分析 B、概念设计 C、逻辑设计 D、物理设计 4、将设计好的表创建到ACCESS中，并设计窗体完成对表数据的操作，这是数 据库设计中的（ C ）阶段的任务。 A、逻辑结构设计 B、物理结构设计 C、实施 D、使用与维护 5、数据库应用系统开发一般包括两个方面的内容，即（ D ）。 A、需求分析和维护 B、概念结构设计和逻辑结构设计 C、功能设计和测试设计 D、结构特性设计和行为特性设计 6、将e-r图中的实体和联系转换为关系模型中的关系，这是数据库设计过程 中（ D ）设计阶段的任务。 A、需求分析 B、概念分析 C、物理结构 D、逻辑结构 7、把实体-联系模型转换为关系模型时，实体之间一对多联系在关系模型中是 通过（ B ）来实现。 A、建立新的主关键字 B、在n方增加1方的主关键字为外部关键字 C、建立新的关系 D、建立新的实体 8、数据库设计可分为6个阶段，每个阶段都有自己的设计内容，“为哪些关 系，在哪些属性上、建什么样的索引”这一设计内容应该属于（ C ）设计阶段。 A、概念设计 B、逻辑设计 C、物理设计 D、全局设计 9、把实体-联系模型转换为关系模型时，实体之间一对一联系在关系模型中是 通过（ A ）来实现。 A、两个关系各自增加对方的关键字为外部关键字 B、建立新的主关键字 C、建立新的关系 D、建立新的实体 10、数据库物理设计完成后，进入数据库实施阶段，下述工作中（ D ）一般 不属于实施阶段的工作。 A、建立库结构 B、系统调试 C、加载数据 D、扩充功能 11、以下错误的说法是，需求阶段的主要目标包括（ D ）。 A、画出数据流图 B、了解用户对数据库应用系统的各种要求
数据库原理习题与答案第3章数据库系统结构
第三章．数据库系统结构 习题： 一．选择题 1．数据库技术中采用分级方法将数据库的结构划分成多个层次，是为了提高数据库的（1）和（2）。 （1）A.数据独立性 B.逻辑独立性C.管理规范性 D.数据的共享 （2）A.数据独立性 B.物理独立性C.逻辑独立性 D.管理规范性 2．数据库中，数据的物理独立性是指。 A.数据库与数据库管理系统的独立 B.用户程序与DBMS的相互独立 C.用户的应用程序与存储在磁盘上数据库 中的数据是相互独立的 D.应用程序与数据库中数据的逻辑结构相 互独立 3．数据库系统的最大特点是。 A.数据的三级抽象和二级独立性 B.数据共享性 C.数据的结构化
4．
5．试述数据库系统三级模式结构，这种结构的优点是什么。 6．定义并解释以下术语：模式、外模式、内模式、DDL、DML。 7．什么叫数据与程序的物理独立性？什么叫数据与程序的逻辑独立性？为什么数据库系统具有数据与程序的独立性？
参考答案： 一．选择题 8．（1）B （2）B 9． C 10．A 11．D 12．B 13．A 二．简答题 1．数据库系统的三级模式结构由外模式、模式和内模式组成。外模式，亦称子模式或用户模式，是数据库用户能够看见和使用的局部数据
的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。模式，亦称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。模式描述的是数据的全局逻辑结构，外模式涉及的是数据的局部逻辑结构，通常是模式的子集。内模式，亦称存储模式，是数据在数据库系统内部的表示，即对数据的物理结构和存储方式的描述。 数据库系统的三级模式是对数据的三个抽象级别，它把数据的具体组织留给DBMS管理，使用户能逻辑抽象地处理数据，而不必关心数据在计算机中的表示和存储。 为了能够在内部实现这三个抽象层次的联系和转换，数据库系统在这三级模式之间提供了两层映像：外模式/模式映像和模式/内模式映像，正是这两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。 2．模式，亦称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。外模式，亦称子模式或用户模式，
数据库设计中英文术语表 June 27, 2004, In Focus on 索引 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 正文 1.Access method（访问方法）：此步骤包括从文件中存储和检索记录。 2.Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。 3.Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。 4.Anomalies（异常）参见更新异常（update anomalies） 5.Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设 计用户界面以及使用和处理数据库的应用程序。 6.Attribute（属性）（关系模型）：属性是关系中命名的列。 7.Attribute（属性）（ER模型）：实体或关系中的一个性质。 8.Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些 与超类有关的属性的过程。 9.Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。 10.Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如， panch Has Staff。 11.Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标 识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。 12.Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。 13.Candidate key（候选键，ER关系模型）：仅包含唯一标识实体所必须得最小数量的 属性/列的超键。 14.Cardinality（基数）：描述每个参与实体的可能的关系数目。 15.Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并 成新数据库应用程序的一个需求集合 16.Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。 17.Client（客户端）：向一个或多个服务器请求服务的软件应用程序。 18.Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段， 这些行在这个字段上有相同的值。 19.Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一 个主索引或一个群集索引。 20.Column（列）：参加属性（attribute）。 https://www.doczj.com/doc/a31599306.html,plex relationship（复杂关系）：度数大于2的关系。 https://www.doczj.com/doc/a31599306.html,posite attribute（复合属性）：由多个简单组件组成的属性。 https://www.doczj.com/doc/a31599306.html,posite key（复合键）：包含多个列的主健。 24.Concurrency control（并发控制）：在多用户环境下同时执行多个十五并保证数据完 整性的一个DBMS服务。
物理结构设计 数据库物理设计阶段的任务是根据具体计算机系统(DBMS和硬件等)的特点，为给定的数据库模型确定合理的存储结构和存取方法。所谓的“合理”主要有两个含义：一个是要使设计出的物理数据库占用较少的存储空间，另一个对数据库的操作具有尽可能高的速度。 为了设计数据库的物理结构，设计人员必须充分了解所用DBMS的内部特征；充分了解数据系统的实际应用环境，特别是数据应用处理的频率和响应时间的要求；充分了解外存储设备的特性。数据库的物理结构设计大致包括：确定数据的存取方法、确定数据的存储结构。 物理结构设计阶段实现的是数据库系统的内模式，它的质量直接决定了整个系统的性能。因此在确定数据库的存储结构和存取方法之前，对数据库系统所支持的事务要进行仔细分析，获得优化数据库物理设计的参数。 对于数据库查询事务，需要得到如下信息： l 要查询的关系。 l 查询条件(即选择条件)所涉及的属性。 l 连接条件所涉及的属性。 l 查询的投影属性。 对于数据更新事务，需要得到如下信息： l 要更新的关系。 l 每个关系上的更新操作的类型。 l 删除和修改操作所涉及的属性。 l 修改操作要更改的属性值。 上述这些信息是确定关系存取方法的依据。除此之外，还需要知道每个事务在各关系上运行的频率，某些事务可能具有严格的性能要求。例如，某个事务必须在20秒内结束。这种时间约束对于存取方法的选择有重大的影响。需要了解每个事务的时间约束。 值得注意的是，在进行数据库物理结构设计时，通常并不知道所有的事务，上述信息可能不完全。所以，以后可能需要修改根据上述信息设计的物理结构，以适应新事务的要求。 1. 确定关系模型的存取方法 确定数据库的存取方法，就是确定建立哪些存储路径以实现快速存取数据库中的数据。现行的DBMS一般都提供了多种存取方法，如索引法、HASH法等。其中，最常用的是索引法。
xxxx学院xxxx级通信工程《C语言程序设计》实验报告姓名：xxx 学号：xxxxxxxxxxxxxxx 实验序号:实验二 实验项目：最简单的C程序设计，逻辑结构程序设计。 实验目的:1.掌握C语言中使用最多的一种语句——赋值语句的使用方法。2. 掌握各种类型数据的输入输出的方法，能正确使用各种格式转换符。3.了解C语言表示逻辑量的方法。4.学会正确使用逻辑运算符和逻辑表达式。5.熟练掌握语句和语句。6.结合程序掌握一些简单的算法。7.学习调试程序。 实验内容： 1、 #include
2.设圆半径r=1.5，圆柱高h=3，求圆周长、圆面积、圆球表面积、圆球体积、圆柱体积。#include
第三章数据库的逻辑结构与物理结构设计数据库的逻辑结构设计的主要任务是把概念层数据模型转换为组织层数据模型，即根据数据库的概念结构导出特定的数据库管理系统可以处理的数据库的逻辑结构。与数据库的逻辑结构相对应，本章我们称组织层的数据模型为逻辑模型。数据库的物理结构设计的主要任务是为逻辑模型选取一个最适合应用要求的物理结构。 本章主要介绍以下内容： ?逻辑模型 ?关系模型 ?关系规范化 ?逻辑结构设计的任务 ?数据库的物理结构设计 第一节逻辑模型 概念模型经过转换成为逻辑模型（也称为结构数据模型、组织层数据模型，常简称为数据模型）。它直接面向数据库的逻辑结构，直接与DBMS有关。 一、主要的逻辑模型 目前，数据库领域中主要的逻辑模型有层次模型、网状模型、关系模型和面向对象模型等。 1. 层次模型 层次模型（Hierarchical Model）是按照层次结构的形式组织数据库数据的数据模型，是数据库中使用较早的一种数据模型，其典型代表是IBM公司研制的、曾经被广泛使用的第一个大型商用数据库信息管理系统IMS（Information Management System）。 （1）数据结构。层次模型使用树形结构表示实体及实体间的联系。层次模型的基本特点是：有且只有一个结点没有父结点，这个结点称为根结点；根以外的其他结点有且只有一个父结点。 在层次模型中，树的结点是记录类型。上一层记录类型和下一层记录类型之间的联系是1:n的，用结点之间的连线表示。这种联系是父子之间的一对多联系。层次模型如图3-1所示。在层次模型数据库中查找记录，必须指定存取路径，即从根结点开始沿途所经过的路程。 在层次模型中，同一父结点的子结点称为兄弟结点，没有子结点的结点称为叶结点。如果要存取某一记录类型的记录，可以从根结点开始，按照有向树层次逐层向下查找，查找路径就是存取路径。任何一个给定的记录值只有按其路径查看时，才能显示其全部意义，没有一个记录值能够脱离父记录而独立存在。除根节点外，任何结点的父结点都是唯一的，因此只要知道每个结点的父结点，就可以知道整个模型的整体结构。
2.6 数据库物理结构设计 ?数据库在物理设备上的存储结构与存取方法称为数 据库的物理结构，它依赖于给定的计算机系统。 ?为一个给定的逻辑数据模型选取一个最适合应用环 境的物理结构的过程，就是数据库的物理设计。 ?充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数 ?充分了解所用RDBMS的内部特征，特别是系统提供的存取方法和存储结构
?关系数据库物理设计的内容 –为关系模式选择存取方法(建立存取路径) –设计关系、索引等数据库文件的物理存储结构 ?物理数据库设计所需参数 －数据库查询事务（查询的关系，查询条件所涉及的属性，连接条件所涉及的属性，查询的投影属性）－数据更新事务（被更新的关系，每个关系上的更新操作条件所涉及的属性，修改操作要改变的属性值）－每个事务在各关系上运行的频率和性能要求
其他需考虑的问题： 目标DBMS支持的特性、功能和选项； 主机计算机系统的特性和能力； 磁盘存储配置； 数据量。
数据库物理设计步骤： 1.数据库逻辑模式调整 2.文件组织与存取设计 3.数据分布设计 4.安全模式设计 5.确定系统配置 6.物理模式评估
1数据库逻辑模式调整 将与平台无关的描述数据库逻辑结构的关系模式及其视图转换为所选定的具体DBMS平台可支持的基本表和视图，并利用DBMS提供的完整性机制设计定义在基本表上的面向应用的业务规则。 （1) 实现目标数据库基本表和视图 遵循目标数据库的语法规则或变通 （2)设计基本表业务规则 利用目标DBMS提供的Check、断言、触发器等完成完整性约束
2文件组织与存取设计 （1)分析事务的数据访问特性 ?使用事务/表交叉引用矩阵，分析系统內重要事务对各基表的访问情况，确定事务访问哪些基本表，对哪些基本表执行了何种操作，并进一步分析各操作涉及到的基本属性表。 将所有事务路径映射到表中； 确定哪些表最常被事务访问； 分析选出的包含了这些表的事务。