文档文库

手机版

投诉建议

首页 > 元数据设计文档20

元数据设计文档20

发布时间：2020-04-16 10:17:29 来源：文档文库

小中大

字号：

手机查看

元数据管理系统

1. 前言

目前的元数据管理系统，存在以下问题：

 应用系统产生的元数据分别保存在应用系统中和元数据管理系统中，从而导致了元数据的不一致性。

 元数据管理系统往往采用任务抽取和手工录入的方式维护元数据，与应用系统集成度低。

 元数据管理系统中的数据使用率底，只起到集中存储元数据的功能。

 元数据管理系统无法对应用系统产生的元数据进行权限和生命周期管理。

 元数据管理系统应用分析功能弱。

2. 整体设计

1

2

2.1 设计思路

元数据管理是分为后台支撑和前台展现。后台支撑：工具中的很多功能，必须依赖于元数据的支撑。前台展现：通过元数据管理前台实现传统元数据管理的诸多功能。

元数据管理应采用高内聚、低耦合的组件式产品架构，利用丰富功能组件，搭建功能强大的、主动式的元数据管理平台，同时向集成商全面开放元数据功能调用接口，并提供整套应用开发方法论。使税务人员能够自行加载业务元数据、自动生成技术元数据、全面管控管理元数据。在完成元数据管理、维护等基础功能的同时，方便集成商实现二次开发，快速满足业务应用的针对性需求。

2.2 架构图

 应用系统中将不再保存元数据信息，元数据信息直接保存到元数据管理系统中，应用系统通过访问接口和元模型视图对元数据进行查询、添加、修改和删除维护。从而保证了元数据的一致性。

 应用系统访问元数据管理系统，首先需要通过元数据权限管理模块。只有权限管理模块的授权用户才能对元数据进行增加、修改、删除和检索。

检索方式上采用两种方式：

⏹ 接口检索：

应用系统可以根据元数据的路径、元数据名称和元数据ID对元数据进行检索。

⏹ 通过元数据库中的元模型视图：

为了方便与应用系统的集成，元数据管理系统提供元模型视图。应用系统可以根据拥有的元模型访问权限查询相应的元数据信息。

 元数据管理系统通过生命周期管理模块对元数据进行生命周期管理。

 元数据管理系统通过版本管理模块对元数据进行版本控制。

 元模型创建的时候系统自动创建元模型视图。

1

2

2.1

2.3 功能图

元数据管理系统包含三大功能模块：

 应用、分析模块

主要对元数据进行应用和分析。主要包括数据库管理、血统/影响分析、元数据使用情况统计、元数据质量管理、指标库管理、元数据差异分析和元数据权限管理。

 元数据管理模块

主要对元数据进行维护。主要包括元数据检索、变更订阅、版本管理、元数据采集、元数据生命周期、元数据基本信息维护和元数据关系维护。

 元模型管理模块

主要对元模型进行维护。主要包括元模型基本信息维护、元模型关系维护、元模型属性维护、元模型索引维护、包维护、关系类型维护、业务领域维护和枚举类型维护。

3. 功能模块

1

2

3

3.1 元模型

3.1.1 元模型维护

3.1.1.1 元模型基本信息维护

 数据项:

⏹ ID:元模型的主键。系统自动生成。

⏹ 路径：显示模型的包路径。例org.omg.cwm.objectmodel.core.ClassifierMap

⏹ 名称：元模型的名称。只能是字母数字和下划线。同包下不能有相同的名称。

⏹ 显示名称：元模型的显示名称。

⏹ 使用显示名称：复选框。选择：元模型则显示显示名称。不选：元模型则显示名称。

⏹ 描述：用于填写元模型的描述信息。

⏹ 使用视图：复选框。选择：创建元模型的时候，创建元模型视图。不选：只创建元模型。

⏹ 视图名称：创建元模型视图的名称。创建时检查视图名称是否唯一。

⏹ 备注：填写备注信息。

 功能：

⏹ 检索：检索元模型的基本信息。

⏹ 修改：修改元模型的基本信息。

⏹ 删除：删除元模型时，需要删除相应继承关系。

⏹ 添加：新建元模型的基本信息。

⏹ 应用：创建和更新元模型和元模型视图。

3.1.1.2 元模型属性维护

 数据项

⏹ 名称：属性的名称。只能是字母数字和下划线。同模型下不能有相同的名称。

⏹ 显示名称：属性的显示名称。

⏹ 使用显示名称：复选框。选择：属性则显示显示名称。不选：属性则显示名称。

⏹ 类型：string、boolean、short、integer、long、float、double、date和枚举类型。

⏹ 长度：类型的长度。

⏹ 小数位数：小数精度。

⏹ 是否为空：属性是否可为空。

