当前位置:文档之家› 元数据管理

元数据管理

元数据管理
元数据管理

1.前言

数据仓库中的数据是从许多业务处理系统中抽取、转换而来,对于这样一个复杂的企业数据环境,如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息,其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等,而且整个数据仓库系统的运行都是基于元数据的,是元数据把数据仓库系统中的各个松散的组件联系起来,组成了一个有机的整体。2.元数据

2.1 元数据的概念

按照传统的定义,元数据(Metadata)是关于数据的数据。在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical Metadata)和业务元数据(Business Metadata)。

技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据。

业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法以及公式和报表的信息。

2.2 元数据的作用

在数据仓库系统中,元数据机制主要支持以下五类系统管理功能:(1)描述哪些数据在数据仓库中;(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据;(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排;(4)记录并检测系统数据一致性的要求和执行情况;(5)衡量数据质量。

与其说数据仓库是软件开发项目,还不如说是系统集成项目[1],因为它的主要工作是把所需的数据仓库工具集成在一起,完成数据的抽取、转换和加载,OLAP分析和数据挖掘等。

3.数据仓库元数据管理现状

元数据管理的主要任务有两个方面:一是负责存储和维护元数据库中的元数据;二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递,协调各模

块和工具之间的工作。

元数据几乎可以被称为是数据仓库乃至商业智能(BI)系统的“灵魂”,正是由于元数据在整个数据仓库生命周期中有着重要的地位,各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理,各个解决方案都没有明确提出一个完整的管理模式;它们提供的仅仅是对特定的局部元数据的管理。与元数据相关的数据仓库工具大致可分为四类:

1. 数据抽取工具:把业务系统中的数据抽取、转换、集成到数据仓库中,如Ardent的DataStage、CA(原Platinum)的Decision Base和ETI的Extract等。这些工具仅提供了技术元数据,几乎没有提供对业务元数据的支持。

2. 前端展现工具:包括OLAP分析、报表和商业智能工具等,如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO,以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图,进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。

3. 建模工具:为非技术人员准备的业务建模工具,这些工具可以提供更高层的与特定业务相关的语义。如

CA的ERwin、Sysbase的PowerDesigner以及Rational 的Rose等。

4. 元数据存储工具:元数据通常存储在专用的数据库中,该数据库就如同一个“黑盒子”,外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库(Metadata Repository)的工具,它们独立于其它工具,为元数据提供一个集中的存储空间。包括微软的Repository,CA的Repository,Ardent 的MetaStage和Sybase的WCC等。

4.元数据管理的标准化

没有规矩不成方圆。元数据管理之所以困难,一个很重要的原因就是缺乏统一的标准。在这种情况下,各公司的元数据管理解决方案各不相同。近几年,随着元数据联盟MDC(Meta Data Coalition)的开放信息模型OIM (Open Information Model)和OMG组织的公共仓库模型CWM(Common Warehouse Model)标准的逐渐完善,以及MDC和OMG组织的合并,为数据仓库厂商提供了统一的标准,从而为元数据管理铺平了道路。

从元数据的发展历史不难看出,元数据管理主要有两种方法:

(1) 对于相对简单的环境,按照通用的元数据管理标准建立一个集中式的元数据知识库。

(2) 对于比较复杂的环境,分别建立各部分的元数据管理系统,形成分布式元数据知识库,然后,通过建立标准的元数据交换格式,实现元数据的集成管理。

下面我们分别介绍数据仓库领域中两个最主要的元数据标准:MDC的OIM标准和OMG的CWM标准。4.1 MDC的OIM存储模型

MDC成立于1995年,是一个致力于建立与厂商无关的、不依赖于具体技术的企业元数据管理标准的非赢利技术联盟,该联盟有150多个会员,其中包括微软和IBM 等著名软件厂商。1999年7月MDC接受了微软的建议,将OIM作为元数据标准。

OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用。它涉及了信息系统(从设计到发布)的各个阶段,通过对元数据类型的标准描述来达到工具和知识库之间的数据共享。OIM所声明的元数据类型都采用统一建模语言UML(Universal Modeling Language)进行描述,并被组织成易于使用、易于扩展的多个主题范围(Subject Areas)。这些主题范围中的包都是采用UML定义的,可以说UML语言是整个OIM标准的基础。虽然OIM标准并不是专门针对数据仓库的,但数据仓库是它的主要应用领域之一。目前市场上基于该标准的元数据管理工具已经比较成

熟,例如微软的Repositry和CA的Repositry均采用了OIM标准。

4.2 OMG组织的CWM模型

OMG是一个拥有500多会员的国际标准化组织,著名的CORBA标准即出自该组织。公共仓库元模型(Common Warehouse Metamodel)的主要目的是在异构环境下,帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月,OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储,也包括元数据交换,它是基于以下三个工业标准制定的:

(1) UML:它对CWM模型进行建模。

(2) MOF(元对象设施):它是OMG元模型和元数据的存储标准,提供在异构环境下对元数据知识库的访问接口。

(3) XMI(XML元数据交换):它可以使元数据以XML 文件流的方式进行交换。

CWM为数据仓库和商业智能(BI)工具之间共享元数据,制定了一整套关于语法和语义的规范。它主要包含以下四个方面的规范:

(1) CWM元模型(Metamodel):描述数据仓库系统的模型;

(2) CWM XML:CWM元模型的XML表示;

(3) CWM DTD:DW/BI共享元数据的交换格式

(4) CWM IDL:DW/BI共享元数据的应用程序访问接口(API)

CWM元模型的组成与OIM规范一样,也是由很多包组成的。

在数据抽取过程中,数据从各个业务系统中被统一转换存储到中央数据仓库中。CWM中的转换模型定义了数据在源和目的之间移动的过程,其中不仅包括源和目标之间的参数,还包括转换中的业务逻辑。这些业务逻辑可能包括一些商业规则、类库甚至是用户脚本。数据仓库如果有一个规范的转换模型将给工具软件厂商和专业服务提供商带来极大的好处,例如,按照统一的规范厂商可以设计一个通用的模型从标准ERP包中抽取数据。工具厂商甚至可以随软件提供成熟的模型,集成商也可以将一个模型应用到多个项目中。

最终用户同样也能从CWM中受益,在使用商业智能分析软件进行多维分析的时候,用户往往会对数据的含义和来源产生疑问。CWM能够提供这些信息,用户可以清楚地看到数据来自哪个系统,并且是如何组成的。

4.3 CWM与OIM之间的关系

上两节分别介绍了与数据仓库相关的两个主要标准,CWM实际上是专门为数据仓库元数据而制定的一套标

准,而OIM并不是针对数据仓库元数据的。OIM所关注的元数据的范围比CWM要广,CWM只限定于数据仓库领域,而OIM模型包括有:分析与设计模型、对象与组件、数据库与数据仓库、商业工程、知识管理等五个领域。OIM与CWM在建模语言的选择(都选择UML当做自己的描述语言)、数据库模型的支持、OLAP 分析模型的支持、数据转换模型的支持方面都比较一致;但是OIM并不是基于元对象设施(MOF)的,这意味着用OIM所描述的元数据需要通过其它的接口才能访问,而CWM所描述的元数据可以通过CORBA IDL来访问;在数据交换方面,OIM必须通过特定的转换形成XML文件来交换元数据,而CWM可以用XMI 来进行交换。尽管如此,由于OMG与MDC两个组织的合并,CWM也会与OIM相互兼容以保护厂商已有的投资。

需要说明的是,MDC与OMG组织已经合并,今后所有的工具都将遵循统一的CWM标准,不过支持CWM 的工具才刚刚出现,而支持OIM标准的工具已经相对成熟。

5. 元数据管理系统的设计与实现

5.1 设计原则

数据仓库环境下的元数据管理系统的建设是十分困难

的。但是在实际项目的实施过程中,这个环节又是非常重要的。当前情况下,OMG组织的CWM标准将会成为数据仓库元数据领域事实上的标准,在元数据管理系统的建立过程中应尽量参考这个标准,这样使系统的可扩展性增强。可是在与之相关的工具成熟之前,我们完全可以采用OIM中的元模型(因CWM对OIM是兼容的)以及支持它的元数据管理工具进行元数据管理系统的建设,而且元数据所包含的范围很广。我们在建立元数据管理系统的时候,绝对不能盲目追求大而全,要坚持目标驱动的原则,在实施的时候要采取增量式、渐进式的建设原则。具体的建设步骤如下:

(1)如果是在建设数据仓库系统的初期,那么首先要确定系统的边界范围,系统范围确定的原则是首先保障重点,不求大,只求精。

(2)系统边界确定以后,把现有系统的元数据整理出来,加入语义层的对应。然后存到一个数据库中,这个数据库可以采用专用的元数据知识库,也可以采用一般的关系型数据库。

(3)确定元数据管理的范围。比如,我们只想通过元数据来管理数据仓库中数据的转换过程,以及有关数据的抽取路线,以使数据仓库开发和使用人员明白仓库中数据的整个历史过程。

(4)确定元数据管理的工具,采用一定的工具可以完成相应的工作。当前相关工具有微软的Repositry,它带有相应的编程接口,可以借助于它来完成元模型出入库的功能;与之相似的还有Platinum的OEE;另外还有Sybase的Wcc,它可以通过MDC以前的一个老标准――MDIS来集成抽取工具与转换工具,在一个窗口中就可以表示数据抽取与转换,并且可以把语义层以MDIS的格式导出到一个前端工具当中(比如Cognos 的Improptu)。

5.2 元数据存储模式

元数据存在的状况是有差异的,系统层元数据应随数据库存在,且由建立在分布式网络数据库管理系统统一管理;数据集层次元数据可以随数据库存在也可随数据集存在;数据特征层次的元数据只能随数据集存在。

简单地,元数据存贮有两种形式:其一是以数据集为基础,即每一个数据集有一个对应的元数据文档,每一个元数据文件中包含对相应数据集的元数据内容。另一种存在方式是以数据库为基础(即元数据库),给一个数据库有一个元数据文件,该文件为一表格数据,它由若干项组成,每一项表示元数据的一个要素,其记录为每一个数据集的元数据内容。、

两种存贮方式各有优缺点,对于第一种存储模式,其好

处是调用数据时其相应的元数据也作为一个独立的文件被传输,相对数据库有较强的独立性,在对元数据进行检索时可以利用数据库的功能实现,也可以将元数据文件调到其它数据库系统中进行操作;其问题是:每一数据集都有一个元数据文档,那么在规模巨大的数据库中则会有大量的元数据文件,管理上极为不便。在第二中存在模式中,由于库中只有一个元数据文件,管理极为方便,添加或删除数据集只把该文件中添加或删除相应的记录项即可;但如果想获取某数据集的元数据时,实际得到的只是关系表格数据的一个记录,则要求数据用户使用的系统中可以接受这种特定形式的数据。因此推荐使用元数据库的方式。

元数据库是用于存储元数据的地方,元数据库最好选用主流的关系数据库管理系统,支持CWM标准。一个元数据库还包含那些用于操作和查询元数据的机制;建立元数据库的主要好处是提供了统一的关键数据结构和业务规则,易于将企业内部的多个数据集市有机的结合起来;特别是,现在一些客户倾向建立多个数据集市,而不是一个庞大无比的数据仓库。可以考虑在建立数据仓库(或数据集市)之前,先建立一个用于描述数据的、用于应用集成的元数据库,做好数据仓库实施的初期支持工作,对后续开发和维护有很大的帮助。

在拥有不同厂商、不同功能和不同元数据库的环境下,要实现两种产品之间的元数据同步是非常富有挑战性的工作。因为必须从一种产品中获得足够详细的元数据,将其映射到另一种产品中,再指出两者意义或编码的差别;通常系统有数百、数千个元数据,必须对每个元数据重复这一过程。

在整个数据仓库环境中,元数据管理工具可以从各个数据仓库组件中收集元数据,存储到元数据库中,然后向业务用户传递和展示正确的信息。采集、集成和描述元数据可以扩展到十分广泛的范围,可以在设计和建模的过程中,可以在数据转换、清洗和过滤的过程中,也可以在数据移植的过程中;可以从数据库/数据存储软件,和前端展示工具中得到元数据。

元数据库为整个企业的宝贵信息提供了详细的记录,保存数据存储位置和商业含义、生成和维护数据的主体、数据驱动的应用处理、与其它数据的关系以及数据的转换过程等。元数据库保证了数据仓库数据的一致性和准确性,为企业进行数据质量管理提供数据依据。

另外,元数据库还支持强大的查询和报表生成工具,用户使用报表工具可以查询元数据库,从元数据库获得重要的决策支持信息。

5.3 元数据管理模式

元数据管理涉及到各个层次的元数据,管理的内容包括元数据的获取、元数据的更新、使用和面向应用项目的元数据使用处理等多个方面。元数据的管理涉及数据库、数据处理软件、数据使用系统、面向应用的数据分析等各个环节。

通常意义上的元数据管理是指元数据通过各种途径形成后,对其内容的添加、删除、更新等涉及内容改变的操作和元数据内容检索、查询、放置、组织等常规性元数据操作,从这种意义上元数据的管理可以通过两种方式实现,即系统管理模式和用户管理模式。系统管理模式是面向数据库的,由数据库管理系统专业人员完成,数据用户只有使用权,没有元数据的操作权,数据应用项目中新生成的数据集的元数据也有应用系统传递给数据库管理员,然后由数据库管理员统一管理。这种方式中,数据在处理过程中形成的动态元数据很难及时记录下来。另一种管理方式是用户管理模式,它是面向应用项目的,即允许某些数据用户在数据应用元数据的变动信息直接反馈给元数据库,这样则能保证元数据的动态更新和新生成数据集元数据的及时捕获及写入元数据文件。但这种模式中数据用户的权限要适当的控制,以避免数据库的破坏。通常对元数据的管理是采用两者结合的模式。

总之,建立元数据管理系统一定要坚持关注标准,又不被标准所束缚的原则,建立符合自身目标的元数据管理系统。

常用项目管理工具

常用项目管理工具—本人看到的文章,共享 ---来源:不详。 随着IT行业的发展,IT行业内的项目拓展和投资比比皆是。为了提高项目管理水平,赢得市场竞争,特别是在加入WTO后在国内、国际市场上拥有与国际接轨的项目管理人才,越来越多的业界人士正通过不同的方式参加项目管理培训并力争获得世界上最权威的职业项目经理(PMP)资格认证。同时,大部分的IT行业项目管理人士正尝试使用项目管理软件对自己的项目进行辅助管理,为了方便大家的使用,现对项目管理作一简要介绍。 目前市场上项目管理软件种类较多,具有代表性的为微软项目管理软件2000,但大多以美国项目管理协会(PMI)的项目管理理论为基础,在使用过程中要注意以下内容: 一、项目管理软件特征 1.预算及成本控制 大部分项目管理软件系统都可以用来获得项目中各项活动、资源的有关情况。人员的工资可以按小时、加班或一次性来计算,也可以具体明确到期支付日;对于原材料,可以确定一次性或持续成本;对各种材料,可以设立相应的会计和预算代码。另外,还可以利用用户自定义公式来运行成本函数。大部分软件程序都应用这一信息来帮助计算项目成本,在项目过程中跟踪费用。项目过程中,随时可以就单个资源、团队资源或整个项目的实际成本与预算成本进行对比分析,在计划和汇报工作中都要用到这一信息。大多数软件程序可以随时显示并打印出每项任务、每种资源(人员、机器等)或整个项目的费用情况。 2.日程表 日程表程序主要用来对项目中各个单项资源或一组资源确定工作时间。可以用这些日程表计算出项目的进度计划。大部分系统软件都对基本工作时间设置一个默认值,比如星期一到星期五,早上8点到下午5点,中间有一小时的午餐时间。对于各个单项资源或一组资源,可以修改此日程表。例如:修改上、下班时间,按非工作时间输入公司假期,输入各种换班(白天、夜晚),包括节假日以及数量单位(小时、天、周)。汇报工作进程时要用到这些日程表,它通常可以根据每个单项资源按天、周或月打印出来,或者将整个项目的日程打印成一份全面的,可能有墙壁大的项目日程表。 3.电子邮件 一些项目管理软件程序的共同特征是可以通过电子邮件发送项目信息。这一功能使得用户不必通过打印机或屏幕显示,直接从电子邮件中获得信息。通过电子邮件,项目团队成员可以了解重大变化,比如最新的项目计划或进度计划,可以掌握当前的项目工作情况,也可以发出各种业务表格。 4.图形 对于有大量活动事项的项目工程,人工制出一份甘特图或网络图,或人工进行修改制图是一件极其乏味而又容易出错的工作。当前项目管理软件的一个最突出的特点是能在最新数据资料的基础上简便、迅速地制作各种图表,包括甘特图及网络图。有了基准计划后,任何修改就可以轻易地输入到系统中,图表自动会反映出这些改变。项目管理软件可以将甘特图中的任务连接起来,显示出工作流程。特别是用户可以仅用一个命令就在甘特图和网络图之间来回转换显示。另外,图形和表格通常有以下功能供用户使用: . 进行任务和关系的交互式操作处理。例如,通过图表连接任务,改变优先关系或通过扩展活动持续显示功能来改变活动持续时间。

石竹元数据管理软件 MetaOne Catalog_1.5

MetaOne产品简介

MetaOne 功能简介 MetaOne 基本功能 元模型/元数据管理 元数据关系维护 自动获取/批量导入 元数据版本管理 基本分析功能 元数据全文检索 系统管理 MetaOne 高级功能 元数据发布流程管理 高级分析功能 元数据分析 基本分析:血统分析、影响分析、映射分析等 高级分析:差异分析、表重要程度分析、表无关程度分析等 血统分析 元数据是企业数据资源管理、使用的基础。MetaOne 作为企业实施元数据管理的软件支撑平台,其先进的理念、成熟的技术让业界耳目一新。 元模型/元数据管理 元模型支持CWM 规范,可完全扩展;元数据展现树型化,体系结构清晰直观;支持常规数据类型,及针对企业应用的特殊类型,如大文本、枚举、公式编辑器、URL 等。 自动获取/批量导入元数据 自动获取:PowerCenter 、DataStage 、Oracle 、DB2、DB2 OLAP SERVER 、 Essbase 、TeraData 等 批量导入:Excel 格式、XMI 格式、Erwin 、PowerDesigner 等 元数据全文检索 多种组合条件的模糊查询,可在整个元数据环境随时检索所需信息 系统管理 基于角色的用户权限管理;用户可定制系统参数; 元数据发布流程管理 提供元数据发布流程管理,规范企业元数据的管理流程。可以让企业更好地管理和跟踪元数据的整个生命周期, 在元数据的流程管理中, 可以安全地创建、获取、扩展的元数据信息。 元数据关系维护 图形化的元数据关系维护,拖拉鼠标轻松实现,效果直观易于维护; 图形化维护ETL 程序内部的字段级映射关系,清晰追溯数据来源及加工过程。 元数据版本管理 元数据版本变更记录、版本变更查询、版本浏览、版本恢复

元数据管理平台

元数据管理平台 技术白皮书 北京亿信华辰软件责任有限公司 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)

元数据管理解决方案-2018.3.27

元数据解决方案 随着报价系统每年收集和使用的数据飞速增长,数据体量日趋增长,数据形态多样化且不统一,多种数据源之间的采集、传播和共享遇到困难。元数据管理作为大数据治理的核心,是有效管理这些数据的基础和前提,在信息化建设中发挥着重要的作用。如何理解、管理并发挥出元数据的价值,成为迫切的任务。 一、什么是元数据 元数据(Metadata)是关于数据的数据。元数据是描述数据仓库内数据的结构和建立方法的数据。可将其按用途的不同分为两类:技术元数据(Technical Metadata)和业务元数据(Business Metadata)。 1. 技术元数据 技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据,它主要包括以下信息: 1) 数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据 的定义,以及数据集市的位置和内容。 2) 业务系统、数据仓库和数据集市的体系结构和模式。 3) 汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚集、 汇总、预定义的查询与报告。 4) 由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分 割、数据提取、清理、转换规则和数据刷新规则、安全(用户授权和存 取控制)。 2. 业务元数据 业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息:

