嵌入式移动数据库中的移动Agent问题探讨

嵌入式移动数据库中的移动Agent问题探讨

Research of Mobile Agent Used In Embedded Mobile Database

（桂林工学院电子与计算机系）邹明亮程小辉刘亚荣

Zou,Mingliang Cheng,Xiaohui Liu,Yarong

摘要：随着互联网络技术和无线通信技术的发展，嵌入式移动数据库技术已成为目前数据库领域的一个新的研究分支，文中对移动Agent技术进行了概要说明，在此基础上讨论了将移动Agent技术应用于嵌入式移动数据库中的优势，探讨了基于移动Agent的嵌入式移动数据库的体系结构以及将移动Agent引入后它的研究侧重点。

关键词：移动Agent；体系结构；移动数据库

中图分类号：TP311.13 文献标识码：A

Abstract: With the development of network and wireless communication technologies, embedded mobile database has become a new research branch in database field. This article studies something about mobile agent, on this base discusses some advantages of the mobile agent used in the embedded mobile database. They are also discussed that the architecture of embedded mobile database and its research focus after mobile agent is used.

Key words: mobile agent; architecture; mobile database

1 引言

随着移动通信技术的迅速发展以及移动计算终端的大量普及，使得人们随时随地访问任何所需信息成为可能。对于传统的分布式计算以及分布式数据库的研究都是基于有线网络和固定主机的，采用了一些如固定网络连接、对等通信代价、主机结点固定不变等默认的隐含假设。若计算结点在自由移动的过程中与网络建立连接，则上述这些假设条件不再成立，由此需要一种更加复杂、灵活的分布式计算环境，因此研究移动计算以及移动数据库成为一个新兴的热点领域。

移动Agent作为一种前沿技术，也是计算机领域的一个研究热点。近年来国内外对移动Agent技术研究的投入都非常大，并且在移动Agent的并行计算、移动Agent系统安全、多Agent建模等方面都有突出成果。移动Agent作为一种可携带执行代码和数据的迁移对象，带有一定的智能性，能够自主结合客户机和服务器的知识，并在服务器上进行推理以确定自己的下一步工作。其次移动Agent对于用户没有实时网络连接的要求，仅仅是在发送请求和接受结果时需要网络连接，可以大幅减少无线通信网络上的通信流量，基于移动Agent具有的这些优势，在嵌入式移动数据库中引入移动Agent技术并进行研究探讨，具有一定的价值。

2 移动Agent技术

移动Agent是一个代替人或其它程序执行某种任务的程序,它在复杂的网络系统中能自主地从一台主机移动到另一台主机[1],该程序能够选择何时、何地移动，在移动时该程序可以根据要求挂起其运行,然后转移到网络的其它地方重新开始或继续执行,最后返回结果和消息。移动Agent具有自治性、移动性、智能性、异步计算性等特性。

从实现技术的角度看,移动Agent系统主要由移动Agent平台(MAE)和移动Agent(MA) 组成。移动Agent平台是一个虚拟机,通常被称为移动Agent服务器,为移动Agent的移动和执行提供执行环境，为移动Agent的发射、接收、恢复、安全管理和服务调用等提供基础设备设施。移动Agent携带完成计算任务所需的代码和数据以及Agent的运行状态，在网络上

不同主机之间迁移并完成相应的动作，移动Agent迁移示意图如图1。

将移动Agent技术应用于嵌入式移动数据库主要具有如下一些优势：

1）移动Agent可以减少通信网上的流量。将任务请求通过Agent移动到服务器端执行，使得Agent不经过网络传输这个中间环节而直接访问服务器资源，任务在远地执行完后直接返回结果，从而降低系统对网络带宽的依赖，这恰好适合移动计算环境所具有的断接性的特点；2）移动Agent可以异步计算。移动Agent不需要统一的调度，由用户创建的移动Agent 可以异步的在不同网络节点上运行，对于相对复杂的任务，用户还可以创建多个Agent，同时在相同或不同的节点上运行，不需要客户端与主机永久连接。也恰好适合移动计算环境所具有的低带宽和弱可靠性的特点；3）移动Agent可以方便的访问异构数据库。在数据库系统中存在一些异构的环境，此时如果采用传统的数据库访问方式，往往需要客户端预先安装多种类型的数据库连接驱动程序，并在访问时执行这些连接驱动程序，这会大大增加移动终端的负载[2]，因此，传统的数据库访问方式很难适用于移动计算环境中移动数据库的访问，但由于移动Agent本身的特性却使得访问异构数据库较其他方式更加方便；4）移动Agent 可以方便的实现负载平衡。移动Agent能携带自身的代码从一个平台移动到另一个平台，在目的主机上也无需预先安装就能运行，因此移动Agent可以方便的实现负载平衡。