⏹ 是否可用：创建元模型时是否创建此属性。

⏹ 是否显示：用于隐藏元模型属性。

⏹ 描述：描述属性信息。

⏹ 默认值：属性的默认值。

⏹ 备注：填写备注信息。

 功能

⏹ 添加：添加新的属性。

⏹ 删除：删除属性。继承的属性不能删除。

⏹ 修改：修改属性。继承的属性不能修改。

3.1.1.3 元模型关系维护

 数据项

⏹ 名称：关系的名称。只能是字母数字和下划线。同模型下不能有相同的名称。

⏹ 显示名称：关系的显示名称。

⏹ 使用显示名称：复选框。选择：关系则显示显示名称。不选：关系则显示名称。

⏹ 类型：关系类型包括继承、依赖、聚合、组合、关联和扩展类型。

⏹ 源端：起始的元模型。

⏹ 目标端：结束的元模型。

⏹ 上限：0、1、2、*

⏹ 下限：0、1、2、*

⏹ 描述：描述关系信息。

⏹ 备注：填写备注信息。

 功能

⏹ 添加：添加新的关系。

⏹ 修改：修改关系。继承的关系不能修改。

⏹ 删除：删除关系。继承的关系不能删除。

3.1.1.4 元模型索引维护

 数据项

⏹ 名称：索引的名称。只能是字母数字和下划线。同模型下不能有相同的名称。

⏹ 显示名称：索引的显示名称。

⏹ 使用显示名称：复选框。选择：关系则显示显示名称。不选：关系则显示名称。

⏹ 描述：描述索引信息。

⏹ 是否创建：创建元模型的时候是否创建此索引。

⏹ 备注：填写备注信息。

⏹ 引用的属性：创建索引时用到的列。

 功能

⏹ 添加：添加新的索引。

⏹ 修改：修改索引。

⏹ 删除：删除索引。

3.1.2 包维护

 数据项

⏹ 名称：包的名称。只能是字母数字和下划线。同包下不能有相同的名称。

⏹ 显示名称：包的显示名称。

⏹ 使用显示名称：复选框。选择：包则显示显示名称。不选：包则显示名称。

⏹ 描述：描述包信息。

⏹ 备注：填写备注信息。

 功能

⏹ 添加：添加新包。

⏹ 修改：修改包信息。

⏹ 删除包：包删除的时候，会同时删除包下面的元模型。

3.1.3 关系类型维护

 数据项

⏹ 名称：包的名称。只能是字母数字和下划线。同包下不能有相同的名称。

⏹ 抽象：是否是抽象关系。例如：数据层关系类型。

⏹ 显示名称：包的显示名称。

⏹ 使用显示名称：复选框。选择：包则显示显示名称。不选：包则显示名称。

⏹ 描述：描述包信息。

⏹ 备注：填写备注信息。

 功能

⏹ 添加：添加关系类型。

⏹ 修改：修改关系类型。

⏹ 删除：删除关系类型。引用的关系类型不允许删除。

3.1.4 业务领域维护

 数据项

⏹ 名称：业务领域的名称。只能是字母数字和下划线。不能有相同的业务领域名称。

⏹ 显示名称：业务领域的显示名称。

⏹ 使用显示名称：复选框。选择：业务领域则显示显示名称。不选：业务领域则显示名称。

⏹ 描述：描述业务领域信息。

⏹ 备注：填写备注信息。

 功能

⏹ 添加：添加业务领域。

⏹ 修改：修改业务领域。

⏹ 删除：删除业务领域。同时删除其下的包和元模型。

3.1.5 枚举类型维护

 数据项

⏹ 基本信息

◆ 名称：枚举类型的名称。只能是字母数字和下划线。不能有相同的枚举类型名称。

◆ 允许多选：选择：页面显示复选框。不选择：页面显示单选框。

◆ 显示名称：枚举类型的显示名称。

◆ 使用显示名称：复选框。选择：枚举类型则显示显示名称。不选：枚举类型则显示名称。

◆ 描述：描枚举类型域信息。

◆ 备注：填写备注信息。

⏹ 条目

◆ 名称：条目的名称。只能是字母数字和下划线。不能有相同的枚举类型名称。

◆ 显示名称：条目的显示名称。

◆ 使用显示名称：复选框。选择：条目则显示显示名称。不选：条目则显示名称。

◆ 值：条目的值。

◆ 描述：描枚举类型域信息。

 功能

⏹ 基本信息

◆ 添加：添加枚举类型。

◆ 修改：修改枚举类型。

◆ 删除：删除枚举类型。

⏹ 条目

◆ 添加：添加条目。

◆ 修改：修改条目。

◆ 删除：删除条目。

3.2 元数据

3.2.1 元数据基本信息维护

 数据项