1) 使用者的业务术语所表达的数据模型、对象名和属性名。 2) 访问数据的原则和数据的来源。 3) 系统所提供的分析方法以及公式和报表的信息。 4) 企业概念模型、多维数据模型,业务概念模型与物理数据的依赖, 二、元数据的作用 元数据可以实现业务模型与数据模型的映射,帮助用户理解数据仓库中的数据;元数据清晰的描述了数据的来龙去脉,描述了数据抽取转换规则,是保证数据质量的关键;元数据管理系统可以把整个业务的工作流、数据流和信息流有效的管理,可以支持需求变化,从而提高系统的可扩展性;打通数据孤岛,统一数据定义,形成企业级知识传承平台,元数据管理使得数据变的更有价值。三、元数据管理 在大数据时代的背景下,数据即资产,元数据实现了信息的描述和分类的格式化,从而为机器处理创造了可能,它能帮助企业更好地对数据资产进行管理,理清数据之间的关系。元数据管理是企业提升数据质量的基础,也是企业数据治理中的关键环节。元数据管理不当,信息很容易被丢失,进而不能对业务进行有效支撑,企业内部业务人员要识别相关信息就会变得十分困难,最终用户也将失去对数据的信任。 1. 元数据采集 技术元数据的采集,根据现有元数据设计出元模型,然后将数据仓库系统之中的元数据按元模型集中汇总并关联到一起,达到企业对数据统一管理与应用的目的,ETL等产生的元数据,对于元数据管理工具支持的格式可直接进行导入,对于一些自定义的规则,需要进行格式转换并导入。