3、基于移动Agent的移动数据库的体系结构

传统的基于Agent的移动数据库的体系结构一般采用如图2所示的客户层、客户Agent 层、服务器Agent层、服务器层的体系结构，该结构能对移动数据库的数据复制与缓存、断接期间的管理、减少客户与服务器之间的通信量等方面都能提供有效的支持。但该体系结构对于服务器之间的协同工作、客户端在网络中的自由移动等方面不能提供理想的支持，对此，本文采用一种更加灵活的体系结构。该体系结构对传统的基于Agent的移动数据库的体系结构模型进行扩充，在客户机和服务器之间加入一个新的层次移动Agent层。如图3所示。

其中客户Agent层主要负责本地缓存以及本地事物的管理；移动Agent层根据客户Agent 提出的任务请求完成相应的功能并返回结果；服务器Agent主要负责提供数据访问接口。基于移动Agent的移动数据库的体系结构可设计成如图4所示。

图2

图3

图1

注: MSS: Mobile Support Station(具有无线通信接口的支持移动计算机的固定节点) SVR: Server(固定主机) LDB: Local Database(本地数据库)

MA: Mobile Agent (移动代理) MC: Mobile Client(移动客户)

4 基于移动Agent的嵌入式移动数据库的研究侧重点

1）移动Agent的协同。移动Agent具有自主性，同时也具有协作性，能够相互合作，从而高效透明的使用网络上的资源[3]。通常各种数据资源存储在各个不同的网络节点上，随着数据库技术的发展，很多应用都涉及到访问不同位置的数据库，对此，用户可以创建多个Agent，让其分散到网络的多个节点上去执行，当多个移动Agent共同完成一个任务时，Agent 之间需要进行通信，移动Agent系统可采用的通信方式有很多，比如RPC，RMI等，在具体的代理系统中，通信的实现方式则有很大的差别。如：Cornell大学的Tocama通过一个携带数据的briefcase来交换数据；General Magic公司的Telescript中Agent只能在会话点中用本地方法调用的方式相互通信；Dartmouth学院的D’Agent既支持底层的基于字节流的消息传递方式，也支持基于Agent层次的高层通信方式。

2）移动Agent的重定位。移动Agent在完成客户Agent所提出的任务时，由于所需的资源可能分布在网络不同的节点上，Agent需要在网络中移动。在移动数据库系统中，移动客户端的位置通常不断发生变化，这时，Agent也需要根据移动客户端的位置重新在网络中进行定位，从而缩短与移动客户端的距离，达到减少通信时间以及网络通信开销的目的。对于移动Agent的重定位方法可以采取如下方式：（1）通过使用位置服务器。当移动Agent 创建时，在相应的位置服务器中注册当前位置，当移动Agent发生位置变化时，要在位置服务器中更新自己的位置信息，要定位所需的移动Agent通过向位置服务器查询即可。（2）通过跟踪移动Agent的移动路径。移动Agent迁移时，记录下移动Agent的迁移路径，从而可以根据路径来定位所需的移动Agent。（3）通过发送广播消息，采取与局域网中ARP协议类似的方法，向系统内所有节点发送广播消息，由符合的条件的移动Agent发回响应消息。

3）并发操作的控制。嵌入式移动数据库在实际应用中必须解决好数据的一致性[4]，在移动数据库系统中，有时存在多个Agent并发访问共享信息的情况，为了保证数据的一致性，需要对并发操作进行正确的控制，目的是为了避免出现使数据处于不一致状态的并发事物调度。在基于移动Agent的系统中，既要维护本地数据库系统的一致性，也要维护网络节点上数据库系统的一致性。并发控制可以借助DBMS本身的功能来完成，因为目前一般的数据库管理系统都有较好的并发控制功能，同时也可借助一些开发工具来实现并发控制。相对于

传统的数据库系统，Agent并发控制相对较复杂，可能存在网络节点上的数据库不完全接受Agent的控制、本地数据库与网络节点上的数据库之间存在相互约束关系等一些影响因素。