⏹ 名称：元数据名称。必填

⏹ 别名：元数据别名。

⏹ 元模型：创建元数据的类型。

⏹ 版本状态：分为初始建立、公示状态、审核状态、发布状态、维护状态五种状态。

⏹ 生命周期状态：元数据的生命周期状态。

⏹ 描述：元数据的描述信息。

 功能

⏹ 维护属性：根据元模型维护元数据的属性信息。

⏹ 创建子节点：创建元数据基本信息。

⏹ 删除：删除元数据基本信息。

⏹ 修改：修改元数据基本信息同时删除元数据之间的关系信息。

⏹ 移动：将元数据移动到其它元数据下面。两个元数据之间必须有组合关系。

3.2.2 元数据关系维护

 数据项

⏹ 源数据：起始的元数据。

⏹ 源数据路径：起始的元数据路径。

⏹ 目标数据：结束的元数据。

⏹ 目标数据路径：结束的元数据路径。

⏹ 关系类型：依赖、聚集、关联和自定义类型。

⏹ 关系名称：元数据关系的名称。

⏹ 显示名称：元数据关系的显示名称。

⏹ 关系描述：元数据关系的描述信息。

 功能

⏹ 添加：添加元数据关系。只有两个元模型之间建立关系，才能添加相应的关系。例如元模型之间建立了依赖关系，则只能添加依赖关系。不能添加关联或其他关系。

⏹ 删除：删除关系。

⏹ 修改：修改关系信息。

3.2.3 元数据生命周期

为了能让用户控制元数据的增加、删除、修改和移动，使得每次对元数据的操作都要经过审核。

 数据项

⏹ 生命周期配置

◆ 设置方式：开启所有、关闭所有、根据元模型配置

◆ 选择元模型：需要进行生命周期管理的元数据。

⏹ 待审核处理

◆ 审核操作：通过、驳回。

◆ 操作状态：创建、编辑、删除和移动。

◆ 审核意见：填写审核意见。

 功能

⏹ 生命周期配置：维护生命周期基本设置。

⏹ 元数据审核管理：审核元数据的操作。

⏹ 影响分析：分析元数据改变产生的影响。

3.2.4 元数据采集

3.2.4.1 元数据导入导出

导出元数据的信息和关系。文件类型为EXCEL。

3.2.4.2 CWM导入导出

根据CWM定义XMI的规范导出元数据。这些元数据的元模型必须继承CWM定义的元模型。文件类型为XMI。

文件内容如下图：

3.2.4.3 元数据模版导出

导出元模型和关系。文件类型为EXCEL。元模型结构如下图：

关系结构如下图：

3.2.5 版本管理

元数据创建，修改和删除的时候都要保存之前版本信息。版本分为大版本和小版本。

大版本如开发、试用、正式等。小版本如开发.1,试用.2。

 数据项

⏹ 版本名:版本的名称。

⏹ 操作者：创建版本的用户。

⏹ 创建时间：版本的创建时间。

 功能

⏹ 新增版本：添加新的版本。

⏹ 修改版本名：修改版本的名称。

⏹ 删除版本：删除版本信息。

⏹ 查询版本：可以按大版本查看历史版本信息。

⏹ 版本比较：可以比较两个版本之间的不同。

3.2.6 变更订阅

让用户及时了解的元数据的变更情况。

 功能

⏹ 元模型订阅：用户可以根据元模型订阅变更信息。信息以短信或者EMAIL的形式发送给用户。

⏹ 元数据订阅：用户可以根据元数据订阅变更信息。信息以短信或者EMAIL的形式发送给用户。订阅元数据的同时可以订阅元数据的下级节点。

⏹ 已订阅列表：检索用户订阅信息列表。

⏹ 变更通知：检索所有的变更通知。

3.2.7 元数据检索

 功能

⏹ 查询元数据：根据元数据名称检索元数据。

⏹ 高级查询：提供区分大小写设置、完全匹配设置、指定搜索目录和元模型搜索等查询条件。

3.3 应用

3.3.1 元数据权限管理

权限管理模块主要管理三种资源系统功能菜单、元数据元模型操作和元模型视图。体系结构如下图：

3.3.1.1 用户管理

 数据项

⏹ 用户名：用户的帐号信息。

⏹ 别名：用户的显示名称。

⏹ 密码：用户登录时显示的密码。

⏹ 描述：用户的描述信息。

⏹ Email：用户的email。变更订阅模块需要使用Email。

⏹ 角色：用户所拥有的角色信息。

 功能

⏹ 添加用户：添加新的用户。

⏹ 编辑：编辑用户信息。

⏹ 删除：删除用户信息。

⏹ 修改密码：修改用户密码。

3.3.1.2 角色管理

 数据项

⏹ 角色名称：角色的名称。

