逻辑结构设计的任务是，把概念结构中的E—R模型转换成数据库管理系统所支持的数据模型。

在数据库管理系统中，采用数据模型（Data Model）来对现实世界进行抽象，反映数据本身及其数据之间的联系。有关数据模型的相关知识，请读者参考本教材第二章数据库技术一节的相关知识。数据模型按照计算机系统的观点来组织数据。为了将现实世界中的事物抽象为数据库管理系统支持的数据模型，通常需要一个不依赖于计算机系统的中间层次，即首先将现实世界中的事物及其联系抽象为概念模型（概念结构设计），再由概念模型转化为数据模型，最常用的是关系数据模型。

将E—R模型转换为关系模型，一般遵循如下原则：

（1）一个实体转换为一个关系，实体的属性就是关系的属性，实体的关键字就是关系的关键字。

（2）一个1∶1的联系有两种方式向关系模式转换：一种方式是将联系转换为一个独立的关系，关系的属性包括该联系所关联的两个实体的码及联系本身的属性，关系的码取自任一方实体的码；另一种方式是将联系归并到关联的两个实体的任一方，给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可，归并后的实体码保持不变。

（3）一个1∶n的联系有两种方式向关系模式转换：一种方式是将联系转换成一个独立的关系，关系的属性包括该联系所关联的两个实体的码及联系本身的属性，关系的码是多方实体的码；另一种方式是将联系归并到关联的两个实体的多方，给待归并的多方实体的属性集中增加一方实体的码和该联系的属性即可，归并后多方实体的码保持不变。

（4）一个n∶m的联系转换为一个关系，联系中各实体关键字的组合组成关系的关键字（组合关键字）。

通过以上方法，就可以将全局E—R模型中的实体、属性、联系全部转换为关系模型，建立初步的关系模型。

但是，关系模型的好坏对数据的存储、操作有很大影响。因此，一般基于规范化理论进行关系模型的设计，要将前面得到的初步的关系模型进行规范化。规范化理论是科德（E.F.Codd）在1971年提出的，研究关系模型中各属性之间的关系，探讨关系模型应具备的性质和设计方法。

在数据的规范化表达中，一般将一组相互关联的数据称为一种关系，这种关系落实到具体数据库上就是基本表，在规范化理论中该表是二维的，它具有以下性质：

（1）列是同质的，即每一列中的分量是同一类型的数据，属于同一个域；

（2）列的顺序无所谓，即列的次序可以任意交换；

（3）任意两个元组不能完全相同，即行不能重复；

（4）行的顺序无所谓，即行的次序可以任意交换。

规范化体系中通过多层范式（Normal Form）结构表示关系模型的规范化程度，其结构如图6—6所示。在规范化体系中，如果满足最低要求，则称为第一范式（First Normal Form，1NF），在1NF的基础上进一步满足一定的条件则为第二范式（2NF），以此类推。数据库是关系模式的集合，模式设计三个方面的内容包括数据依赖、范式、模式设计方法，范式是经过规范的关系模式。关系可以分为静态关系和动态关系。静态关系是指一旦数据已加载，用户只能在这个关系上进行查询操作，不再进行插入、删除、更新操作，静态关系一般规范到1NF就可以满足需要。动态关系是指要对该关系中的数据经常进行更新、插入、删除操作，一般要规范到BCNF或3NF。

图6—6　各种范式之间的关系

1.第一范式（1NF）

所谓第一范式，即关系模式中属性的值域中每一个值都是不可再分解的值。如果某个数据库模式都是第一范式的，则称该数据库模式是属于第一范式的数据库模式。

比如有一个学习关系（学号，课程），若有如表6—6所示的几行记录，这时的第三条记录就表示本关系模式不是1NF的，因为课程中的值域还是可以分解的，它包括两门课程。(www.daowen.com)

表6—6　学生学习表

如果改为如表6—7所示的记录，则成为1NF的关系。1NF的关系应满足的基本条件是，元组中每个分量都必须是不可分割的数据项。

表6—7　学生学习表

2.第二范式（2NF）

如果关系模式R为第一范式，并且R中每一个非主属性都完全依赖于R的主键，则称为第二范式模式。表6—8的关系模式满足1NF的要求，但不满足2NF的要求。

表6—8　学生学习表

在此关系模式中，“学号”和“课程号”共同构成此关系模式中的主码。“所在系”、“系主任”和“成绩”是非主属性。在这里“所在系”只是部分依赖于码（即只依赖于主码的第一个分量“学号”），“系主任”也是部分依赖于码，因此该关系模式不属于第二范式。经过规范化分解，可得如下两个满足第二范式的关系：

学生和系（学号，姓名，所在系，系主任）

成绩表（学号，课程号，成绩）

3.第三范式

如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的主键，则称R为第三范式模式。如表6—9所示的关系模式属于第二范式，但不满足第三范式。

表6—9　学生和院系

在该关系中，主码为“学号”。“所在系”这个非主属性依赖于主码“学号”，而“系主任”又依赖于“所在系”，因此，“系主任”的传递依赖于主码“学号”。这样的关系存在着高度冗余和更新问题。消除传递依赖关系的办法是将上述关系分解为如下几个满足第三范式的关系：

学生（学号，姓名，所在系）

院系（所在系，系主任）

3NF消除了插入、删除异常及数据冗余等问题，已经是比较规范的关系了。