4）故障的恢复。在基于移动Agent的移动数据库系统中，故障恢复较传统的数据库系统也相对复杂一些，需要恢复网络节点上的各个数据库中的数据、恢复每个Agent的本地数据以及运行时的环境。对于网络节点上的各个数据库以及每个Agent的本地数据的故障恢复可以借助DBMS本身的功能来完成。对于Agent运行时的环境的恢复可以通过专门为对应的Agent新建一个数据库来维护运行时的环境，当Agent需要对数据进行更新操作时，先更新在为其新建的那个数据库中，当整个事物完成时再提交数据给本地数据库。

5 结束语

针对移动数据库具有的移动性、断接性、网络条件多样性、网络通信的非对称性、移动计算机的弱电源能力等特性，将移动Agent技术引入到移动数据库中，移动Agent计算模式能有效的减少网络通信流量、减少访问服务器的延迟、支持断接操作、支持异步计算等，使得移动Agent的优点得到了很大的发挥，有助于实现移动数据库的各种操作。由于移动Agent 技术本身还处于发展过程中，应用移动Agent来完善移动数据库技术还有待于更加深入的研究和探索。

本文作者创新点：

鉴于在分布式数据库中使用的多层架构技术在访问量大的情况下能较好的适应数据库的各种操作，笔者在移动数据库中借鉴其相关技术同时利用了移动Agent的特点，并对由此产生的部分问题探讨了其初步的解决方式。

参考文献：

[1] 朱淼良，邱瑜.移动代理系统综述[J]，计算机研究与发展，2001，38（1）：16-25.

[2]王彤，王良. 移动计算中基于Mobile Agent的数据库访问技术，小型微型计算机系统，2002，23（10）：1165-1168.

[3] 刘振鹏等.基于协同式移动Agent分布式数据库系统研究[J], 计算机工程与设计, 2004，24（11）：10-12.

[4] 牛立新，关永，刘旭敏. 嵌入式移动数据库研究, 微计算机信息， 2006，第22卷第1-2期，85-87页转251页

作者简介：邹明亮，男，1977年6月，汉族，湖南邵阳人，助教，硕士研究生;研究方向：计算机网络技术，E-mail: zoumingliang@https://www.wendangku.net/doc/024362837.html,

导师简介：程小辉，男，1961年3月，教授；研究方向：计算机网络技术、嵌入式系统应用、数据库技术

(541004 广西桂林工学院电子与计算机系) 邹明亮程小辉刘亚荣(Department of Electronics and Computer Science，Guilin University of Technology, Guilin 541004) Zou,Mingliang Cheng,Xiaohui Liu,Yarong

基金项目：广西自然科学基金项目资助（桂科自0447099）

中国移动NgBoss数据库安装配置

中国移动通信集团业务支撑系统－NG数据库安装配置 Version 0.2 ?中国移动通信集团信息技术中心 2010年1月18日

文档信息 文档变更记录 审核批准

目录 操作系统准备 (4) 创建dba、oinstall组 (4) 创建oracle用户 (4) 建立两节点信任关系 (5) 网络配置 (5) NTP配置 (6) 设备配置 (6) 环境变量配置 (7) 安装CRS 10.2.0.1 (7) 以root用户执行vipca (13) 安装Oracle DB 10.2.0.1 (20) 升级CRS 至10.2.0.4.0 (25) 备份Oracle Database 10.2.0.1的rawutl (25) 确认CRS 10.2.0.4.0升级结果 (32) 升级Oracle 数据库软件至10.2.0.4.0 (33) 确认Oracle 10g 10.2.0.4.0软件升级结果 (39) 使用DBCA创建数据库 (39) 使用10.2.0.1的rawutl 替换10.2.0.4.0的版本 (39) 口令加固 (43) 数据库相关补丁加载 (51) 数据库隐含参数和事件设置 (52) 归档模式调整 (52) 创建watch用户 (53) EM DBConsole配置 (54) 修改EM DBConsole端口从5000改为1158 (56)