⏹ 描述：角色的描述信息。

⏹ 权限设置：用于设置系统功能资源的访问权限。

 功能

⏹ 添加角色：添加新的角色。

⏹ 编辑：编辑角色信息。

⏹ 删除：删除角色信息。

3.3.1.3 系统功能资源

 数据项

⏹ 资源名称：资源的名称

⏹ 父资源：上级资源。

⏹ 提示信息：资源的提示信息。

⏹ 值：功能的访问路径。

 功能

⏹ 添加：添加新的资源。

⏹ 编辑：编辑菜单

⏹ 删除：删除菜单。

3.3.1.4 元数据操作权限

元数据权限分为浏览、查看、创建子节点、修改、删除。

 功能

⏹ 浏览：可以在元数据树形结构中看到元数据。

⏹ 查看：可以查看元数据的详细信息。

⏹ 创建子节点：可以创建元数据的下级元数据。

⏹ 修改：修噶元数据的基本信息和属性信息。

⏹ 删除：删除元数据。

⏹ 禁用：禁用浏览、查看、创建子节点、修改、删除权限。

⏹ 子节点继承：子节点继承当前节点的权限。

⏹ 继承父节点权限：继承上级节点的权限。

 页面

3.3.1.5 数据库用户维护

通过对数据库用户访问视图的权限设定，来维护应用系统可访问的元模型视图。

 数据项

⏹ 用户名：数据库的用户名。

⏹ 描述：描述数据库用户。

⏹ 元模型视图：用与设置用户可访问的视图。

 功能

⏹ 添加：添加新的数据库用户。

⏹ 修改：修改数据库用户。

⏹ 删除：删除数据库用户。

3.3.2 数据库管理

3.3.2.1 表维护

3.3.2.1.1 表基本信息维护

 功能

⏹ 添加：添加表的元数据信息。

⏹ 修改：修改表的元数据信息。

⏹ 删除：删除表的元数据信息。

⏹ 同步：在数据库中创建或更新相应表。

⏹ 删除库表：删除数据库中的表。

⏹ 建表语句解析：解析建表语句，生成相应元数据。

3.3.2.1.2 字段维护

 功能

⏹ 添加：添加字段的元数据信息。

⏹ 修改：修改字段的元数据信息。

⏹ 删除：删除字段的元数据信息。

3.3.2.1.3 索引维护。

 功能

⏹ 添加：添加索引的元数据信息。

⏹ 修改：修改索引的元数据信息。

⏹ 删除：删除索引的元数据信息。

3.3.2.2 视图维护

3.3.2.2.1 视图基本信息维护

 功能

⏹ 添加：添加视图的元数据信息。

⏹ 修改：修改视图的元数据信息。

⏹ 删除：删除视图的元数据信息。

⏹ 创建视图：创建数据库中的视图。

⏹ 删除视图：删除数据库中的视图。

3.3.2.2.2 视图字段维护

 功能

⏹ 添加：添加字段的元数据信息。

⏹ 修改：修改字段的元数据信息。

⏹ 删除：删除字段的元数据信息。

3.3.2.3 SQL语句查询

 功能

⏹ 查询：通过sql语句查询数据库表中的数据。

3.3.2.4 存储过程维护

 功能

⏹ 添加：添加存储过程的元数据信息。

⏹ 修改：修改存储过程的元数据信息。

⏹ 删除：删除存储过程的元数据信息。

3.3.2.5 表空间维护

 表空间信息

⏹ 添加：添加表空间的元数据信息。

⏹ 修改：修改表空间的元数据信息。

⏹ 删除：删除表空间的元数据信息。

 存储文件信息

⏹ 添加：添加存储文件的元数据信息。

⏹ 修改：修改存储文件的元数据信息。

⏹ 删除：删除存储文件的元数据信息。

3.3.2.6 数据库用户维护

 功能

⏹ 添加：添加数据库用户的元数据信息。

⏹ 修改：修改数据库用户的元数据信息。

⏹ 删除：删除数据库用户的元数据信息。

3.3.3 血统、影响分析

3.3.3.1 血统分析

3.3.3.1.1 图形展示

用图形的形式展示数据的流向。如图

3.3.3.1.2 表格展示

用表格的形式展示数据流向。如图

支持EXCEL导出。如图

3.3.3.2 影响分析

元数据的改动对其它元数据产生的影响。

3.3.3.2.1 图形展示

用图形的方式展示元数据改动对其它元数据产生的影响。

3.3.3.2.2 表格展示

用表格的形式展示影响。如图

支持excel导出如图

3.3.4 元数据使用情况统计

3.3.4.1 元数据浏览用户统计（按用户）

通过分析每一个用户在一段时间内浏览元数据的次数,可用于分析哪一些用户在经常关注、使用元数据

 功能

