设计大型复杂的数据库应用系统需要适当地选择应用模型。传统的客户/服务模型依靠加入中间层而得到改进成为三层模型，如图6-4所示。这三个层次将系统划分为三个逻辑构件：数据服务(Data Service)、业务服务(Business Service)和表达服务(Presentation Service)。如图6-4所示，每一层都负责提供相应的服务。
图6-4 三层体系结构
|
(1) 数据服务(Data Service) 负责维护数据和操作数据，如对数据的增加、修改、删除和存档。这些服务维护数据关系和联系，支持备份和恢复操作。通常数据服务由数据库管理系统或其它数据管理平台予以完成。
(2) 业务服务(Business Service) 由业务规则和数据处理逻辑组成，如数据合法性规则、事务处理支持和记录存档逻辑。这些服务的主要目的是向应用程序提供数据维护的逻辑。
(3) 表达服务(Presentation Service) 提供可视化的图形用户界面，浏览信息和收集数据；与用户交互，组织用户的操作请求；负责用户数据输入和数据表达(输出)。
系统的物理实现在不同的开发环境和开发工具中可通过许多不同途径进行。下面讨论数据库应用系统中三层逻辑模型的几种实现方法：
・ 胖客户机(fat client)实现。
・ 瘦客户机(thin client)实现。
・ 多层(multi tier)客户/服务器实现。
・ 浏览器(browsers)/服务器实现。 (1) 胖客户机实现
三层结构的一种实现选择是在客户机上运行业务和表达服务。这是早期大多数数据库应用程序的最普通途径。这种实现物理上只有两层，服务器只提供数据服务，如图 6-5所示。
图6-5 胖客户机实现
这种方法有两点不足。首先，当应用程序在客户计算机上增加时，客户计算机需要更为强大的功能，这将增加系统开销，因为一个系统经常带有多个客户机。当系统带有数以千百万的客户机时，这种方法会变得过于昂贵。
另一点不足是可能增加维护费用。每次对系统的合法性逻辑和业务规则的改动将导致升级客户机程序。如果系统有相当数量的客户机，这就是个问题。
胖客户机实现的最大优点是减少网络流量，如果合法性和业务规则不必由数据库决定的话。这种情况下，只有通过合法性逻辑的数据能传向服务器。作为输入数据合法性的示例，假设读者有一张小表(比如国家名称表)放在客户机里。如果数据入口模块检查本地表而不是在主数据库里比较国家名称，则显然会减少网络流量。
另一重要用途是在系统的开发过程中。如果前端开发者被限制了对后端的访问，比如，不能通过数据库里的数据来验证输入合法性，那么，这种方法可以使其正确处理数据。
(2) 瘦客户机实现
在瘦客户机实现中，业务服务位于服务器端，业务逻辑通常表现为存储过程或数据库触发器。这种实现像胖客户机实现一样物理上只有两层，如图6-7 所示。
例如，对于微软的SQL Server数据库管理系统，存储过程和数据库触发器使用T-SQL编写。
图6-6 瘦客户机实现
这种方法的优点是减少系统开销，因为瘦客户机需要更少的系统资源，这对于带有许多客户机的系统很重要。而且，维护费用也比胖客户机系统少些，因为代码在服务器端集中控制。