操作系统准备 检查操作系统依赖补丁，参考Doc ID：169706.1 35936--->38949 36242--->38949 37185--->38949 35900--->38949 36248--->38544 36249--->38053 35936--->38949 后面是替代补丁 zwdb21[/]#show_patches |grep -e 38949 -e 38053 –e 38055 PHKL_38053 esdisk cumulative patch PHKL_38949 vm cumulative patch PHKL_38055 scheduler cumulative patch 创建dba、oinstall组 # /usr/sbin/groupadd –g 300 oinstall # /usr/sbin/groupadd –g 301 dba 创建oracle用户 # /usr/sbin/useradd -u 300 -g oinstall -G dba oracle # /usr/sbin/usermod -g oinstall -G dba oracle # passwd oracle zwdb21#[/]getprivgrp dba dba: zwdb21#[/]setprivgrp dba MLOCK RTPRIO RTSCHED zwdb21#[/]echo "dba MLOCK RTPRIO RTSCHED">/etc/privgroup zwdb21#[/]getprivgrp dba dba MLOCK RTPRIO RTSCHED zwdb21#[/]getprivgrp oinstall oinstall: zwdb21#[/]setprivgrp oinstall MLOCK RTPRIO RTSCHED zwdb21#[/]echo "oinstall MLOCK RTPRIO RTSCHED ">>/etc/privgroup zwdb21#[/]getprivgrp oinstall oinstall MLOCK RTPRIO RTSCHED

SQL Server 移动系统数据库

说到这个问题，基本上有人就会想到三个问题： 1，什么是系统数据？ 2，为什么要移动系统数据库？ 3，移动系统数据库我们可以用附加和分离，为什么还要单独拿出来说呢？ 对于这三个问题我一个一个讲吧，也算是自己做个笔记。 1，什么是系统数据？ 所谓系统数据库就是我们在装SQL Server之后，系统自带的数据库(这样的回答是不是很白痴^_^). 如果你装SQL Server2005或2008在打开一个SQL实例后，就会看到一个数据库--->系统数据库文件夹，里边就是系统自带的数据库，如图： 对于每一个系统数据库，这里我先用简单的语言说一下: 1)，master: 这个数据库是全局数据库，它包含一些系统表，权限分配，用户帐号设置，当前数据库配置信息以及关于磁盘空间，文件分配等信息。所以在执行诸如用户帐号设置，权限分配和改变系统配置信息后都要备份此数据。所以在这里强烈建议,不仅要经常备份自己的数据库，还有备份此数据库，虽然不像备份自己数据库那样那么频繁。至少半个月或一个月备份一次此数据库。 在这里还有专门的一个数据库大牛讨论过是否应该备份此数据库：SQL SERVER –Backup master Database Interval – master Database Best Practices 2)，model: 这个数据库只是一个模板数据库，我们在创建任意的一个数据库的时候，都是复制此数据库为新数据库的基础，如果希望每一个新的数据库都含有某些对象或者权限，

可以把这个对象或权限放在此数据库中，新创建的新数据库都会继承此数据的新对象或权限，并且拥有这些对象或权限。 3)，msdb: 作者原话：SQL Server代理服务器会使用该数据库，它会执行一些列如备份和复制任务的计划好的活动。Service Borker也会用到该数据库，他为SQL Sever提供队列和可靠消息传递。当我们不在该数据库执行备份或维护任务时，通常可以忽略该数据库。在SQL Server2005之前，实际上是可以删除该数据库的,只后SQL Server 仍然可用，但不能在维护任何备份历史了，并且不能够在定义任务，警告，工作或者建立复制，不过因为默认的msdb数据库非常小，建议即使用不到也不要删除它。 4)，tempdb: 该数据库说白了，就是一个中转站或数据寄存站，用户显示创建的临时表，在查询处理和排序时内部所产生的中间结果的工作表，维护用的快照等，都会用到此数据库，与其他数据库所不同的是，在每次SQL Server实例重启之后，都会重建而不是恢复. 所以我们在其中创建的所有对象和权限在下次重启SQL Server时都会全部丢失。 但是我们也不能忽略此数据库，因为tempdb的大小和配置，对优化SQL Server的功能和性能来说很重要。 对tempdb数据库，还要多说几句，虽然在tempdb每次被重建时，它会从model 数据库继承大多数的数据库选项，但是tempdb却不会从modeldb数据库中复制其恢复模式，因为它总是使用简单恢复模式。另外，tempdb是无法删除的，也不用备份。 2，为什么要移动系统数据库？ 我们在安装SQL Server后默认的这些系统数据库都会放在C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA此文件夹下，一般的都不很大，为什么我们还有移动他们呢？ 在没有实践管理服务器之前，我也没有这个想法，但是我发现我的服务器C盘一直都在增加，或者万一重装系统，我设置的数据库选项，以及用户账户设置都要重新设置，所以就有了这个想法。 还有一点就是作为重新布置计划或安排好的维护操作的一部分，我们也许需要移动系统数据库。 3，用附加和分离就可以，为什么还要单独说呢？ 回答这个问题之前，我们在看一张图

微信成为移动数据库

