关系模式的规范化不是目的而是手段，数据库设计的目的是最终满足应用需求。因此，为了进一步提高数据库应用系统的性能，还应该对规范化后产生的关系模式进行评价、改进，经过反复多次的尝试和比较，最后得到优化的关系模式。
模式评价的目的是检查所设计的数据库模式是否满足用户的功能要求、效率，确定加以改进的部分。模式评价包括功能评价和性能评价。
(1) 功能评价
功能评价指对照需求分析的结果，检查规范化后的关系模式集合是否支持用户所有的应用要求。关系模式必须包括用户可能访问的所有属性。在涉及多个关系模式的应用中，应确保联接后不丢失信息。如果发现有的应用不被支持，或不完全被支持，则应该改进关系模式。发生这种问题的原因可能是在逻辑设计阶段，也可能是在需求分析或概念设计阶段。是哪个阶段的问题就返回到哪个阶段去，因此有可能对前两个阶段再进行评审，解决存在的问题。
在功能评价的过程中，可能会发现冗余的关系模式或属性，这时应对它们加以区分，搞清楚它们是为未来发展预留的，还是某种错误造成的，比如名字混淆。如果属于错误处置，进行改正即可，而如果这种冗余来源于前两个设计阶段，则也要返回重新进行评审。
(2) 性能评价
对于目前得到的数据库模式，由于缺乏物理设计所提供的数量测量标准和相应的评价手段，所以性能评价是比较困难的，只能对实际性能进行估计，包括 逻辑记录的存取数 、传送量以及物理设计算法的模型等。
美国密执安大学的T.Teorey和J.Fry于1980年提出的逻辑记录访问（Logical Record Access，LRA）方法是一种常用的模式性能评价方法。LRA方法对网状模型和层次模型较为实用，对于关系模型的查询也能起一定的估算作用。
有关LRA方法本书不详细介绍，读者可以参考有关书籍。
2．模式改进
根据模式评价的结果，对已生成的模式进行改进。
如果因为需求分析、概念设计的疏漏导致某些应用不能得到支持，则应该增加新的关系模式或属性。
如果因为性能考虑而要求改进，则可采用合并或分解的方法。
(1) 合并
如果有若干个关系模式具有相同的主键，并且对这些关系模式的处理主要是查询操作，而且经常是多关系的查询，那么可对这些关系模式按照组合使用频率进行合并。
这样便可以减少联接操作而提高查询效率。
(2) 分解
为了提高数据操作的效率和存储空间的利用率，最常用和最重要的模式优化方法就是分解，根据应用的不同要求，可以对关系模式进行垂直分解和水平分解。
水平分解是把关系的元组分为若干子集合，定义每个子集合为一个子关系。
对于经常进行大量数据的分类条件查询的关系，可进行水平分解，这样可以减少应用系统每次查询需要访问的记录数，从而提高了查询性能。
例如，有学生关系（学号，姓名，类别……），其中类别包括大专生、本科生和研究生。如果多数查询一次只涉及其中的一类学生，就应该把整个学生关系水平分割为大专生、本科生和研究生三个关系。
垂直分解是把关系模式的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是把经常一起使用的属性分解出来，形成一个子关系模式。
例如，有教师关系（教师号，姓名，性别，年龄，职称，工资，岗位津贴，住址，电话），如果经常查询的仅是前六项，而后三项很少使用，则可以将教师关系进行垂直分割，得到两个教师关系：
教师关系1（教师号，姓名，性别，年龄，职称，工资）
教师关系2（教师号，岗位津贴，住址，电话）
这样，便减少了查询的数据传递量，提高了查询速度。
垂直分解可以提高某些事务的效率，但也有可能使另一些事务不得不执行连接操作，从而降低了效率。因此是否要进行垂直分解要看分解后的所有事务的总效率是否得到了提高。垂直分解要保证分解后的关系具有无损连接性和函数依赖保持性。相关的分解算法已经在第4章进行了详细介绍。
经过多次的模式评价和模式改进之后，最终的数据库模式得以确定。逻辑设计阶段的结果是全局逻辑数据库结构。对于关系数据库系统来说，就是一组符合一定规范的关系模式组成的关系数据库模型。
数据库系统的数据物理独立性特点消除了由于物理存储改变而引起的对应程序的修改。标准的DBMS例行程序应适用于所有的访问，查询和更新事务的优化应当在系统软件一级上实现。这样，逻辑数据库确定之后，就可以开始进行应用程序设计了。
