软件工程硕士学位论文-银行非现场监测系统设计与实现.pdf

北京i n i i _ ! 人学t 程硕1 - 争业学位论文 密级：保密期限： 踌贡却童大肇 工程硕士专业学位论文 学 姓 专 导 学 号： q 2 珏圣鱼垦 名：题毯 业： 筮往王程 师：渣维医 院：让篡扭堂暄 2 0 0 9 年9 月2 7 日 n 磊 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特另t l ；h l ：l 以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：刀及弓欠同期：弘炒7 7 乙7 | 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在年解密后适用本授权书。非保密论 文注释：本学位论文不属于保密范围，适用本授权书。 本人签名：乃灸多岌日期：妒7 7 y 7。 。 ， 导师签名：j 锄纪良 日期 幻，7 罗印 i i i 北京邮f u 人学t 程硕i j 孥业学位论文 i v ! j 0 奠 气 j 北京邮i 乜人学t 程硕卜争业学位论义 银行非现场监测系统的设计与实现 摘要 近年来随着金融与国际接轨的不断深入，银行业面临了前所未有的各式各样 的风险。而这些风险的防范，在大量的交易中是很难靠人工的方式去发现这些欺 诈或者风险。银行非现场监测系统利用技术手段，在海量的交易数据上发现类似 可疑行为的系统。对银行的风险防范具有重要的意义。 本文从需求开始，讨论了整个非现场监测系统设计与实现。按照商业银行不 同的业务类型，给出了业务上需要检测各类模型或者说是规则。按照不同风险类 别，给出了银行所需要的风险查证模板。同时对于软件的功能需求做了探讨。 本文从总体设计和详细设计讨论了适合于银行的非现场监测系统。总体设计 上，设计了系统的功能架构。功能架构涵盖了欺诈甄别( 预警监测) 、查询查证、 基础管理、项目管理、内控评价和程序化审计。同时基于s t r u t s 、s p r i n g 、工 作流等设计了技术架构。从层次结构上描述了软件架构。本文给出了基础管理、 欺诈监测模块和查询查证模块的详细设计。同时给出了主要的数据模型设计。最 后，对后台数据的处理过程做了详细设计。 最后，本文依据软件工程方法，给出了项目的主要管理过程。包括管理机制 和实施安排等。同时本文给出最后系统实现效果。 本系统已经在国内某商业银行上线使用。并起到了良好的风险防范效果。 关键词：金融欺诈，非现场监测，s p r in g ，s t r u t s v 北京l | i | j i u 人学t 千口顾l - 譬业学位论义 v l t ，j ， 一 c 北京邮i u 人学t 程颀l ：专业学化论文 t h ed e s i g na n dl m p l e m e n t a t l 0 no fo f f s i t e s u p e r v i s i o ns y s t e mi nb a n k a b s r t a c t i nr e c e n t y e a r s ，f i n a n c i a l a n di n t e r n a t i o n a ls t a n d a r d sw i t ht h ec o n t i n u o u s d e e p e n i n go ft h eb a n k i n gi n d u s t r yf a c e sa nu n p r e c e d e n t e dv a r i e t yo fr i s k s t h e s er i s k p r e v e n t i o n ，i nal a r g en u m b e ro ft r a n s a c t i o n si sv e r yd i f f i c u l tt or e l yo na r t i f i c i a l m e a n st of i n dt h e m ，o rt h er i s ko ff r a u d b a n ko fo f f - s i t em o n i t o r i n gs y s t e mf o rt h e u s eo ft e c h n i c a lm e a n s ，i nt h ev a s ta m o u n t so ft r a n s a c t i o nd a t af o u n do nas y s t e m s i m i l a rt ot h es u s p i c i o u sa c t i v i t y p r e v e n t i o no fr i s k sb yb a n k si so fg r e a ts i g n i f i c a n c e i nt h i sp a p e r ，d e m a n dh a sb e g u nt od i s c u s st h ee n t i r eo f f - s i t em o n i t o r i n gs y s t e m d e s i g na n di m p l e m e n t a t i o n a c c o r d a n c ew i t ht h ec o m m e r c i a lb a n k so fd i f f e r e n tt y p e o fb u s i n e s s ，g i v e nt h en e e dt od e t e c ta l lt y p e so fb u s i n e s sm o d e lo ri st h er u l e a c c o r d i n gt od i f f e r e n tr i s kc a t e g o r i e s ，g i v e nt h er i s k so fb a n k sn e e dt ov e r i f yt h e t e m p l a t e a tt h es a m et i m et h ef u n c t i o n a lr e q u i r e m e n t sf o rs o f t w a r et od ow e r e d i s c u s s e d t h i sp a p e rd i s c u s s e st h eo v e r a l ld e s i g na n dd e t a i l e dd e s i g nf o rt h eb a n ko f f - s i t e m o n i t o r i n gs y s t e m o v e r a l ld e s i g n ，t h ed e s i g nf u n c t i o no ft h es y s t e ma r c h i t e c t u r e f u n c t i o n a ls t r u c t u r eo ft h e c o v e r i n go ff r a u ds c r e e n i n g ( e a r l yw a r n i n ga n d m o n i t o r i n g ) ，c h e c kv e r i f i c a t i o n ，i n f r a s t r u c t u r em a n a g e m e n t ，p r o j e c tm a n a g e m e n t ， i n t e r n a lc o n t r o le v a l u a t i o na n dp r o c e s so ft h ea u d i t a tt h es a m et i m eb a s e do ns t r u t s ， s p r i n g ，w o r k f l o wa n do t h e rt e c h n i c a la r c h i t e c t u r ed e s i g n f r o mt h eh i e r a r c h i c a l s t r u c t u r ed e s c r i b e st h es o f t w a r ea r c h i t e c t u r e i nt h i sp a p e r ，t h eb a s i cm a n a g e m e n t ， f r a u dm o n i t o r i n gm o d u l ea n dq u e r ym o d u l et ov e r i f yt h ed e t a i l e dd e s i g n a tt h es a m e t i m eg i v e st h em a i nd a t am o d e ld e s i g n f i n a l l y ，t h eb a c k g r o u n dd a t a ，m a d ead e t a i l e d d e s i g np r o c e s s f i n a l l y ，t h ep a p e ri sb a s e do ns o f t w a r ee n g i n e e r i n gm e t h o d s ，g i v e st h ep r o j e c t s m a i n m a n a g e m e n tp r o c e s s i n c l u d i n g t h e m a n a g e m e n tm e c h a n i s m s a n d i m p l e m e n t a t i o na r r a n g e m e n t s i nt h i sp a p e r ，t h ef i n a ls y s t e ma tt h es a m et i m et o a c h i e v er e s u l t s t h es y s t e mh a sb e e ni nad o m e s t r i cc o m m e r c i a lb a n ko n 1 i n eu s e a n da c ta sa g o o dr i s kp r e v e n t i o ne f f e c t k e yw o r d s ：f i n a n c i a lf r a u d ，o f f - s i t e s u p e r v i s i o n ，s p r i n g ，s t r u t s i 一，；。 北京i | l l j i u 人学t 程f 砚f j 专q k 学化论文 彳 北京i l f | j i u 人学t 程硕i ：号业学化论文 第一章绪论 目录 l 1 1 本文研究的背景及意义1 1 2 本文研究的内容2 1 3 本文的章节安排2 第二章相关技术综述3 2 1 规则引擎3 2 1 1 基于规则的争家系匀故r b e s k 。3 2 1 2 规则引擎的相关构件。3 2 1 3 规则引擎的架构发推理机锄5 2 1 4 禊爿涩朔眈管弦p e t e 8 2 1 5 龆删之鲈1 1 2 2 e t l 相关知识介绍1 2 2 2 1嬲舀维1 2 2 2 2 苏磋溪虎j 3 2 2 3 歹i i ；l ! 驴j 乐莹。j 4 第三章业务需求 1 6 3 1 预警监测功能需求1 6 3 1 j 菝浙扔贸箩j 6 3 1 2 来分颜该学17 3 1 3 关伤哟勇可擎j7 王1 4 让丢冶铡j7 3 2 案例管理功能需求1 7 j2 j 爰澎绕；枣咧j 8 3 2 2 冀饼鲥缫移矿。j 8 3 3 查询查证功能需求1 8 i i j 穆誊彰；强 护j 8 3 i 2 模噬绻耽f 2 0 3 4 预警和查证业务需求2 1 3 4 1 新移澎务霈蒜2 1 3 4 3 蓊赶丝务方驴袋2 3 第四章系统总体设计 4 1 系统功能架构。2 6 4 2 系统技术架构2 8 4 3 系统软件架构。3 0 第五章详细设计 3 2 5 1 基础管理模块( b m p ) 设计3 2 5 1 1 b m p 配置文件到表3 2 5 1 2 b m p 靳久囊勇馏( a c t i o n f o r m ) j 形疣3 3 5 1 3 b m p 筷珙功磁列寿鲥 5 1 4 b m p 历r 磁殍净豹鬣述3 4 5 2 欺诈监测模块( f d p ) 设计3 5 t。l，o 北京l i i l j f u 人学t 程硕i ：专业学位论文 5 2 1 f d p 雕霞之殉叨厶毫硝 5 2 拼_ p 耢久耢凹( a c t i o n f o r m ) 刃乞寿粥 置z 3 f d p 摸瓒幼膨j 疙3 9 5 2 4z 多磁举勿岿j 鎏。4 0 王2 s f d p 必理彦缀簏述卯 5 3 查询杏证模块( a v p ) 设计4 2 工3 a v p 昭霞之多豫铊 工3 2 a v p 颊 a 焉殄凹( a c t i o n f o r m 夕夕瘛私 工3 3 a l q “ 模珙功磁刃籀钙 5 3 4 菇磁翁切僦功名笆。4 6 5 3 5z 貔萨细岿毯4 7 5 3 6 a v p 必鲤逻辑描述4 7 5 4 数据模型设计4 9 5 4 1 系z 移鳓? 5 d 5 4 2 参0 数告乞髫5 j 工4 3 措j 簖爹鸶翌船 5 4 4 模叛擎髫。钌 5 4 5 案例爹髫弼 5 4 6 规别管翟爹硝 5 4 7 措粝缮察5 6 工z 8 秘发主鲈5 8 工4 9 颅臀缮纂5 9 5 5 后台运算流程设计6 0 5 5 1 c o n f i g s e r v e r ( f - a 日“ 分窿务缎昌影匆6 2 5 s 2 e t l s e r v e r ( 厉# 粤j 纺l o a d d a t a 彳瘦劈： 6 4 工5 3 a u d i t s e r v e r ( f a 分彭算磁名匆，6 5 王工4 渤奶w 算饪务葶型6 6 工工5 掰磐萨鲈征务触6 7 第六章系统实施 6 1 项目管理机制6 8 6 1 1 关磁殇掀力弦6 8 6 1 2 项管理9 筑蘑傩 6 2 项目实施安排6 9 6 z 1 项目复i 彪澎发6 9 6 z 2z 髫甘始a 蘑哆勘。7 0 6 3 实现效果7 l 第七章结论与展望 7 1 本文结论7 3 7 2 未来展望7 3 参考文献 致谢 x 7 4 7 5 一 f j 北京邮i u 人学t 程硕l ：号业学位论文 第一章绪论 1 1 本文研究的背景及意义 金融行业由于欺诈行为【1 】每年造成的损失约为上万亿美元。银行业越来越 重视金融欺诈因为对社会带来的危害。从国内外金融机构的一些典型案例( 见表 1 - 1 和表1 - 2 ) n - 以看到，金融风险引起的损失频发于欺诈行为。 表1 - 1 金融风险部分典型案例( 国外银行) 损失金额( $ 机构名称发生年份 产生根源 百万) r 本大和银行( d a i w a1 9 8 4 1 9 9 5 未经授权( 3 万笔) 的交易行为、伪造会计账册 b a n kl t d )年 1 ，1 0 0 文件，及管理阶层企图隐匿，做出不实揭露。 同商住友银行1 9 8 6 1 9 9 6 ( s u m i t o m oc o r p ) 年 1 , 7 0 0从事未经授权之期货商品交易达十年之久。 国际商业与信用银行 1 9 9 1 年1 0 ，0 0 0 欺诈性贷款、虚假存款和洗钱等广泛的非法经营 ( b c c i )业务活动。 英国巴林银行 1 9 9 5 年 1 ，6 0 0 从事未经授权之交易行为及隐匿巨额期货交易 ( b a r i n g sb a n k ) 损失。 爱尔兰联合银行 2 0 0 2 年 7 5 0 银行职员鲁斯纳克伪造交易文件，进行违法外汇 ( a l b ) 交易。 法国兴业银行 2 0 0 8 年8 0 0 0 交易员凯维埃尔违规操作。 表1 - 2 金融风险部分典型案例( 国内银行) ， ，一 损失金额 ，j 机构名称发生年份，产生根源 + ( ￥人民币) 内外勾结，采取私刻印鉴、印章，制作假合同、 中国建设银行吉林1 9 9 9 1 2 3 2 8 4 4 。万假存款证明书，伪造资信材料、担保文件等手 分行 2 0 0 1 4 段，进行贷款、承兑汇票的诈骗。 2 0 0 0 1 2 北京“森豪公寓”的开发商以员工名义，虚构 中国银行北京分行6 4 亿房屋买卖合同，提供虚假收入证明套取按揭贷 2 0 0 2 6 款和重复按揭贷款。 银行工作人员与社会人员相互串通、勾结作 中国农业银行包头2 0 0 3 7 1 1 4 9 万 案，挪用联行资金、虚开大额定期存单、办理 分行2 0 0 4 6假质押贷款、违规办理贴现、套取银行信贷资 金，谋取高息。 中国工商银行南海 使用虚假的财务报表、经济合同、证明文件， 支行 1 9 9 0 2 0 0 3超过2 0 亿使用虚假的产权证明、抵押物作担保、抵押， 骗取银行贷款 中国工商银行上海2 0 0 2 7 1 4 1 万以消费信贷名义经营谋利：姚康达将个人住房 北京i | i | f i u 人学t 程顺i j 专业学位论文 外高桥保税区支行2 0 0 3 6贷款用于购买1 2 8 套住房，炒作房地产。 中国银行黑龙江省 分行河松街支行 2 0 0 4 2 0 0 5 1超过1 0 亿内外勾结的票据诈骗案件。 中国银行双鸭山四5 名工作人员沆瀣一气，非法出具大量的承兑 马路支行 2 0 0 5 2 2 0 0 64 3 2 5 亿 汇票。 上海浦发银行陆家严重违反有关管理制度和操作规程进行操作 嘴支行 2 0 0 6 51 - 2 6 亿 引发的风险贷款事件。 交通银行沈阳分行 2 0 0 6 62 亿 内外勾结利用汇票多次作案。 2 0 0 1 年1 月，巴塞尔委员会公布了新巴塞尔资本协议 2 ，其核心内容 是提高资本的风险敏感度，更加强调对信用奉献、市场风险和操作风险的监测与 控制，全面推行风险管理理念。信息技术的迅速发展，推动全球进入了知识经济 时代，这个时代的显著特征之一是把计算机网络通信技术融入到金融业务创新领 域，将计算机广泛应用于会计核算、财务费用、信贷、资金管理等业务系统，实 现经营业务电子化网络管理。银行系统已逐步迈向经营业务电子化发展轨道开展 计算机审计业务；充分运用现代信息技术手段，抓紧金融系统风险监测、预警体 系的建设，提高金融统计、会计、审计和监管水平。 1 2 本文研究的内容 银行的审计系统对银行来说是风险的最后一道防线。本文的主要研究内容 有： 首先，给出了银行审计系统主要模块的业务需求。针对风险预警业务需求， 查证业务需求做了详细分析。 其次，对于系统架构进行了总体设计。包括了，系统的总体功能架构、系统 技术架构和系统的软件架构。 再次，对非现场监测系统做了详细设计。包括了基础管理、欺诈甄别和查询 查证三个模块的详细设计。同时设计了相应的数据库模型。然后，对于后台数据 处理部分做了详细的设计。 最后，介绍了本系统的实现及其使用过程。并展望系统为了的应用。 1 3 本文的章节安排 第一章阐述了本课题提出的背景，本论文的主要工作及论文的结构。 第二章介绍了规则引擎和e t l 相关技术。 第三章主要介绍了业务需求。 第四章对系统总体设计作了描述。 第五章对系统的详细设计做了描述。 第六章系统的实现和应用描述。 第七章结论和展望。 2 一 【l 北京f i 【j i u 人学t 程硕l ：专业学位论文 2 1 规则引擎 第二章相关技术综述 规则引擎可以看作是一套软件组件，它负责将应用程序中的业务规则抽取出 来，使用预定义的语义模块编写业务决策。是一种嵌入在应用程序中的组件，它 的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行测试和 比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻 辑，触发应用程序中对应的操作。 2 1 1 基于规则的专家系统( r b e s ) j a v a 规则引擎起源于基于规则的专家系统【3 】，而基于规则的专家系统又是 专家系统的其中一个分支。为了更深入地了解j a v a 规则引擎，下面简要地介绍 基于规则的专家系统。r b e s 包括三部分：r u l eb a s e ( k n o w l e d g eb a s e ) 、w o r k i n g m e m o r y ( f a c tb a s e ) 禾1 i n f e r e n c ee n g i n e 。它们的结构如图2 - l 所示： 图2 - 1 基于规则的专家系统构成 如上图所示，推理引擎( i n f e r e n c ee n g i n e ) 包括三部分：p a t t e r nm a t c h e r 、 a g e n d a 和e x e c u t i o ne n g i n e 。p a t t e r nm a t c h e r 决定选择执行哪个规则，何时执行 规则；a g e n d a 管理p a t t e r nm a t c h e r 挑选出来的规则的执行次序；e x e c u t i o ne n g i n e 负责执行规则和其他动作。 2 1 2 规则引擎的相关构件 与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理【4 】， 下面将对这些概念进行逐一介绍。 3 北京邮fl 人学t 程f 砍卜擘业学 _ ：) = 论艾 1 信息元( i n f o r m a t i o nu n i t ) 信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对 象。这些信息包括：消息、产生事件的应用程序标识、产生事件、信息元类型、 相关规则集、通用方法、通用属性以及一些系统相关信息等等。 2 信息服务( i n f o r m a t i o ns e r v i c e s ) 信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对 象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有 不同的属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服 务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它 自己类型相对应的信息元。 3 规则集( r u l es e t ) 规则集是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个 条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组 合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的 情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放 弃动作( d i s c a r da c t i o n ) 、包含动作( i n c l u d ea c t i o n ) 和使信息元对象内容持久化 的动作。 4 队列管理器( q u e u em a n a g e r ) 队列管理器用来管理来自不同信息服务的信息元对象的队列。 下面将研究规则引擎的这些相关构件是如何协同工作的。 如图2 2 所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化 为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并 应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。 4 北京邮f u 人学t 程顺f j 专业学位论义 图2 - 2 处理过程协作图 2 1 3 规则引擎的架构及推理机制 规则引擎的架构【5 】如图2 - 3 所示。 5 一，；j 北京j | i i i u 人学t 干口顾f j 簟业学化论爻 图2 - 3 规则引擎工作机制 规则引擎的推理步骤如下： 将初始数据( f a c t ) 输入至工作内存( w o r k i n gm e m o r y ) 。 使用模式匹配( p a t t e mm a t c h e r ) 将规则库( r u l e sr e p o s i t o r y ) 中的规则( r u l e ) 和 数据( f a c t ) t 匕较。 如果执行规则存在冲突( c o n f l i c t ) ，即同时激活了多个规则，将冲突的规则放 入冲突集合。 解决冲突，将激活的规则按顺序放入议程( a g e n d a ) 。 执行议程( n g e n d a ) 中的规则。重复步骤2 至5 ，直到执行完毕议程( a g e n d a ) 中的所有规则。 当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例， 由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则 执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条 件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则 6 北京i i l f j i u 人学t 程坝i j 专业学f 逆论文 执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数 据驱动的。 规则引擎的内部处理过程如图2 4 所示，规则引擎从队列管理器中依次接收 信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。如图所示，规 则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关 的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真，所有 与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中 的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。 在这个过程中并未考虑两个特殊动作：放弃动作( d i s c a r da c t i o n ) 和包含动作 ( i n c l u d ea c t i o n ) 。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有 规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包 含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则 引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的 地方继续执行。这一过程将递归进行。 图2 - 4 规则引擎的内部处理过程 j a v a 规则引擎的工作机制【6 】与上述规则引擎机制十分类似，只不过对上述 概念进行了重新包装组合。j a v a 规则引擎对提交给引擎的j a v a 数据对象进行检 索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发 现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令 时、依照某种优先序依次执行。一般来讲，j a v a 规则引擎内部由下面几个部分构 成：工作内存( w o r k i n gm e m o r y ) t i p t _ 作区，用于存放被引擎引用的数据对象集合； 规则执行队列，用于存放被激活的规则执行实例；静态规则区，用于存放所有被 加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改 7 北京邮l 也人学t 程顺| 争业学位论文 变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行 实例。j a v a 规则引擎的结构示意如图2 5 所示。 图2 - 5 规则引擎的结构示意图 任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效 率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的 数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1 9 8 2 年美国卡耐基梅隆大学的c h a r l e sl f o r g y 发明了一种r e t e 算法【7 】【8 】，很好地 解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用r e t e 算法。 2 1 4 模式匹配算法r e t e 所谓模式就是规则里面的条件元素，每一个模式由一个或多个约束组成，其 目的是匹配自定义模板事实之中的字段。规则引擎将规则的模式与事实列表中 的事实相匹配，如果规则的所有模式与事实匹配，则规则就被激活( a c t i v a t e d ) 并放入议程( a g e n d a 卜己被激活的规则集合。 对于单一事实以单一方式进行模式匹配【9 】的情形比较简单，而对于以多种 方式进行的模式匹配往往变得非常复杂，这时候我们一般是通过使用多字段通配 符( $ ，? ) ，字段约束与组合、函数控制等来实现模式匹配的。对于高级模式匹配 问题，主要是通过谓词函数、谓词字段约束、返回值字段约束以及各种条件元素 创建一个控制流来控制规则的执行。这时候的规则模式就是控制模式( c o n t r o l p a t t e r n ) ，专门用于控制规则何时可用。控制事实( c o n t r o lf a c t ) 用来触发控制模 式。 8 3 一 北京邮i 【1 人学t 程硕| _ 争业学位论文 基于规则语言，使用了一种非常有效的算法，将事实与规则中的模式匹配， 以确定哪些规则满足了它们的条件，这种算法被称为r e t e 模式匹配算法( r e t e p a t t e r n m a t c h i n ga l g o r i t h m ) 。下图2 - 6 给出了事实与规则匹配的过程【1 0 】。 图2 - 6 模式匹配规则与事实1 如果匹配过程只需一次，推理机可以检查每条规则并寻找一套事实来决定规 则的模式是否己满足。如果是，则将此规则记入议程中。图2 7 给出了该方法。 图2 7 模式匹配规则与事实2 然而，在基于规则的语言中，匹配过程是不断重复进行的。通常，事实列表 在每次执行中都会被修改，添加新的事实到事实列表或删除旧的事实。事实列表 的不断变化使得先前不满足条件的模式得到满足，匹配问题成为了不断进行的过 程。在每次循环中，随着事实的添加和删除，必须对己满足条件的规则进行更新。 在每次循环后，令推理机检查每条规则以指导对事实的寻找。这种方法最大 的缺点是速度太慢，即出现了大多数基于规则的专家系统的所显示的特征：时间 冗余性( t e m p o r a lr e d u n d a r y ) 。一般地说，一条规则的运行仅改变事实列表中 的少数事实，在每次循环中，仅删除、添加很少一部分事实。所以，事实列表的 变化只影响很少一部分的规则。因此，令规则推动对所需事实的寻找，需要大量 不必要的计算。这是因为，在当前循环中，大多数规则所找到的事实很可能与上 一次循环所找到的相同。图2 8 表示了这种低效的方法，阴影部分代表了对事实 列表所作的改变。 9 北京邮i u 人学t 千口顾f j 号、i k 学f 蕾论文 图2 - 8 规则寻找事实，不必要的计算 r e t e 模式匹配算法的工作原理见图2 - 9 ，它的实现是在不断循环中，通过记 住哪些是己经匹配好的事实，然后只计算那些刚添加或删除事实所引起的必要变 化，从而可以避免不必要的计算。规则是不变化的，而事实是变化的，所以应是 事实寻找相应的规则，而不是规则寻找变化的事实。 图2 - 9 事实寻找规则 r e t e 模式匹配算法正是利用了基于规则的专家系统所具有的时问冗余性。它 的实现是通过存储不断循环中匹配过程的状态，并且只重新计算在事实列表中发 生了变化、又反映到本次状态中的变化。也就是说，如果在一次执行周期中，一 组模式找到三个所需要的事实中的两个，那么在下一周期中，就无需对己经找到 的这两个事实进行检查，只有第三个事实才是需要关注的。仅当添加或删除事实 时，匹配过程的状态才会被更新，如果添加、删除事实的数量与事实和模式的数 量相l k j e 4 , ，那么匹配过程会进行得很快。最糟的情况是，如果所有的事实都改 变了，那么所有的事实将与所有模式进行匹配。 1 0 北京邮i 乜人学t 程颀f j 专业学化论文 如果仅是事实列表进行更新，那么每一条规则必须记住已与之匹配的事实， 也就是说，如果一个新的事实与规则的第三模式相匹配，那么，前两个模式的匹 配信息必须存在以完成匹配过程。这种状态信息指出了与某一规则中自 面的模式 相匹配的事实，称之为部分匹配。规则的部分匹配是满足规则模式的任何一组事 实，它以规则的第一个模式开始，以任一模式( 包括最后一个模式) 为结束。因此， 一条有三个模式的规则对第一个模式、第一和第二个模式及第一、第二和第三个 模式都有部分匹配。一条规则的所有模式的部分匹配也是一个激活。另一种存储 的状态信息称为模式匹配。当一个事实满足了任一规则中的单个模式而不考虑在 其他模式中可能会限制匹配过程的变量时，则出现的就是模式匹配。 r e t e 算法通过利用规则中结构相似性的优点，提高基于规则的系统效率。结 构相似性是指许多规则通常包含了相似的模式或模式群。利用这一特性，r e t e 算法通过将公共部分放在一起来提高效率，因为公共部分不必多次计算。r e t e 模式匹配算法的主要缺点是内存使用量大，将所有的事实与所有的模式进行简单 的比较不需要使用内存。但是，存储使用了模式匹配和部分匹配的系统的状态会 消耗大量的内存。对每一模式，附加一个匹配事实来记录工作存储器中所有能与 之匹配的事实。当一个新事实加入到工作存储器时，算法找出所有能与之匹配的 模式，并将该事实加入到匹配事实表中；当一个事实从工作存储器中删除时，同 样找出所有与该事实匹配的模式，并将事实从匹配事实表中删除。r e t e 算法接受 对工作存储器的修改操作描述，产生一个修改冲突集的动作。总的来说，为了速 度而牺牲内存是值得的，然而要记住，一条设计不好的规则不仅运行速度慢，而 且会消耗掉大量内存。 2 1 5 规则文件 本系统规则引擎部分采用j b o s sr u l e s 1 1 】。j b o s sr u l e s 是一个基于r e t e 算 法( 同时支持l e a p 算法) ，专为j a v a 语言所设计的丌源规则引擎。 j s r 9 4 1 2 没有提供规则和动作该如何定义以及该用什么语言定义规则，也 没有为规则引擎如何读取和评价规则提供技术性指导。j s r 9 4 规范将上述问题 留给了开发规则引擎的厂商。规则语言是规则引擎应用程序的重要组成部分，所 有的业务规则都必须用某种语言定义并且存储于规则执行集中，从而规则引擎可 以装载和处理他们。由于没有关于规则如何定义的公用规范，市场上大多数流行 的规则引擎都有其自己的规则语言，j b o s sr u l e s 系统则采用系统专用的规则语 言d r l 2 1 来描述规则。如图2 1 0 所示，是一个最基本的d r l 文件示例。 此京i | i l j i 【i 人学t 程倾f j 专业学位论义 p a c k a g ec o b s a m pl e x m p o r tc 锄s a 瑚l e d r o o l 毒t e s 乞1 l e s a a g e ： r u l e g o o d b y e w h e n 撕l歉毒暑 g el毒t a 乞馏h e s s e g e g 0 b 张，m e 暑n a g e： 嫩0 5 妒i t h e n s y s t e m o u t p r i n t i n l 豫暑嚣囊q ei ； 珀5 e c 置e 骞a 曩g elm e s s a g el ； e n d 图2 - 1 0d r l 文件示例 上述文件中“g o o d b y e “ 代表了规则的名称，这个规则在工作内存中查找 c o m s a m p l e d r o o l s t e s t m e s s a g e 对象的实例。如果发现一个m e s s a g e 实例，并且 满足其属性s t a t u s 的值等于m e s s a g e g o o d b y e 对应的值，则将m e s s a g e 对象的 m e s s a g e 属性绑定到本地变量。然后规则触发结果，打印m e s s a g e 消息，同时为 m e s s a g e 的对象实例的m e s s a g e 属性赋值。 2 2 e t l 相关知识介绍 e t l 是一种数据处理的过程，它实现的是数据从原始业务数据系统到目标数 据系统的数据抽取，转换和装载的过程。他是对数据的处理，因此，e t l 中所用 到的数据是如何存储的将是我们关心的话题，下面将对e t l 设计到的相关的概念 进行简单介绍。 2 2 1 数据仓库 数据仓库是数据分析和决策支持的理想环境，它包括从多个异构数据源