“人类很多行为遵循一些统计规律，在这个意义上人类93%的行为是可以预测的”，via巴拉巴西《爆发》。 “腾讯正将开放战略推向移动互联网”，这是小马哥在2012移动开发者大会上传递出来的信息。微信，腾讯目前最成功的移动互联网应用，也是互联网历史上增长最快的新软件，号称中国第四大运营商，它在这个战略中将会扮演什么角色，起到什么作用呢? 我的看法是如果QQ和Qzone是腾讯pc端的大数据开放平台，那么微信将成为腾讯移动端的大数据开放平台。 还记得一个月前微信团队宣布微信用户数突破两亿，当时中国智能机用户数2.9亿，也就是微信已经覆盖了近7成用户，业界在惊呼羡慕之余也在关注微信未来发展道路，是打造一个精准营销的媒体平台，还是做一个闭环的电商平台，或者兼而有之? 时间过去一个月，微信公众账号已经暂停了认证，小戴同学的微信会员卡推广之路也是路漫漫兮汝将上下探索，因此对于微信的商业化探索很多人提出了质疑，小马哥9月份在互联网大会上提到的通过微信普及二维码，布局O2O的目标还能实现么?我也抱着怀疑的态度，微信虽然有开放平台，但是那些接口只是浅层次的开放，无法满足第三方开发者的需要，也就不具有很高的价值，但是这次小马哥已经明确放出风声，将逐步测试开放QQ的关系链，甚至有可能是微信的关系链，这让我非常期待，依靠着庞大的用户数据为基础，用开放的心态做平台，微信的潜力绝对是可以被挖掘的，或者说和新浪微博真正的竞争从现在才开始。 先说说大数据，这可是自云平台后最热的概念了，随着社会化媒体的兴起，针对互联网用户数据的分析、营销、挖掘产品越来越多，大部分是在为企业服务，或者用来做自身产品推广，比较经典的案例就是美丽说、蘑菇街，而最近走红的“啪啪”更是依靠着新浪微博的用户关系迅速发展用户，每天达到上万的下载量。以上的大数据主要还是来源于pc互联网上。那么在移动互联网的大数据呢?

嵌入式移动数据库的与应用

2012.No10 0 塔底压力（MPa）: 0.08塔顶温度（℃）： 75出塔气体CO2%（V）： 99.8 3.3 工艺流程说明 根据松南气田气源条件和净化度要求，结合MDEA技术特点，脱碳工艺决定采用部分再生工艺。 来自集气站分离器的原料天然气，自下部进入吸收塔，在塔内与自上而下流动的MDEA溶液逆流接触，原料天然气中大部分CO2被MDEA溶液脱除，湿净化天然气由吸收塔塔顶出来经冷却分离分水后，至下游天然气脱水装置进行脱水处理；吸收塔塔底出来的MDEA富液经能量回收后进闪蒸塔闪蒸出溶解烃后，从再生塔的上部进塔，在再生塔内自上而下流动，经减压解析出吸收的CO2，并在再生塔中间经蒸汽加热，使之维持溶液温度。由再生塔塔底出来的MDEA贫液经冷却后，再次由贫液泵送入吸收塔上部，完成溶液的循环流程，为保持再次循环溶液的清洁，约15%的富液进行溶液过滤清除杂质。 从闪蒸塔闪蒸出的烃类气体，经冷却分离水分后，送燃烧系统。 为维持系统水平衡，系统回流液及补充软水由补液泵送回再生塔底部。 3.4 主要工艺控制要求 （1）入吸收塔贫液流量：185-390m3/h；（2）入吸收塔贫液温度：70℃ ；（3）MDEA贫液中酸气含量不大于22L酸气/L溶液；（4）再生塔顶压力：0.06Mpa。可以通过调节溶液泵流量、循环水量、蒸汽流量等方法进行调整。 3.5 工艺流程图 脱碳系统工艺流程图见图3-1 4 结论 通过对各种脱碳方法的比较，可以看出MDEA法是松南气田天然气脱除CO2的最佳选择，此工艺具有以下优点：①CO2脱除率高，最高可脱除至0.1%，很容易满足工艺要求；②可同时脱除硫化物；③溶液的吸收能力强；④热能耗低；⑤溶剂损失少。 参考文献 [1]张学元, 邸超, 雷良才. 二氧化碳腐蚀与控制. 北京: 化学工业出版社, 2000. [2]张宏伟. MDEA溶液脱碳工艺的应用. 小氮肥设计技术 VOL.26 NO.2,2005 [3]冯叔初.《油气集输与矿场加工》中国石油大学出版社 东营 P397-399 摘 要 随着智能移动终端的普及和移动计算技术的发展，人们对移动数据实时处理和管理要求的不断提高，移动数据库逐步走向应用，嵌入式移动数据库也体现出其优越性。本文从嵌入式移动数据库的概念、特点、系统结构和关键技术等几个方面进行了分析，最后指出嵌入式移动数据库的具体应用方向。 关键词 嵌入式 数据库 移动计算 事务处理 随着移动通信技术和网络技术迅速发展，加之移动计算机和移动通信设备的大量普及以及网络系统的完善，许多计算节点可以在移动过程中与网络建立连接。这中间，嵌入式技术就已经在人们的生活中得到广泛应用,移动计算更是给人们的生活带来了极大的方便。数据库技术已经发展到一个新的领域——嵌入式移动数据库(EMDB)。 1 嵌入式移动数据库的概念 嵌入式系统是以应用为中心,以计算机技术为基础,并且软硬件可裁剪,适用于应用系统对功能、可靠性、成本、体积、功 浅谈嵌入式移动数据库的研究与应用 孟立凡 李 铮 （中北大学） 耗有严格要求的专用计算机系统。它一般由嵌入式微处理器、外围硬件设备、嵌入式操作系统以及用户的应用程序等四个部分组成,用于实现对其它设备的控制、监视或管理等功能。 移动计算是随着移动通信、互联网、数据库、分布式计算等技术的发展而兴起的新技术。移动计算技术将使计算机或其它信息智能终端设备在无线环境下实现数据传输及资源共享。它的作用是将有用、准确、及时的信息提供给任何时间、任何地点的任何客户。这将极大地改变人们的生活方式和工作方式。移动计算环境比传统的计算环境更为复杂和灵活。典型的移动计算环境有:(1)移动用户+传统工作站+传统有线网络。(2)智能计算设备+调制解调器+电话网络。(3)智能计算设备+无线网络。 2 嵌入式移动数据库的特点及其系统结构 2.1 嵌入式移动数据库的特点 移动数据库的计算环境是传统分布式数据库的扩展,它可以看作客户端与固定服务器节点动态连接的分布式系统。因此

