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

中国移动通信人%ll>梃QB-X-00X-2006由国跋钥如幽谷4圻SS2006实施发布2006中国移动通信发布ZU>¾&*三EVNQVV1.3. 元数据访问层31.4. 元数据标准要求-CWM模型32 .元数据管理实施步骤42.1. 元数据库逻辑模型设计422元数据的提取42.3. 元数据的存储52.4. 元数据访问接口实现72.5. 元数据的业务应用实现82.6. 元数据的维护与管理83 .逻辑模型设计83.1. 概述83.2. 逻辑模型映射规那么93.2.1. 类到实体的映射91.1. 1.1.类的映射91.2. 1.2.属性的映射91.3. 1.3.继承模式映射103.2.2. 关联映射103.2.3. ,引用映射113.3. 数据逻辑模型主题域E-R模型H3.3.1. ,核心主题123.3.2. ,行为主题163.3.4. 实例主题183.3.5. 业务信息主题193.3.6. 数据类型主题203.3.7. 表达式主题213.3.8. 键和索引主题223.3.9. 软件部署主题233.3.10. 类型映射主题253.3.11. 关系型主题253.3.12. 记录主题（可选）293.3.13. 多维主题313314.XM1.主题（可选）313.3.15. 转换主题323.3.16. O1.AP主题353.3.17. 数据挖掘主题383.3.18. 信息可视化主题533.3.19. 题（可选）553.3.20. 仓库处理主题563.3.21. 仓库操作主题623.4. 关系型逻辑模型实现方法643.4.1. 实体映射规那么643.4.2. 继承的实现规那么653.4.3. 关系的转换规那么653.4.3.1. 一对一关系的映射65343.2.一对多关系的映射653.433,多对多关系的映射66343.4.组合关系的映射663.5.关系型逻辑模型的扩展663.5.1.子类扩展663.5.2.Stercotype和TaggedValue扩展674.数据提取674.1.1.1.CORBAID1.684.1.1.2.JMI684.1.1.3.XMI694.1.2.不兼容CWM标准的系统元数据提取方法694.1.2. 1.产品特定元数据访问接口694.1.3. 2.元数据的手工提取704.2.子系统元数据提取方式704.2.1. 生产系统704.2.2. ET1.系统714.2.3. 数据仓库和数据集市714.2.4. O1.AP系统724.2.5. 前端展示工具724.2.6. 其他735.访问接口实现735.1. .概述735.2. CORBAID1.接口实现741.1. 1.接口生成74.2.接口实现751.2. 2.1.自动实现765.222. 手工实现76522.3. 半自动实现775.3. JMI接口实现785.3.1. 接口生成方法785.3.2. 接口实现方法795.3.2.1 .自动实现795.3.2.2 ,手工实现805.3.2.3 自动实现815.4. XMI接口实现815.4.1. 映射方法825.4.1.1 元数据到XMI文件的映射835.4.2. 接口实现方法845.4.3. 1.第三方工具845.4.4. 自行开发855.5. 与一级经营分析系统的接口856,管理工具要求866.1. 概述866.2. 元数据抽取866.3. 元数据存储866.4. 元数据访问接口866.5. 元数据前端展示及分析876.6. 元数据维护876.7. 权限管理871.元数据管理总体介绍1.1.元数据管理架构元数据管理贯穿经营分析系统构建、运行和维护的整个生命周期，是经营分析系统构建过程中重要的一环。同时，在数据仓库构建的整个过程中，如数据源分析、ET1.过程、数据库结构、数据模型、业务应用主题的组织和前端展示等，均需要对相应的元数据的有力支撑。经营分析系统元数据管理架构如图1-1所示。图1“经营分析系统元数据管理框架图在图1-1所示的元数据管理框架图中，元数据贯穿经营分析系统数据“流动”的全过程，主要包括： 数据源元数据 数据采集元数据 数据仓库存储元数据 数据集市元数据 应用效劳层元数据 门户管理元数据根据元数据用途及针对使用角色的不同，也可以把元数据分为技术元数据、业务元数据和管理元数据三类： 技术元数据：面向经营分析运维技术人员，偏重数据结构和数据处理细节方面的技术化描述，是用于开发和维护经营分析的根本信息，主要包括源系统接口标准、数据仓库结构的描述、数据集市定义描述以及经营分析数据处理过程的描述等信息； 业务元数据：面向业务分析人员，是对经营分析的数据和处理规那么的业务化描述，主要包括业务规那么、业务术语、指标业务口径、信息分类等； 管理元数据：面向经营分析运维管理人员，是对经营分析运维管理相关信息的描述，主要包括管理流程、人员职责、工作内容分配描述等信息。元数据贯穿经营分析系统数据“流动”的始终，只有实施元数据的集中管理,才可以提供一个集中的元数据全局视图，才可以全局把握经营分析系统数据的组成、转换以及来龙去脉，有效地进行数据质量的管理。1.2. 元数据功能框架经营分析元数据功能框架分五层，分别为元数据源层、元数据获取层、元数据存储层、元数据管理层和元数据访问层。元数据源层包括元数据的各个源系统;元数据抽取层中的连接桥（或称适配器）实现元数据源层元数据的抽取；元数据抽取层抽取出的元数据存储在元数据存储层中的元数据库中，元数据库中的元数据按照主题进行组织；元数据管理层提供元数据访问、分析、导入、导出等功能供元数据管理工具前端、二级经营分析系统以及中央元数据抽取效劳器使用。图12经营分析系统元数据功能框架图图1-2是经营分析元数据功能框架图，其中各个层说明如下：元数据源层元数据源层包括经营分析系统的数据源系统，ET1.工具、数据仓库产品、数据集市产品、O1.AP效劳器、前端展现工具、数据挖掘工具等。元数据获取层元数据获取层实现元数据源层中各个系统的元数据抽取。元数据连接桥（或称适配器）通过符合CWM标准的接口或者各个产品提供的特定接口实现元数据的抽取，并把抽取出的元数据存入元数据存储层中的元数据库。元数据存储层元数据存储层实现元数据的存储，存储的元数据包括业务元数据、技术元数据和管理元数据，元数据按照主题组织。存储库的逻辑模型设计需兼顾效率和实现符合CWM标准的接口的方便性与灵活性。元数据管理层元数据管理层提供符合CWM标准的接口实现，包括CoRBAlD1.接口实现/JMI接口实现，和XMl接口实现；并且实现元数据查询、元数据浏览、元数据访问、元数据分析、元数据导入、元数据导出等根本功能模块。1.3. 元数据访问层元数据访问层包括元数据管理工具前端、二级经营分析系统和中央元数据抽取效劳器。这些系统通过元数据管理层访问元数据存储层的元数据。1.4. 元数据标准要求-CWM模型由于经营分析系统涉及到大量业务系统的集成，因此，如果没有统一的元数据标准支持，实施各子系统元数据的有效集成是很困难的。在这种情况下，各公司的元数据管理解决方案各不相同。元数据管理之所以困难，一个很重要的原因就是缺乏统一的标准。近几年，随着元数据联盟MDC的开放信息模型OIM和OMG组织的公共仓库模型CWM标准的逐渐完善，以及MDC和OMG组织的合并，为数据仓库厂商提供了统一的标准，从而为元数据管理铺平了道路。OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据库进行元数据交换。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的： UM1.,它对CWM模型进行建模； MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据库的访问接口； XMl（XM1.元数据交换）：（它可以使元数据以XM1.文件流的方式进行交换。CWM模型目前已经得到了几乎所有的数据库、数据仓库以及数据分析工具的支持，包括IBMDB2,NCRTeradata等。它已经成为目前元数据应用中主流的选择模型，本方案将遵循CWM模型进行实施。（CWM详细内容参见经营分析系统元数据管理标准）2,元数据管理实施步骤元数据管理涉及经营分析系统中的各个组成局部，所以元数据管理的实施是一个复杂的工程，下面分步骤描述元数据管理实施过程的各个重要局部，以及在实施过程中应该注意的主要问题。2.1. 元数据库逻辑模型设计与以往其它任何类型的数据应用一样，元数据管理首先要根据业务逻辑设计存储库的逻辑模型，然后才能依照它得到存储库的物理模型，将提取出的元数据存到其中，并在其上开发具体的应用。逻辑模型的设计方法可以有很多种，可以采用基于关系型的，也可以是面向对象型的。采用不同的逻辑建模方法,就得到不同表述的元数据存储库逻辑模型,对应不同的业务处理逻辑。但是，表述的业务含义是唯一的。目前，采用面向对象的逻辑建模技术和关系建模技术都有成熟的方法和应用。CWM模型本身是一个基于面向对象建模技术得到的元数据存储库的逻辑模型，但是，目前主流的数据（仓）库都是面向关系型的，而且已有的解决方窠也都侧重于关系型，因此在实施中国移动数据质量管理系统时，要求统一采用关系型逻辑模型来建模。元数据库逻辑模型设计的主要任务是设计基于关系数据库存储的元数据存储逻辑模型。元数据库逻辑模型设计需要考虑符合CWM标准的所有元数据的存储，同时要兼顾元数据访问和交换接口（CORBAlD1.接口、JMl接口和XMl接口）的有效实现。因为CWM标准以及CoRBAID1.、JMl接口基于对象模型，所以关系数据库中存储的元组和对象之间的有效转换是一个关键点。2.2. 元数据的提取元数据提取实现从经营分析系统各子系统中提取元数据的过程。提取目的：元数据提取的目的是把各子系统的元数据提取出来，为元数据的装入提供数据准备;提取方式：元数据的提取可以分为自动提取、手工提取两种方式。目前，大局部主流厂商的产品（如IBMDB2,NCRTeradata等）都支持CWM模型。也就是说，可以利用它们提供的接口直接把系统内的元数据按照CWM规定的格式标准直接提取出来。但是，也存在一些产品目前尚不支持CWM模型，尤其是一些前端的数据分析产品，因此无法实现元数据的自动提取，只能采用手工的方式来实现。提取结果：元数据提取的结果是符合CWM模型的XM1.文件，该文件符合XMI格式，并保持元数据本身以及它们之间的语义关系。提取过程：自动提取方式通过元数据管理工具的连接桥（或称适配器）来实现，元数据连接桥抽取元数据源系统中的元数据，直接使用CORBAlD1.接口/JMI接口实现元数据到元数据库的存储，或者生成符合XMI标准的XM1.文件，再导入元数据库。对于要自行开发元数据管理工具的省份，元数据连接桥的实现需要针对具体产品的特定元数据访问接口进行设计。手工提取方式要求数据质量管理系统能够提供灵活定制的模版，模版的定制需要考虑底层元数据库的相关字段。用户只需使用可视化界面输入相关信息，系统应该能够实现用户录入信息到符合XMI标准的XM1.文件的转换，或者能够直接使用CC）RBAID1.接口/JMI接口实现元数据到元数据库的存储。2.3. 元数据的存储元数据存储设计实现将抽取出的元数据导入按照逻辑模型设计的元数据库中。存储方式：采用关系数据库方式进行存储。存储结构：采用二级结构进行存储。集中式结构是建立统一的元数据模型，用该模型定义和管理各种元数据，并将所有元数据集中存储在中心元数据库中。所有工具和数据仓库直接访问中心元数据库，而不局部存储和管理元数据。这种结构的优点是元数据全局可用，无需元数据交换机制；缺点是对中心元数据库维护复杂，访问速度慢，工具不具有自治性。对于大多数中等规模的组织，这种结构可以满足元数据管理的需要。分散结构解决中心元数据库管理结构存在的缺陷，目前大多数数据仓库系统中采用一种基于交换机制的分散式元数据管理结构。这种管理结构通过建立相应的元数据交换标准，使得不同数据仓库工具能够使用不同的数据模型和不同的表示形式，而这些工具之间可以通过元数据交换标准进行连接和通信。这种管理结构的最大优点是不同工具可以高度自治地访问局部元数据库，提高了访问速度，但系统需要提供元数据交换机制来满足不同局部元数据库之间的互操作和连接等问题，相应地增加了系统的负担。另外这种管理结构使得数据和元数据分散在多个系统中，增大了对它们协调和管理的难度。邦联结构是前面两种结构的折衷，结合了前面两种结构的优点，比拟适合数据仓库环境中的元数据管理。每个工具拥有自己的元数据库，因而支持快速访问和自治，并提供与共享元数据库的交换接口，共享元数据库管理的所有共享元数据。局部元数据库可以采用异构的表示形式，而共享的元数据库必须采用统一的元数据表示表示形式。如基于标准的元数据模型(C)IM或CWM)或自定义模型。邦联结构的优点是保护了元数据库的自治性和异构性，每个局部元数据库自己确定需要导出哪些元数据到共享的元数据库中，缺点是元数据库的结构比拟松散，元数据导航较为复杂。结合中国移动的实际需求，在中规定了采用两级元数据存储架构，如图2-1所示。图2-1经营分析系统元数据存储架构整体架构是二级结构，包括集团级元数据存储和省级元数据存储。集团级元数据物理的存放在集团公司，包含从各省提取过来的元数据和一级经营分析系统提取的元数据的集合；省级元数据存储着省级经营分析系统的元数据。省级元数据才用集中式的方式进行存储，各子系统的元数据被集中的存放在一个中央的元数据中。整个架构那么是采用联邦结构的形式进行存储，统一的采用基于CWM模型的方式进行数据的存储和彼此之间的元数据的交互。存储过程：在元数据提取的根底上，可以导出符合CWM模型的各子系统的元数据，该元数据采用符合XMI标准的XM1.文件来进行存储表示。由于元数据是使用XMI标准来进行描述的，因此存储方可以根据XMl标准来理解该元数据，对其进行解析。解析后得到符合CwM标准的元数据模型。由于CWM模型是按照对象的方式进行存储和彼此之间关系表示的，而数据质量管理系统底层却是使用关系数据库的方来来进行存储的，因此就需要将对象模型及之间的逻辑关系转换为关系模型来进行存储。对象模型到关系模型的转换在本实施方窠的第3章中进行了详细的描述。这个转换不仅仅是对象模型到关系模型之间的转换，同时也包含之间接口的操作规那么的转换，使得可以把对象型的元数据存进关系型的元数据库当中，并将CWM模型的元数据对象保存到关系数据库中的相应位置，在存储的过程中保持着他们之间的关系。从而为顶层的各种应用，如血缘分析，回朔分析等，奠定根底。2.4. 元数据访问接口实现根据CWM标准规定，访问元数据库的接口有三种方式：CORBAID1.接口、JMl接口和XMl接口。前两者提供给访问者程序语言调用的接口，后者提供文件交互的接口。Corbaidl接口和JMl接口可以由各个省份根据自身情况以及实现的难易程度选择其一实现。实现目的实现元数据库的访问功能接口。实现方式Ce)RBAlD1.接口和JMl接口的实现有三种方式：自动实现方式，即由数据质量管理系统接受CWM模型为输入，然后产生元数据的关系存储模型，同时生成Corbaidl接口/jmi接口，并同时生成Corbaidl接jmi接口的实现代码。人工实现方式，即是数据质量管理系统实现人员手工编码CORBAID1.接口/JMI接口中要求的每一个方法。半自动实现方式，即是由数据质量管理系统生成接口的局部实现代码（例如生成一个代码框架），然后再手工完成接口实现代码的其它局部。2.5. 元数据的业务应用实现基于设计的元数据存储库和开发的接口实现的根底上，可以根据实际的业务需求开发出各种元数据应用0这些元数据的前端分析和应用通过元数据管理层各个功能模块实现。根本功能：元数据插入、删除、修改、查询等。主要应用：元数据浏览，数据质量追踪，数据质量抽样检查，指标管理与分析，指标的解释与追踪，业务变更管理，基于元数据的平安管理，基于元数据的日常管理以及报表的动态制定和报表定义。2.6. 元数据的维护与管理元数据维护和管理功能包括元数据库中的元数据实时/定期更新功能，当元数据源系统中的元数据发生变化时，数据质量管理系统能够实现元数据库中的元数据的实时/定期更新。数据质量管理系统还应当提供元数据关联分析功能，确定元数据修改可能产生的影响。另外，元数据维护和管理功能还应当包括数据质量管理系统的权限管理和版本控制。3.逻辑模型设计3.1. 概述元数据逻辑模型设计的目的是为元数据库的建立提供逻辑根底。根据约定，在各省经营分析数据质量管理系统采用关系型对元数据逻辑模型实施建模。但是，由于CWM模型是基于对象方式进行描述的，因此必须将之转换为关系的方式，然后才能实施。这就是本章的主要目的。逻辑模型的转换过程如图3-1所示。根本思路是：首先根据对象到关系映射规那么，实现从CWM对象模型到E-R模型的转换，包括类到实体、关联到关系和引用到关系的映射；然后，根据逻辑模型到关系模型的映射规那么实现E-R模型到关系模型的转换，包括实体到关系表和实体关系到关系表列的映射；另外，关系模型中的存储过程方便使用面向对象的方法来访问关系数据。下面各章节首先介绍CWM对象模型到ER模型映射规那么，然后介绍逻辑模型的各个主题包含的实体、关系以及属性，并以ER图的形式进行了展现，最后描述ER模型到关系模型转换规那么和方法。元数据逻辑模型设计和实现过程如图5-1所示。图3”逻辑模型的设计和实现过程图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面向对象的根底以方便理解、使用和接口设计，对于在UM1.和MOF根底框架内进行成功的元数据交换非常重要。映射的过程描述如下：将CWM模型中的每个类映射到E-R模型中的一个实体，CWM模型中的父子继承结构直接转化成为实体之间的概括层次结构。UM1.中的父类中的属性，也就是公共属性，映射到E-R模型中高层实体的属性;UM1.中的子类的属性，也就是专有属性，映射到ER模型中低层实体的属性。3.2.2. 关联映射关联映射完成从CWM模型类之间的关联到E-R图中实体之间关联的等价映射转换。CWM模型中，类之间的关系采用关联的形式进行描述，主要包括一对一关联、一对多关联和多对多关联。这些关联模式到E-R模型中实体关联的映射方法相同，就是从类的关联到实体间的关系的一一映射。CWM模型中还广泛地使用了组合关联，这种组合关联映射为E-R模型中的实体间关系，这种实体间关系在本方案中使用图3-2中最下方关联图示来表示。图3-2以图形的方式描述了本方案中使用到的E-R实体间关系及相应的意义解释O图32EH实体间关联关系表示3.2.3. 引用映射引用可以当作是类的属性，它指向其它类的实例。实际上，引用在CWM中是由关联端表现的，也就是说一个引用可以被看作是一个关联端的代替。在从CWM模型到ER模型的映射中，引用直接映射成为实体间关系。具体的方法和规那么可以参考上一节“关联映射规那么3.3.数据逻辑模型主题域E-R模型元数据的逻辑模型根据CWM模型中包的结构划分为不同的主题，每个主题有自己特定的元数据存储范围和特定作用。主题间存在依赖关系，如图3-3所示:图33元数据主题间依赖关系图图3-3包括了各大元数据主题，以及主题间的相互依赖关系。主题间的依赖关系表示主题内的某些实体是从别的主题的某些实体继承而来或者是主题内的实体与别的主题的实体有关系。举例来说，主题A依赖于主题B,表示A中的某个实体X可能是主题B中某个实体Y的子实体，或者是A中的某个实体X与B中某个实体Y存在关系。每个实线框及其内部的主题对应着CWM模型的一个层次及其包含的包。核心主题是整个主题域的根底，其它所有主题都依赖于核心主题。为了图形表示的简洁性，核心主题在图3-3中没有画出，实际上每个主题到核心主题都存在一个箭头表示该主题对核心主题的依赖。如果依赖与被依赖的主题所对应的CWM模型中的包属于CWM元模型中同一个层次，这样的依赖关系使用黑色箭头表示，否那么使用蓝色箭头表示;箭头方向表示依赖的方向，即A÷B表示A依赖于B0元数据逻辑模型主题域由以下主题组成：主题CWM中对应包核心主题Core行为主题Behavioral关系主题Relationship实例主题Instance业务信息BUsinessInformatino数据类型主题DataTypes表达式主题Expression键和索引主题KeysIndexes软件部署主题SoftwareDepIoyment类型映射主题TypeMapping关系型主题Relational记录主题Record多维主题MultiDimensionalXM1.主题XM1.转换主题TransformationO1.AP主题O1.AP数据挖掘主题DataMining信息可视化主题InformationVisualization业务术语主题BusinessNomenclature仓库处理主题WarehouseProcess仓库操作主题WarehouseOperation3.3.1. 核心主题图3-4核心主题实体说明（一）图3-5核心主题实体说明（二）核心主题包括根本的实体和关联，这些类和关联被其他所有的主题使用O主题主要实体实体主要属性实体说明属性名属性说明核心主题CoreAttributeinitialValue初始的时候确定属性的初始值的表达式。当对象初始化的时候被计算出来；类型：Expression；多重性：0或1Attribute描述在Classifier里面的一个有名字的数据槽,这个数据槽可能是有值的BooleanEXpression空空BooleanExpression定义了一个表达式，当这个表达式被计算的时候会产生一个布尔型的实例Class空空Class是对于一组对象的描述,这些对象具有相同的属性，操作，方法，关联和语义,用来描述具有多个实例的实体Classifier空空Classifier是用来描述结构和行为特征的元素,它能够被表现成为多种特定的形式，包括Class,数据类型，接口，组件和在其他元模型包中定义的结构。ClaSSifier通常被用做类型Constraintbody是一个布尔表达式，当一个系统的实例满足这个表达式的时候，表达式必须被计算为真。这个布尔表达式定义了约束。表达式是由指定的语言表示的字符串；类型：BooleanExpression；多重性：1Constraint是用文本表示的语义条件或者约束DataType空空Datatype是一种没有标识符的类型，更确切的说，它们是纯数值。记录只能拥有一个实例的实体的信息DependenCykind包含了对于描述“客户”和“提供商”之间的依赖关系的一种自然描述。可能的取值列表是没有尽头的。但是在这里预定义的值为“Abstraction”和“Usage"；类型：字符串；多重性：0或1Dependency描述了一个或多个元素出现的时候要求另外的一个或多个元素也出现的这种机制或者实现Element空空Element是一个模型的最根本的“代理”。在元模型里，Element是最根本的实体.Expressionbody用指定的语言表达的表达式的正文；类型：字符串；多重性：1Expression定义了一个表达式,这个表达式在上下文环境中会计算出一language表达式的正文所使用的语言的名字，对于表达式的正文的解释是由语言所决定的。如果语言的名字被忽略了，就不能解释出表达式的意义；类型：Name；多重性：O或者1个实例的集合（或者为空）。一个表达式在计算中不会修改这个表达式所在的环境FeatureOwner-Scope确定这个Feature是出现在每个Classifier的实例中还是只是出现在ClaSSifier类中一次；类型：ScopeKind;多重性：O或者1FeatUre是一种特性,比方在Classifier里面的属性或者操作。Feature定义了一个Classifier的实例的结构或者行为特征，或者是QaSSifier本身的结构或行为特征Model空空Model是一个物理系统的视图。它是物理系统的一种带有特定目的的抽象ModelElementnamename是MedelElement在包含它的命名空间里的一个标识；类型：Name；多重性：1ModelEIement是具有名字的实体,在CWM中它是所有的被建模的元类型的根底,所有别的元类型都是ModelElement的直接或者间接子实体visibility确定MedelEIement在包含它的命名空间里可见性范围；类型：VisibilityKind;多重性：1Multiplicity空空在元模型里，Multiplicity定义了非负整数的非空集合MultiplicityRangelower确定一个范围的非负的下界；类型：整型；多重性：1在元模型里MultiplicityRange定义了一个整数的范围。这个范围的上界不能小于下界，下届必须是一个非负的整数。上界必须是一个非负整数或者是特别的值“无限”，“无限”代表了这个范围没有上界upper确定范围的上界，可以是一个非负整数或者是特定的值“无限”代表没有上界；类型：没有上界的整数；多重性：INamespace空空Namespace是Model的一个局部，包含了ModelElement的一个集合，这些ModelEIement的名字在这个namespace中是唯一的Package空空描述包信息,记录了包中从其他包引入的模型元素，以作为对该包的扩展ProcedureExpression空空ProcedureExpression定义了表达式,这个表达式在计算的时候会改变它所在环境的值StereotypebaseClass确定stereotype对什么模型元素使用，比方说类，关联，约束等。这是一个元类型的名字，确定的说是元模型自身而不是用户定义的元类型；类型：Name；多重性：1Stereotype提供了一种方法，给模型元素指定名字，让这些模型元素可以像新构造的虚拟的元模型的实例那样工作StructuralFeatureChangeability确定对象被创立后它的值能否被修改；类型：ChangeabiIityKind：多重性：1StructuralFeature是指一个模型元素的静态特性Multiplicity这个特征的对象的实例可能的数目；类型:Multiplicity；多重性：1ordering确定一组实例是不是有序的；类型：OrderingKind;多重性：0或1IargetScoPe确定目标是普通的实例还是类元；类型:ScopeKind;多重性：0或1Subsystem空空Subsystem是组模型元素的集合,表现了一个物理系统的行为单元。Subsystem提供接口，也具有操作TaggedVaIuetagTaggedValUe的名字，这个名字确定了值的属性的内容的适用的语义；类型：Name；多重性：1TaggedValue允许信息被附加到任何模型元素上，用“taggedvalue”这样的格式，确切的说，name=value这样的格式来对模型元素进行补充描述的信息Value当前的TaggedVaIue的值；类型：字符串；多重性：I图3-6行为主题实体说明行为主题是描述CWM的类型的行为的实体及其关系的集合，提供了记录被定义行为的记录的根底。主题主要实体实体主要属性实体说明属性名属性说明行为BehaviorArgumentValue当执行时候决定实际Argument实例的表达式;类型:EXPreSSiOn；多重性：1Argument是描述在CanACtiOn里的实际值是如何被传递的表达式Behavior-FeatureisQuery确定BehavioralFeature执行有没有改变系统状态，TrUe代表没有改变，False代表产生副作用改变了系统状态；类型：Boolean；多重性：1指一个模型元素的动态特性，比方操作或方法。BehavioralFeature指定了类元实体的行为方面.Call-Action空空CallAction是一个记录操作发生的行为，CaHAetion的目的是用来标识一个特定的Operation发生的时候所实际使用的参数Event空空EVem是可观察的事件的说明，事件会产生一个event的实例Interface空空Interface是定义了一个元素的行为的OPeraliOn的有名字的集合Methodbody用一些适当的方式来表达Method的具体实例（比方一种程序语言）；类型：ProcedureExpression；多重性：1Method是操作的一个实现,它详细说明了一个算法或者一个过程,这个算法或者过程会影响到一个操作的结果OperationisAbstract如果是TrUe那么OPeration没有个实例，应该由个缺省值来补充，如果是FalSe,那么Operation必须被实现或者继承一个实体；类型：Boolean；多重性：1Operation是可以由对象要求的种影响行为的效劳。OPeratiOn具有标签,这个标签描述了可能的参数（包括可能的返回值）Parame-terdefaultValUC一个表达式，当没有值提供给这个参数的时候，可以用它计算的值作为Parameter的值；类型：Expression：多重性：0或1Parameter被用在Operation,Method>Event的说明中,一个Parameter可能包含有名字,类型和信息的传递方向kind指定一个Parameter的类型；类型：ParameterDirectionKind；多重性：13.3.3. 关系主题图3-7关系主题实体说明关系主题是实体和关联的集合，这些实体和关联描述了CWM信息存储库里对象之间的关系（关联和泛化关系）。主题主要实体实体主要属性实体说明属性名属性说明关系RelationshipsAssociation空空Association定义了实体之间的语义关系。Association具有两个或多个有名字的端AssociationEndAggregation显示一端是否是另外一端的聚合端，两端只有一端能是聚合的；类型：AggregationKind;多重性：1ASSOCiatiOnEnd是关联的一个端点，ASSoCiationEnd连接到一个类元实体的关联。每个ASSoCiationEnd是一个关联的一个局部。每个关联的ASSoCiationEnd都是有序的isNavigable描述是否可以从一个资源端实例横跨到与它关联的一个目标端实例。TrUe代表关联可以从资源类访问，并且目标端的名字可以被用在通用表达式中。每一个方向能否通过是被单独定义的；类型：Boolean：多重性：1；Generalization空空一个概括元素与一个具体元素之间的分类关系。更具体的元素是与更概括的元素完全相容的（它具有概括元素的所有属性，成员和关系），还可能具有附加的信息3.3.4. 实例主题图3-8实例主题实体说明在CWM通常用来交换元数据的根底上，CWM也在某些时候用来交换特定的具体数据。实例主题允许元数据包含有数据实例。主题主要实体实体主要属性实体说明属性名属性说明实例Insta-nceDataSlotdataValueSlot的使用字符串类型表达的值；类型：String；多重性：1Da【aSlol用来保存一个数据值，当没有必要把这个数据的值当作元素管理的时候Data-Valuevalue用字符串表达出来的值；类型：String；多重性：1DataValue是没有标识的实体。DataValUe是InStanCe的子实体,并且不能改变自己的状态，也就是说,所有它可适用的操作都是纯函数或者不能引起任何副作用的操作。DataValUe通常被用作属性值Extent空空每一个Extent的实例都拥有一些实例的集合,并且用来连接这个集合到它们在CWM包中的结构和行为定义。Instance空空实例记录了它本身所属的类元信息,实例具有与它的类元实体所定义的属性相配的属性值Object空空Object是由一个实体产生的InstanceSlot空空Slot是Objectinstance中的一块有名字的区域,保存和SIotinstance相关联的Str