⏹ 可查询在一段时间内全部用户的浏览次数统计，显示内容应包括用户账号、用户名称、浏览次数、浏览排名。“浏览次数”是链接，可链接查看元数据的明细信息。

⏹ 可在“浏览次数”中链接查看单个用户浏览元数据的明细信息，显示内容应包括元数据名称、元数据类型，访问时间。

3.3.4.2 元数据浏览用户统计（按元数据类型）

通过统计每一类元数据在一段时间内被浏览的次数，可用于分析哪一些元数据是用户最为关注的。

 功能

可查询在一段时间内所有元数据类型的浏览次数统计，显示内容包括元数据类型、浏览次数、浏览排名。“浏览次数”是链接，可链接查看元数据的明细信息。

⏹ 可在“浏览次数”中链接查看单类元数据被浏览的明细信息，显示内容包括元数据名称、浏览用户、访问时间。

3.3.5 元数据质量管理

3.3.5.1 属性填充率

 功能

⏹ 用于检查元模型的所有元数据属性填写情况。

⏹ 计算公式如下：（∑参与检查的各属性非空记录数/（某类型实体总数×参与检查的属性个数））×100

⏹ 当填充率超过80%时，字体显示为绿色，低于30%显示为红色，两者中间显示为黑色。

⏹ 检查完毕之后，结果能以“XSL”，“DOC”，“PDF”格式导出。

3.3.5.2 属性合法性

 功能

⏹ 检查元数据的属性是否唯一

即是否有两个或以上元数据的某项属性相同，例如：元数据a和元数据b的属性attribute1都为1，勾选attribute1检查其唯一性，这两个元数据a,b都将被搜索出来。

⏹ 检模元数据的属性是否非空

即是否有元数据的值非空，例如：元数据a和元数据b的属性attribute1都不为空，勾选attribute1检查其非空值，这两个元数据a,b都将被搜索出来。

⏹ 检查完毕之后，结果能以“XSL”，“DOC”，“PDF”格式导出。

3.3.5.3 名称重复性

 功能

⏹ 此功能用以检查某个包或元模型下的所有元数据是否同名。

如果勾选的是包，则表示检查其下所有元模型的元数据是否有同名，例如：包“aaa”下元模型“model4”有一元数据名为“a”,同时包“aaa”下元模型“model5”有一元数据亦为“a”,则这两个元数据将被检查出来。

⏹ 检查完毕之后，结果能以“XSL”，“DOC”，“PDF”格式导出。

3.3.6 指标库管理

指标库是指元数据库中与指标相关的元数据的集合，类别包括指标元数据和维度元数据。

 功能

 支持指标命名规范性检查、指标模型规范性检查，提供相关统计分析和报表功能。如：提供具有相似名称指标的列表，在指定范围内，列出不符合指标命名规范、指标模型规范的指标列表。

 提供指标库的版本管理功能。支持对指标库设定版本号、支持对不同版本的指标库差异比较和支持对指定版本的指标库进行查询操作。

 查询的对象包括：核心指标名称、核心指标业务描述、报表名称、报表描述、报表指标名称、报表指标业务定义、报表指标技术统计口径进行查询、修订时间。

3.3.7 元数据差异分析

分析两个元数据属性之间的差异。

3.3.7.1 流程差异比较

3.3.7.2 属性差异比较

列出具有相同的属性。属性值不同则背景用红色表示。

4. 内部接口调用标准

4

4.1 元数据服务接口（MetadataService）

元数据服务。对元数据进行增删改和查询等操作。

 Public MetaData create(MetaData data)

创建元数据。

 Public MetaData create(MetaData data,String path)

在指定的路径下创建数据。

 Public List createBatch(java.util.List datas)

批量创建元数据，返回成功创建的记录。

 Public Boolean delete(MetaData data)

删除元数据。

 Public Boolean delete(String dataId)

根据元数据ID删除元数据。

 Public MetaData update(MetaData data)

更新元数据。该方法不能修改parentId、modelId。

 Public boolean move(MetaData thisData, MetaData newParentData)

移动元数据，将thisData移动到newParentData下面。

 Public boolean move(String dataId, String newParentId)

移动元数据，将dataId移动到newParentId下面。

 Public List getDataList(List dataIds)

批量根据ID获取元数据。

 Public List getDatas(String modelId)

获取指定模型的所有元数据。

 Public List getDatas(String modelId, int start, int count)

分页获取指定模型的所有元数据。

 Public String getPath(String dataId)

获取元数据的路径，以字符串数组的形式返回，路径不包含domain。

 Public String getPath(String dataId, boolean includeDomain)

获取元数据的路径，以字符串数组的形式返回。

 Public MetaData getRoots()