移动通信网的数据库

移动通信网中的数据库（苏波、王芙蓉）摘要移动通信网有多种数据库，由于要对移动用户进行管理，它们与通常的数据库不同。文章分析了移动通信网数据库系统的技术特征。关键词数据库数据库管理系统移动性管理1数据库技术的发展现状数据库技术的发展经历了三个阶段。第一阶段，1969年IBM公司研制了基于层次模型数据库管理系统（IMS），并作为商品化软件投入市场，该系统至今还有其特定用户，技术还在继续发展。第二阶段从60年代到70年代初，美国数据库系统语言协会（CODAS YL）下属的数据库任务组（DBTG）对数据库的方案和技术进行了系统研究，提出了DBTG 报告。该报告提出了数据库系统的许多基本概念、方法和技术，成为网状数据模型的典型代表，奠定了数据库发展的基础。DBTG 的存取效率较高，系统研制较容易，但数据独立性差，用户使用不方便。目前一些实时性要求较高的专用系统仍采用网状模型。第三阶段，1970年IBM公司的E.F.Codd发表了基于关系模型数据库技术的论文“大型共享数据库数据的关系模型”，获得1981年ACM图灵奖。随着数据库技术和计算机软硬件水平的提高，近年来又出现了许多新的数据库技术，如实时数据库、主动数据库、内存数据库、分布数据库、面向对象数据库、多介质数据库及专家数据库等。分布式数据库是数据的集合，它在逻辑上属于同一个整体，但存放在不同节点。在分布式数据库中，每个节点都有自己的数据库管理系统（DBMS），具有高度的自治性，其位置对于用户而言是透明的，与集中式数据库相比，可靠性和灵活性更高。考虑到系统的性能和效率，分布式数据库往往把数据集的不同副本存放在不同节点，以减少网络传输的开销，但同时又增加了副本数据库更新操作所需的开销。因此对副本数据库存放策略进行研究，是分布式数据库设计的重要任务。传统的DBMS无法满足存取大量共享数据和控制信息的应用要求（如过程控制和网络管理等），这类应用的共同要求是DBMS能监视系统状态，无须用户干预就能调度相关任务，并使其满足定时和一致性等要求。因此人们提出了主动数据库的概念。主动DBMS扩展了以下功能：（1）用户可显式地定义想要监视的情形（事件和条件）；（2）系统能自动检测和评价出现的状态；（3）一旦定义的状态出现，即进行相应的工作。这些功能除了支持外部应用，还可实现或扩展DBMS本身的功能，如完整性及安全性控制等。实时数据库系统（RTDBS）是业务和数据都有定时特性或显式时间限制的数据库系统。系统的正确性不仅依赖逻辑结果，还依赖逻辑结果产生的时间。RTDBS是数据库和实时系统的结合，它集成两者的概念和要求，同时处理定时性和一致性。对RTDBS 而言，实时指的是能设置和处理“显式”的定时限制，即通过“识时协议”处理有关的截止时间或定时限制。随着计算机硬件技术的不断发展，动态随机存取存储器（DRAM）的容量越来越大，这无疑为计算机内存的不断扩大提供了硬件基础，但在并行数据库，后端机I／O瓶颈越来越突出，因此出现了内存数据库（MMDB），它将整个数据库或大部分热点数据存放在主存中，消除了I／O瓶颈。在传统的面向磁盘数据库DRDB中，数据库主备份位于磁盘，在MMDB中则位于主存。对不同的存储介质，DBMS采取的策略也各不相同。数据驻留内存，可以大部分或全部在内存中存取数据，缩短系统的响应时间，对于实时数据库系统有重要意义。2移动通信网的数据库移动通信网有多种数据库，这些数据库除了具有通常数据库的功能外（如数据的独立性、安全性、完整性、共享、并发控制、故障恢复等），还要满足严格的实时性要求。目前移动通信系统的数据库包括：归属位置寄存器（HLR）、拜访位置寄存器（VLR）、设备识别寄存器（EIR）和鉴权中心（AUC）。在现有蜂窝通信系统中，支持终端和用户移动性的主要是HLR和VLR。HLR是移动通信系统的中央数据库，存放签约用户的所有数据信息，包括鉴权数据、位置数据、基本业务数据和补充业务数据等。VLR存放的大部分用户数据来源于HLR，它作为HLR数据库的副本，与HLR中的数据保持一致。这种分布式数据存放降低了网络负荷，减少了访问时延，是移动通信网的显著特征。不论是HLR还是VLR，它们的主要功能都是实现移动应用部分的协

