ORM

一、Object/Relation Mapping　　对象-关系数据库映射

　　什么是ORM?

　　对象关系映射（ORM）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：

　　简单：以最基本的形式建模数据。

　　传达性：数据库结构被任何人都能理解的语言文档化。

　　精确性：基于数据模型创建正确标准化了的结构。

　　典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。

　　规则表达式

　　ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。

　　简单事实的一些例子包括：

　　人有电话

　　人住在某个地方

　　人生于某个日期

　　人在某个日期被雇佣

　　ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。

　　ORM模型的简单性简化了数据库查询过程。使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。

　　=================================================================================================

　　对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。

　　对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。

　　面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。

　　让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。

　　当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。

　　如果打开你最近的程序，看看DAL代码，你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例，你传入一个对象，为SqlCommand对象添加SqlParameter，把所有属性和对象对应，设置SqlCommand的CommandText属性为存储过程，然后运行SqlCommand。对于每个对象都要重复的写这些代码。

　　除此之外，还有更好的办法吗？有，引入一个O/R Mapping。实质上，一个O/R Mapping会为你生成DAL。与其自己写DAL代码，不如用O/R Mapping。你用O/R Mapping保存，删除，读取对象，O/R Mapping负责生成SQL，你只需要关心对象就好。

　　对象关系映射成功运用在不同的面向对象持久层产品中，如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。

　　一般的ORM包括以下四部分：

　　一个对持久类对象进行CRUD操作的API；

　　一个语言或API用来规定与类和类属性相关的查询；

　　一个规定mapping metadata的工具；

　　一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。

　　一、目前流行的 ORM 产品

　　目前众多厂商和开源社区都提供了持久层框架的实现，常见的有：

　　Apache OJB （http://db.apache.org/ojb/）

　　Cayenne （http://objectstyle.org/cayenne/）

　　Jaxor （http://jaxor.sourceforge.net）

　　Hibernate （http://www.hibernate.org）

　　iBatis （http://www.ibatis.com）

　　jRelationalFramework （http://ijf.sourceforge.net）

　　mirage （http://itor.cq2.org/en/oss/mirage/toon）

　　SMYLE （http://www.drjava.de/smyle）

　　TopLink （http://otn.oracle.com/products/ias/toplink/index.html）

　　其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。

　　其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。

　　二、对象－关系映射模式

　　从《公共仓库元模型：开发指南》一书第8章CWM元仓库中摘录出来的内容，实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射，是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。

　　基本情况：公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准，采用UML表示的对象层次结构，在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流)，所以该书的作者倾向于使用成熟的关系型数据库来保存－这也是存储本体时所遇到的问题。

　　采用方法：将UML模型中的各种元素通过转换，保存为数据库模式。由于CWM是一种元模型，因此模型的实例也是一种模型，将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。

　　1、数据类型映射模式

　　1.1简单数据类型模式：建立UML和关系型数据库中简单数据类型的映射表以指导映射。

　　1.2枚举数据类型模式：每种枚举类型对应一个表，只有一个列(_EnumLiteral)表示枚举值。

　　1.3基于类的数据类型模式：使用外键约束，将基础列与基于类的类型实例相关联。

　　2、类映射模型

　　每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射，而引用属性将在关联映射模式中提到。

　　2.1单值属性模式：是cardinality的上界为1的属性，映射到类所对应的表的列上。若其下界也为1（必须有的属性），列属性为NOT NULL。

　　2.2多值属性模式：每个多值属性映射成一个独立的表，使用外键连接到类所对应的表上。

　　2.3继承模式：每加入一个类的实例时，根据其继承关系自顶向下生成每个类的对象，这些对象具有相同的ID（根对象对应记录的主键）。删除对象实例时，自底向上删除数据。遇到从中间删的情况怎么办？多重继承怎么处理？（金龙飞）

　　3、关联映射模式

　　3.1一对一关联模式：在关联两端各加一列。

　　3.2一对多关联模式：和3.1一样。如果多这端是有序的，还需加入一列表示序号。

　　3.3多对多关联模式：将关联单独作一个表。

　　3.4组合关联模式：注意级联式删除。

　　3.5反演关联模式：关联两端指向相关的类型，和普通关联一样。

　　3.6成对关联模式：关联记录两个类间的关系，用交集类表示关联，表示成一个单独的表，每个关联对应一个表，用外键表示它们间的关系。

　　3.7关联上的OCL需要分析成对应的存储过程代码。

　　3.8保证关联的cardinality也需要分析成对应的存储过程代码。

　　4、引用映射模式

　　在UML中不存在的MOF特征，指属性是声明为引用类型的实例。用存储过程实现。

[编辑本段]

二、Operational Risk Management

　　操作风险管理

　　一、操作风险的界定与基本特点