获取元数据的根节点。

 Public List getSources(String targetDataId,List rtIds)

获取与指定元数据有rtIds列表中任一类型的关系的元数据列表（根据target获取source）。

 Public List getTargets(String sourceDataId, List rtIds)

获取与指定元数据有rtIds列表中任一类型的关系的元数据列表（根据source获取target）。

4.2 元数据版本服务接口（MDRevisionService）

元数据版本服务，对单个元数据的历史版本进行查询。

 Public List getLatestRevisions(Date startDate, Date endDate, int start, int count)

获取一段时间内数据的最新版本列表（同一数据的版本只返回最新的那个）

 Public List getLatestRevisions(List modelIds, Date startDate, Date endDate, int start, int count)

获取一段时间内数据的最新版本列表（同一数据的版本只返回最新的那个）

 Public MDRevision getRevision(String revisionId)

根据ID获取元数据版本。

 Public List getRevisionsByDate(String dataId, Date startDate, Date endDate)

获取数据在一段时间内的版本。

 Public List getRevisionsCountByDate(String dataId, long startTime, long endTime)

获取数据在一段时间内的版本总数。

4.3 元数据关系服务接口（MDRelationService）

数据关系服务，用于对数据间的关系进行操作。

 Public boolean canBuildDRelation(String data1,String data2, String rtId)

两个数据间是否可以建立指定类型的关系。

 Public MDRelation create(MDRelation dr)

创建数据关系。

 Public List createBatch(List mdrs)

批量创建数据关系。

 Public boolean delete(MDRelation dr)

删除数据关系。

 Public boolean delete(String id)

删除数据关系。

 Public List getAllDRelations()

获取所有的数据关系。

 Public List getAllDRelationsBetween2Data(String data1, String data2)

获取两节点间的所有数据关系的列表。包括从 data1 到 data2 和 data2 到 data1 的关系。

 Public List getAllSourceDRelations(String tarDataId)

获取数据的所有源关系的列表。

 Public List getAllTargetDRelations(String srcDataId)

获取数据的所有目标关系的列表。

 Public MDRelation update(MDRelation dr)

更新数据关系。

 Public void updateSourceRelations(String tarDataId, List srcDataIds, String rtId)

同步指向源的某一类型关系。把原来多的删除掉，新的增加进去。

 Public void updateTargetRelations(String srcDataId, List tarDataIds, String rtId)

同步指向目标的某一类型关系。把原来多的删除掉，新的增加进去

5. 外部工具接口标准

元数据管理系统使用REST风格的Web服务作为元数据操作的外部交互接口，服务端提供唯一的资源定位地址URI供客户端调用。客户端通过HTTP方法实现对资源的唯一操作，HTTP方法主要包括GET、PUT、POST和DELETE方法。

在元数据交互过程中，客户端通过调用基于REST的服务接口，将请求消息通过HTTP协议发送给服务端。服务端接收到客户端的请求消息后，通过REST解析、权限验证、映射转换和XML解析等模块的处理，最终通过接口实现与元数据库数据的交互。基于REST的Web服务的交互模式采用在线请求－同步响应方式。

 REST解析

客户端通过HTTP协议，向服务端传入一个REST请求，其中包含HTTP协议头和XML格式的元数据服务原语。服务端解析分离HTTP头和XML格式元数据服务原语，其中从HTTP头中得到URI，从XML格式元数据服务原语分离出消息头和消息体。

 权限验证

服务端完成REST解析后，根据元数据服务原语消息头中的用户信息，调用服务管理的认证鉴权和权限管理模块，检查用户是否有访问元数据功能的权限。

 映射转换

服务端完成权限验证后，根据元数据与URI的映射关系和REST请求中的URI，最终得到要访问元数据的ID。

 XML解析

XML解析对REST解析后的服务原语进行再次解析，得到消息体中的元数据信息部分。

5

5.1 获取元数据信息

 URL

http://ip:port/RESTFUL /metadata_path

http://ip:port/ RESTFUL /metadata_id

 格式

XML

 HTTP请求方式

GET

Header:

Accept: application/xml

User-ClientID: {username}

User-Password: {password}

 返回结构

应答执行结果类型

应答时间

应答/错误代码

应答/错误描述

...

5.2 新增元数据信息

 URL

http://ip:port/RESTFUL/metadata_parent_path

http://ip:port/ RESTFUL/metadata_parent_id

 格式

XML

 HTTP请求方式

Post

Header:

Accept: application/xml

Content-Type: application/xml;utf-8

 请求数据

用户ID

用户口令

请求来源

请求时间

路由类型

路由标识

...

 返回结果

应答执行结果类型

应答时间

应答/错误代码

应答/错误描述

 说明

同一路径元数据已存在就不能创建。

5.3 修改元数据信息

 URL