移动数据库关键技术研究报告

移动数据库关键技术研究报告 1 前言 (1) 1.1 移动数据发展现状 (1) 1.2 移动数据库概述 (1) 1.3 研究移动数据库的背景及意义 (1) 1.4 移动数据库的应用 (2) 1.5 论文主要研究内容 (3) 2 移动数据库关键技术 (3) 2.1 复制与缓存技术 (3) 2.2 数据广播技术 (4) 2.2.1 数据广播技术的特点 (4) 2.2.2 广播时间的优化 (4) 2.3 位置管理 (5) 2.4 查询处理及优化 (5) 2.5 移动事务处理技术 (6) 2.5.1 移动事务处理的特点 (6) 2.5.2 移动失误处理要求 (7) 2.6 移动AGENT技术 (8) 2.7 移动数据库的安全技术 (8) 3 移动事物处理技术 (9) 3.1 移动事务的定义 (9) 3.2 移动事务的基本特征 (10) 3.3 移动事务的问题 (10) 3.4 理想移动事务处理模型标准 (11) 3.5 Clustering事务模型 (12) 3.6 MutiDatabase事务模型 (12) 3.7 数据的一致性 (13)

3.8 过区切换 (13) 3.9 移动事务的恢复 (14) 4 移动事物处理的应用 (14) 4.1 移动数据库应用的分类 (14) 4.2 移动数据库的典型应用 (15) 4.3.1 移动数据库在银行领域的应用 (17) 4.3.2 移动数据库在物流领域的应用 (18) 4.3.3 移动数据库在移动互联网的应用 (18) 5 移动事务断接一致性(MT一BC)事务模型 (19) 5.1 设计背景 (19) 5.2 移动事物处理的需求目标 (20) 5.3 模型的总体结构 (21) 6 移动数据库的复制技术 (22) 6.1 传统复制技术 (22) 6.2 移动数据库的二级复制技术 (24) 6.3 移动数据库的三级复制技术 (26) 6.3.1 三级复制体系结构 (26) 6.3.2 三级复制支持移动计算环境的原因分析 (30) 7 结束语 (31)

移动数据业务管理信息系统数据库设计书

