财务系统概要设计说明书.docx

财务系统概要设计说明书.docx

《财务系统概要设计说明书.docx》由会员分享，可在线阅读，更多相关《财务系统概要设计说明书.docx（64页珍藏版）》请在冰豆网上搜索。

财务系统概要设计说明书

AsiaInfo项目文档

西藏移动元数据管理系统

概要设计说明书

创建日期：

2006-10-08

最后修改日期：

2007-12-08

版本号：

V2.3

电子版文件名：

西藏移动元数据管理系统概要设计说明书.doc

亚信科技（中国）有限公司版权所有

文档中的全部内容属亚信科技（中国）有限公司所有，

未经允许，不可全部或部分发表、复制、使用于任何目的。

文档修订摘要

版本号

日期

修改说明

著者

审阅者

1.0

2007-10-08

创建

邱辉

2.3

2007-12-08

部分调整

李政

1引言

1.1编写目的

本说明书从全局的角度说明元数据管理系统的总体架构，帮助技术人员和系统维护人员了解元数据管理系统，方便元数据系统的使用和维护。

1.2背景介绍

西藏移动公司一直高度重视企业信息化建设，在全企业范围内建立了全方位的业务支撑系统，建立了由BOSS（业务支撑系统）、BBOSS（商业客户BOSS）、经营分析系统、客户服务系统、渠道管理支撑系统等构成的完善的CRM信息化系统，成为各级领导对公司运营情况进行综合分析和决策支持的重要工具。

西藏移动经营分析系统的数据来自多个业务系统、跨部门跨业务系统集成，同时也在全企业流通使用。

由于各业务系统的定位、作用及使用人员不同，存在相同名称的数据或指标，在不同业务部门及业务系统间含义不一致的情况。

只有对有关数据配有相应的定义描述（即元数据），才可以解释各部门从不同角度出发产生的同名统计指标的数据不一致的正常现象，确保数据的正确性和可信度，否则将大大限制经营分析系统的应用。

随着西藏移动公司信息化建设的不断推进，业务系统及其提供的数据日趋丰富、经营分析纵深化发展，各系统之间数据定义不一致的问题将不可避免且呈增长态势，这些问题最终将集中体现到经营分析系统，因此经营分析系统在建设、完善的过程中，必须同步完善对所使用的数据的解释、定义，形成企业范围内的一致、统一的数据定义，这即是元数据管理系统的范畴。

西藏移动经营分析系统的使用人员要能直接使用数据，就需要了解更多的有关业务数据的统计口径、数据来源等，元数据管理系统提供了完善的数据指标解释。

缺少了元数据的帮助，业务人员很难看懂报表和分析结果，更无法对数据进行自主的深入分析。

移动经营分析系统中存在大量历史数据，这些历史数据需要有详细的背景情况说明、获取方式描述，才能正确地与现行数据进行比较分析、时间序列分析，才是真正有用的信息资源。

对历史数据的充分利用，才能有效保护以往的信息化投资、真正发挥经营分析系统的作用。

西藏移动经营分析系统的建设是一个不断演化发展的过程，包括完善数据模型、扩充数据主题、增加数据源、丰富业务应用等，元数据系统记载保存了它的发展轨迹，为系统的演变过程提供历史纪录，保护已建设的各个模块和分析主题能够被持续、有效地利用，从而达到充分利用原有投资的目的。

此外，西藏移动经营分析系统涉及众多的工具、数据存储，它们各自产生自己的元数据，也需要使用、共享其他工具的元数据，围绕经营分析系统需要进行大量的元数据互操作。

元数据管理系统为这种需求提供了最可靠、简捷的解决方案。

总的来说，元数据管理系统集成、管理经营分析系统相关的元数据，形成企业的全局数据视图，提供企业级共享元数据的平台，是移动经营分析系统的基础设施，对经营分析系统的发展、应用有着深远影响。

西藏移动公司以战略的眼光提出元数据管理系统的建设，石竹软件有限公司非常荣幸有此机会将业界领先的元数据管理产品介绍给西藏移动公司、并将我们在元数据系统方面多年的开发、建设经验应用于西藏移动元数据管理系统。

1.3术语定义

✧元数据：

是描述经营分析系统中数据的数据，为数据质量管理等业务功能提供信息支撑。

✧技术元数据：

技术元数据包含关于经营分析系统数据技术层面的信息，描述了数据源、ETL、数据仓库和数据集市、OLAP、一经接口等子系统的数据特征。

✧业务元数据：