　　通常，银行的风险管理一般将信用风险管理、市场风险管理、操作风险管理并列为三大领域。与信用风险管理、市场风险管理相比，操作风险的管理应当说还处于起步阶段，目前甚至还没有形成一个统一的、国际认可的定义。不过，随着操作风险的影响不断增大，国际银行界已经越来越将巴塞尔银行委员会的定义作为标准化的界定：

　　“操作风险就是指由于内部程序、人员、系统不充足或者运行失当、以及因为外部事件的冲击等导致直接或者间接损失的可能性的风险。”，巴塞尔委员会同时指出，这一界定包含了法律风险，但是并不包含策略性风险和声誉风险。 当前，操作风险已经成为全球银行业风险管理日趋重要的领域之一。实际上，操作风险并不仅仅与银行的“操作”（如后线支持、信息系统出现故障、业务流程上的问题等等）相关，而且也与银行业务操作之外的领域相关，如欺诈交易（rogue trading）、模型的风险、报告和会计体系出现问题等。

　　从广义来说，操作风险可以划分为操作性杠杆风险（operational leverage risk）和操作性失误风险（operational failure risk）。操作性杠杆风险主要是指外部因素引起的操作风险，如因为外部冲击导致金融机构收益的减少、这些外部冲击包括税制和政治方面的变动、监管和法律环境的调整、竞争者的行为和特性的变化等，通常衡量这个操作风险的方法是运用情景分析（scenario analysis）。操作性失误风险主要是指因为金融机构的内部因素引起的操作风险，这些内部因素主要包括处理流程、信息系统、人事等方面的失误。总体来看，操作性失误风险在整个操作风险中所占据的比重近年来明显上升。

　　如果对操作失误风险作进一步细分，我们还可以划分为：（1）执行风险：即执行人员不能证券理解管理人员的意图或者有意错误操作等；（2）信息风险，即信息在机构内部、或者机构内外之间的产生、接收、处理、储存、转移等环节出现故障；（3）关系风险，即因为产品和服务、管理等方面的问题影响到客户与金融机构的关系；（4）法律风险，即金融机构的经营管理活动不符合所在地的法律和监管要求所导致的风险；（5）人员风险，即缺乏足够合格的员工、缺乏对员工表现的恰当评估和考核等导致的风险；（6）系统事件风险，即电脑系统等出现故障所可能导致的风险。根据巴塞尔新资本协议的要求和不同金融机构的实际状况，还可以提出更为详细的操作风险的细分。

　　（一）操作风险的特点

　　1与市场风险和信用风险不同的是，操作风险中的风险因素是内在于银行的业务操作的，而且单个的操作风险因素与操作性损失之间并不存在清晰的、可以定量界定的数量关系。因此，对于操作风险的管理，具体的业务部门应当承担第一位的作用，董事会则应当承担最终的责任。

　　2在业务规模大、交易量大、结构变化迅速的业务领域，受到操作风险冲击的可能性最大。

　　3 由于通常可以监测和识别的操作风险因素同由此可能导致的损失规模、频率之间不存在直接的关系，因而银行的风险管理部门难以确定哪些因素对于操作风险管理来说是最为重要的。

　　4 从覆盖范围看，操作风险管理实际上覆盖了几乎银行经营管理的所有方面的不同风险（a catch-all title for a set of very diffent risks），从一个极端看，操作风险既包括那些发生频率高、但是可能造成的损失相对较低的日常业务流程处理上的小错误；在另外一个极端，操作风险也包括那些发生频率低、但是可能导致的损失相对高的自然灾害、大规模舞弊等。因此，试图用一种方法来覆盖操作风险的所有领域几乎是不可能的。

　　（二）操作风险应当包含的内容

　　目前，国际金融界关于操作性风险应当包含那些内容，也依然存在相当明显的争论和分歧。大致来说，可以归结为以下几个方面：

　　基本认同的内容

　　1 清算失误

　　2 交易记录错误

　　3 火灾和洪灾等灾害

　　4 系统故障

　　部分认同的内容

　　1 内部舞弊

　　2 外部舞弊

　　3 虚假交易

　　4 不适当的销售技术

　　5 战略决策失误（如进入边际收益已经很低的业务领域）

　　少数认同的内容

　　1 市场逆转时导致的损失

　　2 交易对手违约

　　同时，从金融几个的不同业务领域看，投资银行业务、市场交易业务、公司业务等被视为市场风险和信用风险主导的业务（market and credit risk dominates），零售业务、资产管理业务、信托业务、服务性收费业务则被视为操作风险主导的业务（operational risk domonates）。

　　二 操作风险衡量的主要方法