元数据管理平台的建立

元数据管理平台的建立 1.1 元数据简介 元数据被定义为:描述数据的数据,对数据及信息资源的描述性信息。 元数据(Metadata)是描述其它数据的数据(data about other data),或者说是用于提供某种资源的有关信息的结构数据(structured data)。元数据是描述信息资源或数据等对象的数据,其使用目的在于:识别资源;评价资源;追踪资源在使用过程中的变化;实现简单高效地管理大量网络化数据;实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。 元数据的基本特点主要有: 1、元数据一经建立,便可共享。元数据的结构和完整性依赖于信息资源的价值和使用环境;元数据的开发与利用环境往往是一个变化的分布式环境;任何一种格式都不可能完全满足不同团体的不同需要; 2、元数据首先是一种编码体系。元数据是用来描述数字化信息资源,特别是网络信息资源的编码体系,这导致了元数据和传统数据编码体系的根本区别;元数据的最为重要的特征和功能是为数字化信息资源建立一种机器可理解框架。 元数据体系构建了企业业务的逻辑框架和基本模型,从而决定了企业业务的功能特征、运行模式和系统运行的总体性能。企业业务的运作都基于元数据来实现。其主要作用有:描述功能、整合功能、控制功能和代理功能。 由于元数据也是数据,因此可以用类似数据的方法在数据库中进行存储和获取。如果提供数据元的组织同时提供描述数据元的元数据,将会使数据元的使用变得准确而高效。用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。