业务元数据用业务术语、名称、定义来描述经营分析系统中的各种业务信息，供业务人员使用。

✧元数据管理系统：

集成、管理所有元数据，并提供企业级元数据共享的平台，是数据仓库系统的基础设施。

✧CWM：

CWM标准是OMG组织定义的数据仓库和相关系统的国际元数据标准，CWM标准的目的在于使得数据仓库和商业智能软件的元数据在分布异构的数据分析工具，数据仓库平台，元数据存储等系统之间交互。

1.4参考文档

CWM规范http:

//www.omg.org

MOF规范http:

//www.omg.org

XMI规范http:

//www.omg.org

J2EE规范

2系统概述

2.1系统功能设计目标

本系统主要针对西藏移动的经营分析系统建设元数据管理平台，并在此基础上根据西藏移动的实际需要，开发建立元数据维护与指标管理系统。

本期工程以完成西藏移动公司元数据管理平台和元数据管理系统为主，涉及与一级经营分析系统元数据接口部分。

在实施深度方面，要求构建从ETL一直到数据仓库、OLAP分析、报表、KPI等方面的元数据管理系统，完成“数据流图”的构建过程，能够进行有关数据指标的信息回溯工作，并提供可供业务人员理解和使用的用户访问界面。

2.2元数据管理框架

元数据源层——元数据源层包括经营分析系统的数据源系统，ETL工具、数据仓库产品、数据集市产品、OLAP服务器、前端展现工具、数据挖掘工具等。

元数据获取层——元数据获取层实现元数据源层中各个系统的元数据抽取。

元数据连接桥（或称适配器）通过符合CWM规范的接口或者各个产品提供的特定接口实现元数据的抽取，并把抽取出的元数据存入元数据存储层中的元数据库。

元数据存储层——元数据存储层实现元数据的存储，存储的元数据包括业务元数据、技术元数据和管理元数据，元数据按照主题组织。

存储库的逻辑模型设计需兼顾效率和实现符合CWM规范的接口的方便性与灵活性。

元数据管理层——元数据管理层提供符合CWM规范的接口实现，包括CORBAIDL接口实现/JMI接口实现，和XMI接口实现；并且实现元数据查询、元数据浏览、元数据访问、元数据分析、元数据导入、元数据导出等基本功能模块。

元数据访问层

元数据访问层包括元数据管理工具前端、二级经营分析系统和中央元数据抽取服务器。

这些系统通过元数据管理层访问元数据存储层的元数据。

2.3CWM规范支持

元数据工具的类型：

Metaone是一个通用的、企业级元数据管理工具，它具备可以扩展的元模型，能够进行元数据的集中、展现和分析。

它采用关系型数据库作为存储库，支持自动元数据获取、支持多种工具产品的接口、具有强大的用户权限管理功能以及提供多种图形化的分析功能。

Metaone对CWM规范的支持：

从技术设计的概念上讲，Metaone是一个元数据集中和分析平台，因此对于各种不同工具、软件产生的元数据能够正确描述和统一管理、分析是至关重要的。

OMG组织的CWM规范正是在这个意义下提出的。

通过支持元数据的CWM规范能够统一技术元数据的模型，可以统一不同工具之间的元数据的定义，这为Metaone跨不同工具建立各类分析和统计等打下基础。

正是基于这个考虑，Metaone在设计时，元模型的定义支持CWM模型的描述，并采用CWM或者在兼容CWM的基础上进行扩展的方式定义元模型。

具体实现的手法体现在下面几个方面：

1.Metaone的元模型定义支持CWM。

CWM是采用UML来描述的元模型。

因此，为了实现CWM定义，在Metaone的元模型定义上，需要实现对于包、类、属性、继承以及关系等的定义。

并在这个基础上，Metaone元模型中的核心包、关系数据库、OLAP等均是采用CWM标准来进行定义的。

2.导入CWM标准的XMI文件。

符合CWM标准的XMI文件能够导入到Metaone存储库中。

3.导出CWM标准的XMI文件。

Metaone能够导出符合CWMXMI标准的元数据文件。

2.4元数据系统架构

西藏移动元数据系统由四部分组成：

Metaone管理工具，元数据维护系统,元数据存储库，元数据整合平台。

元数据维护系统负责元数据展现，元数据管理，元模型管理和元数据分发，比如元数据浏览，影响分析，关系图形维护。

元数据管理平台同时负责与一经系统的数据交互，经分系统提供元数据查询和浏览。

另外，元数据管理平台还负责用户，组，权限管理，以及系统参数配置等。

元数据存储库负责元数据，元模型存储，版本记录。