　　在2001年巴塞尔新资本协议中，操作风险被给予了一个明确的定义，同时，这份新资本协议还确定了比较宽泛的资本要求，即配置到操作风险的资本为当前金融机构最低资本金水平的20％，显然这是一个相当高的水平，大多数银行看来不愿意配置如此高水平的资本金到操作风险方面。为此，新的资本协议提供了多种可供选择的衡量操作风险、及其所需配置的资本金的方法，这主要包括： （1）基本指标方法：对于业务活动范围有限的小型银行，覆盖操作风险的资本为总收入的一个比率（目前这个比率暂时确定为30％）。

　　（2）标准法，这种方法将金融机构划分为不同的业务线，对于每种业务线，其所需的资本为beta 乘以敞口系数，beta由监管当局根据样本银行的基本数据进行测算和确定。

　　（3）内部衡量方法，这种方法要对每种业务线和每种类型的损失分别从内部采集数据进行计算，每种业务线的预期损失为敞口系数、损失概率和给定事件的损失等共同确定的，所需配置的资本则是gama系数与预期损失的乘积。目前，很少有银行能够采用内部衡量方法，因为当前很少有银行能够积累足够充分的内部损失数据来建立相关的模型，当然其中部分数据也可以向外部采集。

　　从目前金融机构在风险管理方面的实践看，当前正在被采用的衡量操作风险的主要方法主要包括：

　　1 监测主要指标。这主要是运用不同业务线最能代表其操作风险的指标（如成本、收益、资产、交易量等）进行衡量。其主要优点是简单易行，但是这种方法不能注意到不同业务线、不同领域的操作风险的差异。金融机构在着手监测操作风险时，值得关注的指标主要包括：（1）交易失误的记录，包括失误的汇总分析、趋势分析、前台、中台和后天之间的合作状况等；（2）保管业务和仓库等的报告；（3）不同系统之间的整合状况；（4）清算系统、外汇交易系统、交易代理业务的状况等。

　　2 参考外部指标。运用外部机构在不同业务领域管理操作风险时所采用的范围、方法及其测算的结果，作为自身的参照。在运用这种方法时，如果选取的外部指标得当，实施起来也相对简单，便于不同金融机构之间的对比，而且也可以作为对其他测算方法的有效性的检测（sanity check）。但是，这种方法一般被视为只是一种对比性的测量，而不是基于不同金融机构自身特点的定量化分析；同时，这种测量方法不能鼓励金融机构采取积极的缓释操作风险的方法。 3 统计分析。通过采集内部的历史损失数据建立统计模型，测算在不同的业务部门和整个金融机构范围内所需要配置的资本水平。这种方法为许多金融机构和咨询公司所采用。这种方法实施的实际效果取决于内部历史损失数据的质量和数量，而且不能灵敏地反映金融机构动态的风险变动状况。

　　4 计分卡方法。这主要是包括多项前瞻性的关于操作风险的指标。通常金融机构运用这种方法来分配其他方法测算出来的所需的资本金。采用这种方法能够对前线的业务人员形成积极的激励机制，促使其积极监控操作风险。不过，这种方法得出的结果是否可靠，关键取决于设计这种方法的专家，因为计分卡所选取的指标、以及不同指标所占的权重都是有专家来确定的。 5 体现风险及其影响的因果关系的复杂模型。这主要是指金融机构在对操作风险及其可能导致的损失的因果判断的基础上，通过采集历史数据建立自身的关于操作风险的模型。这种方法测量的效果应当说是最好的，如果金融机构能够成功实施的话，这种方法能够促使前线的业务人员积极参与操作风险的管理，因为这种方法不仅考虑了操作风险所可能导致的损失，而且还考虑了可能导致这种损失的预警性指标和因素。但是，这种方法对于内部数据采集的要求最高（data availability），开发整个模型所需要投入的资源最多，在整个金融机构范围内统一实施的难度自然也较大。

　　正如我们的分析所指出的，因为不同的衡量方法之间存在的优劣各有不同，因而综合运用不同的方法进行判断和相互引证，可能是效果最好的方法。目前，关于操作风险的模型还存在相当大的分歧和争论，不过其基本目标应当是一致的，就是测算操作风险所可能带来的损失，并相应配置资本，提出管理操作风险的方法。在这个测算过程中，重点要确定不同类型的操作风险发生的部门和领域、这种风险发生的可能性、以及发生这种事件所可能导致的损失。

　　从具体的定量衡量的角度看，描述操作风险经常采用的函数形状是浴缸型的（bathtub shape），即：一个操作性的系统在引入初期，员工缺乏经验，管理上存在漏洞，因而出现操作风险的概率较高；随着系统的运行正常，风险频率较低，主要是一些随机性的故障；最后，随着系统的老化、以及环境的变化，出现操作风险的概率重新上升。在早期阶段，运用有经验的员工、强化对员工的培训、系统在投产之前进行多方位的测试等都可以降低操作风险出现的概率；另外，常用的模型还包括VAR的测算等。

