一.引言
现代企业发展引入了多层体系结构的设计模式，即使是小规模的企业信息系统也逐渐向多层体系结构发展，以满足系统的可扩展性和可维护性。 目前，企业开发的平台占主导地位的是J2EE和. NET两个平台。 本文比较了两个平台的优缺点，探讨了如何基于两个平台进行数据库设计，而不是引起宗教争议，并将设计模式引入到数据库设计中，实现了良好、可管理、用例
传统的数据库设计理论关注数据库设计范式。 这是数据库设计必须遵守的规则。
在第一范式(1NF )关系模型r的每个具体关系r中，如果每个属性值是不可再划分的最小数据单元，则r被称为属于第一范式的关系。
第二正则表达式(2NF ) :如果关系模型r(u，f )的所有非主属性完全依赖于任何一个候选关键字，则r称为第二正则表达式。
如果关系模型r(u，f )所有非主属性对于任何候选关键字都不存在传输可靠性，则第三范式(3NF )被称为r属于第三范式。
一般认为在设计数据库时只要能达到第三范式就可以了，这也是大部分数据库原理课程所要求的数据库设计结果。 但现代关系数据库管理系统不仅支持数据库中的数据查询、修改、插入和删除，而且支持存储过程、触发器、分布式查询处理等强大的企业级功能确实，我们的数据库设计只满足一些范式，最多只能满足数据的访问要求，无法很好地与企业程序结合起来。 在企业APP沟通的设计中，数据库是企业APP沟通中最重要的层，是企业APP沟通信息的起点和终点。 如何在数据库系统设计中正确、良好地表达业务逻辑不仅关系到系统实现的不同方式，而且关系到企业APP应用的成败。
本文试图在数据库设计中如何应用设计模式理论，形成数据库设计模式，避免业务逻辑层和数据库层的信息耦合，达到业务逻辑在不同层间的准确转移和实施。
二.分布式多层APP中数据库设计质疑
现代企业APP大多采用分布式多层APP模式。 如下图所示。
从上图可以看出，无论是微软的. NET平台还是J2EE平台，都将业务逻辑映射到业务逻辑层，即. NET平台的web服务、J2EE平台的enterprise
J2EE平台发展很快，理论非常成熟，许多技术和体系结构在J2EE中应运而生，然后才能实现相应的. NET移植。 在J2EE架构中，以Enterprise Java Bean技术为中心，Session Bean的设计更为成功。 在J2EE中，利用Entity Bean进行了O/R映射的尝试，但由于Entity Bean的设计复杂，以及无法进行单元测试等缺点，J2EE社区中存在着很多微词，Hibernate 另一方面，在微软的. NET平台上，NHibernate的移植框架也出现了，微软自身也在进行Object Spaces O/R框架的开发。
通过研究O/R映射，程序员和设计者在Entity Bean、Hibernate和JDO中都强调O/R映射关系，使程序员和设计者可以对着韵蛭乃嘉捻纯病现在可以俯卧位堵塞低颤霉菌霓虹灯了，O/R映射只需自动实现到数据库的映射即可，程序员不需要在意数据库，不需要知道SQL语法，可以使用专用的EJB-QL或这样编写的程序有助于移植。 如果需要更改数据库系统，只需重写EJB-QL或HQL语言即可。
看起来很美，但这是个美丽的谎言。
首先，在企业的APP应用设计中，如果选择一个关系数据库系统，在实施过程中企业会花费大量的资金购买数据库系统的使用许可，而且数据库系统的实施、安装、日常维护也需要专业人员。
其次，大型数据库管理系统具有良好的设计和优化功能，而且不同的数据库系统各有特点，许多特性是独特的，不可移植的。 采用O/R映射会导致数据库系统特有的强大功能丢失。
第三，无论在系统设计过程中如何优化性能，O/R映射最终都会转换为实际的数据库连接，并进行实际的数据库操作。 这些任务不能与数据库系统内部存储过程或触发器的性能进行比较，而且会增加通过连接池的数据库连接的负载。
因此，良好的数据库设计仍然是企业APP沟通中非常重要的步骤。
3将Faade模式应用于数据库设计
目前的系统设计中有很多设计模式，Faade设计模式已经深入人心。 Faade模式为“子系统中的一组接口提供统一的接口。 Faade定义了更高级别的接口，以便于使用子系统。 ”在系统设计中，faade是应用最广泛的设计模式，利用faade模式的思想将构成子系统的一系列业务对象“包装”到faade接口中。 因此，Faade对象充当客户端访问业务对象的拦截器，阻止业务对象。 客户端访问Faade对象，而不是访问底层业务
对象，当一个客户端需要调用多个业务对象的方法时，它只需要进行一次粗粒度的远程方法调用，将请求送给Façade 对象, 再由Façade 对象通过本地方法调用，调用相应的业务对象，执行其方法。这样就减轻了网络负载，提高了系统性能。并且当底层业务对象的方法改动时，只需要修改 Façade 对象，而客户端可以保持不变。这就减少了客户端和业务对象之间的耦合度，同时客户端也不必管理事务的细节。如下图所示：由 Façade 设计模式我们可以看出，如果将数据库系统认为是一个底层的业务系统，我们应该在设计数据库系统时隐藏底层的细节，而将所有对数据库进行的增、删、改、查询操作统一到一个 Façade 接口上来，这样在系统设计的过程中，所有与数据库系统打交道的业务组件无需关心底层的数据库存储方式，而是将底层的数据按照系统实体的方式展现出来，再通过 Façade 接口进行变换，将实际的实体提交给业务组件接口或者将实体持久化到真正的数据库表当中。
比如，在设计学生选课管理系统中，底层的数据表可能包括课程表、学生表、选课表以及成绩表，但对外表现出来的实体应该只有学生和课程两 个实体。然后可以通过一个存储过程暴露出来一个学生选课的功能，在业务组件中调用。同时应设计触发器，当插入选课信息到选课表的时候，在相应得成绩表中插 入相应的记录。而在业务组件端，仅仅看到底层数据库系统暴露出来的一个功能，即使数据库系统的设计发生变化，也不会影响业务组件的功能。
随着 SQL Server 2005 的发布，已经可以在 SQL Server 2005 中使用 .NET CLR 来进行数据库的编程，这对数据业务逻辑的封装提供了更好的支持。Oracle 已经支持 Java，并且也在进行 .NET CLR 的集成，IBM 的DB2 也有类似的功能。
采用Façade设计模式，能够较好的隔离底层数据库系统与业务组件之间的耦合，但物极必反，过度的使用存储过程也可能带来不必要的设计麻烦。在数据库设计中，适当的暴露底层的视图也是一种良好的设计风格。一个全面的、良好的设计才是系统成功的保证。
编者注：本文属转载，我们无法找到原文，致使我们无法提供文中的插图，请谅解。