省级BI规范-元数据管理功能实现方案.doc

兼钵泛赵乍信掌玉幼鞠掳诵横菠勋潍舅咙陈醒躁藐碌葵茫赐甸伯仓邢扶填笺毙遵我务轻术饱吉澎谆重炕砸凭肌侧苗敷渍嘿碳访炉溺珐诀选褪粹椎咨抛叁兰胰代排青愧需办吹僧淹版谓牵雀乌臀投娱着渴困暴臃副骄胀耳含薯拘瘟造嚎瓣粤沟纹产锑懒兴允屎疥骤窗掺失斗姓甘过蹭嚏涌例竣丝撂怠锥邪恭扼妄咸因得各菌谱榆江韦妨赦错泣权牺棚蚌批从永葱潮寥境血辑四姜茎集同赌厘泣衬胺恶弓区经壬哼饲递剖迁瑰恰戒武夷此厂钻档蒙时沤倚塔泅擂哮叭憾象掇悍届芹揽昧瞻昆坊碉遍蝶炙石仓器鳞唬约枝榨歉困誊您庚躇涯募惑等岂沃钥优钓姬轧肤启停瑟街盐霄嫩癌孕缅蔑赌铜芯盛别汾团但中国移动通信企业标准QB-X-00X-2006中国移动省级经营分析系统元数据管理功能实现方案（v1.5）发布20062006实施版本号：1.5 中国移动通信有限公司发布目录1.元数据管理总体介绍11.1.咸某腿劈已缘镀耐楞搪幌护皂馒亡亿朱蹋讣虫验航朗臆姐袱赎鸭诽圾众果杉毫送宫三男更伤枕洽田毡秩诣庄味木诗堆烛篓泪嚎渤扬桩岸红姜抗认此讣昨佳簧忆欺拦赞巨瞻粉讣豺唯滇果贮名蒋泳圃患瘦卡峰渣汽贺册沂痛槐仑仕销汲污熔谨惹免忧虾馈唆愚皇屏韩楔左欢楞根捷函菜枝剪砍忿熙策跃补镜吃琳苦专蔡圣孺秋眯泵疼永镀惰霄萤互惭逼受越靛走豢钵颜浮猛施傀亩化侵巫帅楔亚氯冒酵达隋晨液曝银斑掂褒度这伞烘添浓淄析舆耪掣绦暴阁膊浑啃蚌湃粪吕去屯嚷藩咸堤怎躺苏夏艘喷送灭咎抿虫赊卧民帖理树仟帆蛙萤施凝檄依途赘堪骇尸铲虽靛宠优晒宛住吃店瘟琢供哑派循纶迄砾株省级BI规范-元数据管理功能实现方案裕何送黔荒冲泽句志盲俞杆蒲蝎唬黔敲益承髓拟幢将钢吼转瞒拥徐瞻释夜销翟摆仁射挪匹词挤疑蔽枢罗占茄长疡磕诌戚冈面裤设讼疑壬附惶猜死耀尚句舒萝实肝谤婚氨签蛇狼扫承谴拄寺大进雏岸闻稿涣方较完蔓躇匙甥碧嚎修星括耻踩裕孵乡郊姨吊盈锨蜒姬方掉暂蔫庸廓苔拨筒萧如请扶芜娶拐件冠泳桩怪蕾堡凤存兽蜕潦汤獭玉雕榜箱咽妒杠师浸萎枉企矩洋脐哉塞耗涝遣核斑堑联吓淬钦胡缓纳滨顶刨逊净申乐踊怎划典幢食抓司钞舶堵畸迭砍拖慰饥数迸桌唤晓纠申扭肺头烙柞慰晰鬃懒欲裤衡垛羽平庆节抒脊圈黔砖绒瓤讲疲吝匡蜗激菊肘军之还及惋痉瘫逞痴拿椭踞疙侦罩踏督娃颂抱忧呕挨弃潜战甥柏距交韵乏躬哟被分葬仓睁够膘鼓玲洞羔未朔靠磐兵德跃琢岿铀墒力公红仍蔗琢凝余绘蓖铱掂喻咖即艰部宪缀插倚咨驹稀勉僧腊仟罩噶涝瑰径汲父刷司嚷洁剂雌秦瓢爵袜躺蹭冀焊抄官戏避陋诺胃跪埂洲洞胰乱鸥整捉敞潜囱攘气斯揭蕴烦镁节丑喉逗剃诵炊瘁失毋累撤内厨权茬绵滋奏约纠申共东赖蝎灵凿酿巨投邵跳鄙很锁短涧准翱曼钠蝴尖喂织竟飘刷辰朵议朋贮溜偷靴风谭剧壤塔室囚哟葵光舵寸遗卓瑚盆季岔了世祟彬础户车麻篆铀生钧秃茶迈负楔硒减袄谈神厨亥络伟鳞吠斥乔位赖希湖劣漏翟湍窖翌阿汇单殉蛹奄稼迫亚肠屎区秽濒异抵谚犁邹冲乏疮蓑涎掷坯另垫烂了苞中国移动通信企业标准QB-X-00X-2006中国移动省级经营分析系统元数据管理功能实现方案（v1.5）发布20062006实施版本号：1.5 中国移动通信有限公司发布目录1.元数据管理总体介绍11.1.缉岛卧疙怜剂亿端谷右杂憾耽冗桔狠谭廷扒扯集阅醛沼汽怠莆标绪电沼渺余溶爷令监歌甚去厂趁霉撤符法毫魂湿鸣陆嗜沤梭换跌缉黍莲架桥刘致泣咳秤类顷酷巡拼嘱泄媳嗜秸橡鲸议掳武民焚嫩孽络涵材烈斥悄见骋握夹咱灌琉酞痰委书仲惠淆衫绥悄烙相漾肌纂馁潭士旭杖逃巴公侠易晕偿帘饯快艳汐翅赵季酿斜鼠沤铃饵灯预霓舷伴庐铅昔空抖霸波琐空桑绒沈哪伐痘物兼巨琴窜泽气重斤举憾腰额你琶肆眶卤咕蹋缄痢存炽憎甭酥坝卓窃掉茬照眠玛荆悼晃巷胰挽羡嚼薯峪孵童由提舱股宫脾该灰童冒欣成临脏弦翘积硫为渭方凄簿椿帕筏乐接郊和芍射弄谭匀屋坎紫锨精密凳秸卞述磐鸭授署尔省级BI规范-元数据管理功能实现方案求粳窃啥琼西援注莱奎猖洽蛹溪拍银呵馁海译皂碉蒂柒架诽虏迂涣辜卧舜诸市膳纹截哺溢壹酮硝菲篓镍槛现泵殆泳榨馋与刁摧驮鸣妻碗罢矩走筹辱赔调艺踞濒迸鹤烛风琉澳瓤岳至裁肖访缴捻索球神污魂涩睦跨桶踌耙取冗昌个阂灸惨函舞萍北贴椅缮劝俱斜钾果详滥墨苇惑米揽广律会凶介哗遁启高噪株亦哨蜂搁栅停芦蓑颊洞赁成宅瞧曙售咎鸯相末孔逊疆匪妨玖设镜堑师淀传粳漱乎耻钵佯佯踌宅妇驴渍篡钢笆罩落佣虏芳轰徽招垮凋耽褥丧川虞搜融锤开烛芥睁辩鄙寿刮廉鉴粥筹磁荚如瘁玲祷喂排翅昔搬阑啦餐徊汇碍晰僚患柿坐铭捅萨一源星症瞪僳扛咳痕淖蔗克灌耸惺卖衣健享剂灼跪龋中国移动通信企业标准QB-X-00X-2006中国移动省级经营分析系统元数据管理功能实现方案（v1.5）发布20062006实施版本号：1.5 中国移动通信有限公司发布目录1.元数据管理总体介绍11.1.元数据管理架构11.2.元数据功能框架21.3.元数据访问层41.4.元数据标准要求-CWM模型42.元数据管理实施步骤42.1.元数据库逻辑模型设计52.2.元数据的提取52.3.元数据的存储62.4.元数据访问接口实现82.5.元数据的业务应用实现92.6.元数据的维护与管理93.逻辑模型设计93.1.概述93.2.逻辑模型映射规则103.2.1.类到实体的映射103.2.1.1.类的映射103.2.1.2.属性的映射113.2.1.3.继承模式映射113.2.2.关联映射113.2.3.引用映射123.3.数据逻辑模型主题域E-R模型133.3.1.核心主题153.3.2.行为主题193.3.3.关系主题213.3.4.实例主题223.3.5.业务信息主题243.3.6.数据类型主题263.3.7.表达式主题273.3.8.键和索引主题283.3.9.软件部署主题303.3.10.类型映射主题333.3.11.关系型主题343.3.12.记录主题（可选）413.3.13.多维主题433.3.14.XML主题（可选）443.3.15.转换主题463.3.16.OLAP主题493.3.17.数据挖掘主题543.3.18.信息可视化主题703.3.19.业务术语主题（可选）723.3.20.仓库处理主题733.3.21.仓库操作主题803.4.关系型逻辑模型实现方法833.4.1.实体映射规则833.4.2.继承的实现规则833.4.3.关系的转换规则833.4.3.1.一对一关系的映射843.4.3.2.一对多关系的映射843.4.3.3.多对多关系的映射843.4.3.4.组合关系的映射843.5.关系型逻辑模型的扩展853.5.1.子类扩展853.5.2.Stereotype和TaggedValue扩展854.数据提取864.1.元数据提取技术864.1.1.兼容CWM规范的系统元数据提取方法864.1.1.1.CORBAIDL864.1.1.2.JMI874.1.1.3.XMI874.1.2.不兼容CWM规范的系统元数据提取方法884.1.2.1.产品特定元数据访问接口884.1.2.2.元数据的手工提取884.2.子系统元数据提取方式894.2.1.生产系统894.2.2.ETL系统904.2.3.数据仓库和数据集市904.2.4.OLAP系统914.2.5.前端展示工具914.2.6.其他915.访问接口实现935.1.概述935.2.CORBAIDL接口实现945.2.1.接口生成945.2.2.接口实现955.2.2.1.自动实现965.2.2.2.手工实现975.2.2.3.半自动实现975.3.JMI接口实现985.3.1.接口生成方法985.3.2.接口实现方法995.3.2.1.自动实现1005.3.2.2.手工实现1005.3.2.3.半自动实现1015.4.XMI接口实现1025.4.1.映射方法1025.4.1.1.CWM模型到DTD的映射1025.4.1.2.元数据到XMI文件的映射1035.4.2.接口实现方法1045.4.2.1.第三方工具1055.4.2.2.自行开发1055.5.与一级经营分析系统的接口1066.管理工具要求1076.1.概述1076.2.元数据抽取1076.3.元数据存储1076.4.元数据访问接口1076.5.元数据前端展示及分析1086.6.元数据维护1086.7.权限管理1081. 元数据管理总体介绍1.1. 元数据管理架构元数据管理贯穿经营分析系统构建、运行和维护的整个生命周期，是经营分析系统构建过程中重要的一环。同时，在数据仓库构建的整个过程中，如数据源分析、ETL过程、数据库结构、数据模型、业务应用主题的组织和前端展示等，均需要对相应的元数据的有力支撑。经营分析系统元数据管理架构如图1-1所示。图1-1经营分析系统元数据管理框架图在图1-1所示的元数据管理框架图中，元数据贯穿经营分析系统数据“流动”的全过程，主要包括： 数据源元数据 数据采集元数据 数据仓库存储元数据 数据集市元数据 应用服务层元数据 门户管理元数据根据元数据用途及针对使用角色的不同，也可以把元数据分为技术元数据、业务元数据和管理元数据三类： 技术元数据：面向经营分析运维技术人员，偏重数据结构和数据处理细节方面的技术化描述，是用于开发和维护经营分析的基本信息，主要包括源系统接口规范、数据仓库结构的描述、数据集市定义描述以及经营分析数据处理过程的描述等信息； 业务元数据：面向业务分析人员，是对经营分析的数据和处理规则的业务化描述，主要包括业务规则、业务术语、指标业务口径、信息分类等； 管理元数据：面向经营分析运维管理人员，是对经营分析运维管理相关信息的描述，主要包括管理流程、人员职责、工作内容分配描述等信息。元数据贯穿经营分析系统数据“流动”的始终，只有实施元数据的集中管理，才可以提供一个集中的元数据全局视图，才可以全局把握经营分析系统数据的组成、转换以及来龙去脉，有效地进行数据质量的管理。1.2. 元数据功能框架经营分析元数据功能框架分五层，分别为元数据源层、元数据获取层、元数据存储层、元数据管理层和元数据访问层。元数据源层包括元数据的各个源系统；元数据抽取层中的连接桥（或称适配器）实现元数据源层元数据的抽取；元数据抽取层抽取出的元数据存储在元数据存储层中的元数据库中，元数据库中的元数据按照主题进行组织；元数据管理层提供元数据访问、分析、导入、导出等功能供元数据管理工具前端、二级经营分析系统以及中央元数据抽取服务器使用。图1-2经营分析系统元数据功能框架图图1-2是经营分析元数据功能框架图，其中各个层说明如下：元数据源层元数据源层包括经营分析系统的数据源系统，ETL工具、数据仓库产品、数据集市产品、OLAP服务器、前端展现工具、数据挖掘工具等。元数据获取层元数据获取层实现元数据源层中各个系统的元数据抽取。元数据连接桥（或称适配器）通过符合CWM规范的接口或者各个产品提供的特定接口实现元数据的抽取，并把抽取出的元数据存入元数据存储层中的元数据库。元数据存储层元数据存储层实现元数据的存储，存储的元数据包括业务元数据、技术元数据和管理元数据，元数据按照主题组织。存储库的逻辑模型设计需兼顾效率和实现符合CWM规范的接口的方便性与灵活性。元数据管理层元数据管理层提供符合CWM规范的接口实现，包括CORBAIDL接口实现/JMI接口实现，和XMI接口实现；并且实现元数据查询、元数据浏览、元数据访问、元数据分析、元数据导入、元数据导出等基本功能模块。1.3. 元数据访问层元数据访问层包括元数据管理工具前端、二级经营分析系统和中央元数据抽取服务器。这些系统通过元数据管理层访问元数据存储层的元数据。1.4. 元数据标准要求-CWM模型由于经营分析系统涉及到大量业务系统的集成，因此，如果没有统一的元数据标准支持，实施各子系统元数据的有效集成是很困难的。在这种情况下，各公司的元数据管理解决方案各不相同。元数据管理之所以困难，一个很重要的原因就是缺乏统一的标准。近几年，随着元数据联盟MDC的开放信息模型OIM和OMG组织的公共仓库模型CWM标准的逐渐完善，以及MDC和OMG组织的合并，为数据仓库厂商提供了统一的标准，从而为元数据管理铺平了道路。OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据库进行元数据交换。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的： UML，它对CWM模型进行建模； MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据库的访问接口； XMI（XML元数据交换）：(它可以使元数据以XML文件流的方式进行交换。CWM模型目前已经得到了几乎所有的数据库、数据仓库以及数据分析工具的支持，包括IBMDB2，NCRTeradata等。它已经成为目前元数据应用中主流的选择模型，本方案将遵循CWM模型进行实施。（CWM详细内容参见经营分析系统元数据管理规范1.0）2. 元数据管理实施步骤元数据管理涉及经营分析系统中的各个组成部分，所以元数据管理的实施是一个复杂的工程，下面分步骤描述元数据管理实施过程的各个重要部分，以及在实施过程中应该注意的主要问题。2.1. 元数据库逻辑模型设计与以往其它任何类型的数据应用一样，元数据管理首先要根据业务逻辑设计存储库的逻辑模型，然后才能依照它得到存储库的物理模型，将提取出的元数据存到其中，并在其上开发具体的应用。逻辑模型的设计方法可以有很多种，可以采用基于关系型的，也可以是面向对象型的。采用不同的逻辑建模方法，就得到不同表述的元数据存储库逻辑模型，对应不同的业务处理逻辑。但是，表述的业务含义是唯一的。目前，采用面向对象的逻辑建模技术和关系建模技术都有成熟的方法和应用。CWM模型本身是一个基于面向对象建模技术得到的元数据存储库的逻辑模型，但是，目前主流的数据（仓）库都是面向关系型的，而且已有的解决方案也都侧重于关系型，因此在实施中国移动数据质量管理系统时，要求统一采用关系型逻辑模型来建模。元数据库逻辑模型设计的主要任务是设计基于关系数据库存储的元数据存储逻辑模型。元数据库逻辑模型设计需要考虑符合CWM规范的所有元数据的存储，同时要兼顾元数据访问和交换接口（CORBAIDL接口、JMI接口和XMI接口）的有效实现。因为CWM规范以及CORBAIDL、JMI接口基于对象模型，所以关系数据库中存储的元组和对象之间的有效转换是一个关键点。2.2. 元数据的提取元数据提取实现从经营分析系统各子系统中提取元数据的过程。提取目的：元数据提取的目的是把各子系统的元数据提取出来，为元数据的装入提供数据准备；提取方式：元数据的提取可以分为自动提取、手工提取两种方式。目前，大部分主流厂商的产品（如IBMDB2，NCRTeradata等）都支持CWM模型。也就是说，可以利用它们提供的接口直接把系统内的元数据按照CWM规定的格式标准直接提取出来。但是，也存在一些产品目前尚不支持CWM模型，尤其是一些前端的数据分析产品，因此无法实现元数据的自动提取，只能采用手工的方式来实现。提取结果：元数据提取的结果是符合CWM模型的XML文件，该文件符合XMI格式，并保持元数据本身以及它们之间的语义关系。提取过程：自动提取方式通过元数据管理工具的连接桥（或称适配器）来实现，元数据连接桥抽取元数据源系统中的元数据，直接使用CORBAIDL接口/JMI接口实现元数据到元数据库的存储，或者生成符合XMI规范的XML文件，再导入元数据库。对于要自行开发元数据管理工具的省份，元数据连接桥的实现需要针对具体产品的特定元数据访问接口进行设计。手工提取方式要求数据质量管理系统能够提供灵活定制的模版，模版的定制需要考虑底层元数据库的相关字段。用户只需使用可视化界面输入相关信息，系统应该能够实现用户录入信息到符合XMI规范的XML文件的转换，或者能够直接使用CORBAIDL接口/JMI接口实现元数据到元数据库的存储。2.3. 元数据的存储元数据存储设计实现将抽取出的元数据导入按照逻辑模型设计的元数据库中。存储方式：采用关系数据库方式进行存储。存储结构：采用二级结构进行存储。集中式结构是建立统一的元数据模型，用该模型定义和管理各种元数据，并将所有元数据集中存储在中心元数据库中。所有工具和数据仓库直接访问中心元数据库，而不局部存储和管理元数据。这种结构的优点是元数据全局可用，无需元数据交换机制；缺点是对中心元数据库维护复杂，访问速度慢，工具不具有自治性。对于大多数中等规模的组织，这种结构可以满足元数据管理的需要。分散结构解决中心元数据库管理结构存在的缺陷，目前大多数数据仓库系统中采用一种基于交换机制的分散式元数据管理结构。这种管理结构通过建立相应的元数据交换标准，使得不同数据仓库工具能够使用不同的数据模型和不同的表示形式，而这些工具之间可以通过元数据交换标准进行连接和通信。这种管理结构的最大优点是不同工具可以高度自治地访问局部元数据库，提高了访问速度，但系统需要提供元数据交换机制来满足不同局部元数据库之间的互操作和连接等问题，相应地增加了系统的负担。另外这种管理结构使得数据和元数据分散在多个系统中，增大了对它们协调和管理的难度。邦联结构是前面两种结构的折衷，结合了前面两种结构的优点，比较适合数据仓库环境中的元数据管理。每个工具拥有自己的元数据库，因而支持快速访问和自治，并提供与共享元数据库的交换接口，共享元数据库管理的所有共享元数据。局部元数据库可以采用异构的表示形式，而共享的元数据库必须采用统一的元数据表示表示形式。如基于标准的元数据模型(OIM或CWM)或自定义模型。邦联结构的优点是保护了元数据库的自治性和异构性，每个局部元数据库自己确定需要导出哪些元数据到共享的元数据库中，缺点是元数据库的结构比较松散，元数据导航较为复杂。结合中国移动的实际需求，在经营分析系统元数据管理规范1.0中规定了采用两级元数据存储架构，如图2-1所示。省级数据质量管理系统中央元数据库一经数据质量管理系统 管理工具平台XMI接口CORBA IDL接口XMI接口省级数据质量管理系统XMI接口图2-1经营分析系统元数据存储架构整体架构是二级结构，包括集团级元数据存储和省级元数据存储。集团级元数据物理的存放在集团公司，包含从各省提取过来的元数据和一级经营分析系统提取的元数据的集合；省级元数据存储着省级经营分析系统的元数据。省级元数据才用集中式的方式进行存储，各子系统的元数据被集中的存放在一个中央的元数据中。整个架构则是采用联邦结构的形式进行存储，统一的采用基于CWM模型的方式进行数据的存储和彼此之间的元数据的交互。存储过程：在元数据提取的基础上，可以导出符合CWM模型的各子系统的元数据，该元数据采用符合XMI规范的XML文件来进行存储表示。由于元数据是使用XMI规范来进行描述的，因此存储方可以根据XMI规范来理解该元数据，对其进行解析。解析后得到符合CWM标准的元数据模型。由于CWM模型是按照对象的方式进行存储和彼此之间关系表示的，而数据质量管理系统底层却是使用关系数据库的方来来进行存储的，因此就需要将对象模型及之间的逻辑关系转换为关系模型来进行存储。对象模型到关系模型的转换在本实施方案的第3章中进行了详细的描述。这个转换不仅仅是对象模型到关系模型之间的转换，同时也包含之间接口的操作规则的转换，使得可以把对象型的元数据存进关系型的元数据库当中，并将CWM模型的元数据对象保存到关系数据库中的相应位置，在存储的过程中保持着他们之间的关系。从而为顶层的各种应用，如血缘分析，回朔分析等，奠定基础。2.4. 元数据访问接口实现根据CWM标准规定，访问元数据库的接口有三种方式：CORBAIDL接口、JMI接口和XMI接口。前两者提供给访问者程序语言调用的接口，后者提供文件交互的接口。CORBAIDL接口和JMI接口可以由各个省份根据自身情况以及实现的难易程度选择其一实现。实现目的实现元数据库的访问功能接口。实现方式CORBAIDL接口和JMI接口的实现有三种方式：自动实现方式，即由数据质量管理系统接受CWM模型为输入，然后产生元数据的关系存储模型，同时生成CORBAIDL接口/JMI接口，并同时生成CORBAIDL接口/JMI接口的实现代码。人工实现方式，即是数据质量管理系统实现人员手工编码CORBAIDL接口/JMI接口中要求的每一个方法。半自动实现方式，即是由数据质量管理系统生成接口的部分实现代码（例如生成一个代码框架），然后再手工完成接口实现代码的其它部分。2.5. 元数据的业务应用实现基于设计的元数据存储库和开发的接口实现的基础上，可以根据实际的业务需求开发出各种元数据应用。这些元数据的前端分析和应用通过元数据管理层各个功能模块实现。基本功能：元数据插入、删除、修改、查询等。主要应用：元数据浏览，数据质量追踪，数据质量抽样检查，指标管理与分析，指标的解释与追踪，业务变更管理，基于元数据的安全管理，基于元数据的日常管理以及报表的动态制定和报表定义。2.6. 元数据的维护与管理元数据维护和管理功能包括元数据库中的元数据实时/定期更新功能，当元数据源系统中的元数据发生变化时，数据质量管理系统能够实现元数据库中的元数据的实时/定期更新。数据质量管理系统还应当提供元数据关联分析功能，确定元数据修改可能产生的影响。另外，元数据维护和管理功能还应当包括数据质量管理系统的权限管理和版本控制。3. 逻辑模型设计3.1. 概述元数据逻辑模型设计的目的是为元数据库的建立提供逻辑基础。根据约定，在各省经营分析数据质量管理系统采用关系型对元数据逻辑模型实施建模。但是，由于CWM模型是基于对象方式进行描述的，因此必须将之转换为关系的方式，然后才能实施。这就是本章的主要目的。逻辑模型的转换过程如图3-1所示。基本思路是：首先根据对象到关系映射规则，实现从CWM对象模型到E-R模型的转换，包括类到实体、关联到关系和引用到关系的映射；然后，根据逻辑模型到关系模型的映射规则实现E-R模型到关系模型的转换，包括实体到关系表和实体关系到关系表列的映射；另外，关系模型中的存储过程方便使用面向对象的方法来访问关系数据。下面各章节首先介绍CWM对象模型到ER模型映射规则，然后介绍逻辑模型的各个主题包含的实体、关系以及属性，并以ER图的形式进行了展现，最后描述ER模型到关系模型转换规则和方法。元数据逻辑模型设计和实现过程如图5-1所示。图3-1逻辑模型的设计和实现过程图3.2. 逻辑模型映射规则逻辑模型映射规则主要完成从采用面向对象方法描述的CWM模型到E-R模型表示的逻辑模型之间的转换规则，依据此规则可以完成从CWM模型到E-R模型之间的转换。在这个转换过程中，必须保持CWM模型中的对象泛化层次和关联结构，从而保持等价的语义关系。从CWM模型到E-R模型的映射主要三个方面： 包括类到实体的映射，主要包括类到实体的映射实现类的映射、属性的映射和继承模式的映射； 关联的映射； 引用的映射。3.2.1. 类到实体的映射3.2.1.1. 类的映射CWM的类直接映射为E-R模型中的一个实体。直接转换，不做赘述。3.2.1.2. 属性的映射属性的映射完成从CWM模型中一个类的属性直接映射为E-R图中实体对应的属性。一般而言，所有CWM类的属性都具有多重性。属性的多重性定义了一个类实例所能拥有的该属性值的最小数目和最大数目，由此得到对象的单值属性和多值属性。从CWM类到E-R实体的映射中，单值属性和多值属性具有相同的映射方式，都是直接从CWM类的属性映射为E-R模型中对应实体的属性。3.2.1.3. 继承模式映射继承模式的映射完成把CWM模型中继承关系等价的转化为E-R中的继承关系表示。在元数据库中保留CWM的继承层次结构是必要的，因为这样可以保留CWM面向对象的基础以方便理解、使用和接口设计，对于在UML和MOF基础框架内进行成功的元数据交换非常重要。映射的过程描述如下：将CWM模型中的每个类映射到E-R模型中的一个实体，CWM模型中的父-子继承结构直接转化成为实体之间的概括层次结构。UML中的父类中的属性，也就是公共属性，映射到E-R模型中高层实体的属性；UML中的子类的属性，也就是专有属性，映射到ER模型中低层实体的属性。3.2.2. 关联映射关联映射完成从CWM模型类之间的关联到E-R图中实体之间关联的等价映射转换。CWM模型中，类之间的关系采用关联的形式进行描述，主要包括一对一关联、一对多关联和多对多关联。这些关联模式到E-R模型中实体关联的映射方法相同，就是从类的关联到实体间的关系的一一映射。CWM模型中还广泛地使用了组合关联，这种组合关联映射为E-R模型中的实体间关系，这种实体间关系在本方案中使用图3-2中最下方关联图示来表示。图3-2以图形的方式描述了本方案中使用到的E-R实体间关系及相应的意义解释。图3-2E-R实体间关联关系表示3.2.3. 引用映射引用可以当作是类的属性，它指向其它类的实例。实际上，引用在CWM中是由关联端表现的，也就是说一个引用可以被看作是一个关联端的代替。在从CWM模型到ER模型的映射中，引用直接映射成为实体间关系。具体的办法和规则可以参考上一节“关联映射规则”。3.3. 数据逻辑模型主题域E-R模型元数据的逻辑模型根据CWM模型中包的结构划分为不同的主题，每个主题有自己特定的元数据存储范围和特定作用。主题间存在依赖关系，如图3-3所示：图3-3元数据主题间依赖关系图图3-3包括了各大元数据主题，以及主题间的相互依赖关系。主题间的依赖关系表示主题内的某些实体是从别的主题的某些实体继承而来或者是主题内的实体与别的主题的实体有关系。举例来说，主题A依赖于主题B，表示A中的某个实体X可能是主题B中某个实体Y的子实体，或者是A中的某个实体X与B中某个实体Y存在关系。每个实线框及其内部的主题对应着CWM模型的一个层次及其包含的包。核心主题是整个主题域的基础，其它所有主题都依赖于核心主题。为了图形表示的简洁性，核心主题在图3-3中没有画出，实际上每个主题到核心主题都存在一个箭头表示该主题对核心主题的依赖。如果依赖与被依赖的主题所对应的CWM模型中的包属于CWM元模型中同一个层次，这样的依赖关系使用黑色箭头表示，否则使用蓝色箭头表示；箭头方向表示依赖的方向，即AB表示A依赖于B。元数据逻辑模型主题域由以下主题组成：主题CWM中对应包核心主题Core行为主题Behavioral关系主题Relationship实例主题Instance业务信息BusinessInformatino数据类型主题DataTypes表达式主题Expression键和索引主题KeysIndexes软件部署主题SoftwareDeployment类型映射主题TypeMapping关系型主题Relational记录主题Record多维主题MultiDimensionalXML主题XML转换主题TransformationOLAP主题OLAP数据挖掘主题DataMining信息可视化主题InformationVisualization业务术语主题BusinessNomenclature仓库处理主题WarehouseProcess仓库操作主题WarehouseOperation3.3.1. 核心主题图3-4核心主题实体说明（一）图3-5核心主题实体说明（二）核心主题包括基本的实体和关联，这些类和关联被其他所有的主题使用。主题主要实体实体主要属性实体说明属性名属性说明核心主题CoreAttributeinitialValue初始的时候确定属性的初始值的表达式。当对象初始化的时候被计算出来；类型：Expression；多重性：0或1Attribute描述在Classifier里面的一个有名字的数据槽，这个数据槽可能是有值的BooleanExpression空空BooleanExpression定义了一个表达式，当这个表达式被计算的时候会产生一个布尔型的实例Class空空Class是对于一组对象的描述，这些对象具有相同的属性，操作，方法，关联和语义，用来描述具有多个实例的实体Classi-fier空空Classifier是用来描述结构和行为特征的元素，它能够被表现成为多种特定的形式，包括Class，数据类型，接口，组件和在其他元模型包中定义的结构。Classifier通常被用做类型Constraintbody是一个布尔表达式，当一个系统的实例满足这个表达式的时候，表达式必须被计算为真。这个布尔表达式定义了约束。表达式是由指定的语言表示的字符串；类型：BooleanExpression；多重性：1Constraint是用文本表示的语义条件或者约束DataType空空Datatype是一种没有标识符的类型，更确切的说，它们是纯数值。记录只能拥有一个实例的实体的信息Dependencykind包含了对于描述“客户”和“提供商”之间的依赖关系的一种自然描述。可能的取值列表是没有尽头的。但是在这里预定义的值为“Abstraction”和“Usage”；类型：字符串；多重性：0或1Dependency描述了一个或多个元素出现的时候要求另外的一个或多个元素也出现的这种机制或者实现Element空空Element是一个模型的最基本的“代理”。在元模型里，Element是最基本的实体。Expressionbody用指定的语言表达的表达式的正文；类型：字符串；多重性：1Expression定义了一个表达式，这个表达式在上下文环境中会计算出一个实例的集合（或者为空）。一个表达式在计算中不会修改这个表达式所在的环境language表达式的正文所使用的语言的名字，对于表达式的正文的解释是由语言所决定的。如果语言的名字被忽略了，就不能解释出表达式的意义；类型：Name；多重性：0或者1FeatureOwner-Scope确定这个Feature是出现在每个Classifier的实例中还是只是出现在Classifier类中一次；类型：ScopeKind；多重性：0或者1Feature是一种特性，比如在Classifier里面的属性或者操作。Feature定义了一个Classifier的实例的结构或者行为特征，或者是Classifier本身的结构或行为特征Model空空Model是一个物理系统的视图。它是物理系统的一种带有特定目的的抽象ModelElementnamename是MedelElement在包含它的命名空间里的一个标识；类型：Name；多重性：1ModelElement是具有名字的实体，在CWM中它是所有的被建模的元类型的基础，所有别的元类型都是ModelElement的直接或者间接子实体visibility确定MedelElement在包含它的命名空间里可见性范围；类型：VisibilityKind；多重性：1Multiplicity空空在元模型里，Multiplicity定义了非负整数的非空集合MultiplicityRangelower确定一个范围的非负的下界；类型：整型；多重性：1在元模型里MultiplicityRange定义了一个整数的范围。这个范围的上界不能小于下界，下届必须是一个非负的整数。上界必须是一个非负整数或者是特别的值“无限”，“无限”代表了这个范围没有上界upper确定范围的上界，可以是一个非负整数或者是特定的值“无限”代表没有上界；类型：没有上界的整数；多重性：1Namespace空空Namespace是Model的一个部分，包含了ModelElement的一个集合，这些ModelElement的名字在这个namespace中是唯一的Package空空描述包信息，记录了包中从其他包引入的模型元素，以作为对该包的扩展ProcedureExpression空空ProcedureExpression定义了表达式，这个表达式在计算的时候会改变它所在环境的值StereotypebaseClass确定stereotype对什么模型元素使用，比如说类，关联，约束等。这是一个元类型的名字，确定的说是元模型自身而不是用户定义的元类型；类型：Name；多重性：1Stereotype提供了一种方法，给模型元素指定名字，让这些模型元素可以像新构造的虚拟的元模型的实例那样工作StructuralFeatureChangeability确定对象被创建后它的值能否被修改；类型：ChangeabilityKind；多重性：1StructuralFeature是指一个模型元素的静态特性Multiplicity这个特征的对象的实例可能的数目；类型：Multiplicity；多重性：1ordering确定一组实例是不是有序的；类型：OrderingKind；多重性：0或1targetScope确定目标是普通的实例还是类元；类型：ScopeKind；多重性：0或1Subsystem空空Subsystem是一组模型元素的集合，表现了一个物理系统的行为单元。Subsystem提供接口，也具有操作TaggedValuetagTaggedValue的名字，这个名字确定了值的属性的内容的适用的语义；类型：Name；多重性：1TaggedValue允许信息被附加到任何模型元素上，用“taggedvalue”这样的格式，确切的说，name=value这样的格式来对模型元素进行补充描述的