数据仓库和元数据管理

《数据仓库和元数据管理》由会员分享，可在线阅读，更多相关《数据仓库和元数据管理（6页珍藏版）》请在金锄头文库上搜索。

1、数据仓库和元数据管理在事务处理系统中的数据，主要用于记录和查询业务情况。随着数据仓库( DW )技术 的不断成熟， 企业的数据逐渐变成了决策的主要依据。 数据仓库是一种面向决策主题、 由多 数据源集成、拥有当前及历史总结数据、 以读为主的数据库系统， 其目的是支持决策。 数据 仓库要根据决策的需要收集来自企业内外的有关数据， 并加以适当的组织处理， 使其能有效 地为决策过程提供信息。 数据仓库中的数据是从许多业务处理系统中抽 取、转换而来， 对于这样一个复杂的企业数据环境，如何以安全、 高效的方式来对它们进行 管理和访问就变得尤为重要。解决这一问题的关键是对元数据进行科学有效的管理。 元数据是

2、关于数据、 操纵数据的 进程和应用程序的结构和意义的描述信息， 其主要目标是提供数据资源的全面指南。 元数据 不仅定义了数据仓库中数据的模式、 来源以及抽取和转换规则等， 而且整个数据仓库系统的 运行都是基于元数据的， 是元数据把数据仓库系统中的各个松散的组件联系起 来，组成了一个有机的整体。本文首先介绍了元数据的定义、作用和意义； 然后讨论了 数据仓库系统中元数据管理的现状和关于元数据的标准化情况； 最后提出了建立元数据管理 系统的步骤和实施方法。建立数据仓库一个重要的工作是元数据管理。按照传统的定义，元数据(Metadata )是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理

3、员和数据仓库的开发人员非常方便地找到他们所关心的数据； 元数据是描述数据仓库内数据的结构和建立 方法的数据，可将其按用途的不同分为两类：技术元数据( Technical Metadata)和业务元数据( Business Metadata)。元数据使得用户可以掌握数据的历史情况， 如数据从哪里来？流通时间有多长？更新频 率是多大？数据元素的含义是什么？对它已经进行了哪些计算、 转换和筛选等等。 在需求不 确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。通常把元数据分为技术元数据(Technical Metadata )和业务元数据 (Business Meta

4、data)。技术元数据是存储关于数据仓库系统技术细节的数据， 是用于开发和管理数据仓库使用的数 据，它主要包括以下信息：数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义， 以及数据集市的位置和内容； 业务系统、 数据仓库和数据集市的体 系结构和模式； 汇总用的算法， 包括度量和维定义算法， 数据粒度、 主题领域、 聚集、汇总、 预定义的查询与报告；由操作环境到数据仓库环境的映射， 包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全(用户授权和存取控 制)。业务元数据从业务角度描述了数据仓库中的数据， 它提供了介于使用者和实际系统之间 的语义层，使

5、得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、 对象名和属性名； 访问数据的原则和数据的来源； 系统所提供的分析方法以及公式和报表的信息； 具 体包括以下信息：企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领

6、域业务事实表和维表的多维组织形式。业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、 层次等之间的对应关系也应该在元数据知识库中有所体现。在数据仓库系统中，元数据机制主要支持以下五类系统管理功能：（1）描述哪些数据在数据仓库中；（2）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（3）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（4）记录并检测系统数据一致性的要求和执行情况；（5）衡量数据质量。与其说数据仓库是软件开发项目，还不如说是系统集成项目1，因为它的主要工作是把所需的数据仓

7、库工具集成在一起，完成数据的抽取、转换和加载，OLAP分析和数据挖掘等。如图1所示，它的典型结构由操作环境层、数据仓库层和业务层等组成。其中，第一层（操作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源；第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层；第三层是为了完成对业务数据的分析而由各种工具组成的业务层。图中左边的部分是元数据管理，它起到了承上启下的作用，具体体现在以下几个方面：便于集成提高系统的灵活性保证数据的质量帮助用户理解数据的意义元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间

8、的消息传递，协调各模块和工具之间 的工作。由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。在数据抽取过程中，数据从各个业务系统中被统一转换存储到中央数据仓库中。CWM中的转换模型定义了数据在源和目的之间移动的过程，其中不仅包括源和目标之间的参数，还包括转换中的业务逻辑。这些业务逻辑可能包括一些商业规则、类库甚至是用户脚本。数据仓库如果有一

9、个规范的转换模型将给工具软件厂商和专业服务提供商带来极大的 好处，例如，按照统一的规范厂商可以设计一个通用的模型从标准ERP包中抽取数据。工具厂商甚至可以随软件提供成熟的模型，集成商也可以将一个模型应用到多个项目中。最终用户同样也能从 CWM中受益，在使用商业智能分析软件进行多维分析的时候，用户往往会对数据的含义和来源产生疑问。CWM能够提供这些信息，用户可以清楚地看到数据来自哪个系统，并且是如何组成的。上两节分别介绍了与数据仓库相关的两个主要标准， CWM 实际上是专门为数据仓库元 数据而制定的一套标准，而 OIM 并不是针对数据仓库元数据的。 OIM 所关注的元数据的范 围比 CWM 要广

