数据库设计：逻辑结构设计

5.3逻辑结构设计
逻辑结构设计的任务就是把概念模型转换为某个具体的数据库管理系统所支持的数据模型。

具体来讲就是从E-R模型到关系模型的转换。

（1）根据E-R模型设计关系模式；
（2）选择适当的范式对所得到的关系模式进行规范化；
（3）将得到的关系模型转换为具体DBMS支持的数据模型，设计关系数据库模式。

（4）依据关系的完整性约束来设计用户视图。

1、关系模型
关系模型是指用二维表的形式表示实体和实体间联系的数据模型。

关系模型中无论是实体还是实体间的联系均由单一的结构类型——关系来表示。

在实际的关系数据库中的关系也称表。

一个关系数据库就是由若干个表组成。

关系模型数据结构
（1）关系
一个关系也就是通常所说的一张表。

关系具有以下特征：
1.关系中不能有任意两条完全相同的记录。

2.关系中的记录是非排序的。

3.关系中记录的字段是非排序的。

4.字段名称不能相同。

5.字段不可再分。

（2）元组
每一横行称为一个元组。

（3）属性
属性:每一竖列称为一个属性,在DBMS中常被称作字段。

在一个关系中，有
一个关系名，同时每个属性都有一个字段名
（4）码（键）
能唯一标识元组的属性或属性集称为码。

码分为以下几种：
候选码：如果在关系的一个码中不能移去任何一个属性，否则它就不是这个关系的键，则称这个被指定的候选键为该关系的候选键或者候选码。

例如下列学生表中“学号”或“图书证号”都能唯一标识一个元组，则“学号”和“图书证号”都能唯一地标识一个元组，则“学号”和“图书证号”都可作为学生关系的候选键。

主键（主码）：在一个关系的若干候选键中指定一个用来唯一标识该关系的元组，则称这个被指定的候选码称为主关键字，或简称为主键、关键字、主码。

每一个关系都有并且只有一主键，通常用较小的属性组合作为主键。

外键（外码）：关系中的某个属性虽然不是这个关系的主键，或者只是主键的一部分，但它却是另外一个关系的主键时，则称之为外键或者外码。

例如学生表，选定“学号”作为数据操作的依据，则“学号”为主键。

而在选课表中，主键为（学号，课程号），外码为“学号”。

（5）关系模式
关系模式是对关系的描述，关系是关系模式的一个实例关系模式包括关系名、各属性名，通常简记为：
R(A1，A2，…,An)
其中R为关系名，A1，A2，…,An为各属性名。

例如：学生（学号*，姓名，性别，出生日期，院系）
其中标“*”号的属性为主键
（6）关系完整性约束
现实世界中，实体及其联系都要受到许多语义要求的限制。

例如，一个学生一个学期可以选修多门课程，但只能在本学期已开出的课程中进行选修；百分制成绩的取值只能在0～100之间等。

对应在关系数据库中，关系的值随着时间变化时应该满足一些约束条件，这种对关系的约束条件就表现为关系的完整性约束。

关系完整性主要是指以下三方面：
1.实体完整性：实体完整性是指关系的主码不能重复也不能取“空值"。