在数据仓库领域中,元数据按用途分成技术元数据和业务元数据。首先,元数据能提供基于用户的信息,如记录数据项的业务描述信息的元数据能帮助用户使用数据。其次,元数据能支持系统对数据的管理和维护,如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。具体来说,在数据仓库系统中,元数据机制主要支持以下五类系统管理功能: (1)描述哪些数据在数据仓库中; (2)定义要进入数据仓库中的数据和从数据仓库中产生的数据; (3)记录根据业务事件发生而随之进行的数据抽取工作时间安排; (4)记录并检测系统数据一致性的要求和执行情况; (5)衡量数据质量。 1.2 元数据管理平台体系结构 图1 元数据管理平台体系结构 关键特性

元数据管理

1.前言 数据仓库中的数据是从许多业务处理系统中抽取、转换而来,对于这样一个复杂的企业数据环境,如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。元数据是关于数据、操纵数据的进程和应用程序的结构和意义的描述信息,其主要目标是提供数据资源的全面指南。元数据不仅定义了数据仓库中数据的模式、来源以及抽取和转换规则等,而且整个数据仓库系统的运行都是基于元数据的,是元数据把数据仓库系统中的各个松散的组件联系起来,组成了一个有机的整体。2.元数据 2.1 元数据的概念 按照传统的定义,元数据(Metadata)是关于数据的数据。在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical Metadata)和业务元数据(Business Metadata)。 技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据。