10、， CWM 只限定于数据仓库领域，而 OIM 模型包括有：分析与设计模型、 对象与组件、数据库与数据仓库、商业工程、知识管理等五个领域。 OIM 与 CWM 在建模 语言的选择（都选择 UML 当做自己的描述语言） 、数据库模型的支持、 OLAP 分析模型的 支持、 数据转换模型的支持方面都比较一致； 但是 OIM 并不是基于元对象设施 （ MOF ）的， 这意味着用 OIM 所描述的元数据需要通过其它的接口才能访问，而 CWM 所描述的元数据 可以通过 CORBA IDL 来访问；在数据交换方面， OIM 必须通过特定的转换形成 XML 文件 来交换元数据，而 CWM 可以用 XMI 来进行

11、交换。尽管如此，由于 OMG 与 MDC 两个组 织的合并， CWM 也会与 OIM 相互兼容以保护厂商已有的投资。需要说明的是， MDC 与 OMG 组织已经合并，今后所有的工具都将遵循统一的 CWM 标准，不过支持 CWM 的工具才刚刚出现，而支持 OIM 标准的工具已经相对成熟。目前元数据的研究集中在：数据和数据库管理11,12,13、元数据模型 14,15,16 、数据集成 17,18 、元数据工具 19 。在各研究领域中都存在一些问题。在数据仓库的研究课题当中，有许多是针对元数据的研究。文献 5描述了一个在数 据仓库环境中，基于微软的 Repositry 的、元数据驱动的数据转换方法

12、，它包含了技术元数 据与业务元数据；文献 6中描述了一个基于元数据的数据仓库安全的解决方法，它只限 定在技术元数据级别；更有名的一个研究项目是数据仓库质量项目（ Data Warehouse Quality ），这个项目的核心是通过元数据模型来衡量整个数据仓库中的数据质量。它是基于 一个演绎数据库 CONCEPTBASE 的，并且使用该数据库特定的逻辑语言进行描述，目前该 项目距离实用的阶段还比较远。数据仓库环境下的元数据管理系统的建设是十分困难的。但是在实际项目的实施过程 中，这个环节又是非常重要的。当前情况下， OMG 组织的 CWM 标准将会成为数据仓库元 数据领域事实上的标准， 在元数

13、据管理系统的建立过程中应尽量参考这个标准， 这样使系统 的可扩展性增强。可是在与之相关的工具成熟之前， 我们完全可以采用 OIM 中的元模型（因 CWM 对 OIM 是兼容的） 以及支持它的元数据管理工具进行元数据管理系统的建设， 而且元数据所包含的 范围很广。 我们在建立元数据管理系统的时候， 绝对不能盲目追求大而全， 要坚持目标驱动 的原则，在实施的时候要采取增量式、渐进式的建设原则。具体的建设步骤如下：（1） 如果是在建设数据仓库系统的初期， 那么首先要确定系统的边界范围， 系统范围确定 的原则是首先保障重点，不求大，只求精。（2） 系统边界确定以后，把现有系统的元数据整理出来，加入语义

14、层的对应。然后存到 个数据库中，这个数据库可以采用专用的元数据知识库，也可以采用一般的关系型数据库。（3） 确定元数据管理的范围。 程，以及有关数据的抽取路线， 程。比如，我们只想通过元数据来管理数据仓库中数据的转换过4） 确定元数据管理的工具，采用一定的工具可以完成相应的工作。当前相关工具有微软以使数据仓库开发和使用人员明白仓库中数据的整个历史过的 Repositry ，它带有相应的编程接口，可以借助于它来完成元模型出入库的功能；与之相 似的还有Platinum的OEE;另外还有Sybase的Wcc,它可以通过MDC以前的一个老标准MDIS 来集成抽取工具与转换工具，在一个窗口中就可以表示数

15、据抽取与转换，并且可以把语义层以 MDIS 的格式导出到一个前端工具当中（比如Cognos 的 Improptu ）。元数据存在的状况是有差异的， 系统层元数据应随数据库存在， 且由建立在分布式网络 数据库管理系统统一管理； 数据集层次元数据可以随数据库存在也可随数据集存在； 数据特 征层次的元数据只能随数据集存在。元数据存贮有两种形式（图 5）：其一是以数据集为基础，即每一个数据集有一个对应 的元数据文档， 每一个元数据文件中包含对相应数据集的元数据内容。 另一种存在方式是以 数据库为基础（即元数据库） ，给一个数据库有一个元数据文件，该文件为一表格数据，它 由若干项组成，每一项表示元数据的

16、一个要素，其记录为每一个数据集的元数据内容。两种存贮方式各有优缺点， 对于第一种存储模式， 其好处是调用数据时其相应的元数据 也作为一个独立的文件被传输， 相对数据库有较强的独立性， 在对元数据进行检索时可以利 用数据库的功能实现， 也可以将元数据文件调到其它数据库系统中进行操作； 其问题是： 每 一数据集都有一个元数据文档， 那么在规模巨大的数据库中则会有大量的元数据文件， 管理 上极为不便。在第二中存在模式中， 由于库中只有一个元数据文件， 管理极为方便， 添加或删除数据 集只把该文件中添加或删除相应的记录项即可； 但如果想获取某数据集的元数据时， 实际得 到的只是关系表格数据的一个记录，