4.4 逻辑结构设计
逻辑结构设计的任务是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。也就是导出特定的DBMS可以处理的数据库逻辑结构，这些模式在功能、性能、完整性和一致性方面满足应用要求。
特定的DBMS可以支持的组织层数据模型包括关系模型、网状模型、层次模型和面向对象模型等。对某一种数据模型，各个机器系统又有许多不同的限制，提供不同的环境与工具。设计逻辑结构时一般包括3个步骤，如图4-17所示。
图4-17 逻辑结构设计
1）将概念结构转化为一般的关系、网状、层次模型。
2）将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。
3）对数据模型进行优化。
目前，新设计的数据库应用系统大多都采用支持关系数据模型的DBMS，所以这里只介绍E-R图向关系数据模型转换的原则与方法。
4.4.1 E-R图向关系模型的转换
概念设计中得到的E-R图是由实体、属性和联系组成的，而关系数据库逻辑设计的结果是一组关系模式的集合。所以将E-R图转换为关系模型实际上就是将实体、属性和联系转换成关系模式。（第2章已经阐述，此处不再展开）
4.4.2 关系模式规范化
应用规范化理论对上述产生的关系的逻辑模式进行初步优化，以减少乃至消除关系模式中存在的各种异常，改善完整性、一致性和存储效率。规范化理论是数据库逻辑设计的指南和工具，规范化过程可分为两个步骤：确定范式级别和实施规范化处理。
1．确定范式级别
考查关系模式的函数依赖关系，确定范式等级。逐一分析各关系模式；考查是否存在部分函数依赖、传递函数依赖等，确定它们分别属于第几范式。
2．实施规范化处理
确定范式级别后，利用后面的规范化理论，逐一考察各个关系模式，根据应用要求，判断它们是否满足规范要求，可用已经介绍过的规范化方法和理论将关系模式规范化。
综合以上数据库的设计过程，规范化理论在数据库设计中有如下几方面的应用。
1）在需求分析阶段，用数据依赖概念分析和表示各个数据项之间的联系。
2）在概念结构设计阶段，以规范化理论为指导，确定关系键，消除初步E-R图中冗余的联系。
3）在逻辑结构设计阶段，从E-R图向数据模型转换过程中，用模式合并与分解方法达到规范化级别。
4.4.3 模式评价与改进
关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。
模式评价的目的是检查所设计的数据库模式是否满足用户的功能要求、效率要求，确定加以改进的部分。模式评价包括功能评价和性能评价。
所谓的功能评价指对照需求分析的结果，检查规范化后的关系模式集合是否支持用户所有的应用要求。对于目前得到的数据库模式，由于缺乏物理结构设计所提供的数量测量标准和相应的评价手段，所以性能评价是比较困难的，只能对实际性能进行估计，包括逻辑记录的存取数、传送量以及物理结构设计算法的模型等。
根据模式评价的结果，对已生成的模式进行改进。如果因为系统需求分析、概念结构设计的疏漏导致某些应用不能得到支持，则应该增加新的关系模式或属性。如果因为性能考虑而要求改进，则可采用合并或分解的方法。
（1）合并
如果有若干关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的连接查询，那么可对这些关系模式按照组合使用频率进行合并。这样便可以减少连接操作而提高查询效率。
（2）分解
为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。
经过多次的模式评价和模式改进之后，最终的数据库模式得以确定。逻辑结构设计阶段的结果是全局逻辑数据库结构。对于关系数据库系统来说，就是一组符合一定规范的关系模式组成的关系数据库模式。
数据库系统的数据物理独立性特点消除了由于物理存储改变而引起的对应程序的修改。标准的DBMS例行程序应适用于所有的访问，查询和更新事务的优化应当在系统软件一级上实现。这样，逻辑数据库确定之后，就可以开始进行应用程序设计了。
在数据库设计的工作中，有时数据库开发人员仅从范式等理论知识无法找到问题的“标准答案”，需要靠数据库开发人员经验的积累以及智慧的沉淀。设计同一个系统，不同经验的数据库开发人员，仁者见仁智者见智，设计结果往往不同。但不管怎样，只要实现了相同的功能，所有的设计结果没有对错之分，只有合适与不合适之分。
因此，数据库设计像一门艺术，数据库开发人员更像一名艺术家，设计结果更像一件艺术品。数据库开发人员要依据系统的环境（网络环境、硬件环境、软件环境等）选择一种更为合适的方案。有时为了提升系统的检索性能、节省数据的查询时间，数据库开发人员不得不考虑使用冗余数据，不得不浪费一些存储空间。有时为了节省存储空间、避免数据冗余，又不得不考虑牺牲一些时间。设计数据库时，“时间”（效率或者性能）和“空间”（外存或内存）好比天生的一对“矛盾体”，这就要求数据库开发人员保持良好的数据库设计习惯，维持“时间”和“空间”之间的平衡关系。