民航气象数据库系统是一个24小时连续运行的、规模庞大的实时联机气象信息系统。它是由北京等几大气象中心以及若干个空管中心、站气象数据库系统组成的分布式数据库系统。它集数据上传、分发、监控、共享等于一体，对民航气象所需资料进行整理和分析，在保障航空飞行安全上有着极为重要的地位和作用。在民航气象数据库系统中，气象资料入库是尤为关键的一步，所有数据经过传输后最终都要分类进入各级数据库中，资料共享亦须通过数据库提取。本文主要针对“站”一级别的气象资料入库进行分析和讨论。
本站所属的气象数据库系统由通信机、数据库分系统DB00、DB01及若干网络通信设备组成。“气象资料入库”指的是气象资料（报文、产品）在通过上级转发到本地通信机后，进入数据库分系统DB00和DB01并存储的过程。在此存储过程中，通信机和DB00、DB01之间通过MQ或FTP的方式传递气象信息，其中MQ为主要传输方式。
针对气象数据库资料无法入库，通常按照如下步骤进行分析和排查：
1MQ传输问题
由于MQ的通讯是建立在系统网络运行正常的基础之上的，为保障其顺利运行，首先要检查网络连接是否正常。可以使用ping命令，也可以采用FTP方式，在两个主机之间尝试进行数据传输，以判断网络是否正常；使用tracert命令对网络通信节点进行逐级排查。其次，检查队列、通道的运行状态。
1）查看MQ队列管理器状态：dspmq，正常状态应显示：Running；启动方法为：strmqm。
2）查看通道状态：showchl，正常状态应显示：Running；
2.4磁盘空间使用率过高影响进程启动
定时检查DB00、DB01中/home磁盘空间使用率，如使用率超过70%，易导致重要进程如awos、cac等无法启动。可以使用dfm命令查看磁盘空间使用率，当/home使用率超过70%时，移除/home/mhdbs/data/backup文件夹中的归档文件；如发现awos、cac等进程在经上述处理后仍无法启动，/home/mhmdbs/
3.1通信机系统
4系统其他配置文件问题
针对大部分气象资料入库正常，而仅有某类资料无法入库的情况，可以从存储于通信机中的控制数据BSB（公报说明块）中查找原因。
控制数据BSB用于决定气象公报的处理原则，需要通过extract_bsb命令对其进行提取，使用vi命令编辑完成后，再用make_bsb命令对其进行编译使用。在BSB中，参数channel_X
（X为1、2……）对应的线路号指明了转发地址。当转发地址不正确或者不完全时，会导致气象资料因地址缺失而无法正常转发或入库。
线路号存储于通信系统软件的环境参数文件mssini.ini中，用ldt命令可以进行查看与对照。线路号与转发地址一一对应，在进行配置文件检查时，先查明此类气象资料需转发到哪些地方（如机场、本地数据库等），再用ldt命令查看与转发地址相对应的线路号，然后查看BSB中是否写有所需的线路号，如有缺失，需用vi命令编辑补齐，各个线路号之间用“空格”分开。
参考文献：
[1]刘竹涛，《科技风》，河北省科学技术协会，2009.17.
关键词:异构多数据库;集成技术;模式消解;查询处理;事务处理
ExploretheIntegrationofHeterogeneousMulti-databaseSystemTechnology
CHENFei
Abstract:HeterogeneousMulti-DatabaseIntegrationSystemisadatabaseresearchinthefieldhotanddifficultissues.Thisarticlefirstintegrationofheterogeneousmulti-databasesystemdesign,andtofurtherexploretheimplementationofthesystemintegrationtechnology,involvingdigestionpattern,queryprocessingtechnology,andtransactionprocessingtechnology.
Keywords:Heterogeneousmulti-database;integrationtechnology;modeldigestion;queryprocessing;transactionprocessing
1异构多数据库系统的集成设计
1.1异构多数据库的体系结构
异构MDBS的体系结构如图1所示。
异构MDBS本身是一种Client/Server结构,多个异构MDBS的Client与MDBS交互作用,用户可以通过异构MDBS对多个LDB进行存取操作。异构MDBS管理所有全局数据库的控制信息,包括全局模式、全局事务的提交和控制等。每一个LDB通过一个驱动器(Driver)与MDBS连接,这个驱动器与LDB在一个站点上,异构MDBS与驱动器之间的通信构成一个通信子层CSS(CommunicationSubsystem)[1]。从异构MDBS的体系结构可以看出,异构MDBS对LDB没有做任何改动,因此LDB上的用户还可以对LDB进行直接访问,LDB上原来的应用程序还可以直接运行于LDB之上。
1.2集成设计的关键技术
建立异构多数据库系统的集成时经常遇到的一项十分棘手的工作便是整合用户原有的一些应用系统,而这些旧的应用系统往往是建立在异构的数据库基础之上。
首先,为给用户提供一个统一的存取模式,在异构MDBS中只保留一个供用户查询及修改的全局数据模式,而这个全局模式是由各个异构的LDB数据模式通过模式消解得到的,这就是异构多数据库系统集成中的模式消解技术。
其次,在异构MDBS中采用统一的全局查询语言,因此需要把全局查询语言分解和转换为相应的LDB查询语言交于LDB执行,然后合并各LDB查询结果以产生最终的用户查询结果,这就是异构多数据库系统集成中的查询处理技术。
另外,由于异构MDBS中的事务是被分解为多个子任务,并由各LDB分别执行相应子任务来完成的,因此在异构MDBS中,存在着如何保持全局事务的可串行化执行、全局事务的原子性及各个LDB之间的数据一致性等问题,即异构多数据库系统集成的事务管理技术[2]。
2异构多数据库系统的集成实现
2.1模式消解技术
模式消解的目的是将一组不同的LDB模式转换成一个统一的全局模式,通过对一组模式施行一组函数来实现的。其中每一个函数将一种LDB模式转换成统一的模式。
消解可以通过重命名实体和属性的方法来实现,该方法所解决的是实体命名和属性命名的冲突,即在不同的LDB中,相同的概念有不同名称或不同概念有相同名称时出现的冲突。该方法是在异构MDBS中建立一个MDBS与LDB之间名称对应关系的目录。也可以通过一致化表示和属性一致化来实现,一个实体是由一系列属性组成的,类似地,虚类也是由一系列属性组成的,它的成员查询部分决定了一个虚类的实现方法,每一个成员查询对应一个LDB中的实体与异构MDBS中虚类的对应关系。因此每一个LDB中实体的属性都要转换成异构MDBS中相应的虚类的属性。
2.2查询处理技术
异构MDBS中的查询处理主要包括查询分解、查询转换。在异构MDBS中,用户可以根据全局模式用全局查询语言对多个LDB同时进行查询。一个全局查询一般要经过三步处理:
1)把全局查询分解成多个子查询,每一个子查询对应一个LDB中的数据,分解后的子查询仍用全局查询语言表示的。
2)每一个子查询都转换成相应的LDB的本地查询语言并递交到相应LDB中执行。
3)子查询的结果返回并组合成最终的查询结果。
不同的查询分解对应不同的系统性能,为达到优化系统性能的目的,还需要全局优化器和本地优化器。一个全局查询的开销是各个LDB查询的开销加上后处理的开销再加通信开销。
2.3事务处理技术
一个MDBS是建立在多个分布异构多数据库之上的,它为用户提供一个统一的存取数据的接口,其中的每一个LDB都是自治的,由一个本地的DBMS来管理,它的局部事务不为MDBS所知,因此在MDBS中保持事务的一致性和原子性是非常困难的。
由于LDB上的局部事务不受GTM的控制,所以GTM只能控制全局事务的执行顺序。但在某些情况下,即使全局事务严格串行执行也不能保证全局的可串行化,如下例:
设有两个站点Sl、S2,Sl上有数据a和b,S2上有数据c和d。T1和T2是两个只读的全局事务:
T1:r1(a)r1(c)
T2:r2(b)r2(d)
另外还有T3、T4分别为S1、S2上的局部事务:
T3:w3(a)w3(c)
T4:w3(b)w3(d)
虽然已经严格保证了全局事务Tl、T2的顺序执行,但是从执行结果上来看却是这样的:Sl上的执行顺序为T1、T3、T2,而S2是执行顺序为T2、T4、T1,在这种情况下,全局事务的可串行性没有得到保证。上面的主要问题在于局部事务与全局事务发生了冲突,但是由于GTM不知道局部事务的执行情况,因此也无法发现这种冲突,这是异构MDBS中控制全局事务可串行化执行所面临的主要问题。
为了避免出现上面的情况,可以采用不允许无冲突的事务(如T1、T2)在相同的站点上执行的方法。主要思想是GTM在每一个站点上只运行相互之间有冲突的事务,如果两个要在同一个站点上执行的事务之间没有冲突,则GTM对它们进行修改使之产生冲突。一种可行的方法是在每一个站点上设一个特殊的数据,称之为令牌,使无冲突的两个全局事务在令牌上发生冲突。每个LDB上只有一个令牌,不同的LDB上的令牌不同,只有全局事务才可以存取令牌。每一个站点上执行的事务都要执行读令牌和写令牌操作,这个令牌数据的读写操作保证了全局事务的可串行化执行。
3结束语
总之,基于单一数据库产品开发的系统已经难以适应新应用的需要,许多应用不可避免地涉及多个不同异构数据库系统,需要联合使用。对于用户而言,面对所有这些复杂的分布异构特性,他们希望屏蔽掉各种层次的异构特性,他们不必知道各物理数据库系统的分布及数据库的结构组成和操作方法,也不必自己去进行数据转换和结果汇总,只需通过简便的全局访问方法得到一个综合结果,这就是异构多数据库集成技术的主要研究内容,也是其意义所在。
参考文献:
关键词：数据库；数据库系统；分布式；分布式数据库；安全
AnalysisofSecurityStrategyonDDBS
JIANGWen-bin,ZHANGRen-jin,ZHANGFang-xia
(GuizhouNormalUniversityMathematicandComputerInstitue,GuizhouNormalUniversitythemulti-mediaComputerAssistedInstructionInstitue,Guiyang550001,China)
Abstract:AsthecombinationofcomputernetworkanddatabasesystemDistributedDatabaseisbecomingthesharecenterofinformationresourceintheInternetsituationanditssecurityisveryimportant.AimingatthesecurerequestsofDistributedDatabaseSystem,onthebaseofanalysingsystemframeandpossibleattacking.Itdiscussesuserauthentication,secretcommunication,accesscontrol,contentciphertext,cryptosystem,keyanddistributedaffairmanagement,audittrack,faultrepairinthesecuritypoliceandsecuritymechanism.
Keywords:database;databasesystem;distributed;distributeddatabasesystem;security
Internet的高速发展推动着分布式数据库的发展，另一方面它也增加了分布式数据库安全问题的复杂性。如何保证开放网络环境中分布式数据库系统的安全是一个复杂的问题，需要进行认真分析研究。分布式数据库面临着两大类安全问题：一类安全问题研究抗击单站点故障、网络故障等自然因素故障，即研究在发生了障时如何使系统仍能可靠运行或从故障中恢复。另一类安全问题研究抗击来自于本机或网络上的人为攻击，即研究在有黑客攻击时如何保证库存数据和通信报文的保密性和可靠性。数据库最突出的特点是之一是数据共享，数据共享给数据库应用带来了众多的好处；但给数据库特别是网络化的开放环境与基于网络的分布式数据库系统的安全带来了严重的问题，如何保证分布式数据库的安全问题己经成为数据库领域的重要课题之一。
1分布式数据库构建与应用概述
1.1分布式数据库的定义和特点
分布式数据库系统是由若干个站集合而成，这些站（节点）在通讯网络中互联在一起，每个站都拥有各自的数据库、中央处理机，以及各自的局部数据库管理系统，因此分布式数据库系统可看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构上是分散的。分布式数据库系统使用计算机网络，将地理位置分散，而管理又需要不同程度集中的多个逻辑单位（通常是集中式数据库系统）联接起来，共同组成一个统一的数据库系统，因此分布式数据库系统可以看成是：计算机网络与数据库系统的有机结合。它应该具有如下的特点：
1)物理分布性：分布式数据库系统中的数据不是存储在一个站点上，而是分散存储在由计算机网络联结起来的多个站点上。所以分布式数据库系统的数据具有物理分布性，这是与集中式数据库系统的最大差别之一。
2)逻辑整体性：分布式数据库系统中的数据物理上是分散在各个站点中，但这些分散的数据逻辑上却是一个整体，它们被分布式数据库系统的所有用户(全局用户)共享，并由一个分布式数据库管理系统统一管理。这是分布式数据库的“逻辑整体性”特点，也是与分散式数据库的最大区别。区别一个数据库系统是分散式还是分布式，只要判断该数据库系统是否支持全局应用（数据在逻辑
上统一管理，在物理上分散存储）。因此，分布式数据库系统中就有了全局数据库(GDB-GlobalDatabase)和局部数据库(LDB-LocalDatabase)的概念。全局数据库由全局数据库管理系统进行管理，所谓全局是从整个系统角度出发研究问题。局部数据库由局部数据库管理系统进行管理，所谓局部是从各个站点的角度出发研究问题。
3)站点自治性：站点自治性也称场地自治性，各站点上的数据由本地的DBMS管理，具有自治处理能力，完成本站点的应用(局部应用)，这是分布式数据库系统与多处理机系统的区别。
1.2体系结构图
图1为体系结构图。
1.3分布式数据库运行过程
2分布式数据库系统的主要安全隐患
对于分布式数据库安全问题扩展地来说，应该保障数据库数据的完整性，包括数据的物理完整性、逻辑完整性和元素完整性；保障数据库数据的保密性：身份鉴别、推理防范、数据库系统的可审计性等；保障数据库数据的可靠性，就是防止和减少因为软、硬件系统的错误所造成的数据库恶性破坏，和及时修复软、硬件系统的错误所造成的数据库恶性破坏。对于第一类由单站点故障、网络故障等自然因素引起，这类故障通常可利用网络提供的安全性来实现安全防护，所以说网络安全是分布式数据库安全的基础；对于另一类来自本机或网络上的人为攻击，主要有：
1)黑客的攻击：为了窃取数据或扰乱系统正常运行，黑客对分布式数据库系统主要采取以下攻击方式：
窃听：黑客在网络信道上监听客户-数据库服务器或服务器-服务器之间的报文来窃取数据。
重发攻击：黑客把窃听到的报文又重发给客户或服务器，重发的报文或保持原样或做了修改，以扰乱系统正常运行甚至修改数据库中数据。重发攻击可以是针对站点间的数据通信过程，也可以是针对站点间的身份验证过程。
假冒攻击：黑客可以发送报文使客户或服务器通讯端口堵塞，然后再假冒该客户或服务器扰乱分布式数据库系统内其它站点的正常运行甚至非法访问数据。
迂回攻击：黑客利用网络协议、操作系统的安全漏洞绕过分布式数据库系统直接访问数据库文件。在上述各种过程中，为了实施更有效的攻击，黑客往往还借助于破译工具，采用密码分析方法对得到的密文进行解密或纂攻。
2)计算机病毒的攻击：病毒的种类迅速增加，病毒的机制越来越复杂化，破坏性和攻击性越来越强。
3)网络安全环境的脆弱性：包括操作系统安全的脆弱性，数据库管理系统安全的脆弱性，网络协议的脆弱性等。
3解决分布式数据库安全问题的关健技术
如何保证开放网络环境中分布式数据库系统的安全是一个非常复杂的问题，需要进行认真分析研究。针对上述开放式网络环境下分布式数据库系统的安全隐患，总结解决这些问题的身份验证、保密通信、访问控制和审计、库文加密、密码体制与密钥管理、分布事务管理和故障恢复等关键技术。
3.1身份验证
3.2在通讯双方之间建立保密信道
保密通信客户一服务器、服务器一服务器之间身份验证成功后，就可以进行数据传输了，为了对抗报文窃听和报文重发攻击，需要在通讯双方之间建立保密信道，对数据进行加密传输。在分布式数据库系统中，由于传输的数据量往往很大，加解密算法的速度对系统性能影响也就大，而非对称密码体制运算复杂、速度慢，对称密码体制速度快，所以一般采用对称密码算法来进行加解密。因此，建立保度信道的过程就是约定会话密钥，用会话密钥来加解密数据的过程。通常这一过程也可以和身份验证结合在一起。
3.3访问控制和审计
3.4库文加密
在分布式数据库系统中，为了对抗黑客利用网络协议、操作系统安全漏洞绕过数据库的安全机制而直接访问数据库文件，有必要对库文进行加密。只要保管好密钥，并且加密算法具有一定的强度，即使黑客得到了数据库文件，他们也难以知道明文，这样使得重要数据受系统安全漏洞因素的威胁减小。
3.5密码体制与密钥管理
在分布式数据库系统中，身份验证、保密信道、库文加密等都用到加解密算法，但是它们的应用背景是有区别的：身份验证仅需传输少量控制信息；保密通信除了传递少量控制信息外，通常还传递大量的数据信息；库文加密涉及不同粒度的数据对象，而且还要考虑数据库的插人、删除、更改数据密钥等操作。
3.6全局视图机制
和集中式数据库一样，分布式数据库环境中同样可定义视图，实现数据的独立和安全性，这是，视图的作用更加显著，因为分布式数据库非常大而且复杂，用户数目也非常大。利用视图，可以将用户分组，只向用户提有关数据。
3.7安全审核
3.8分布事务管理
在分布式数据库系统中，分布事务管理的目的在于保证事务的正确执行及执行结果有性主要解决系统可靠性、事务并发控制及系统资源的有效利用等问题。分布事务首先要分解为多个子事务到各个站点上去执行，各个服务器之间还必须采取合理的算法进行分布式并发控制和提交，以保证事务的完整性。
3.9故障恢复
在数据库系统中尽管采取了很多措施和手段保证数据库系统的正常运行，然而计算机系统中的软、硬件的故障及操作的失误和人为的破坏仍是不可避免的，这经常造成数据库不能正常的执行，出现错误，数据的全部或部分遭到破坏。因此数据库系统必须具有把数据库系统从故障状态恢复到一个已知的正确状态。分布式事务的两段提交协议(2PC协议)是一种用于故障恢复的方法，在系统运行日志无丢失的情况下，对任何故障均有一定的恢复能力。
4结束语
[1]邵佩英.分布式数据库系统及其应用[M].北京:科学出版社,2005.
[2]鞠海玲,宁洪,郑若忠,等.分布式数据库安全关键技术[J].微型电脑应用,1999,15(9):6-8.
[3]鞠海玲,宁洪,郑若忠,等.分布式数据库安全机制[J].计算机工程与应用,2000,36(3):98-100.
[4]郑振媚,于戈,郭敏.分布式数据库[M].北京:科学出版社,l999.
[5]吴江,李太勇,吴晓知.分布式数据库系统中的安全策略研究[J].网络安全技术与运用,2006,2(4):98-102.
[6]BrinkKnight.SQLServer2000forExperiencedDBAS[M].北京:清华大学出版社,2003.
【关键词】民航气象数据库
一、引言
呼伦贝尔机场民航气象数据库系统，主要由数据库服务器、WEB应用服务器、通信服务器、预报平台工作站，监控终端等组成，软件主要有AIX操作系统、LINUX操作系统、ORACLE数据库、MQ通信中间件等。该系统自2008年5月运行，设备运行稳定可靠，系统故障较少。但在实际使用过程中，也出现过无法进行数据交换的故障，下面笔者对以下两例故障进行分析。
二、常见故障及维修
2.1网络传输设备故障
故障现象：2013年11月7日，值班人员发现数据库中资料不能及时更新，中心交换服务器有大量消息积压且通道章台显示为Running，MQ消息传输延时较长。
故障分析及处理过程：值班机务员仔细查看交换机、路由器、基带猫工作指示灯显示正常，使用ping命令测试到民航华北气象中心的传输链路通信质量，发现ICMP丢失现象比较频繁。检查DB00、DB01服务器传输正常。联系气象中心确认对方交换服务器运行正常，可以排除对方数据库故障的情况。联系本单位技术保障部们=门检查更换传输线路，确认本地线路正常。联系网络公司确认北京至本地的数据传输正常，这样可以排除北京至本地网络线路故障的可能性。联系北京网控中心临时更换ATM传输端口，确认ATM网络数据传输正常。这样故障点初步判断在路由器、交换机、基带猫三个方面，通过监控终端ping通信机、及服务器不存在丢包现象，所以交换机可以排除。更换备用路由器，故障依旧。所以初步判断故障点应该在基带猫，由于基带猫没有备件，拆开基带猫后，检查Modem电源模块输出电压不稳，经过抢修以后更换电源模块，数据链路恢复正常，丢包现象消失，MQ消息传输正常。
2.2通信机故障
故障现象：2015年7月12日，14：50分左右，值班机务员发现通过CMTS客户端发现无法清除AB报，ping北京服务器及本地服务器均正常；使用telnet命令无法登陆通信机。在19：30左右，再次出现以上情况，重启恢复；在24：00左右再次出现以上情况。
故障分析及处理过程：根据以往处理经验，由于硬盘满，无法提供存储空间及程序运行空间，易出现类似情况，重启通信机后，设备恢复，通过查看硬盘空间，硬盘空间充足。
2.3报文的转发
故障现象：2015年8月10日，本场数据库无法收到其他机场的气象情报。08：05（北京时）预报员通过在蓝波终端发请求报的方式请求所需的实况及预报报文。值班机务员在设备巡视中，发现民航气象数据库系统MQ线路转发了某地机场的气象情报，值班机务员立即进行排查。
故障分析及处理过程：机务员通过对通信系统$HOME/COMM/history/的留底文件进行检查，确认了请求报所请求的报文被通过MQ线路所转发。为了进一步分析转发的原因，仔细对通信系统BSB控制数据进行检查，检查结果正常，控制数据无误，在存储转发参数设置为N。对数据库系统各个进程进行检查，检查结果正常，对转报机蓝波终端软件进行检查，发现发送的RQM请求报的请求地址包含本地地址。
蓝波终端发送RQM请求报：报文内容如下：
GGZBBBYPYX，ZBBBYZYX，ZNNNYMYX，
RQM/SAZXXX，ZMMMFC=
请求地址为：ZBBBYPYX，ZBBBYZYX，ZNNNYMYX，发送请求报时，错误增加本地数据库请求地址，红色字体部分。故障原因分析为本地数据库收到请求报后，将本地数据库ZXXX、ZMMM最新时次报文收集，以公报形式附加本地报头发送到转报机，转报机收到报文后，再次将报文发送至ZNNNYMYX（本地数据库），数据库系统收到的这份报，由于报头是本地的报头，并且时次是最新的，于是数据库系统做存储转发处理，通过MQ线路，转发至华北地区气象中心民航气象数据库。
三、小结
对于维修人员来说，设备出现故障之后要沉着冷静分析，平时多看业务维修手册，对系统有整体的把握，熟悉数据的处理流程，有利于快速判断故障点，分析故障原因，必要时向厂家寻求技术支持，可达到事半功倍的效果，要善于对故障进行记录、归纳、总结。通过实践的学习，经验的积累，这样就可以快速的解决设备故障，为维修带来方便。从而保证设备的正常运转，充分发挥设备的作用。
基于广域网的数据库访问带来的非法访问、黑客攻击、数据的截取、篡改等安全问题，在传统的数据库访问方式中加入加密和认证安全技术以及防火墙技术，形成新的数据库访问结构。而新加入的模块以的形式在起作用。从而达到安全访问数据库的目的。
一、数据库安全访问系统结构
数据库安全访问用来提供用户身份认证和数据库访问服务并提供了网络传输加密服务。所有的客户方的数据库访问请求都通过数据库安全访问进行转发。客户方数据访问用于接收所有的客户应用数据库访问请求(包括数据库客户的连接建立和连接断开请求)，并负责向数据库客户传送数据库访问的结果。数据库访问请求是按照协议格式化为数据报提供给数据加密/认证客户端，而数据库访问结果是按照协议
格式由数据加密/认证客户端提供。数据加密认证客户端完成客户端的数据加密和认证工作，同服务器端的数据加密/认证服务器一起完成强大的数据加密功能保障数据安全。数据加密/认证服务器接收通过广域网(或者是局域网)传输的客户端发出的数据库访问请求数据报，这个请求是经过数据加密/认证客户端加密的。解密后的数据传递给数据库访问服务器。然后将数据库访问服务器返回的结果加密通过网络回送客户端。
二、安全访问的作用
1、安全访问的中间件特点
数据库安全访问处在应用和数据库之间，起一个数据库中间件的作用和结构。可以在系统中，对数据库的访问请求进行控制管理，配合数据库的特点，达到发挥最大数据库性能的目的。
2、安全访问的作用
之所以称为是因为系统接收数据库应用的数据库访问请求，把请求映射到系统对于数据库的访问，而系统不对这些请求进行过于复杂的处理。而数据库系统可以只接受的访问请求，起到隔离和安全保护作用。另一个重要特点是，可以加入到己经开发应用的信息系统中，极大提高原有系统的安全性能而不需要重新开发。
3、安全访问的防火墙作用
现在网络的一个现状是黑客的攻击广泛存在。后果是窃取信息、使系统瘫痪或者造成网络堵塞。数据库安全访问可以起应用级网关类别的防火墙作用，服务器而不是数据库暴露在广域网中，对数据库的访问都是通过服务器来完成。防火墙是网络安全的屏障，一个防火墙（作为阻塞点、控制点）能极大地提高一个内部网络的安全性，并通过过滤不安全的服务而降低风险。
三、安全访问系统采用的技术
1、安全访问系统采用SSL加密认证技术
为了保护敏感数据在传送过程中的安全，全球许多知名企业采用SSL（SecuritySocketLayer）加密机制。SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，适用于商业信息的加密。
系统中的数据加密和身份认证及签名采用SSL技术来完成，系统中的数据加密和身份认证及签名采用SSL技术来完成。应用程序通常使用IPC(InterporcessCommunicationsFacility)与不同层次的安全协议打交道，在不同传输层协议中工作。
2、安全访问系统形成多层结构
为了克服由于传统客户/服务器模型的这些缺陷给系统应用带来的影响，一种新的结构出现了，这就是三层(N层)客户/服务器模型。三层客户/服务器结构构建了一种分割式的应用程序。主要分为三层:用户服务层，业务处理层，数据服务层。系统中由于安全访问的加入而形成多层结构，安全形成独立的一层，与其它层通过标准的数据库访问接口，这就提供了极大的灵活性，这也很大程度上降低了数据安全访问的设计复杂性。
3、安全访问系统采用ODBC技术
(OpenDatabaseConnectivity，开放数据库互连)是微软公司开放服务结构(WOSA，WindowsOpenServicesArchitecture)中有关数据库的一个组成部分，它建立了一组规范，并提供了一组对数据库访问的标准API（应用程序编程接口）。
ODBC之所以能够操作众多的数据库，是由于当前绝大部分数据库全部或部分地遵从关系数据库概念。ODBC基本思想是提供独立程序来提取数据信息，并具有向应用程序输入数据的方法。ODBC接口的优势之一为互操作性，程序设计员可以在不指定特定数据源情况下创建ODBC应用程序。
4、安全访问系统对于应用的透明性
对于应用的透明性是指对应数据库应用来说，采用或者不采用数据库安全访问，对于数据库的访问方法没有区别。对应用的透明性是通过采用标准的数据库访问技术来达到的，数据库应用的每一个数据库访问操作经过访问系统映射为同样的数据库访问实施于数据库，对API调用进行一对一的映射，所以原来开发系统不需要改动。也为系统的方案设计提供了灵活性。