http://ip:port/RESTFUL/metadata_path

http://ip:port/RESTFUL/metadata_id

 格式

XML

 HTTP请求方式

PUT

Header:

Accept: application/xml

Content-Type: application/xml;utf-8

 请求数据

用户ID

用户口令

请求来源

请求时间

路由类型

路由标识

...

 返回结果

应答执行结果类型

应答时间

应答/错误代码

应答/错误描述

 说明

修改元数据必须存在

5.4 删除元数据信息

 URL

http://ip:port/RESTFUL/metadata_path

http://ip:port/RESTFUL/metadata_id

 格式

XML

 HTTP请求方式

DELETE

Header:

Accept: application/xml

User-ClientID: {username}

User-Password: {password}

 返回结构

应答执行结果类型

应答时间

应答/错误代码

应答/错误描述

 说明

删除元数据必须存在。

6. 实现工具使用技术

6

6.1 JAVAEE

JAVAEE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循JAVAEE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，企业内部或外部难以互通的窘境。

J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:

 保留现存的IT资产

　　由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。JAVAEE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及Netscape Application Server。这之所以成为可能是因为JAVAEE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的JAVAEE领域的升级途径。由于基于JAVAEE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。

 高效的开发:

　　JAVAEE允许公司把一些通用的、很繁琐的服务端任务交给中间供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务: o 状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。 o 持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。 o 分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。

 支持异构环境:

　　JAVAEE能够开发部署在异构环境中的可移植程序。基于JAVAEE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于JAVAEE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。JAVAEE标准也允许客户订购与JAVAEE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。

 可伸缩性:

　　企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于JAVAEE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）JAVAEE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

 稳定的可用性:

一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。JAVAEE部署到可靠的操作环境中，他们支持长期的可用性。一些JAVAEE部署在WINDOWS环境中，客户也可选择健壮性能更好的操作系统如Sun Solaris、IBM OS/390。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。

6.2 XML

XML（Extensible Markup Language）即可扩展标记语言，它与HTML一样，都是SGML(Standard Generalized Markup Language,标准通用标记语言)。Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立，虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。

XML 的优势有以下几个方面：

 XML可以从HTML中分离数据

　　通过XML,你可以在HTML文件之外存储数据。在不使用XML时，HTML用于显示数据，数据必须存储在。

　　HTML文件之内;使用了XML，数据就可以存放在分离的XML文档中。这种方法可以让你集中精力去到使用。

　　HTML做好数据的显示和布局上，并确保数据改动时不会导致HTML文件也需要改动。这样可以方便维护页面。

　　XML数据同样可以以“数据岛”的形式存储在HTML页面中。你仍然可以集中精力到使用HTML格式化和显示数据上去。

 XML用于交换数据

　　通过XML,我们可以在不兼容的系统之间交换数据。在现实生活中，计算机系统和数据库系统所存储的数据有N^N种形式,对于开发者来说，最耗时间的就是在遍布网络的系统之间交换数据。把数据转换为XML格式存。储将大大减少交换数据是的复杂性，并且还可以使得这些数据能被不同的程序读取。

 XML和B2B

　　使用XML,可以在网络中交换金融信息。在不远的将来，我们可以期望看到很多关于XML和B2B(BusinessToBusiness)的应用。XML正在成为遍布网络的商业系统之间交换金融信息所使用的主要语言。

　　许多与B2B有关的完全基于XML的应用程序正在开发中。

 XML可以用于共享数据

　　通过XML,纯文本文件可以用来共享数据。既然XML数据是以纯文本格式存储的，那么XML提供了一种与软件和硬件无关的共享数据方法。这样创建一个能够被不同的应用程序读取的数据文件就变得简单了。同样，我们升级操作系统、升级服务器、升级应用程序、更新浏览器就容易多了。

 XML可以用于存储数据

　　利用XML,纯文本文件可以用来存储数据。大量的数据可以存储到XML文件中或者数据库中。应用程序可以读写和存储数据，一般的程序可以显示数据。

 XML可以充分利用数据

　　使用XML,你的数据可以被更多的用户使用。既然XML是与软件、硬件和应用程序无关的，所以可以使你的数据可以被更多的用户、更多的设备所利用，而不仅仅是基于HTML标准的浏览器哦。别的客户端和应用程序可以把你的XML文档作为数据源来处理，就像他们对待数据库一样，你的数据可以被各种各样的“阅读器”处理，这时对某些人来说是很方便的，比如盲人或者残疾人。

 XML可以用于创建新的语言

　　XML是WAP和WML语言的母亲。无线标记语言,用于标识运行于手持设备上的Internet程序。

6.3 SOA

