1.元数据管理技术及应用现状
朋友老朱在最近惊喜地发现，在营业部的每周例会上，原先各部门针对每日用户数的争吵声，现在逐渐销声匿迹了。原来，老朱所在的这家电信运营商，最近刚刚验收并启用了一个元数据管理平台工具。通过这一平台，IT部门可以在那些曾经引发激烈争吵的数字后面加上详细的注解。这样，即便各部门得出的当日用户数数值不一样，也能在注解中清楚地看到具体的差异在哪里。如此，自然再没有了吵来吵去的必要。
元数据，最常见的定义是：“关于数据的数据”。更准确一点说：元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义（包括字典和分类法）以及操作特征（如活动指标和使用历史）。早在上世纪末，元数据的概念和相关工具就已经出现，但限于当时的数据量还不够大，而元数据本身又包含太多的内容，以至于它并未得到充分利用。而在今天看来，元数据正在成为解决诸多数据问题时必须要抓住的一个“精髓”要素。
消弭争吵
在此前一年中，老朱所在的那家电信运营商，各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实，在其他电信公司或者其他行业中也都存在着类似问题。简单来讲，这些公司通过各个时期的IT建设，形成了很多个独立分开的系统。以电信运营商为例，就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中，存有不同的客户信息，具体体现就是不同格式的表。
两年前，公司的数据仓库项目建设完成，本以为这会大步提升IT系统的“智能性”，没想到，基层的反映却是根本没法用。而其中的原因就在于，数据质量没法保证，也即：在业务逻辑上并不准确，各部门对于指标的定义不能统一。
以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有6000；市场部的系统显示却只有4000；到了财务部门的系统中，显示仅有3000个。在这种情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大家对数据仓库系统本身的可信度也就打了折扣。
事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月的时间也过去了。
元数据管理平台的建设就是为了避免继续出现类似问题。在元数据管理平台建成之后，其一，可以实现对技术元数据的抽取,把相关的字段放到平台上来。在这个平台上，就能清晰地看到这些表或字段之间的关联关系，有一个很清晰的视图。其二,还会把业务元数据抽取出来，确定要做哪些应用，就把相关的指标、流程在平台上建立起来。把这些元数据抽取出来后，用户可以通过平台很方便地修改数据仓库中的数据，调整业务中的统计指标等等。其三，就是要把技术元数据和业务元数据两种数据对应起来。比如对于当日用户数来讲,它在数据仓库中对应的都是哪些表，让技术元数据和业务元数据联系起来。这样，在把各种定义统一之后，元数据管理平台就可以给出一个更为详细的指标。比如在数值之后做出注解，注明具体开机的有多少，发生费用的又有多少。如此，老朱所在公司的争吵也就不复存在了。
第三方工具的魅力
虽然元数据至今尚未引起业界的广泛重视，但是与元数据相关的管理工具其实早就存在，而专业的元数据管理工具则在2000年左右开始出现，比如像IBM、CA、DAG、Informatica、BEA等公司都有自己专门的元数据管理工具。
总起来看，目前国内的元数据管理工具大概有三类。一是像IBM、CA等公司都提供的专门工具,比如IBM收购Ascential得到的Metastage，CA的DecisionBase都是如此；二是像DAG 的Metacenter，它不依托于某项BI产品，是一种第三方的元数据管理工具；三是像亚信、石竹这样的集成商也在开发自己的元数据管理工具。
“各种元数据管理工具有很多。理论上讲，用户可以用其中一种管理其他系统中的数据，比如选择数据仓库系统厂商提供的元数据管理工具来管理其他层面的元数据。但实际应用中的管理效果如何呢？一般情况是，这些专门工具管理自己本系统的元数据尚可，一旦跨系统管理，效果就不尽如人意了。” 亚信产品及解决方案咨询部总监薛森这样表示。
从国内的实际应用来看，DAG的Metacenter这一工具使用最多，目前所看到的在电信、金融领域建设的元数据管理项目基本上都是应用了这一产品。至于像CA等公司的工具，在国内基本上没有成功案例。记者在对CA公司提出采访要求的时候，该公司在回复中则称没有合适人员接受采访，看来像CA公司在元数据管理技术上似乎还比较滞后。
石竹商业智能软件部产品支持经理薛勇认为，Metacenter能够为很多用户所采用，主要因为这一产品的几项优势：一是它是第三方提供的工具。二是在技术上确有过人之处，可以实现动态元数据管理，实时获取元数据。而其他非第三方工具可能对自己数据仓库中的数据看得很快，但是对于其他系统就不行了。三是可以提供的应用多。比如像血统分析和影响分析、表重要程度和表无关程度分析等都可以提供。
此外，还有两个产品使得SOA和元数据的紧密关系迅速凸显出来。首先是IBM的
Web Sphere元数据服务器将于今年年底作为IBM WebSphere信息集成（WII）平台Hawk 版的组成部分正式上市。
WebSphere元数据服务器将为WII平台中的产品提供元数据管理，并为其他IBM软件品牌中的元数据项目提供通用的元数据服务基础设施。同在今年底，WebMethods公司将在12
月份发布的Fabric产品下一版本也融合了Cerebra公司的语义元数据管理功能，从而来为IT 部门提供了软件资源的单一视图。或许，只有当SOA战略充分认识到元数据管理的重要性之后，企业信息资源的业务价值才能实现最大化。
元数据管理工具现状一览表
应用决定功能
“这样一个平台不是仅仅把元数据抽取出来，我们把元数据管理平台定位为两个应用层次。”亚信产品及解决方案咨询部总监薛森指出了目前元数据管理平台的两个主要应用层次，即系统维护和应用分析。从系统维护来看，元数据管理平台使得数据仓库以及业务系统中的各种修改变得省心省力。比如对数据库中表的修改，小的数据仓库模型的修改等等，都可以通过元数据管理平台来实现。同时对数据仓库、OLAP、ETL等各个层面进行修改。而在以前，这些工作需要DBA自己来完成。
那时虽然也有一些工具，但是都分散在不同的系统中。一个DBA要完成全部修改必须要求精通所有工具才能实现。而如果是多个DBA协作完成，同样需要通知所有人在数据仓库、OLAP、前端展现、ETL等系统中依次修改，耽误时间不说，修改是否准确也不能保证，而业务在这个修改阶段也会陷于停滞。从应用分析上看，目前可见的应用主要有三类。
其一，作为即席查询工具做指标的管理，即通过基于元数据的指标管理，掌控各种指标的异常波动情况。据薛森介绍，像亚信公司建设的吉林移动的元数据管理平台，现在就已经开放了一些接口给业务人员。他们只需通过拖拽一些业务元数据就可以得到他们想要的东西。比如，要找出某项业务的前十大用户，业务人员通过元数据平台提供的即席查询工具，几次操作就可得到结果。而在过去，这需要业务人员首先提出请求，然后计费中心会制作一个工单，再把工单传给集成厂商，厂商再把这个工单分解开来，让某人做ETL层，某人做OLAP层。等这些都做完，半个月的时间也就搭进去了。
当然，薛森也表示，目前这种应用接口还比较有限，因为如果每个业务人员都在用，数据仓库就承受不住了。其二，血统分析和影响分析。血统分析是指，发现某报表中的指标不正常就需要查出问题可能出在哪里。通过血统图就可以很快找出问题是在BOSS系统中，还是在ODS层或者是DW层中。影响分析则和血统图相反，主要看在修改一个表之后，可能会影响到上游的哪些数据。其三，表重要程度分析和表无关程度分析。主要就是针对现在数据仓库提供的表的数量太多（上万个）。这些表中有的使用频率特别高，就需要加倍小心，多做优化。通过元数据管理平台就可以列出不同重要程度的表。
据石竹商业智能软件部产品支持经理薛勇介绍，目前，像四川移动的元数据管理平台上，以上三类应用基本上都已存在。但是，他也表示，目前针对元数据管理平台的应用大都还在探索阶段。亚信薛森也认为，更重要的应用还在于更复杂的分析上。此外，据说目前国内迄今为止最为全面的一个元数据管理平台项目正在中国银行总行抓紧实施，现在尚未开始验收，其中还将出现哪些新的应用尚且不得而知。
编看编想
不够成熟，但足够重要！
“你在做元数据管理平台项目时，最大的工作量是花在哪里？”这是笔者对每位被访者都会问的一个问题，而两位采访者不约而同提到的一点就是，整理元数据。事实上，这一问题也正彰显着目前国内的元数据管理项目尚不够成熟。
“说不成熟，是因为数据不成熟。”薛森表示。作为企业，从一开始就没有完整的规划，比如当初指标的含义，现在几乎都需要倒着往回推，要获得那些元数据自然就比较困难。薛勇也认为，各部门都有各自的描述方式，比如对于男女，有的分成F和M，有的分成0和1。如果把这些整理出来，是个很麻烦的过程。而要克服这种困难，只能靠熬时间一点一点解决。而像管理工具本身的不成熟也是一个方面。薛勇就认为，目前的元数据管理工具还不能自动把不同系统元数据之间的关系自动映射出来，还需要人工去做。
此外，目前平台导入的元数据范围也还很有限。比如在电信企业中，大多仅仅导入了经营分析系统的元数据。而像BOSS系统，动辄都有几千个业务控制点，导入元数据弄不好就要影响业务。也正是因为顾及到这一点，所以目前的元数据管理平台只是选择了在经营分析系统这样一个准实时的分析系统上做试点，然后再逐步推广。
总起来看，目前国内大型行业企业做元数据管理项目虽然不成熟，但是技术发展很快；见效虽然不快，但是早晚要做，而且早做比晚做遇到的困难相对要少些。对于那些有条件的大型行业用户，早点入手无疑更好一些。(CCW-CNW)
2.元数据管理技术及应用现状
朋友老朱在最近惊喜地发现，在营业部的每周例会上，原先各部门针对每日用户数的争吵声，现在逐渐销声匿迹了。原来，老朱所在的这家电信运营商，最近刚刚验收并启用了一个元数据管理平台工具。通过这一平台，IT部门可以在那些曾经引发激烈争吵的数字后面加上详细的注解。这样，即便各部门得出的当日用户数数值不一样，也能在注解中清楚地看到具体的差异在哪里。如此，自然再没有了吵来吵去的必要。
元数据，最常见的定义是：“关于数据的数据”。更准确一点说：元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性（例如，结构和行为）这样的特征、业务定义（包括字典和分类法）以及操作特征（如活动指标和使用历史）。早在上世纪末，元数据的概念和相关工具就已经出现，但限于当时的数据量还不够大，而元数据本身又包含太多的内容，以至于它并未得到充分利用。而在今天看来，元数据正在成为解决诸多数据问题时必须要抓住的一个“精髓”要素。
消弭争吵
在此前一年中，老朱所在的那家电信运营商，各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实，在其他电信公司或者其他行业中也都存在着类似问题。简单来讲，这些公司通过各个时期的IT建设，形成了很多个独立分开的系统。以电信运营
商为例，就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中，存有不同的客户信息，具体体现就是不同格式的表。
两年前，公司的数据仓库项目建设完成，本以为这会大步提升IT系统的“智能性”，没想到，基层的反映却是根本没法用。而其中的原因就在于，数据质量没法保证，也即：在业务逻辑上并不准确，各部门对于指标的定义不能统一。
以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲，就是在业务元数据上，大家对于业务的认识并不统一。比如：计费部门认为，一个用户当天曾拨打电话，就可以计入到当日用户数；而财务部门则认定，只有在发生费用之后才能计入；至于网络部，则认为当天开机的用户就可以算作当日用户。如此一来，各部门的当日用户数数值自然就不一样：计费中心的系统显示，当日用户数有6000；市场部的系统显示却只有4000；到了财务部门的系统中，显示仅有3000个。在这种情况下，担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字，导致大家对数据仓库系统本身的可信度也就打了折扣。
事实上，类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是，原先未能统一的定义导致了某种指标的不一致，而要搞清楚为什么不一致，就得反查数据仓库中的这些表在一开始的时候是如何定义的，表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是，现在的软件开发一般都是迭代式开发，每个阶段都有不同的人在做。回查一个表，很可能需要涉及到这个过程中的每一个开发人员。事实上，很少有人能做到这一点。即便费尽心机终于查到了，一个月的时间也过去了。
元数据管理平台的建设就是为了避免继续出现类似问题。在元数据管理平台建成之后，其一，可以实现对技术元数据的抽取,把相关的字段放到平台上来。在这个平台上，就能清晰地看到这些表或字段之间的关联关系，有一个很清晰的视图。其二,还会把业务元数据抽取出来，确定要做哪些应用，就把相关的指标、流程在平台上建立起来。把这些元数据抽取出来后，用户可以通过平台很方便地修改数据仓库中的数据，调整业务中的统计指标等等。其三，就是要把技术元数据和业务元数据两种数据对应起来。比如对于当日用户数来讲,它在数据仓库中对应的都是哪些表，让技术元数据和业务元数据联系起来。这样，在把各种定义统一之后，元数据管理平台就可以给出一个更为详细的指标。比如在数值之后做出注解，注明具体开机的有多少，发生费用的又有多少。如此，老朱所在公司的争吵也就不复存在了。
第三方工具的魅力
虽然元数据至今尚未引起业界的广泛重视，但是与元数据相关的管理工具其实早就存在，而专业的元数据管理工具则在2000年左右开始出现，比如像IBM、CA、DAG、Informatica、BEA等公司都有自己专门的元数据管理工具。
总起来看，目前国内的元数据管理工具大概有三类。一是像IBM、CA等公司都提供的专门工具,比如IBM收购Ascential得到的Metastage，CA的DecisionBase都是如此；二是像DAG 的Metacenter，它不依托于某项BI产品，是一种第三方的元数据管理工具；三是像亚信、石竹这样的集成商也在开发自己的元数据管理工具。
“各种元数据管理工具有很多。理论上讲，用户可以用其中一种管理其他系统中的数据，比如选择数据仓库系统厂商提供的元数据管理工具来管理其他层面的元数据。但实际应用中的管理效果如何呢？一般情况是，这些专门工具管理自己本系统的元数据尚可，一旦跨系统管理，效果就不尽如人意了。” 亚信产品及解决方案咨询部总监薛森这样表示。
从国内的实际应用来看，DAG的Metacenter这一工具使用最多，目前所看到的在电信、金融领域建设的元数据管理项目基本上都是应用了这一产品。至于像CA等公司的工具，在国
内基本上没有成功案例。记者在对CA公司提出采访要求的时候，该公司在回复中则称没有合适人员接受采访，看来像CA公司在元数据管理技术上似乎还比较滞后。
石竹商业智能软件部产品支持经理薛勇认为，Metacenter能够为很多用户所采用，主要因为这一产品的几项优势：一是它是第三方提供的工具。二是在技术上确有过人之处，可以实现动态元数据管理，实时获取元数据。而其他非第三方工具可能对自己数据仓库中的数据看得很快，但是对于其他系统就不行了。三是可以提供的应用多。比如像血统分析和影响分析、表重要程度和表无关程度分析等都可以提供。
此外，还有两个产品使得SOA和元数据的紧密关系迅速凸显出来。首先是IBM的
Web Sphere元数据服务器将于今年年底作为IBM WebSphere信息集成（WII）平台Hawk 版的组成部分正式上市。
WebSphere元数据服务器将为WII平台中的产品提供元数据管理，并为其他IBM软件品牌中的元数据项目提供通用的元数据服务基础设施。同在今年底，WebMethods公司将在12
月份发布的Fabric产品下一版本也融合了Cerebra公司的语义元数据管理功能，从而来为IT 部门提供了软件资源的单一视图。或许，只有当SOA战略充分认识到元数据管理的重要性之后，企业信息资源的业务价值才能实现最大化。
元数据管理工具现状一览表
应用决定功能
“这样一个平台不是仅仅把元数据抽取出来，我们把元数据管理平台定位为两个应用层次。”亚信产品及解决方案咨询部总监薛森指出了目前元数据管理平台的两个主要应用层次，即系统维护和应用分析。从系统维护来看，元数据管理平台使得数据仓库以及业务系统中的各种修改变得省心省力。比如对数据库中表的修改，小的数据仓库模型的修改等等，都可以通过元数据管理平台来实现。同时对数据仓库、OLAP、ETL等各个层面进行修改。而在以前，这些工作需要DBA自己来完成。
那时虽然也有一些工具，但是都分散在不同的系统中。一个DBA要完成全部修改必须要求精通所有工具才能实现。而如果是多个DBA协作完成，同样需要通知所有人在数据仓库、OLAP、前端展现、ETL等系统中依次修改，耽误时间不说，修改是否准确也不能保证，而业务在这个修改阶段也会陷于停滞。从应用分析上看，目前可见的应用主要有三类。
其一，作为即席查询工具做指标的管理，即通过基于元数据的指标管理，掌控各种指标的异常波动情况。据薛森介绍，像亚信公司建设的吉林移动的元数据管理平台，现在就已经开放了一些接口给业务人员。他们只需通过拖拽一些业务元数据就可以得到他们想要的东西。比如，要找出某项业务的前十大用户，业务人员通过元数据平台提供的即席查询工具，几次操作就可得到结果。而在过去，这需要业务人员首先提出请求，然后计费中心会制作一个工单，
再把工单传给集成厂商，厂商再把这个工单分解开来，让某人做ETL层，某人做OLAP层。等这些都做完，半个月的时间也就搭进去了。
当然，薛森也表示，目前这种应用接口还比较有限，因为如果每个业务人员都在用，数据仓库就承受不住了。其二，血统分析和影响分析。血统分析是指，发现某报表中的指标不正常就需要查出问题可能出在哪里。通过血统图就可以很快找出问题是在BOSS系统中，还是在ODS层或者是DW层中。影响分析则和血统图相反，主要看在修改一个表之后，可能会影响到上游的哪些数据。其三，表重要程度分析和表无关程度分析。主要就是针对现在数据仓库提供的表的数量太多（上万个）。这些表中有的使用频率特别高，就需要加倍小心，多做优化。通过元数据管理平台就可以列出不同重要程度的表。
据石竹商业智能软件部产品支持经理薛勇介绍，目前，像四川移动的元数据管理平台上，以上三类应用基本上都已存在。但是，他也表示，目前针对元数据管理平台的应用大都还在探索阶段。亚信薛森也认为，更重要的应用还在于更复杂的分析上。此外，据说目前国内迄今为止最为全面的一个元数据管理平台项目正在中国银行总行抓紧实施，现在尚未开始验收，其中还将出现哪些新的应用尚且不得而知。
编看编想
不够成熟，但足够重要！
“你在做元数据管理平台项目时，最大的工作量是花在哪里？”这是笔者对每位被访者都会问的一个问题，而两位采访者不约而同提到的一点就是，整理元数据。事实上，这一问题也正彰显着目前国内的元数据管理项目尚不够成熟。
“说不成熟，是因为数据不成熟。”薛森表示。作为企业，从一开始就没有完整的规划，比如当初指标的含义，现在几乎都需要倒着往回推，要获得那些元数据自然就比较困难。薛勇也认为，各部门都有各自的描述方式，比如对于男女，有的分成F和M，有的分成0和1。如果把这些整理出来，是个很麻烦的过程。而要克服这种困难，只能靠熬时间一点一点解决。而像管理工具本身的不成熟也是一个方面。薛勇就认为，目前的元数据管理工具还不能自动把不同系统元数据之间的关系自动映射出来，还需要人工去做。
此外，目前平台导入的元数据范围也还很有限。比如在电信企业中，大多仅仅导入了经营分析系统的元数据。而像BOSS系统，动辄都有几千个业务控制点，导入元数据弄不好就要影响业务。也正是因为顾及到这一点，所以目前的元数据管理平台只是选择了在经营分析系统这样一个准实时的分析系统上做试点，然后再逐步推广。
总起来看，目前国内大型行业企业做元数据管理项目虽然不成熟，但是技术发展很快；见效虽然不快，但是早晚要做，而且早做比晚做遇到的困难相对要少些。对于那些有条件的大型行业用户，早点入手无疑更好一些。(CCW-CNW)
MetaOne产品简介
MetaOne 功能简介 MetaOne 基本功能 元模型/元数据管理 元数据关系维护 自动获取/批量导入 元数据版本管理 基本分析功能 元数据全文检索 系统管理 MetaOne 高级功能 元数据发布流程管理 高级分析功能 元数据分析 基本分析：血统分析、影响分析、映射分析等 高级分析：差异分析、表重要程度分析、表无关程度分析等 血统分析 元数据是企业数据资源管理、使用的基础。MetaOne 作为企业实施元数据管理的软件支撑平台，其先进的理念、成熟的技术让业界耳目一新。 元模型/元数据管理 元模型支持CWM 规范，可完全扩展；元数据展现树型化，体系结构清晰直观；支持常规数据类型，及针对企业应用的特殊类型，如大文本、枚举、公式编辑器、URL 等。 自动获取/批量导入元数据 自动获取：PowerCenter 、DataStage 、Oracle 、DB2、DB2 OLAP SERVER 、 Essbase 、TeraData 等 批量导入：Excel 格式、XMI 格式、Erwin 、PowerDesigner 等 元数据全文检索 多种组合条件的模糊查询，可在整个元数据环境随时检索所需信息 系统管理 基于角色的用户权限管理；用户可定制系统参数； 元数据发布流程管理 提供元数据发布流程管理，规范企业元数据的管理流程。可以让企业更好地管理和跟踪元数据的整个生命周期， 在元数据的流程管理中， 可以安全地创建、获取、扩展的元数据信息。 元数据关系维护 图形化的元数据关系维护，拖拉鼠标轻松实现，效果直观易于维护； 图形化维护ETL 程序内部的字段级映射关系，清晰追溯数据来源及加工过程。 元数据版本管理 元数据版本变更记录、版本变更查询、版本浏览、版本恢复
龙源期刊网 https://www.doczj.com/doc/7712134322.html, 电子档案元数据的管理方案 作者：陈兰 来源：《经营者》2018年第06期 摘要随着社会的进步和信息技术的不断发展，越来越多的电子文件在其归档后就形成了电子档案，这种电子档案是保存各种电子文件的重要工具。其中，元数据是这种电子档案的基础，它又被叫作“关于数据的数据”，是记录各种电子文件全部信息的重要工具，通过元数据可以实现对各种重要的电子文件的完整性、真实性的保护。 关键词电子档案元数据管理方案 元数据的准确定义为：对各种信息资源进行结构化的描述，提供关于信息资源或数据的一种结构化数据。它可以对各种电子数据本身的特征和属性进行描述，具有发现、检索、管理、描述等功能。目前基于元数据的电子档案管理已经广泛应用于各行各业。本文对元数据在电子档案管理中的功能、电子档案元数据管理方案等几个方面进行研究和探讨。 一、元数据在电子档案管理中的作用 （一）保证电子档案的真实性和完整性 因为电子档案与实体分离，并且可以通过相关的操作进行变更，所以它的真实性往往会受到怀疑。但是，如果电子档案有了元数据，就可以将整个电子档案的形成、利用、处理的过程记录下来，从而保证整个电子档案的真实性和完整性。 （二）确保电子档案的长期可读性 我们知道，电子档案的生成和保存主要是依靠电脑和一些软件，一旦电脑或者是软件运行出现问题，电子档案就无法识别。在这种情况下，就可以利用元数据建立相应的模型对电子档案的格式信息、制作信息、转换方式等进行详细的记录与描述，这样就可以在电子档案迁移过程中保证其完整性和可读性。 （三）具有发现、检索、管理、描述等基本功能 元数据最基本的功能就是描述功能，它可以对档案信息对象的属性和位置进行详细的描述，从而将所找对象的基本信息呈现在人们面前。此外，因为元数据将主要信息展示出来了，所以就便于人们快速查找所需信息。同时，元数据还可以对各种资源对象的各个部件之间的结构和关联模式进行管理。 二、电子档案元数据的管理方案
数据管理系统企业级数据可视化项目Html5 应用实践 项目经理：李雪莉 组员：申欣邹丽丹陈广宇陈思 班级：大数据&数字新媒体 一、项目背景 随着大数据、云计算和移动互联网技术的不断发展，企业用户对数据可视化的需求日益迫切。用户希望能够随时随地简单直观的了解企业生产经营、绩效考核、关键业务、分支机构的运行情况，即时掌握突发性事件的详细信息，快速反应并作出决策。随着企业信息化的不断推进，企业不断的积累基础信息、生产运行、经营管理、绩效考核、经营分析等以不同形式分布在多个系统或个人电脑文档内的业务数据。如何将大量的数据进行分析整理，以简单、直观、高效的形式提供给管理者作为经营决策的依据是当前企业数据应用的迫切需求。传统的企业数据可视化方案多基于Java Applet、Flash、Silverlight 等浏览器插件技术进行开发，在当前互联网和移动互联网技术高速发展的背景下，Web技术标准也随之高速发展，用户对互联网技术安全性和使用体验的要求越来越高。Java Applet、Flash、Silverlight 等浏览器插件技术因为落后和封闭的技术架构，以及高功耗、高系统
资源占用，已经被微软、谷歌、苹果、火狐等主流操作系统和浏览器厂商逐步放弃，转而不断支持和完善基于HTML5的新一代Web技术标准 对数据进行直观的拖拉操作以及数据筛选等，无需技术背景，人人都能实现数据可视化无论是电子表格，数据库还是 Hadoop 和云服务，都可轻松分析其中的数据。 数据可视化是科学、艺术和设计的结合，当枯燥隐晦的数据被数据科学家们以优雅、简明、直观的视觉方式呈现时，带给人们的不仅仅是一种全新的观察世界的方法，而且往往具备艺术作品般的强大冲击力和说服力。如今数据可视化已经不局限于商业领域，在社会和人文领域的影响力也正在显现。 数据可视化的应用价值，其多样性和表现力吸引了许多从业者，而其创作过程中的每一环节都有强大的专业背景支持。无论是动态还是静态的可视化图形，都为我们搭建了新的桥梁，让我们能洞察世界的究竟、发现形形色色的关系，感受每时每刻围绕在我们身边的信息变化，还能让我们理解其他形式下不易发掘的事物。 二、项目简介 目前，金融机构（银行，保险，基金，证劵等）面临着诸如利率汇率自由化，消费者行为改变，互联网金融崛起等多个挑战。为满足企业的发展需要，要求管理者运用大数据管理以更为科学的手段对企
元数据管理平台 技术白皮书 北京亿信华辰软件责任有限公司 2018年4月
目录 1.前言 (1) 1.1.关于本白皮书 (1) 1.2.背景介绍 (1) 1.3.产品定位 (1) 2.产品架构 (2) 2.1.概述 (2) 2.2.数据源层 (2) 2.3.采集层 (2) 2.4.数据层 (3) 2.5.功能层 (3) 2.6.访问层 (3) 3.产品功能特色 (4) 3.1.规范的元模型管理 (4) 3.2.端到端的自动化采集 (5) 3.3.全面的采集适配器 (5) 3.4.可灵活定制的采集模板 (6) 3.5.便捷的元数据检索 (7) 3.6.完善的元数据管理 (7) 3.7.强大的元数据版本管理 (8) 3.8.实时的元数据变更监控 (8) 3.9.数据地图鸟瞰全局 (9) 3.10.丰富的元数据分析应用 (9) 3.10.1.血缘分析 (9) 3.10.2.影响分析 (10) 3.10.3.全链分析 (10) 3.10.4.关联度分析 (11) 3.10.5.属性差异分析 (11) 3.11.出色的元数据检核机制 (12) 3.11.1.一致性检核 (12) 3.11.2.属性填充率检核 (12) 3.11.3.组合关系检核 (12) 3.12.自助式门户 (13) 3.13.丰富的服务接口 (13) 4.产品技术优势 (13)
4.1.系统设计原则 (13) 4.1.1.先进性 (14) 4.1.2.可维护性 (14) 4.1.3.可靠性 (14) 4.1.4.易用性 (15) 4.1.5.安全性 (15) 4.1.6.扩展性 (15) 4.2.可扩展采集适配器设计 (16) 4.3.采用MOF规范 (16) 4.4.支持基于XMI的数据交换 (17) 4.5.运用REST FUL架构 (18) 5.软硬软件环境 (19) 5.1.服务器配置推荐 (19) 5.2.客户端配置 (20) 5.2.1.客户端(建议配置) (20) 5.2.2.客户端浏览器 (20)
元数据解决方案 随着报价系统每年收集和使用的数据飞速增长，数据体量日趋增长，数据形态多样化且不统一，多种数据源之间的采集、传播和共享遇到困难。元数据管理作为大数据治理的核心，是有效管理这些数据的基础和前提，在信息化建设中发挥着重要的作用。如何理解、管理并发挥出元数据的价值，成为迫切的任务。 一、什么是元数据 元数据（Metadata）是关于数据的数据。元数据是描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。 1. 技术元数据 技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息： 1) 数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据 的定义，以及数据集市的位置和内容。 2) 业务系统、数据仓库和数据集市的体系结构和模式。 3) 汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、 汇总、预定义的查询与报告。 4) 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分 割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存 取控制）。 2. 业务元数据 业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：
1) 使用者的业务术语所表达的数据模型、对象名和属性名。 2) 访问数据的原则和数据的来源。 3) 系统所提供的分析方法以及公式和报表的信息。 4) 企业概念模型、多维数据模型，业务概念模型与物理数据的依赖， 二、元数据的作用 元数据可以实现业务模型与数据模型的映射，帮助用户理解数据仓库中的数据；元数据清晰的描述了数据的来龙去脉，描述了数据抽取转换规则，是保证数据质量的关键；元数据管理系统可以把整个业务的工作流、数据流和信息流有效的管理，可以支持需求变化，从而提高系统的可扩展性；打通数据孤岛，统一数据定义，形成企业级知识传承平台，元数据管理使得数据变的更有价值。三、元数据管理 在大数据时代的背景下，数据即资产，元数据实现了信息的描述和分类的格式化，从而为机器处理创造了可能，它能帮助企业更好地对数据资产进行管理，理清数据之间的关系。元数据管理是企业提升数据质量的基础，也是企业数据治理中的关键环节。元数据管理不当，信息很容易被丢失，进而不能对业务进行有效支撑，企业内部业务人员要识别相关信息就会变得十分困难，最终用户也将失去对数据的信任。 1. 元数据采集 技术元数据的采集，根据现有元数据设计出元模型，然后将数据仓库系统之中的元数据按元模型集中汇总并关联到一起，达到企业对数据统一管理与应用的目的，ETL等产生的元数据，对于元数据管理工具支持的格式可直接进行导入，对于一些自定义的规则，需要进行格式转换并导入。
典型的元数据方案 3.1都柏林核心（Dublin core）简介 Dublin core是都柏林元数据核心元素集（Dublin metadata core element set）的简称，在1995年3月，由超级图书馆中心和美国超级计算机应用中心主持，在美国俄亥俄州都柏林召开的第一届元数据研讨会上提出的。其目的就是希望建立一套适合描述网络资源的方法，用来信息识别，查询，组织，检索。 DC元数据简练，易于理解，扩展性强，与其他元数据形式兼容性强。网络资源能够被有效的整合利用，是它成为了一个良好的网络资源描述元数据集合。 DC研讨会已经召开了十届，从理解DC研讨会中我们可以总结出每一节研讨会都推出了一些具体的研究成果，并且在深度，广泛度上都有发展。DC元数据理论不断在实践中完善。 都柏林十次研讨会时间地点及成果如表1
3.2 DC语法的实现 DC在HTML的语法主要是通过“标记”和“标记”来实现的。 以下是一个基于XML和RDF的DC元数据详例：
元数据管理平台的建立 1.1 元数据简介 元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。 元数据（Metadata）是描述其它数据的数据（data about other data），或者说是用于提供某种资源的有关信息的结构数据（structured data）。元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。 元数据的基本特点主要有： 1、元数据一经建立，便可共享。元数据的结构和完整性依赖于信息资源的价值和使用环境；元数据的开发与利用环境往往是一个变化的分布式环境；任何一种格式都不可能完全满足不同团体的不同需要； 2、元数据首先是一种编码体系。元数据是用来描述数字化信息资源，特别是网络信息资源的编码体系，这导致了元数据和传统数据编码体系的根本区别；元数据的最为重要的特征和功能是为数字化信息资源建立一种机器可理解框架。 元数据体系构建了企业业务的逻辑框架和基本模型,从而决定了企业业务的功能特征、运行模式和系统运行的总体性能。企业业务的运作都基于元数据来实现。其主要作用有：描述功能、整合功能、控制功能和代理功能。 由于元数据也是数据，因此可以用类似数据的方法在数据库中进行存储和获取。如果提供数据元的组织同时提供描述数据元的元数据，将会使数据元的使用变得准确而高效。用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。
在数据仓库领域中，元数据按用途分成技术元数据和业务元数据。首先，元数据能提供基于用户的信息，如记录数据项的业务描述信息的元数据能帮助用户使用数据。其次，元数据能支持系统对数据的管理和维护，如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。具体来说，在数据仓库系统中，元数据机制主要支持以下五类系统管理功能: （1）描述哪些数据在数据仓库中； （2）定义要进入数据仓库中的数据和从数据仓库中产生的数据； （3）记录根据业务事件发生而随之进行的数据抽取工作时间安排； （4）记录并检测系统数据一致性的要求和执行情况； （5）衡量数据质量。 1.2 元数据管理平台体系结构 图1 元数据管理平台体系结构 关键特性
数据管理平台建设方案 Document number：NOCG-YUNOO-BUYTT-UU986-1986UT
数据管理平台建设方案 目录 一、数据管理平台项目概述 建立韶关市中小科技企业数据库。韶关市中小科技企业数据库主要收录韶关市科技中小企业的财务数据、治理数据等涉及企业经营和管理的相关的数据，以便为政府决策提供参考。 韶关市中小科技企业数据库的项目建设包括硬件部分和软件部分建设。软件部分建设方面，韶关市科技金融综合服务中心希望能建设成一套综合性的数据管理平台。该数据管理平台的建设以搭建中心与企业桥梁为目标，以提供专业化服务平台为导向，应具备高性能、高安全性、高可靠性、可扩展性、高可用性，便于将来拓展和进一步改造。 二、总体设计 需求概述 1、功能性需求 数据管理平台采用B/S模式，业务操作简单、扩展方便。平台用户群体主要是企业用户与管理员。平台分为前端、后端，具备展示、操作、分析等功能，可以满足服务中心一整套的数据采集、管理、展示及分析需求，具体包含以下模块： ?录入系统
录入系统是录入数据的源头，本着方便录入人员界面录入操作的原则设计，更有效提高数据录入效率。录入系统的数据除了人工录入外，还有一部分通过自动化配置导入的方式，配合人工录入，提高效率。 ?内容发布系统 用户根据需要查询、发布、修改、删除科技金融服务中心的新闻、公告。 并在前端展示。 ?信息检索系统 点击“表”进入检索界面，会员可进行“企业筛选”、“时间筛选”、“字段选 择”、“条件筛选”，快速定位需要数据。 ?元数据管理系统 是韶关市中心企业库的信息目录，用户可很快捷地查询出相关库的信息及与该库相关的流入流出。元数据管理主要是针对韶关市科技金融服务中心的各种元数据进行管理，主要包括元数据的查询，新增，修改，删除。通过建设元数据系统，拥有统一、标准、规范化的库信息，并在所有数据流程中实现有效管理，降低维护成本与资源内耗。 ?数据质检系统 财务数据质检与自动化质检配置结合，用户提交数据同时根据已配置的质检关系将通过质检数据入库，展现用户。为通过质检数据显示在质检不通过列表中根据已配置的质检关系显示对应的错误信息，用户根据错误信息修改数据再次提交质检。 ?配置管理系统
1.前言 数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息，其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等，而且整个数据仓库系统的运行都是基于元数据的，是元数据把数据仓库系统中的各个松散的组件联系起来，组成了一个有机的整体。2.元数据 2.1 元数据的概念 按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。 技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息。 2.2 元数据的作用 在数据仓库系统中，元数据机制主要支持以下五类系统管理功能：（１）描述哪些数据在数据仓库中；（２）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（３）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（４）记录并检测系统数据一致性的要求和执行情况；（５）衡量数据质量。 与其说数据仓库是软件开发项目，还不如说是系统集成项目[1]，因为它的主要工作是把所需的数据仓库工具集成在一起，完成数据的抽取、转换和加载，OLAP分析和数据挖掘等。 3.数据仓库元数据管理现状 元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模
3.6.3遥感影像元数据管理服务系统 遥感影像元数据管理系统在定位为在国家监管中心实现遥感影像元数据管理和对外服务的 基础设施，建成一套持续化、业务化运行系统。该系统的建设目标是：一方面满足海量持续增加的遥感影像数据有序管理的问题，同时面向海洋监测应用部门提供强大的影像服务功能。在保证数据安全的前提下，提供高效快捷的遥感影像网络服务支撑保障和数据持续有效集成能力。 主要工作及系统功能包括： （1）遥感影像元数据库规范 遥感影像元数据库是存放遥感影像数据元数据的空间数据库，以方便用户或者其他程序查询和使用特定的影像数据。遥感影像元数据库规范包括两个部分，一是空间数据模型规范，即如何根据遥感影像数据涉及的数据类型创建空间数据模型；一是元数据信息组织规范，即如何依据影像数据的元数据规范将影像数据的元数据信息有效组织到数据库中，利用ArcSDE 空间数据库进行一体化管理。 （2）影像数据管理子系统 系统采用C/S模式，面向业务人员。提供的具体功能包括：1）批量自动化灵活直接入库和快速浏览影像库支持的各类数据及其元数据；2）高效多条件检索影像库管理的数据并显示；3）直接读取影像库外多种格式影像并自动叠加显示、便捷注册和发布影像与地图服务等；4）管理员可以对不同类型用户和影像数据进行授权和分级管理。 影像数据管理子系统主要功能指标详细如下： *支持常用国外卫星影像数据：WorldView 1/2/3, GeoEye-1/2, RapidEye, IKONOS, QuickBird, Spot5, Spot6, Landsat-5 TM, Landsat-7 ETM+和Landsat-8 ALI等和国内主要卫星影像数据：HJ-A/B CCD, ZY-02-C, ZY-3、CBERS-3/4、天绘系列、高分系列、资源系列等； 影像实时动态镶嵌（自动计算金字塔、覆盖区域和显示比例以及处理分辨率）； 影像元数据自动识别和解析，交互式元数据灵活更新和扩展； 读取和叠加GeoTIFF, ERDAS Image, eYaImage, ECW和JPEG等格式影像； 影像服务和地图服务的编辑，发布，和管理。 （3）影像共享服务子系统 基于B/S结构，面向管理和业务用户提供影像数据服务，包括影像数据检索服务、数据下载服务、影像展示服务等。系统包含以下四个功能模块：几何查询、属性条件过滤、查询结果浏览、对外影像和地图服务等。 系统结构为四层结构，客户浏览层、Web服务层、GIS中间件层以及影像数据存储层。其中，Web服务层基于SOA架构，为客户端提供业务服务；客户浏览器层则基于ArcGIS API for Flex；GIS中间件层提供遵循OGC规范的GIS服务，将遥感影像地理信息库和文件存储库中的数据提供给Web服务层 （4）影像动态处理和镶嵌融合模块 该模块是利用服务器端发布的Image Service服务，为用户提供影像数据进动态镶嵌融合处
元数据管理方案 1.1元数据抽取 为了简化元数据生成工作，系统提供自动生成元数据的功能，即元数据抽取。通过元数据自动抽取，用户可以方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象 元数据抽取主要针对的对象有以下几种： 已有目录：已建业务应用系统中现有的目录资源。 数据库：各种数据库资源，包括关系型数据库、XML数据库等。 格式化电子文件：电子文件，例如Word、PDF、XLS等文件。 1.1.2元数据抽取的流程 元数据抽取的流程有4个主要步骤，分别为： 数据源信息获取：解决要从哪个数据源获得元数据的问题。 内容/结构分析：解决要从数据源中获得哪些元数据的问题。 元数据提取：解决如何从数据源中获取元数据的问题。 存储入库：解决元数据存储的问题。 1.1.3电子文档的元数据抽取 对于电子文档，首先各部门的文档格式不尽相同，另外它们的安全级别也各不相同，同时由于信息化建设水平的不一致，有的部门文档分散在各处，有的部门文档是集中存放的，甚至已经建立了完善的电子系统进行管理。 针对以上状况，对于电子文档的元数据抽取需要进行以下的抽取流程： 整理归档 对于分散在各处的电子文档(纸质文档需要先进行电子化处理)，必须由专人进行统
一整理，根据公开共享的前提进行集中，这种集中可以是物理上集中的，也可以是逻辑上集中的。但要满足以下原则，第一根据安全级别，便于外界访问；第二便于文档的增量发布；第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下，进行自动化采集才是切实可行的。在整理归档的时候，各部门根据各自情况进行归档，没有必要千篇一律，也没有必要制定繁琐和呆板的规则，只要能够满足以上的原则即可。 ●根据安全级别，建立相应的访问机制 由于受到安全级别的限制，所以对于需要共享的数据要进行安全方面的限制，限制的手段可以有：用户名/密码、数字证书、物理隔断等等，根据实际情况建立安全访问机制，做到重要信息不泄露，不丢失。 ●编目处理 现阶段，主流格式的电子文档，主要包含：word、excel、ppt、pdf等。对主流格式的电子文档，要提供自动采集工具进行编目处理。采集的范围主要是文档的标题和内容，对于其它的元数据内容，要提供手工配置的方式进行辅助。另外，在工具的采集效率上，要提高增量文档发布后的采集效率。 对于格式特殊、内容有加密算法的文档，是很难通过抓取工具进行采集的，这些文档主要通过手工编目的方式来处理。 对于存在管理库的文档，就需要对数据库来进行编目采集，详见数据库元数据抽取部分。 ●保存元数据 采集后的数据要放到数据库或者保存到硬盘上，另外要根据目录体系标准，把数据分解为元数据，然后进行存储 1.1.4数据库元数据抽取 数据中心需要抽取的数据库类型主要为Sql server，首先利用ETL工具从源数据库中将所需数据抽取至中心数据库基础业务库中，在利用元数据著录工具对抽取出来的数据进行元数据著录。
数据仓库与元数据管理 1. 前言 在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。 本文首先介绍了元数据的定义、作用和意义；然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况；最后提出了建立元数据管理系统的步骤和实施方法。 2. 元数据 2.1 元数据的概念 按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。 技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息： ●数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义， 以及数据集市的位置和内容； ●业务系统、数据仓库和数据集市的体系结构和模式 ●汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、 预定义的查询与报告； ●由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数 据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。 业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统
元数据管理方案
元数据管理方案 1.1元数据抽取 为了简化元数据生成工作，系统提供自动生成元数据的功能，即元数据抽取。经过元数据自动抽取，用户能够方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象 元数据抽取主要针正确对象有以下几种： 已有目录：已建业务应用系统中现有的目录资源。 数据库：各种数据库资源，包括关系型数据库、XML数据库等。 格式化电子文件：电子文件，例如Word、PDF、XLS等文件。 1.1.2元数据抽取的流程 元数据抽取的流程有4个主要步骤，分别为： 数据源信息获取：解决要从哪个数据源获得元数据的问题。 内容/结构分析：解决要从数据源中获得哪些元数据的问题。 元数据提取：解决如何从数据源中获取元数据的问题。 存储入库：解决元数据存储的问题。
1.1.3电子文档的元数据抽取 对于电子文档，首先各部门的文档格式不尽相同，另外它们的安全级别也各不相同，同时由于信息化建设水平的不一致，有的部门文档分散在各处，有的部门文档是集中存放的，甚至已经建立了完善的电子系统进行管理。 针对以上状况，对于电子文档的元数据抽取需要进行以下的抽取流程： ●整理归档 对于分散在各处的电子文档(纸质文档需要先进行电子化处理)，必须由专人进行统一整理，根据公开共享的前提进行集中，这种集中能够是物理上集中的，也能够是逻辑上集中的。但要满足以下原则，第一根据安全级别，便于外界访问；第二便于文档的增量发布；第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下，进行自动化采集才是切实可行的。在整理归档的时候，各部门根据各自情况进行归档，没有必要千篇一律，也没有必要制定繁琐和呆板的规则，只要能够满足以上的原则即可。 ●根据安全级别，建立相应的访问机制 由于受到安全级别的限制，因此对于需要共享的数据要进行安全方面的限制，限制的手段能够有：用户名/密码、数字证书、物理隔断等等，根据实际情况建立安全访问机制，做到重要信息不泄露，不丢失。 ●编目处理
1.1.1 第一章元数据概论 企业的计算机系统每年会产生很多数据，很多企业面临着这样的困境，难以有效的管理大量的、繁杂的、不一致的数据，并方便地访问、利用这些数据进行辅助决策。 建立数据仓库提供一个方法，把数据转化为有用的、可信赖的信息，支持商业决策。建立数据仓库一个重要的工作是元数据管理。元数据（Metadata）就是数据的数据，用于建立、管理、维护和使用数据仓库。。元数据管理是企业级数据仓库中的关键组件，贯穿于建立数据仓库的整个过程。 元数据使得用户可以掌握数据的历史情况，如数据从哪里来？流通时间有多长？更新频率是多大？数据元素的含义是什么？对它已经进行了哪些计算、转换和筛选等等。在需求不确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。 通常把元数据分为技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库；业务元数据从商业和业务的角度描述数据仓库的数据，提供了良好的语义层定义，业务元数据使业务人员能够更好的理解数据仓库分析出来的数据。 元数据贯彻于建立数据仓库的整个过程，不只是ETL过程需要元数据的支持。 图1 元数据的应用 在使用元数据的同时，随着数据仓库市场的发展，业界出现许多数据仓库管理和分析的工具，各种工具使用不同的元数据标准来表示和处理，不同系统之间的迁移、数据交换变得困难。于是，我们希望用一种单一的元数据标准，使得各种组织的元数据具有单一的元模型（MetaModel），因此，需要建立一种标准使得不同的数据仓库和商业智能系统之间可以相互交换元数据。 1.1.2 第二章元数据标准 1.1. 2.1 一、元数据标准CWM OMG于2001年颁布元数据标准CWM 1.0（Common Warehouse Metamodel Version 1.0）。CWM定义一个描述数据源、数据目的、转换、分析的元数据框架，以及定义建立和管理数据仓库的过程和操作，提供使用信息的继承。 目前宣布支持CWM的厂商包括：IBM、Oracle、Hyperion、Dimension EDI、Genesis IONA、HP、NCR和Unisys等。 CWM基于3个工业标准： UML - Unified Modeling Language，OMG建模标准； MOF - Meta Object Facility，OMG建立元模型和模型库的标准，提供在异构环境下的数据交换的接口； XMI - XML Metadata Interchange，OMG元数据交换标准。 UML在CWM中得到充分的应用，担任3个不同的角色： 1），UML用来做为与MOF对应的meta-metamodel。UML相当于MOF Model,，UML Notation和OCL(Object Constraint Language)，被用来做为建模语言、图形符号、约束语言，
2018年系统元数据管理系统分析 1. 现状分析 随着经营分析系统规模不断扩大，系统所积累数据量也越来越大，收集到的海量数据背后隐藏着大量珍贵重要的信息，但也同时提高了系统的数据管理难度：一方面难以对这些数据进行有效解释，缺乏对业务流程执行的实时监控和管理；另一方面各部门数据与数据整合的难度也不断加大，影响到了经营分析系统中的数据质量。 如何对现有数据进行深层发掘，并揭示出埋藏在元数据中的趋势、因果关系、关联模式等核心信息？这是下一步深化经营分析系统应用的电信运营商需要解决的头等大事。构建BI，首先要保证的是数据质量。元数据管理解决的问题就是如何把业务系统中的数据分门别类地进行管理，并建立数据与数据之间的关系，为数据仓库的数据质量监控提供基础素材。 1.1 目前的困境 使用者(决策层、业务分析人员)： 1) 经营分析系统中存在有很多报表，不同报表中存在一些相同的指标，这些指标往往不一致，给业务分析和决策工作造成很多困惑，必须花费很大的精力去检查核实。 2) 对于很多指标，不清楚其具体含义，不清楚其反映的问题，不清楚其具体算法和来龙去脉。
数据仓库项目开发维护者： 1) 不同报表中的同一指标不一致，必须花费很大的精力去检查，目前基本上是通过手工检查表和存储过程的方式，效率较低。 2) 没有完善的开发、维护规范。比如，新增一张分析报表，开发人员根据业务人员的需求制作完成之后，往往没有整理完善相应的数据指标解释和元数据管理，造成日后检查困难。 3) 开发、维护规范的执行力较低，没有行之有效的管控手段。不严格按照规范执行，随着项目的发展和时间的推移，导致数据仓库项目的健壮性和可维护性呈几何级数下降，给数据仓库的建设带来大量的重复工作。 1.2 什么是元数据管理 元数据最本质，最抽象的定义为：data about data (关于数据的数据)。而对于经营分析数据仓库而言，形象的定义为：元数据就是数据仓库的规范。这些规范包括对各种指标的定义、解释；包括对各表中数据的来龙去脉、数据的大小和格式的定义。 元数据管理，就是要建立一套行之有效的规范以及该规范的管控体系，实现从管理到查询到综合分析的全面管控，管理层次从接口到ETL处理、业务逻辑处理、结果展现处理和指标分析的方方面面，构成数据仓库应用系统的核心和基础。做到开发者能严格遵守规范，维护者和使用者有规范可查，有力的保障数据仓库项目的健壮性和可维护性。
xx移动 元数据管理项目工程实施方案 2012年5月
目录 1建设目标 ------------------------------------------------------------------------------------------------------ 3 2系统环境配置------------------------------------------------------------------------------------------------ 3 2.1客户端环境配置------------------------------------------------------------------------------------- 3 2.2服务器端环境配置---------------------------------------------------------------------------------- 4 2.3网络配置 ---------------------------------------------------------------------------------------------- 4 3元数据管理范围--------------------------------------------------------------------------------------------- 5 4项目实施计划------------------------------------------------------------------------------------------------ 6 4.1建设规划 ---------------------------------------------------------------------------------------------- 6 4.2时间安排 ---------------------------------------------------------------------------------------------- 7 4.3产品部署 ---------------------------------------------------------------------------------------------- 7 4.4元模型定制 ------------------------------------------------------------------------------------------- 7 4.5元数据存储 ------------------------------------------------------------------------------------------- 8 4.5.1技术类元数据存储-------------------------------------------------------------------------- 8 4.5.1.1关系型数据库元数据 ------------------------------------------------------------ 8 4.5.1.2OLAP元数据 ------------------------------------------------------------------------ 8 4.5.1.3ETL元数据-------------------------------------------------------------------------- 9 4.5.1.4模型元数据 ------------------------------------------------------------------------ 10 4.5.2业务元数据存储 ---------------------------------------------------------------------------- 10 4.5.2.1业务指标元数据------------------------------------------------------------------ 10 4.5.2.2业务规则&术语元数据---------------------------------------------------------- 11 4.5.2.3维度&基础编码元数据---------------------------------------------------------- 11 4.5.3管理类元数据存储------------------------------------------------------------------------- 11 4.6建立日常管理流程--------------------------------------------------------------------------------- 12 4.6.1元数据权限管理 ---------------------------------------------------------------------------- 12 4.6.2通过元数据变更流程进行维护管理 --------------------------------------------------- 12 4.6.3元数据同步维护 ---------------------------------------------------------------------------- 12 4.6.3.1业务元数据同步维护 ----------------------------------------------------------- 12 4.6.3.2管理元数据同步维护 ----------------------------------------------------------- 13 4.6.3.3元数据同步维护------------------------------------------------------------------ 14 4.6.3.4库表结构元数据同步维护 ----------------------------------------------------- 14 4.6.3.5Erwin元数据同步维护 --------------------------------------------------------- 15 4.7元数据交付、培训--------------------------------------------------------------------------------- 15 4.8元数据管理应用定制------------------------------------------------------------------------------ 15 5元数据建设中需要的配合工作------------------------------------------------------------------------- 16 6备份策略 ----------------------------------------------------------------------------------------------------- 16