元数据整合平台负责元数据的抽取和整合。

针对每一种数据源有专有的工具抽取元数据，将抽取到元数据整合并组织元数据之间的关系，最后存储到标准的XMI文件中。

最后通过元数据管理平台将元数据加载到元数据存储库中。

2.5元数据维护及管理系统架构

元数据维护及管理系统将不同业务系统的数据结构等信息读取进来，并加入业务规则的描述和业务量值的内涵，以真正动态描述的信息数据百科全书方式，供所有数据相关部门查询使用。

以下是元数据维护及管理系统的系统架构及环境描述：

3元数据技术体系结构

元数据维护系统基于J2EE的三层架构设计，总共分为三层：

展示层，业务层，持久层。

在三层之间，每一层都通过接口隔离，达到高内聚松偶合。

展示层与业务层，持久层是单向依赖关系，层次与层次不能跨层调用。

3.1.1展示层

展示层位于最顶层，负责为用户提供可视化的交互界面。

展示层依赖与业务层，展示层与业务层以接口隔离，因此，业务层的接口具体实现的变化不会影响到业务层。

展示层基于HTML和Applet提供基于web界面和图形界面。

元模型、元数据的基本维护，用户管理，组管理，权限管理等都通过web来操作。

对于Web界面，客户端无需安装任何的软件，直接使用IE浏览器就能访问。

元数据的关系展示与维护则通过图形界面来操作。

基于Applet的图形管理界面，客户端需要额外安装Sun公司的Jre，Jre为Sun公司提供的免费软件。

同时展示层还要为经分系统提供元数据查询和浏览界面，在经分系统中，能够直接登录到元数据关系系统，而且能够在经分系统中浏览元数据资料和影响分析。

3.1.2业务层

业务层位于展示层之后，为展示层提供业务访问接口，所有的业务逻辑都位于业务层。

业务层主要负责元数据系统内部的业务逻辑，比如安全控制，权限控制，元数据版本管理等。

业务层也要调用持久层，将数据持久到数据库。

3.1.3持久层

持久层位于最底层，为业务层提供访问接口和具体实现，负责数据的存储与访问。

业务层不需要知道数据存储和访问的细节，展示层不能直接调用持久层，对于展示层而言，持久层是透明的。

持久层采用JDBC技术开发，具体良好的可扩展性和可移植性。

3.1.4域模型

域模型为整个系统核心模型，域模型描述了系统中模型的状态和行为。

域模型贯穿在这个系统中，在展示层，业务层，持久层都有体现，都以域模型为中心。

具体体现为展示层以域模型为中心展现，业务层以域模型为中心处理业务逻辑，持久层持久于域模型。

4元数据源层概要描述

4.1关系型数据库

作为元数据源层的关系型数据库包括有两大类型：

Oracle和DB2。

其中存放了数据仓库的ODS，DW，ST,RM,DM，EM等模块的数据。

ODSModel,即操作数据存储（OperationalDataStore）模型，它是从业务系统过渡到数据仓库核心层的操作数据的模型，其设计接近于业务系统，其目标是对数据仓库核心层尽量屏蔽不同业务的差异性，ODSModel层的数据不做保留。

DataWareHouseModel，该数据模型是数据仓库核心层的数据模型，用于存放完整的详细历史数据，目前按照三范式设计，其设计目标是为后续的StarSchema/DM/Report/External提供足够的灵活性和扩展性的基础。

由于DataWareHouseModel模型内的数据包含了整个数据仓库的大部分数据，是数据仓库项目的基础，所以保证该层数据长期的稳定性是首要的。

数据仓库（DataWarehouse）是一个面向主题的（SubjectOri2ented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合用于支持管理决策。

对于数据仓库的概念我们可以从两个层次予以理解,首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改，数据集市可以理解为是一个小型的部门或者工作组级别的数据仓库。

StarSchemaModel，该数据模型以DataWareHouseModel为基础建立，对应多维分析的StarSchema，其首要目标是最大程度的满足业务的灵活需求，实现所谓的“商业智能”。

ReportModel该数据模型以DataWareHouseModel为基础建立，专用于生成报表。

DataMiningModel该数据模型以DataWareHouseModel为基础建立，专用于数据挖掘，其内容包括数据挖掘所需的每月的基础性宽表，应用于各个特定数据挖掘模型的数据挖掘模型宽表。

ExternalModel该数据模型以DataWareHouseModel为基础建立，为外部系统直接访问数据仓库提供一个隔离层。