业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统之间的语义层,使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息:使用者的业务术语所表达的数据模型、对象名和属性名;访问数据的原则和数据的来源;系统所提供的分析方法以及公式和报表的信息。 2.2 元数据的作用 在数据仓库系统中,元数据机制主要支持以下五类系统管理功能:(1)描述哪些数据在数据仓库中;(2)定义要进入数据仓库中的数据和从数据仓库中产生的数据;(3)记录根据业务事件发生而随之进行的数据抽取工作时间安排;(4)记录并检测系统数据一致性的要求和执行情况;(5)衡量数据质量。 与其说数据仓库是软件开发项目,还不如说是系统集成项目[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电子文档的元数据抽取 对于电子文档,首先各部门的文档格式不尽相同,另外它们的安全级别也各不相同,同时由于信息化建设水平的不一致,有的部门文档分散在各处,有的部门文档是集中存放的,甚至已经建立了完善的电子系统进行管理。 针对以上状况,对于电子文档的元数据抽取需要进行以下的抽取流程: ●整理归档 对于分散在各处的电子文档(纸质文档需要先进行电子化处理),必须由专人进行统一整理,根据公开共享的前提进行集中,这种集中能够是物理上集中的,也能够是逻辑上集中的。但要满足以下原则,第一根据安全级别,便于外界访问;第二便于文档的增量发布;第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下,进行自动化采集才是切实可行的。在整理归档的时候,各部门根据各自情况进行归档,没有必要千篇一律,也没有必要制定繁琐和呆板的规则,只要能够满足以上的原则即可。 ●根据安全级别,建立相应的访问机制 由于受到安全级别的限制,因此对于需要共享的数据要进行安全方面的限制,限制的手段能够有:用户名/密码、数字证书、物理隔断等等,根据实际情况建立安全访问机制,做到重要信息不泄露,不丢失。 ●编目处理

数据仓库元数据管理

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),被用来做为建模语言、图形符号、约束语言,

元数据管理方案

元数据管理方案 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工具从源数据库中将所需数据抽取至中心数据库基础业务库中,在利用元数据著录工具对抽取出来的数据进行元数据著录。

2018年系统元数据管理系统分析

2018年系统元数据管理系统分析 1. 现状分析 随着经营分析系统规模不断扩大,系统所积累数据量也越来越大,收集到的海量数据背后隐藏着大量珍贵重要的信息,但也同时提高了系统的数据管理难度:一方面难以对这些数据进行有效解释,缺乏对业务流程执行的实时监控和管理;另一方面各部门数据与数据整合的难度也不断加大,影响到了经营分析系统中的数据质量。 如何对现有数据进行深层发掘,并揭示出埋藏在元数据中的趋势、因果关系、关联模式等核心信息?这是下一步深化经营分析系统应用的电信运营商需要解决的头等大事。构建BI,首先要保证的是数据质量。元数据管理解决的问题就是如何把业务系统中的数据分门别类地进行管理,并建立数据与数据之间的关系,为数据仓库的数据质量监控提供基础素材。 1.1 目前的困境 使用者(决策层、业务分析人员): 1) 经营分析系统中存在有很多报表,不同报表中存在一些相同的指标,这些指标往往不一致,给业务分析和决策工作造成很多困惑,必须花费很大的精力去检查核实。 2) 对于很多指标,不清楚其具体含义,不清楚其反映的问题,不清楚其具体算法和来龙去脉。

