数据库设计中使用设计模式

一、引言

现代的企业开发中，越来越多地引入了多层架构设计模式，即使是小型的企业信息系统也逐渐向多层架构发展，以满足系统的可伸缩性以及可维护性。目前企业开发的平台占主导地位的是 J2EE 和 .NET 两大平台，本文并不是去对比两大平台的优缺点，以免引发宗教式的争论，而是在两大平台的基础上探讨如何进行数据库的设计，将设计模式引入到数据库设计中，以期达到良好的、可管理、可伸缩的数据库设计。

传统的数据库设计理论，更加关注的是数据库设计范式，这是数据库设计必须要遵守的规则：

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是属于第一范式的关系。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称 R是属于第二范式的。

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称 R是属于第三范式的。

一般认为设计数据库时能够达到第三范式即可，这也是大部分数据库原理课程所要求的数据库设计结果。但现代关系数据库管理系统中，除了支 持数据库中的数据查询、更改、插入和删除外，更有强大的企业级功能支持，像存储过程、触发器和分布式查询处理，无疑，我们的数据库设计如果只满足几个范式 的话，充其量只是完成了数据的存取要求，而无法和企业程序良好的结合。在设计企业应用中，数据库是企业应用中最重要的一层，是企业应用的信息起点和终点。 如何将业务逻辑在数据库系统设计中正确、良好的表达，不仅涉及到系统实现的不同方式，也涉及到企业应用的成功与否。

本文试图探讨在数据库设计中如何应用设计模式理论，形成一种数据库设计模式，以避免业务逻辑层对数据库层的信息耦合，达到业务逻辑在不同层之间的正确转移与实施。

二、分布式多层应用中数据库设计的疑问

现代的企业应用程序大多采用分布式多层应用模式。如下图所示：

从上面的示意图中可以看出，无论是微软的 .NET 平台还是 J2EE 平台都表现出将业务逻辑单独放置在业务逻辑层中的意图，也即 .NET 平台中的 Web Service，J2EE 平台中的 Enterprise Java Bean。

J2EE 平台发展较早，并且理论非常成熟，很多技术和架构都在 J2EE 中产生，然后才有相应的 .NET 移植与实现。在 J2EE 体系架构中，核心的是 Enterprise Java Bean 技术，而 Session Bean 更是成功的设计。在 J2EE 中，利用 Entity Bean进行了 O/R 映射的尝试，但因为 Entity Bean 的设计复杂以及无法进行单元测试等缺点，在 J2EE 社区中颇多微词，也导致了 Hibernate、JDO 等轻量级 O/R 框架的产生。而在微软的 .NET 平台中，也出现了 NHibernate 的移植框架，微软本身也在进行 Object Spaces O/R框架的开发。

通过研究O/R 映射，让程序员和设计者产生了这样一个感觉：无论是 Entity Bean、还是 Hibernate 和 JDO，都强调 O/R 映射关系，让程序员和设计者可以用面向对象的思维方式来考察系统，而不用关心数据如何在底层存储，甚至我们只要在系统中设计好对象实体，然后利用 O/R 映射去自动实现到数据库的映射即可，程序员不需要关心数据库，不需要知道任何 SQL 的语法，只需要通过专门的 EJB-QL 或者 HQL 语言进行数据的处理即可，而无需在程序中书写任何的设计数据库存取的代码。这样编写的程序有利于移植，如果需要更改数据库系统，仅仅重新改写 EJB-QL 或者 HQL 语言既可。