当外部系统直接访问数据仓库时，其看到的数据以ExternalModel形式呈现而不是以DataWareHouseModel形式呈现，这样数据仓库内部结构被屏蔽，外部系统只能访问到ExternalModel内涉及到的数据而无法获取数据仓库内全体的数据。

在西藏经分系统中，采用Ibmdb2v8.2数据库系统。

4.2OLAP分析

OLAP（on-lineanalyticalprocessing），也叫联机分析处理，是数据仓库系统的主要应用.OLAP是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。

企业决策者把数据处理的重点从传统的业务处理过程扩展到联机分析处理上来，利用该技术，决策者可以从中掌握有用的信息，及时把握市场的动向，做出正确有效的判断。

它将数据仓库的数据按各种主题组织成多个多维立方体，直接为前端各种展示工具提供快速响应服务。

在西藏经分系统中，采用hyperioessbase7.1.6OLAP设计开发工具。

4.3ERWin

作为数据库建模的主流工具之一，ERWIN在经分系统的数据建模过程中也是必不可少的工具之一，经分系统中的数据逻辑关系等重要设计均利用该工具完成。

它在经分中扮演着数据建模及逻辑描述的重要角色，经分系统中的一切逻辑关系的建立及模型设计均依赖于该工具。

在西藏经分系统中，采用erwin4.1.4数据库设计工具。

4.4文件数据

需要通过人工整理的元数据都是以文件数据的方式作为元数据源的。

这些文件数据包括的类型有：

接口文件，TCL程序，报表，数据挖掘，项目管理等等。

文件数据都是以EXCEL的格式存放。

接口文件：

InterfaceFiles是从业务系统抽取数据的接口文件，是整个经营分析系统数据处理的源头。

TCL程序：

是亚信实现ETL过程的主要程序，利用该程序进行数据抽取、转换和加载，在数据仓库实现过程中，将进行数据由数据源系统向数据仓库的加载与处理。

报表：

经分前端展现的主要方式之一。

数据挖掘（DataMining）：

又称为数据库中的知识发现（KnowledgeDiscoveryinDatabase,KDD），就是从大量数据中获取有效的、新颖的、潜在有用的、最终可理解的模式的非平凡过程，简单的说，数据挖掘就是从大量数据中提取或“挖掘”知识。

需要通过人工整理的元数据都是以文件数据的方式作为元数据源的。

这些文件数据包括的类型有：

TCL程序，报表，数据挖掘，项目管理等等。

文件数据都是以EXCEL的格式存放。

5元数据获取层概要设计（元数据抽取）

元数据整合平台分为六个子模块：

OLAP元数据抽取，DB2元数据程序，ERWin,元数据整合。

把DB2数据和ESSBASEOLAP中的元数据，业务人员整理出的元数据导入到存储库中。

首先将元数据转换成XMI文件放到指定目录下，然后分析比较出增量数据（XMI文件），XMI文件包含元数据对存储库（Repository）进行增删改操作，要求数据的操作为一个独立的可回滚的事务操作，即元数据操作要么全部成功，要么全部失败。

同时提供日志记录，记录操作的元数据数量，操作失败的原因。

5.1OLAP元数据抽取

OLAP元数据抽取通过OLAP的EDS服务器获取OLAP的元数据，过滤到一些无用的数据，并按照OLAP的元模型组织元数据。

EDS提供了基于Java的API，通过JavaAPI访问EDS服务器，传递访问命令给EDS服务器，EDS再将命令转递给OLAP服务器，对于OLAP服务器响应的数据返回给元数据整合平台。

JavaAPI和EDS服务器，EDS服务器于OLAP服务器之间都是通过HTTP协议交互。

5.2DB2元数据抽取

关系数据库的元数据几乎都存在在数据库中系统表中，通过访问系统表能够读取到关系数据库的元数据。

DB2元数据抽取通过JDBC连接DB2数据库，通过DB2系统表获取元数据，然后根据业务需要过滤一些不需要的元数据，并按照关系数据库的元模型组织元数据。

程序中有表归档处理，将海量表信息中归档归并同类元数据。

5.3XLS元数据抽取

XLS的元数据抽取直接将XLS中的数据按照定制XLS中定制的元模型组织元模型。

XLS文件中定义了元模型的数据，也包含了要导入的元数据数据，因此XLS文件能够描述任意的元模型的数据。

5.4ERWin元数据获取

开发采用XMI接口将ERWinXML文件抽取到元数据存储库中，提供物理视图与逻辑视图展示平台。

5.5元数据整合