移动数据业务管理信息系统数据库设计书 1 引言 1.1 背景 随着数据业务的不断发展及市场竞争形式的不断变化，现有的业务管理方法已经不能满足工作的需求，加强业务管理成为急待解决的问题。 在数据业务发展的整条生产链中，数据中心起到的是承上启下、融会贯通的枢纽作用，然而目前的现状是数据中心与代理商SP 之间，数据中心与客户经理营业部之间，数据中心与集团客户部之间，及数据中心内部各班组间没有一套统一的业务管理平台。造成数据中心与各部门的业务办理及沟通的途径多达三种以上，象数据中心与代理商间目前还没有一个固定的沟通途径。这大大制约了业务发展的进度、沟通的畅通和信息的及时共享。 《沈阳移动数据业务管理信息系统》的开发建设将全面解决以上所述的问题，在数据中心、集团客户部、营销单位、代理商之间通过建立统一的系统平台及开发相应的业务子系统，消除业务发展管理瓶颈，规范业务流程，实现信息共享。 1.2设计原则 先进性和适用性相结合 在系统设计上，首先应当具有前瞻性。在保证系统经济性的前提下整个软、硬件系统的适度超前性，以确保在较长的时间内保持现系统的先进性、政府的良 好形象，使投资充分发其效率 系统采用当今先进和成熟的 技术，如数据库技术、网络技 术、分布式开发技术等。应当充分考虑到在未来若干年内 发展的需求，技术上保证在相当长的一段时间内（5-10年）不落后。与此同时，还应当结合沈阳移动公司的的实际情况，在保证实现系统建设目标概要设计说明书 沈阳维世达科技股份有限公司 本设计书包括项目功能概要设计和数据库设计 2008-04-23

的前提下，尽量选择较高性能价格比技术和产品。 ?合理性和实用性相结合 结合实际的沈阳移动公司中业务处理流程以及业务管理工作流程，通过对实际业务流程以及需求的分析，设计结构合理、功能实用、符合实际业务需要的系统。系统的设计在运行环境、使用操作等方面以实用为主，以方便用户使用和维护为出发点。系统在产品的选择上，采用了国际上广泛采纳的、主流的、支持开放标准的操作平台、体系结构以及编程方法。 ?开放性与标准性相结合 从系统架构到软件体系结构，都应充分考虑系统的开放性。以模块化设计和基于组件的多层体系结构保证系统的开放性和灵活性。系统建设采用的软件平台、数据标准、开发技术应符合公认的工业标准，符合国家、地方和有关标准与规范，系统分析、设计与实现采取开放路线，遵循国际软件工程的标准、规范，并尽可能采用国际主流产品，以确保系统集成的可行性、良好的可扩充性。采用标准的数据描述语言以及标准的通信协议，适应以后的数据交换标准以及系统间互连的标准协议等。 ?易维护性和扩展性原则 系统要具有较强的易维护性和扩展性，以确保在更长的时期内保系统技术领先地位，适应现代信息技术高速发展，为此我们将全面采用组件化三层结构或多层结构。可根据实际情况对系统硬件和软件进行灵活地配置和组合，能方便地进行功能的调整以及系统的升级、扩展，以适应业务的不断发展和更新。同时，系统的升级要充分考虑与现有其它应用系统的数据接口问题，尽可能保证系统有更长的生命周期。 ?安全性和可靠性原则 系统设计应遵循经济性原则，如果降低每个用户点的成本，整个系统的成本将大为减少。实行基础设施（如网络设备）等一步到位，而计算机硬件和移动终端等可以从实际出发，注重实用性和响应速度，节省资金成本。 安全性对于分布式系统来说很重要，从身份验证到资源授权访问再到数据的安全性。从操作系统的安全性、访问控制、数据的完整性以及业务层的安全机制要考虑整个系统的安全、可靠地运行。 服务器系统应当建立足够的冗余和后备机制，确保系统全天候服务。本系统将采用具有高可用性的多层服务器群集技术，实现负载均衡和热备份，确保系统具有高性能、无单点故障的特点。 ?经济性原则 系统建设要求在实用的基础上做到最经济，以最小的投入获得最大的效益。在硬件和软件配置、系统开发和数据库建立上都充分考虑投入和经济效益。在充分考虑到保证系统整体及各组成部分的功能和性能要求的前提下，最大限度的保护各分系统现有的投资和技术资源，并对这些资源加以有效的利用。各业务管理信息系统将在现有软件系统的基础上，根据业务管理要求和现有软件的生命周期，决定系统是否重新开发或继承使用。