数据仓库项目开发维护者: 1) 不同报表中的同一指标不一致,必须花费很大的精力去检查,目前基本上是通过手工检查表和存储过程的方式,效率较低。 2) 没有完善的开发、维护规范。比如,新增一张分析报表,开发人员根据业务人员的需求制作完成之后,往往没有整理完善相应的数据指标解释和元数据管理,造成日后检查困难。 3) 开发、维护规范的执行力较低,没有行之有效的管控手段。不严格按照规范执行,随着项目的发展和时间的推移,导致数据仓库项目的健壮性和可维护性呈几何级数下降,给数据仓库的建设带来大量的重复工作。 1.2 什么是元数据管理 元数据最本质,最抽象的定义为:data about data (关于数据的数据)。而对于经营分析数据仓库而言,形象的定义为:元数据就是数据仓库的规范。这些规范包括对各种指标的定义、解释;包括对各表中数据的来龙去脉、数据的大小和格式的定义。 元数据管理,就是要建立一套行之有效的规范以及该规范的管控体系,实现从管理到查询到综合分析的全面管控,管理层次从接口到ETL处理、业务逻辑处理、结果展现处理和指标分析的方方面面,构成数据仓库应用系统的核心和基础。做到开发者能严格遵守规范,维护者和使用者有规范可查,有力的保障数据仓库项目的健壮性和可维护性。

数据仓库中元数据的管理

数据仓库中元数据的管理M etadata M anagem en t i n a Data W arehouse 同济大学计算机科学与工程系(上海200092) 史金红 吴永明 【摘要】 介绍了数据仓库中四种基本类型的元数据,说明了不同类型元数据的收集和维护方法,并着重对分布式元数据的集成和管理进行了详细的阐述。 关键词:数据仓库,数据商场,决策支持,元数据 【Abstract】 T h is p ap er in troduces fou r typ es of m etadata and the m ethods of co llecting and m ain tain ing them.It focu ses on the m etadata m anagem en t and in tegrity. Key words: da ta warehouse,da ta mart, dec ision support,m etada ta 1 引言 随着社会的发展和计算机技术的进步,人们已不满足于用计算机只作简单的数据处理和事务处理。进一步用现有的数据进行分析和推理,从而为决策提供依据的需求导致了决策支持系统(D SS)的出现。90年代以来计算机技术、网络技术和数据库技术的迅速发展为D SS提供了必要的技术环境, OL T P和办公自动化普遍应用积累的大量数据为D SS提供了必要的数据基础,日趋激烈的市场竞争促进了各级管理和决策人员对D SS的实际需求,因此自从1991年W.H.Inm on提出数据仓库的概念和1993年E.F.Codd提出OLA P概念以来,已有许多商品化的数据仓库管理系统和联机分析处理工具软件面市。以上诸因素的共同作用促成许多公司、机构纷纷为提高自己的竞争能力建立数据仓库系统以进行决策支持。 元数据是成功的数据仓库的重要组成部分,它可以帮助数据仓库项目小组明确而全面地理解潜在数据源的物理布局以及所有数据元的业务定义,帮助数据仓库用户有效地使用仓库中的信息,帮助数据库管理员了解某些表的变化将对数据仓库产生怎样的影响以及不同商业过程对应的应用等等。项目小组在开发过程中应当识别元数据并将它收入到元数据商店中,实施适当的过程捕作企业数据结构和应用的变化,从而修改相应的元数据,并向用户提供适当的工具访问元数据。 2 元数据的基本类型 元数据按照其用户可以分为技术元数据和商业元数据。技术元数据提供给数据仓库的技术人员,数据仓库技术人员在仓库的开发和维护中使用这类元数据。商业元数据是商业用户在仓库中寻找他们所需商业信息的一个辅助。但是,技术人员可能也需要访问几种类型的商业元数据,如和商业用户讨论信息需求和建立企业的数据模型。同样,商业用户也需要尝试高水平的技术元数据。 元数据按其内容可以分为四个基本类型: 1)关于数据仓库潜在数据来源的信息,包括现有的业务系统、可得到的外部数据和目前手工维护的信息。例如,一个组织可以从中识别数据来源的潜在仓库数据源有:几个现有的应用程序,由财务部门保存的基于PC机的电子报表,从某一卖主处购买的销售数据,目前由顾客服务部门在纸上保存的顾客联系记录。 2)关于数据模型的信息,包括业务实体、关系、企业规则和企业数据模型。 3)关于业务数据与仓库数据结构间的映射信息。只要那些来源中的一个数据元与仓库建立了映射关系,就应该记录下这些数据元间的逻辑联系以及发生的任何变换或变动。 4)关于数据仓库中信息的使用情况。了解这类信息对更好地调整仓库性能、更多地利用现有查询以及理解仓库中的信息怎样用于解决企业问题是很重要的。 3 元数据的收集和维护 在适当的时间收集适当的元数据是成功实施元数据驱动的数据仓库的基础。为保证较高的准确

元数据管理模块方案1.doc

元数据管理模块方案1 目录 1. 现状分析(2) 1.1 目前的困境(2) 1.2 什么是元数据管理(3) 2. 目标分析(3) 2.1 建立完善的指标解释体系(3) 2.2 建立规范的元数据管理体系(4) 2.3 建立有效的数据稽核体系(4) 3. 功能概述(4) 3.1 元数据管理(4) 3.1.1 业务元数据(5) 3.2.2 技术元数据(6) 3.3元数据分析(9) 3.3.1 血统分析(9) 3.3.2 影响分析(10) 3.3.3 重要性分析(11)