在关系模式中，以主关键字作为唯一性标识，而主关键字中的属性(称为主属性)不能取空值，否则，表明关系模式中存在着不可标识的实体(因空值是“不确定\"的)，这与现实世界的实际情况相矛盾，这样的实体就不是一个完整实体。

按实体完整性规则要求，主属性不得取空值，如主关键字是多个属性的组合，则所有主属性均不得取空值。

2.参照完整性：是指参照关系中每个元素的外码要么为空，要么等于被参照关系中某个元素的主码。

比如属性K是关系模式R1的主键，K也是关系模式R2的外键，那么在R2的关系中，K的取值只允许有两种可能，或为空值，或等于R1关系中某个主键值。

3.用户定义的完整性：指对关系中每个属性的取值作一个限制(或称为约束)的具体定义。

比如性别属性只能取”男“或”女“，再就是年龄的取值范围，可以取值
0-130 ，但不能取负数，因为年龄不可能是负数。

（7）关系的规范化，减少数据冗余
关系的规范化是为了解决数据库中数据的插入、删除、修改异常等问题的一组规则。

关系范式是关系模式满足不同程度的规范化要求的标准，是数据库逻辑设计的指南和工具
关系规范化的前三个范式原则如下：
第一范式：若一个关系模式R的所有属性都是不可再分的基本数据项，则该关系模式属于第一范式（1NF）。

第二范式：若关系模式R属于1NF，且每个非主属性都完全函数依赖于码，
则该关系模式属于2NF，2NF不允许关系模式中的非主属性部分函数依赖于码。

成绩表（学号*，课名*，姓名，成绩）→ 姓名1NF
成绩表（学号*，课名*，成绩）→ 成绩2NF
学生表（学号*，姓名）→ 姓名2NF
第二范式仅仅对于具有复合主键的表有意义，也就是主键是由两个或两个以上的列复合而成的表。

具有单列主键的表自动就是2NF。

第三范式：若关系模式R属于1NF，且每个非主属性都不传递依赖于码，则该关系模式属于3NF。

第三范式是一个已经是第一范式和第二范式的表，并且所有非主键列的值都只能由主键列中决定，而不能由其他非主键列决定。

虽然有了第一范式和第二范式已经可以减少很多的数据冗余，但它们还是有可能出现更新异常。

学生表（学号*，姓名，系名，系主任）→系主任2NF
为了符合第三范式，更改为：
学生表（学号*，姓名，系名）3NF
系表（系名*，系主任）3NF
使用关系范式对关系进行规范化的具体步骤如下：
首先，考察关系模型的函数依赖关系，确定范式等级。

逐一分析各关系模式，考察是否存在部分函数依赖、传递函数依赖等，确定它们分别属于第几范式。

然后，对关系模式进行合并或分解。

根据应用要求，考察这些关系模式是否合乎要求，从而确定是否要对这些模式进行合并或分解，例如，对于具有相同主码的关系模式一般可以合并。

实际应用中并不是规范化程度越高越好，有时分解带来的消除更新异常的好处与经常查询需要频繁进行自然连接所带来的效率低相比会得不偿失。

对于那些需要分解的关系模式，可以用规范化方法和理论进行模式分解。

最后，对产生的各关系模式进行评价、调整，确定出较合适的一组关系模式。

关系规范化理论提供了判断关系逻辑模式优劣的理论标准，帮助预测模式可能出现的问题，是产生各种模式的算法工具，因此是设计人员的有力工具。

（8）关系数据库：由一个或一个以上的“关系”彼此关联组成的数据集合可称为关系数据库
在关系模型中，用关系来表示实体以及实体间的联系。

在一个给定的应用领域中，所有实体及实体之间联系的关系的集合构成一个关系数据库。

关系数据库就是表的集合，结构化的数据存储在这些表中。

但是关系数据库是一个整体，并不仅仅只是把不同的表随意的堆积在一起，表与表之间有着密切的联系，通常一个关系数据库中的表格和其他表格都有关系。

2、E-R模型与关系模型的转换
将E-R图转换为关系模型数据库的转换原则如下：
（1）首先将每一个实体集转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。

（2）要把一个1:1联系转换为关系模型，可以在两个实体集转换成的两个关系模式中的任意一个关系模式的属性中加入另一个关系模式的码和联系的属性。

转换后得到的关系模型
厂长（身份证号*，姓名，性别，年龄，厂号，任期）
工厂（厂号*，厂名，地址）或者
厂长（身份证号*，姓名，性别，年龄，）
工厂（厂号*，厂名，地址，身份证号，任期）
（3）要把一个1:n联系转换为关系模型，可以在n端实体集转换成的关系模式中加入1端实体集的码和联系的属性。

得到以下关系模式
仓库（仓库号*，地点，面积）
商品（商品号*，商品名，价格，仓库号，数量）
（4）要把一个m:n联系转换为一个关系模式，要将该联系转换为一个关系模式，属性为两端实体集的码加上联系的属性。

转换后的关系模型
银行（银行名*，地址）
储户（帐号*，姓名，余额）
存取款（银行名*，帐号*，日期，金额，经办人）
实例：
将学生、课程、教师、院系，这四个实体的E-R图转换关系模型，可得以下关系模式：
学生（学号*，姓名，院系号）
课程（课程号*，课程名）
教师（教师号*，姓名，院系号）院系（院系号*，院系名）
选课（学号* ，课程号* ，成绩）授课（教师号*，课程号*，教材）。