元数据整合将已经组织好的OLAP，DB2,按照OMG制定的XMI规范存储到XML文件中，最后调用元数据管理平台的将XML文件中元数据加载到元数据存储库中。

元数据加载能够通过人工加载，也能够通过程序自动加载，提供详细的日志记录文件和统计信息。

6元数据存储层概要设计（元数据存储）

元数据存储库采用关系数据，逻辑模型主要采用OMG的MOF规范设计并有扩展，针对元模型和元数据各有一套对应的库表。

库表与域模型一一对应，元模型主要包括类，属性，关系，包，数据类型等域模型，元数据主要包括类，属性，关系等域模型。

这种结构设计支持任务的元模型和元数据扩展。

6.1概念结构设计

说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项、记录、系、文卷的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图。

6.2逻辑结构设计

把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文卷结构、所建立的各个文卷之间的相互关系，形成本数据库的数据库管理员视图。

代码

名称

METAONE_DATTRIBUTE

元数据属性值表

METAONE_DATTRIBUTE_DIFF

元数据属性版本记录表

METAONE_DCLASS

元数据表

METAONE_DCLASS_COORDINATE

元数据图形坐标表

METAONE_DCLASS_DIFF

元数据版本记录表

METAONE_DCLASS_VALUE

表元数据重要程度表

METAONE_DPRIVILEGE

元数据权限表

METAONE_ENTRY

入口表

METAONE_GROUP

用户组表

METAONE_GROUP_ROLE_LINK

用户组－角色表

METAONE_MATTRIBUTE

元模型属性表

METAONE_MCLASS

元模型表

METAONE_MCLASS_LINK

元模型继承关系表

METAONE_MDATATYPE

元模型数据类型表

METAONE_MDIFFERENCE

元模型版本记录表

METAONE_MENUMERATIOLITERAL

元模型枚举类型表

METAONE_MOPERATION

元模型操作表

METAONE_MPACKAGE

元模型包表

METAONE_MPARAMETER

元模型参数表

METAONE_MPRIVILEGE

元模型权限表

METAONE_PERMISSION

许可权限表

METAONE_PROPERTY

系统参数表

METAONE_PRIVILEGE

系统权限表

METAONE_RESOURCE

可用资源表

METAONE_ROLE

角色表

METAONE_ROLE_DPRIVILEGE_LINK

角色－元数据权限表

METAONE_ROLE_MPRIVILEGE_LINK

角色－元模型权限表

METAONE_ROLE_PERMISSION_LINK

角色－权限表

METAONE_TRACELOG

登录日志表

METAONE_USER

用户表

METAONE_USER_GROUP_LINK

用户－组表

METAONE_USER_ROLE_LINK

用户－角色表

METAONE_MASSOCIATION

元模型关联关系表

METAONE_MDEPENDENCY

元模型依赖关系表

METAONE_DASSOCIATION

元数据关联关系表

METAONE_DDEPENDENCY

元数据依赖关系表

METAONE_DASSOCIATION_DIFF

元数据关联关系版本记录表

METAONE_DDEPENDENCY_DIFF

元数据依赖关系版本记录表

METAONE_USER_PROFILE

元数据用户资料表

METAONE_GROUP_PROFILE

元数据组资料表

METAONE_META_PROFILE

元数据用户－组资料表

6.3物理结构设计

建立系统程序员视图，包括：

1．数据在内存中的安排，包括对索引区，缓冲区的设计。

2．所使用是外存设备以及外存空间的组织，包括索引区，数据块的组织与划分。

3．访问数据的方式方法。

7元数据管理层概要设计（元数据维护）

7.1模块结构

元数据维护系统功能模块结构图：

元数据维护系统由元模型管理，元数据管理，元数据关系管理，元数据维护，元数据分析，系统管理六部分组成。

7.2元模型管理

元模型定义了元数据的形式，为元数据提供了抽象模板。

本模块提供元模型管理功能，可以管理包、类、类的属性、属性的数据类型以及类之间的关系等。

类是元模型的核心，一个元模型类代表了一类元数据，比如元模型类Table可以作为成千上万个表的元数据的模板。

每个类具有属性，比如元模型类Table，它可以有“是否系统表”等属性。

每个类还具有关系，用以建立与其它类的关联，比如元模型类Table，它可以与元模型类Column建立一个关系，用以表达它们见的包含关系。

此外，每个属性都属于一种数据类型，用以定义该属性的格式。

元模型包相当于文件系统中的文件夹，为类提供了层次结构。

7.2.1.1模块结构图

元模型管理的功能模块结构图：

元模型