3.3.4 无关性分析(12) 3.4数据稽核(12) 3.4.1 稽核规则管理(13) 3.4.2 稽核任务调度(13) 3.4.3 稽核结果分析(14) 3.4.4 数据质量评估(14) 3.4.5 数据问题管理(14) 元数据管理系统概述 1.项目背景 随着经营分析系统规模不断扩大,系统所积累数据量也越来越大,收集到的海量数据背后隐藏着大量珍贵重要的信息,但也同时提高了系统的数据管理难度:一方面难以对这些数据进行有效解释,缺乏对业务流程执行的实时监控和管理;另一方面各部门数据与数据整合的难度也不断加大,影响到了经营分析系统中的数据质量。 如何对现有数据进行深层发掘,并揭示出埋藏在元数据中的趋势、因果关系、关联模式等核心信息?这是下一步深化经营分析系统应用的电信运营商需要解决的头等大事。构建BI,首先要保证的是数据质量。元数据管理解决的问题就是如何把业务系统中的数据分门别类地进行管理,并建立数据与数据之间的关系,为数据仓库的数据质量监控提供基础素材。

1.1 需求分析 使用者(决策层、业务分析人员): 1) 经营分析系统中存在有很多报表,不同报表中存在一些相同的指标,这 些指标往往不一致,给业务分析和决策工作造成很多困惑,必须花费很大的精力去检查核实。 2) 对于很多指标,不清楚其具体含义,不清楚其反映的问题,不清楚其具 体算法和来龙去脉。 数据仓库项目开发维护者: 1) 不同报表中的同一指标不一致,必须花费很大的精力去检查,目前基本 上是通过手工检查表和存储过程的方式,效率较低。 2) 没有完善的开发、维护规范。比如,新增一张分析报表,开发人员根据 业务人员的需求制作完成之后,往往没有整理完善相应的数据指标解释和元数据管理,造成日后检查困难。 3) 开发、维护规范的执行力较低,没有行之有效的管控手段。不严格按照 规范执行,随着项目的发展和时间的推移,导致数据仓库项

元数据管理方案

元数据管理方案 元数据管理方案 1.1元数据抽取 为了简化元数据生成工作,系统提供自动生成元数据的功能,即元数据抽取。通过元数据自动抽取,用户可以方便、快捷地获得大量的元数据信息。 1.1.1抽取的对象 元数据抽取主要针对的对象有以下几种: 已有目录:已建业务应用系统中现有的目录资源。 数据库:各种数据库资源,包括关系型数据库、XML数据库等。 格式化电子文件:电子文件,例如Word PDF XLS等文件。 1.1.2元数据抽取的流程 元数据抽取的流程有4个主要步骤,分别为: 数据源信息获取:解决要从哪个数据源获得元数据的问题。 内容/结构分析:解决要从数据源中获得哪些元数据的问题。

元数据提取:解决如何从数据源中获取元数据的问题。 存储入库:解决元数据存储的问题。 1.1.3电子文档的元数据抽取 对于电子文档,首先各部门的文档格式不尽相同,另外它们的安全级别也各不相同,同时由于信息化建设水平的不一致,有的部门文档分散在各处,有的部门文档是集中存放的,甚至已经建立了完善的电子系统进行管理。 针对以上状况,对于电子文档的元数据抽取需要进行以下的抽取流程: 整理归档 对于分散在各处的电子文档(纸质文档需要先进行电子化处理),必须由专人进行统一整理,根据公开共享的前提进行集中,这种集中可以是物理上集中的,也可以是逻辑上集中的。但要满足以下原则,第一根据安全级别,便于外界访问;第二便于文档的增量发布;第三便于采集工具的自动化采集编目。各部门只有在文档完全整理归档的情况下,进行自动化采集才是切实可行的。在整理归档的时候,各部门根据各自情况进行归档,没有必要千篇一律,也没有必要制定繁琐和呆板的规则,只要能够满足以上的原则即可。 根据安全级别,建立相应的访问机制 由于受到安全级别的限制,所以对于需要共享的数据要进行安全方面的限制,限制的手段可以有:用户名/ 密码、数字证书、物理隔断等等,根据实际情况建立安全访问机制,做到重要信息不泄露,不丢失。 编目处理 现阶段,主流格式的电子文档,主要包含:word、excel 、ppt 、pdf 等。对主流格式的电子文档,要提供自动采集工具进行编目处理。采集的范围主要是文档的标题和内容,对于其它的元数据内容,要提供手工配置的方式进行辅助。另外,在工具的采集效率上,要提高增量文档发布后的采集效率。 对于格式特殊、内容有加密算法的文档,是很难通过抓取工具进行采集的,这些文档主要通过手工编目的方式来处理。 对于存在管理库的文档,就需要对数据库来进行编目采集,详见数据库元数据抽取部分。

(整理)数据仓库与元数据管理

数据仓库与元数据管理 1. 前言 在事务处理系统中的数据,主要用于记录和查询业务情况。随着数据仓库(DW)技术的不断成熟,企业的数据逐渐变成了决策的主要依据。数据仓库中的数据是从许多业务处理系统中抽取、转换而来,对于这样一个复杂的企业数据环境,如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。 本文首先介绍了元数据的定义、作用和意义;然后讨论了数据仓库系统中元数据管理的现状和关于元数据的标准化情况;最后提出了建立元数据管理系统的步骤和实施方法。 2. 元数据 2.1 元数据的概念 按照传统的定义,元数据(Metadata)是关于数据的数据。在数据仓库系统中,元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据;元数据是描述数据仓库内数据的结构和建立方法的数据,可将其按用途的不同分为两类:技术元数据(Technical Metadata)和业务元数据(Business Metadata)。 技术元数据是存储关于数据仓库系统技术细节的数据,是用于开发和管理数据仓库使用的数据,它主要包括以下信息: ●数据仓库结构的描述,包括仓库模式、视图、维、层次结构和导出数据的定义, 以及数据集市的位置和内容; ●业务系统、数据仓库和数据集市的体系结构和模式 ●汇总用的算法,包括度量和维定义算法,数据粒度、主题领域、聚集、汇总、 预定义的查询与报告; ●由操作环境到数据仓库环境的映射,包括源数据和它们的内容、数据分割、数 据提取、清理、转换规则和数据刷新规则、安全(用户授权和存取控制)。 业务元数据从业务角度描述了数据仓库中的数据,它提供了介于使用者和实际系统