　　在实行操作风险管理的早期阶段，不少金融机构采用一些便于实施的方法，其中主要是偏于主观的操作风险衡量技术。这种方法主要依赖大量动员人力在机构内部采集数据、进而进行损失的分析，在分析中主要是确定三个方面的因素，即处理失误的数量、损失的规模、不同部门的审核评分。操作风险的管理人员在这三个因素的基础上确定不同业务部门、不同部门的不同环节在操作风险管理中的相对重要性。

　　总体上看，在金融机构的风险管理实践中，与信用风险和市场风险相比，操作风险的定量衡量应当说还处于婴儿阶段。

　　三 操作风险管理在金融机构的引入和管理框架的建立

　　目前国际范围内在操作风险管理方面水平相对较高的金融机构，通常都建立罗强有力的操作风险管理流程和框架，并将操作风险与管理其他风险所采用的方法和框架有机整合起来，而且通过有效管理操作风险减少了收入的波动性，其中有些机构还改进了自身的外部评级水平。巴塞尔新资本协议的颁布及其实施，就促使操作风险进一步向更多的金融机构扩展。

　　立足于国际金融界的经验，金融机构在引入操作风险管理、建立操作风险管理框架时，需要重点注意以下几个方面的问题：

　　1 在建立基本运作程序的同时，从容易衡量的领域着手。从具体的实施过程看，国际金融界的经验是，首先建立一套相对简略的、但是比较完整的操作风险的管理体系，这个体系应当基本覆盖操作风险的识别、评估、缓释、监控、报告等环节，在此基础上建立覆盖整个机构的操作风险管理战略和政策，从相对简略的领域出发，在实际运作中逐步完善，扩大其覆盖的操作风险的领域。

　　2 金融机构在着手管理操作风险时，重点要建立与信用风险和市场风险相一致的操作风险的管理框架，确定不同职位的人员在操作风险管理中的责任（如业务管理人员，其中特别是零售业务部门的操作人员；中台人员；稽核部门；风险管理部门等）。。在此基础上，风险管理委员会等高层机构应当确定打算选用的风险管理方法，业务部门应当据此采集关于操作风险的各种数据，向市场寻求专业的咨询和支持，逐步建立初步的操作风险管理体系。

　　严格地说，整个金融机构范围内管理不同风险的基本原则和方法应当一致，这意味着新建立的操作风险管理框架必须要整合到与信用风险和市场风险管理相一致的框架中去，操作风险所运用的方法和原理也应当与整个企业在风险管理方面运用的相协调。

　　3 风险管理部门并不是操作风险管理的唯一部门，具体的业务部门、法律部门、稽核部门都承担着进行操作风险管理的责任。如果说市场风险和信用风险的管理日趋强调集中化（centralization）的话，那么，操作风险的管理则必须强调分散化（decentralized）.严格地说，具体的业务部门在操作风险管理方面应当承担第一位的责任。这是由操作风险的特征所决定的，当然关于操作风险管理的具体原则应当由风险管理部门提供。

　　4 操作风险的报告体系。操作风险的报告系统应当独立于业务部门，并且应当能够敏感地反映操作风险的变动，主要数据自动生成，在整个机构来采用的采集方法保持一致。

　　5 操作风险体系中的激励和考核机制。在具体的管理人员介入操作风险系统的运行时，就存在着其机会主义式地运用这一系统的可能性，因此，建立完善的激励机制和绩效考核制度在操作风险管理中同样十分重要。同时，即使一个机构中建立了相当自动化的操作风险报告体系，但是如果高级管理人员不能动态地介入整个管理过程、不能将报告的结果与员工和部门的绩效考核有机结合起来，这个系统的运作效果也会大打折扣。

　　6 董事会和高级管理层在操作风险的管理中应当承担更大的责任，包括建立清晰的管理结构、明确的责任分工，并且保证操作风险的管理框架能够覆盖所有的相关领域，还应当建立清晰的关于操作风险的管理和报告程序。 7 所有的业务部门和支持性部门都应当整合在整个操作风险的管理框架中。

　　8 寻求合格的、充足的操作风险管理人员。从人员构成看，目前的一些国际性金融机构中的操作风险管理人员主要有不同业务部门的管理经历、法律或者稽核人员、业务计划人员、信息安全人员等。较之信用风险和市场风险，操作风险管理方面有实际经验的人员相对较少，大部分需要金融机构结合自身的实际情况进行培训，还有一部分需要向外部招聘。

　　9 建立恰当的操作风险管理架构。目前，全球范围内管理操作风险主要采取三种方法：总部集中管理型；总部集中管理与分散化支持的类型；稽核部门占据主导作用的类型。选择其中任何一种类型，主要取决于各自的企业文化和董事会的风险偏好、自身的风险管理能力等。