免费智能真题库 > 历年试卷 > 系统架构设计师 > 2025年下半年 系统架构设计师 下午试卷 论文
  第4题      
  知识点:   开发过程   继承   架构设计   可扩展性   可伸缩性   数据存储   数据库   系统架构   业务层

 
论企业应用系统的数据持久层架构设计
数据持久层(Data Persistence Layer)通常位于企业应用系统的业务逻辑层和数据源层之间,为整个项目提供一个高层、统一、安全、并发的数据持久机制,完成对各种数据进行持久化的编程工作,并为系统业务逻辑层提供服务。它能够使程序员避免手工编写访问数据源的方法,使其专注于业务逻辑的开发,并且能够在不同项目中重用本框架, 这大大简化了数据的增加、删除、修改、查询功能的开发过程,同时又不丧失多层结构的天然优势,继承延续应用系统架构可伸缩性可扩展性。当运用关系型数据库作为 数据存储机制时,在业务层与数据源间加入数据持久层,能够解决对象与关系的“阻抗 不匹配”问题,将对象的状态持久化存储到关系型数据库中。
 
问题:4.1   请围绕“企业应用系统的数据持久层架构设计”论题,依次从以下三方面进行论述。
1. 概要叙述你参与分析和设计的企业应用系统开发项目以及你所担任的主要
工作。
2. 分析在企业应用系统的数据持久层架构设计中有哪些数据访问模式,并详细阐述每种数据访问模式的主要内容。
3. 数据持久层架构设计的好坏决定着应用程序性能的优劣,请结合实际说明在数据持久层架构设计中需要考虑哪些问题。
 
 
 

   知识点讲解    
   · 开发过程    · 继承    · 架构设计    · 可扩展性    · 可伸缩性    · 数据存储    · 数据库    · 系统架构    · 业务层
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
 
       继承
        继承可以在类型的级别上进行,也可以在表级别上进行,下面分别介绍。
               类型继承
               如希望在数据库中对那些是学生和教师的人分别存储一些额外的信息。
               由于学生和教师是人,所以可以使用继承。在SQL-99中定义学生和教师类型如下:
               
               Student和Teacher都继承了Person的属性,即name和address。Student和Teacher被称为Person的子类型,Person是Student的超类型,同时也是Teacher的超类型。像属性一样,结构类型的方法也被它的子类型继承。不过,子类型可以通过在一个方法声明中使用overriding method(重载方法)取代原method(方法)的方式重新声明方法,以重定义该方法的作用。
               现在假定要存储关于助教的信息,这些助教既是学生又是教师,甚至可能是在不同的系里。可以利用多重继承(multiple inheritance)的方法来做。SQL-99标准不支持多重继承,然而SQL-99标准是提供多重继承的,尽管SQL-99最终版中忽略了它,但SQL标准的未来版本可能会引入它。基于SQL-99标准的草案来讨论问题。
               TeacherAssistant将继承Student和Teacher的所有属性。由于name和address属性实际上是从同一个来源即Person继承来的,因此同时从Student和Teacher中都继承这两个属性不会引起冲突。但是,一个助教既可能是某个系的学生同时又是另一个系的教师,所以department属性在Student和Teacher中分别都有定义。为了避免两次出现的department之间的冲突,我们可以使用as子句将它们重新命名,如下面的TeachingAssistant类型定义所示:
               
               注意SQL-99只支持单继承,即一个类型只能继承一种类型,使用的语法如例8.35。TeachingAssistant例子中的多重继承在SQL-99中是不支持的。SQL-99标准还需要在类型定义的尾部有一个特别的字段,取值为final或not final。其中,关键字final表示不能从给定类型创建子类型,not final表示可以创建子类型。
               SQL中的一个结构类型的值必须恰好只有一个“最明确类型(most-specific type)”,即每一个值被创建时必须关联到一个确定的类型,称为它的最明确类型。依靠继承,它也与它的最明确类型的每个超类型相关联。举例来说,假定一个实体具有类型Person,同时又具有类型Student,那么这个实体的最明确类型为Student,因为Student是Person的子类型。然而一个实体不能同时既具有类型Student又具有类型Teacher,除非这个实体具有一个如TeacherAssistant那样既是Student子类型又是Teacher的子类型的类型。
               表继承
               SQL-99中的子表(subtable)对应的是E-R概念中的特殊化/一般化。子表的类型必须是父表类型的子类型,因此,父表中的每一个属性均出现在子表中。
               定义子表students和teachers如下:
               
               当我们声明students和teachers作为people的子表时,每一个students或teachers中出现的元组也隐式存在于people中。如果一个查询用到people表,它将查找的不仅仅是直接插入到这个表中的元组,而且还包含插入到它的子表(也就是students和teachers)中的元组。但是,只有出现在people中的属性才可以被访问。
               多重继承也可在表进行。例如,创建一个类型为TeachingAssistant的表:
               
               作为声明的结果,每一个在teaching-assistants中出现的元组也隐式地在表teachers和students中出现,从而也出现在people表中。SQL-99允许在查询中使用“only people”代替people来查询只在people中而不在它的子表中的元组。
               对子表的一致性要求。如果一个子表和一个父表中的元组对于所有的继承属性具有同样的值,则称子表中的元组符合(correspond to)父表中的元组。因此,相符合的元组表示同一个实体。子表的一致性需求为:
               .父表的每个元组至多可以与它的每个直接子表的一个元组符合。
               .SQL-99有一个附加的约束,所有相符合的元组必须由一个元组派生(插入到一个表中)。
               例如,若没有第一个条件,我们就可能在students(或teachers)中有两个元组与同一个人符合。第二个条件排除了people中的一个元组分别符合students和teachers中的一个元组的情况,除非所有这些元组都隐式出现。这是由于一个元组会被插入到一个既是teacher的子表又是students的子表的teaching-assistants表中。
               由于SQL-99不支持多重继承,所以第二个条件实际上阻止一个人既是老师又是学生。即使支持多重继承,这个问题在没有子表teaching-assistants时也会出现。显然,建立一个即使没有teaching-assistants子表也可以让一个人既是老师又是学生的环境是很有用的。因此,去掉第二个一致性约束是有用的。
               子表可以采用无须复制所有的继承字段的有效方式进行存储,通常有如下两种方式:
               .每一个表只存储主码(可能是从父表中继承来的)和局部定义的属性。继承属性(主码之外的)不需要存储,因为它可以基于主码与父表连接得到。
               .每一个表存储所有继承的和局部定义的属性。当插入一个元组时,它仅仅存储在它被插入的那个表中,在它的每个父表中推断它的出现。因为不需要连接,所以可快速访问元组的所有属性。不过,一旦没有第二个一致性约束(即一个实体可能出现在两个子表中而不在它们的公共子表中出现),这种表达将导致信息重复的问题。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       可扩展性
        该指标主要评价入侵检测系统是否易于配置修改和安装部署的能力,以适应新的攻击技术方法不断出现和系统环境的变迁需求。
 
       可伸缩性
        设计者同样需要考虑网络的可伸缩性,即考虑现在以及将来网络所需的容量。容量设计必须易于调整以适应单位、应用以及网络的适当增长。例如,当设计者实施以太网接口卡(NIC)和非屏蔽双绞线(UTP)连接时,即使只实现10Mbps的以太网,也可能选择购买10/100Mbps的网卡和5类线。这样做,不更换接口卡和线缆平台就能升级到百兆。
        要想作出具体的技术选择,需要设计者详细考虑每种方法的优缺点。考虑的不同技术类型和重点内容如下。
        ◆物理层。
        ◆网络互联。
        ◆逻辑网络图。
        ◆虚拟网策略。
        ◆现代广域网技术。
        ◆网络管理。
        ◆TCP/IP地址设计。
        ◆网络安全。
        ◆防火墙。
        ◆备选设计。
 
       数据存储
        数据存储用来表示存储数据。通常,一个流入加工的数据流经过加工处理后就消失了,而它的某些数据(或全部数据)可能被加工成输出数据流,流向其他加工或外部实体。除此之外,在软件系统中还常常要把某些信息保存下来以供以后使用,这时可以使用数据存储。每个数据存储都有一个定义明确的名字标识。可以有数据流流入数据存储,表示数据的写入操作;也可以有数据流从数据存储流出,表示数据的读操作;还可以用双向箭头的数据流指向数据存储,表示对数据的修改。
 
       数据库
        数据库(DataBase,DB)是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
 
       系统架构
               客户机/服务器系统
               C/S(Client/Server)结构,即大家熟知的客户机和服务器结构。它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到客户机端和服务器端来实现,降低了系统的通信开销。目前大多数应用软件系统都是客户机/服务器形式的两层结构,由于现在的软件应用系统正在向分布式的Web应用发展,Web和客户机/服务器应用都可以进行同样的业务处理,应用不同的模块共享逻辑组件;因此,内部的和外部的用户都可以访问新的和现有的应用系统,通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
               浏览器/服务器系统
               B/S (Browser/Server)结构即浏览器和服务器结构。它是随着Internet技术的兴起,对C/S结构的一种变化或者改进的结构。在这种结构下,用户工作界面是通过WWW浏览器来实现,极少部分事务逻辑在前端(浏览器)实现,但是主要事务逻辑在服务器端(服务器)实现,形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本(TCO)。以目前的技术看,局域网建立B/S结构的网络应用,并通过Internet/Intranet模式下数据库应用,相对易于把握,成本也是较低的。它是一次性到位的开发,能实现不同的人员,从不同的地点,以不同的接入方式(如LAN,WAN, Internet/Intranet等)访问和操作共同的数据库;它能有效地保护数据平台和管理访问权限,服务器数据库也很安全。
               多层分布式系统(Multi-tier System)
               (1)概念。
               随着中间件与Web技术的发展,三层或多层分布式应用体系越来越流行。在多层体系中,各层次按照以下方式进行划分,实现明确分工:
               ①瘦客户:提供简洁的人机交互界面,完成数据的输入/输出。
               ②业务服务:完成业务逻辑,实现客户与数据库对话的桥梁。同时,在这一层中,还应实现分布式管理、负载均衡、Fail/Recover、安全隔离等。
               ③数据服务:提供数据的存储服务。一般就是数据库系统。
               (2)多层系统主要特点。
               多层系统主要特点是:
               .安全性。中间层隔离了客户直接对数据服务器的访问,保护了数据库的安全。
               .稳定性。对于要求24×7工作的业务系统,多层分布式体系提供了更可靠的稳定性。一是中间层缓冲Client与数据库的实际连接,使数据库的实际连接数量远小于Client应用数量。当然,连接数越少,数据库系统就越稳定。二是Fail/Recover机制能够在一台服务器宕机的情况下,透明地把客户端工作转移到其他具有同样业务功能的服务上。
               .易维护。由于业务逻辑在中间服务器,当业务规则变化后,客户端程序基本不做改动。
               .快速响应。通过负载均衡以及中间层缓存数据能力,可以提高对客户端的响应速度。
               .系统扩展灵活。基于多层分布体系,当业务增大时,可以在中间层部署更多的应用服务器,提高对客户端的响应,而所有变化对客户端透明。
               (3)多层系统举例。
               目前最为流行的两类多层应用架构为Sun的J2EE和Microsoft.Net,下面简单介绍J2EE的多层架构。
               
               J2EE多层应用架构
               (4)客户层。
               客户层用于与企业信息系统的用户进行交互以及显示根据特定商务规则进行计算后的结果。基于J2EE规范的客户端可以是基于Web的,也可以是不基于Web的独立(Stand Alone)应用程序。
               在基于Web的J2EE客户端应用中,用户在客户端启动浏览器后,从Web服务器中下载Web层中的静态HTML页面或由JSP或Servlets动态生成的HTML页面。
               在不基于Web的J2EE客户端应用中,独立的客户端应用程序可以运行在一些基于网络的系统中,例如手持设备或汽车电话等。同样,这些独立的应用也可以运行在客户端的Java Applet中。这种类型的客户端应用程序可以在不经过Web层的情况下直接访问部署在EJB容器(EJB Container)中的EJB组件。
               (5) Web层。
               J2EE规范定义的Web层由JSP页面、基于Web的Java Applets以及用于动态生成HTML页面的Servlets构成。这些基本元素在组装过程中通过打包来创建Web组件。运行在Web层中的Web组件依赖Web容器来支持诸如响应客户请求以及查询EJB组件等功能。
               (6)业务层。
               在基于J2EE规范构建的企业信息系统中,将解决或满足特定业务领域商务规则的代码构建成为业务层中的Enterprise JavaBean (EJB)组件。EJB组件可以完成从客户端应用程序中接收数据、按照商务规则对数据进行处理、将处理结果发送到企业信息系统层进行存储、从存储系统中检索数据以及将数据发送回客户端等功能。
               部署和运行在业务层中的EJB组件依赖于EJB容器来管理诸如事务、生命期、状态转换、多线程及资源存储等。这样由业务层和Web层构成了多层分布式应用体系中的中间层。
               (7)企业信息系统层。
               在企业应用系统的逻辑层划分中,企业信息系统层通常包括企业资源规划(ERP)系统、大型机事务处理(Mainframe Transaction Processing)系统、关系数据库系统(RDMS)及其他在构建J2EE分布式应用系统时已有的企业信息管理软件。
 
       业务层
        作为满足某个特定业务领域(如银行、零售或金融业)需要的业务逻辑代码由运行在业务层的EJB(Enterprise JavaBean)来执行。一个EJB从客户程序处接收数据,在需要的情况下对数据进行处理,再将数据发送到企业信息系统层存储。一个EJB还从存储中检索数据,并将数据送回客户程序。运行在业务层的EJB依赖于容器提供诸如事务、生命期、状态管理、多线程及资源缓冲池等十分复杂的系统级功能。业务层也称EJB层。
        业务层和Web层一起构成了J2EE应用的中间层。
   题号导航      2025年下半年 系统架构设计师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第4题    在手机中做本题