个人知识管理常用软件、工具介绍

田志刚:个人知识管理常用软件、工具介绍 一把菜刀,厨师可以用来做出可口的美味佳肴,也可以被犯罪分子利用作为伤害人的凶器,这就是工具的特性,个人知识管理的工具、软件也是如此。 个人知识管理工具、软件和系统是个人管理自己知识的一个热点问题,我们认为在工具的选择和使用上主要需做到知理、知己、知彼、知用。 知理:大部分工具是客观存在的,如果你不掌握相关的理念和方法,即便将工具放在你的面前,你也不知道去选择,所以选择这些工具和方法的前提是掌握相应的理念和方法,这有这样你才能根据自己的需求积极主动的选择相应工具。 知己:你的需求是什么,你的主要问题是什么,制约你发展的瓶颈在那里?你只有知道自己的状况,才能确定自己选择工具和方法的原则,才能找到适合个人状况的工具。 知彼:“不知道自己不知道的东西”对于个人来讲无法选择,本文列出了普通用户可以得到的一些工具和方法,并对这些工具和方法进行了简单介绍。当你知道这些东西存在的时候,如果有更进一步需求的时候就可以用相关搜索引擎工具去查找。在知识管理中心(Knowledge Management Center)的社区中也有相关工具和方法的介绍。 知用:同样一个工具和方法,有人可以用的游刃有余而有人则只能浮在表面无法深入,所以在你选择了工具和方法后,你还需要充分发挥这些工具的作用,做到知到如何用、如何用的更巧妙等。 《你的知识需要管理》中涉及到了许多知识管理软件、工具,我们在选择和推荐相应工具和方法时,遵循了以下两个原则: 1、主流:本书中的工具和方法都是被实践证明过比较主流的应用,他们的提供商都有一定的实力,其在用户中也拥有良好的口碑,跟大部分应用可以集成。 2、经济:普通人不大可能投入大量的资金在这些工具上,所以我们推荐的工具和方法大都可以免费或者以很低成本得到,使这些空间和工具的使用没有门槛。 个人知识管理常用软件工具:

元数据管理

1.元数据管理技术及应用现状 朋友老朱在最近惊喜地发现,在营业部的每周例会上,原先各部门针对每日用户数的争吵声,现在逐渐销声匿迹了。原来,老朱所在的这家电信运营商,最近刚刚验收并启用了一个元数据管理平台工具。通过这一平台,IT部门可以在那些曾经引发激烈争吵的数字后面加上详细的注解。这样,即便各部门得出的当日用户数数值不一样,也能在注解中清楚地看到具体的差异在哪里。如此,自然再没有了吵来吵去的必要。 元数据,最常见的定义是:“关于数据的数据”。更准确一点说:元数据是描述流程、信息和对象的数据。这些描述涉及像技术属性(例如,结构和行为)这样的特征、业务定义(包括字典和分类法)以及操作特征(如活动指标和使用历史)。早在上世纪末,元数据的概念和相关工具就已经出现,但限于当时的数据量还不够大,而元数据本身又包含太多的内容,以至于它并未得到充分利用。而在今天看来,元数据正在成为解决诸多数据问题时必须要抓住的一个“精髓”要素。 消弭争吵 在此前一年中,老朱所在的那家电信运营商,各部门之间经常就每日用户数这类问题的指标数值不一致而吵得面红耳赤。其实,在其他电信公司或者其他行业中也都存在着类似问题。简单来讲,这些公司通过各个时期的IT建设,形成了很多个独立分开的系统。以电信运营商为例,就有计费系统、网络系统、OA系统、财会系统和客服系统等等。在这些系统中,存有不同的客户信息,具体体现就是不同格式的表。 两年前,公司的数据仓库项目建设完成,本以为这会大步提升IT系统的“智能性”,没想到,基层的反映却是根本没法用。而其中的原因就在于,数据质量没法保证,也即:在业务逻辑上并不准确,各部门对于指标的定义不能统一。 以当日用户数为例。对于这一指标,市场部、网络部、计费部等部门给出的定义并不一样。按照元数据技术的术语来讲,就是在业务元数据上,大家对于业务的认识并不统一。比如:计费部门认为,一个用户当天曾拨打电话,就可以计入到当日用户数;而财务部门则认定,只有在发生费用之后才能计入;至于网络部,则认为当天开机的用户就可以算作当日用户。如此一来,各部门的当日用户数数值自然就不一样:计费中心的系统显示,当日用户数有6000;市场部的系统显示却只有4000;到了财务部门的系统中,显示仅有3000个。在这种情况下,担负着业务压力的业务人员很可能谁也说服不了对方来接受自己的数字,导致大家对数据仓库系统本身的可信度也就打了折扣。 事实上,类似问题在目前已经建成的数据仓库项目中还有很多。其中的一大难题就是,原先未能统一的定义导致了某种指标的不一致,而要搞清楚为什么不一致,就得反查数据仓库中的这些表在一开始的时候是如何定义的,表与表之间的联络关系是怎样的。这种反查工作自然要求IT部门的人员就得详细查阅原先软件的设计。但问题是,现在的软件开发一般都是迭代式开发,每个阶段都有不同的人在做。回查一个表,很可能需要涉及到这个过程中的每一个开发人员。事实上,很少有人能做到这一点。即便费尽心机终于查到了,一个月的时间也过去了。

相关主题
文本预览
相关文档 最新文档