面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。SOA技术已存在超过20年的时间，但一直未得到广泛的应用。随着Web服务的出现逐渐被人们接纳，SOA终于迎来了自己的“春天”。对SOA的需要来源于需要使业务IT系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。就开发体系结构方面而言，SOA是将来的一个发展趋势。SOA将数据和信息作为服务公开的模型使其成为了一个非常强大的概念，与当前的应用程序构建块范例截然不同。

 独立的功能实体

　　在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

 大数据量低频率访问

对于.NET Remoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

 .基于文本的消息传递

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。每一项新技术都是在一些旧的技术基础上发展出来的。正如XML根本思想来自于在60年代就已经出现的早期标记性语言一样，SOA虽然这两年才出现，但是它所表达的观念应该说在网络这种分布式系统结构出现不久就已经广泛应用了。例如我们最熟悉的HTTP协议就是一个非常典型的SOA架构设计。HTTP协议的工作过程简单叙述如下：１）客户端，通常是通过浏览器，向服务器端以文本的方式发送一个请求，索取一个Web页面；２）服务器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML语法的文本；３）客户端接收到服务器端的响应文本后调用本地的程序，通常还是浏览器，把返回的HTML文本的内容展现出来。下面来看一下HTTP协议如何满足了SOA的特点：独立的功能实体：作为服务器端的Web服务器是绝对不会因为客户端的状况变化而改变的，它总是非常稳定的按照自己的内在逻辑运行，响应外部的请求，管理自己的资源和数据。这里一个非常好的例子就是Web服务器对缓存(Cache)的处理，很多Web服务器为了提高性能都或多或少的对数据进行缓存，但是缓存数据、刷新数据这些于客户端完全无关的操作完全由服务器端独立完成，完全不受客户端的影响。

6.4 REST

REST，即REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

REST提出了一些设计概念和准则：

　　1.网络上的所有事物都被抽象为资源（resource）；

　　2.每个资源对应一个唯一的资源标识（resource identifier）；

　　3.通过通用的连接器接口（generic connector interface）对资源进行操作；

　　4.对资源的各种操作不会改变资源标识；

　　5.所有的操作都是无状态的（stateless）。

　　对于当今最常见的网络应用来说，resource identifier是url，generic connector interface是HTTP，第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据，而是数据+特定的表现形式（representation），这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说，“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠（有一本书即卖得好，你又喜欢），甚至完全相同。但是它们的representation不同，因此是不同的resource。

REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和destory，这实际上就是对CURD的实现。更进一步讲，Rails（也是当今大部分网络应用）使用HTTP作为generic connector interface，HTTP则把对一个url的操作限制在了4个之内：GET、POST、PUT和DELETE。

　　REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。

6.5 CWM

CWM（CommonWarehouseMetamodel公共仓库元模型）是OMG组织在数据仓库系统中定义了一套完整的元模型体系结构，用于数据仓库构建和应用的元数据建模。CWM元模型由一系列子元模型构成，包括：资源数据元模型用于为对象型的、关系型的、记录型的、多维的和XML等数据源建模；数据分析元模型用于为数据转换、联机处理分析（OLAP）、数据挖掘、结果信息可视化等分析处理结果建模；仓库管理元模型用于为数据仓库处理流程和操作功能进行建模。CWM主要基于以下三个工业标准：

UML（UnifiedModelingLanguage）：统一建模语言，是OMG的一个建模标准；

MOF（MetaObjectFacility）：元对象设施，是OMG关于元模型和元数据库的标准；用来定义元数据并将其表示为CORBA对象的技术。提供在异构环境下对元数据库的访问接口。

XMI（XMLMetadataInterchange）：XML元数据交换，是OMG关于元数据交换的标准；提供基于文件数据流的元数据交换接口和机制。

这三个标准是OMG数据仓库元模型CWM体系结构的核心，CWM元模型直接继承UML元模型用于数据仓库元模型和模型的描述，CWM中的类和关联都直接或间接继承了UML中类的语法和语义。MOF为构建模型和元模型提供了可扩展的框架，并提供了存取元数据的程序接口（IDL/Java）。而利用XMI则可以将元数据转换为标准的XML数据流或文件的格式，以便进行交换，这大大增强了CWM的通用性。

CWM为在数据仓库领域应用MDA方法提供了有力的支持。在数据仓库领域，CWM是定义PIM的语言，其形式是UML；PIM及PSM通常以XML文档作为物理载体，而XMI规范保证这些XML文档具有可理解性和可移植性；MOF保证了PIM可以顺利的转换为PSM，并由PSM转换成代码模型。

6.6 XMI

XMI(XML-based Metadata Interchange)是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs（Document Type Definitions）为UML元模型（元模型是一类特殊的模型）和其他模型定义了一种基于XML的数据交换格式。它同时也定义了一个从UML到XML的映射。