报表工具-数据仓库-商业智能－SAP屠夫的博客

1、报表工具->数据仓库->商业智能SAP屠夫的博客    报表工具->数据仓库->商业智能                  很多国有大企业的ERP实施是伴随着一大堆分析报表的,如果ERP实施不考虑众多的报表指标和报表间复杂的钩稽关系, 而仅仅是满足财务的核算, 就非常可能面临失败, 早期的国外ERP中一般会在各模块提供众多的系统分析报表系统,比如信息系统或专业的报

2、表分析工具, 但是这些在线分析报表如果和业务分析处理系统处在同一服务器,则严重浪费资源,于是产生了所谓的DW数据仓库,  现在DW换了个新叫法BI(商业智能).  在一个大型集团,如果基础数据不全、管理不规范,核算不标准的情况下就实施BI,成功率将非常小.      一.什么是数据仓库(Data Warehouse)?    你可能得到很多关于数据仓库的定义,但我还是愿意引申”数据仓库之父”的William H. Inmon 在1991年 出版的“Building the Data W

3、arehouse”一书中所提出的定义.    */home/ 是Inmon的个人主页,一看就知道是个喜欢折腾技术的人.    数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的、用于支持管理决策的数据集合。         根据数据仓库的定义,它被描述成一个用来支持符合企业发展的管理决策的综合的解决方案.          为什

4、么使用数据仓库(DW)?有这么些原因    (1).企业规模庞大.       (2).业务数据庞大.    (3).各分子公司系统异构.    (4).各种类型业务数据来源,数据需要汇总整合.    (5).ERP数据库性能原因,生产系统性能的降低.    (6) ERP.数据库通常不是为分析的目的设计的  

5、0;    ERP系统一般认为是OLTP系统,它不是专门为交叉主题分析报告而设计的.       交叉主题分析数据通常来自不同的模块,报表公式逻辑将负责且分散.    (7).性能为体,复杂的管理层决策报表可能需要从多个模块获得数据,这样的报表开发通常因为业务数据量过多而导致运行速度极慢,如果ABAPer在程序性能优化方面没有经验,甚至报表根本就无法得出,而且会严重消耗R/3资源.    (8).用户频繁变动需求原因,为了某种分析目的,

6、用户要求报表经常增加几个新字段那是很正常的,不同用户甚至对于同一个报表的取数逻辑的理解不同是正常的,不同领导对相似报表要求的报表行项目可能是不同的,不同企业对同一业务在R/3的处理方式是不一致.          一个在线分析系统OLAP系统(你可认为DW系统也就是一个OLAP系统)应该有这么些系统:    (1).市场和销售分析（Marketing and Sales analysis）    (2).基于历史数据的营销（D

7、atabase marketing）    (3).各种财务报告与合并报表（Financial reporting and consolidation）    (4).各类成本费用分析类的管理报告（Management reporting）    (5).利益率分析（Profitability analysis）    (6).质量分析（Quality analysis）    (7).存货分析(

8、Inventory analysis)    .一个大型ERP厂商应该能同时提供完善的在线分析系统又不影响在线交易系统性能.            集团企业都会寻找整合的高度集成的管理软件，而不是简单的反应式的零散的管理产品.     说到OLAP，就谈下OLTP，数据处理大致可以分成两大类：在线事务处理OLTP（on-line tranSAction processing,R/3可看成一个OLTP系统）、

9、在线分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。    摘自某网络的一段描述， 下表列出了OLTP与OLAP之间的比较。                    

10、;              OLTP             OLAP                     用户  

11、0;          操作人员,低层管理人员             决策人员,高级管理人员                     功能    &

12、#160;        日常操作处理             分析决策                     DB 设计       &

13、#160;     面向应用             面向主题                     数据           

14、  当前的, 最新的细节的, 二维的分立的             历史的, 聚集的, 多维的集成的, 统一的                     存取         

15、60;   读/写数十条记录             读上百万条记录                     工作单位            

16、; 简单的事务             复杂的查询                     用户数             上千个  

17、60;          上百个                     DB 大小             100MB-GB     &#

18、160;       100GB-TB                 OLAP产品和OLAP准则    最早的OLAP产品可以追溯到1970，但真正形成一个大的OLAP市场则是在90年代以后. 联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则，OLAP作为一

19、类产品同联机事务处理 (OLTP) 明显区分开来。    Codd提出OLAP的12条准则来描述OLAP系统：      准则1 OLAP模型必须提供多维概念视图      准则2 透明性准则      准则3 存取能力推测      准则4 稳定的报表能力      准则5 客户/服务器体系结构&

20、#160;     准则6 维的等同性准则      准则7 动态的稀疏矩阵处理准则      准则8 多用户支持能力准则      准则9 非受限的跨维操作      准则10 直观的数据操纵      准则11 灵活的报表生成(目前BEx对中国式的格式报表显然不灵活)   &

21、#160;  准则12 不受限的维与聚集层次(受数据库限制一般DW提供13个自定义纬度).    DW&OLAP的关系    数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取         让我们回过头来结合某BW来理解数据仓库的这几个重要特征:    

22、;(1).面向主题(Subject_orient)    主题是一个针对一决策问题而设置的分析对象,比如一个销售利润分析,如果你在SAP中写过类似报表,你可能需要使用客户,物料,销售订单和客户发票等表,    加一些数据冗余。    (2).集成的数据(Integrated)    数据仓库中存贮的数据是从原来分散的各个子系统中提取出来的，但并不是原有数据的简单拷贝，而是经过统一、综合。其一，数据仓库的数据不能直接从原有数据库系统中得到

23、。原有数据库系统记录的是每一项业务处理的流水帐，这些数据不适合于分析处理，在进入数据仓库之前必须经过综合、计算，抛弃分析处理不需要的数据项，增加一些可能涉及的外部数据,在BW中这些可以通过各种手段比如更新规则,传输规则实现.    其二，数据仓库每一个主题所对应的源数据在原分散数据库中有许多重复或不一致的地方，必须将这些数据转换成全局统一的定义，消除不一致和错误的地方，以保证数据的质量。    对源数据的集成是数据仓库建设中最关键，也是最复杂的一步。    (3).数据更新性

24、    数据仓库的数据一般不可更新，最终用户只能通过分析工具进行查询、分析，一般不允许直接修改其中存贮的数据,管理员可定期删除归档一些历史数据     (4)数据随时间不断变化(Time_variant)    数据仓库中的数据随时间变化而定期地被更新，每隔一段固定的时间间隔后，运作数据库系统中产生的数据被抽取、转换以后集成到数据仓库中，可以采用完全和增量更新,可以根据需要自定义更新周期.       &#

25、160;   .一些常见BI术语(来自网络)    BI    商业智能（Business Intelligence），指数据仓库相关技术与应用的通称。指利用各种智能技术，来提升企业的商业竞争力。         Data mart    数据集市，或者叫做"小数据仓库"。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓

26、库的一个子集，他主要面向部门级业务，并且只是面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。         数据集市:是用来分析特定业务主题或功能目标的公司数据的专门项目的数据收集。这些数据是粒度化的,历史的,整体的,全体的.    数据集市面向部门级业务，并且只是面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。         

27、60;    自下而上，"Think Big,Start Small".    另一种解决数据库方案早期问题的方法是数据集市的发展         (1)独立的数据集市    一个独立的数据集市是建立使用一个中央的、企业级数据库作为数据来源的数据集市。    所特别建立的单独的数据集市是供单个的部门使用或者是为了满足面向专门项目

28、的分析方案的需要，    但是大多数机构在其商务智能环境中愿意拥有多个数据集市。然而，不管在机构内有多少数据集市存在，    所有的数据集市的数据都来自EDW。         (2)非独立的数据集市    (3)作为数据库的数据集市    “数据集市是仓库”,在数据库团体中一种学院派的想法是数据仓库是由公司中的数据集市构成的。 

29、0;  用这种方式，公司建立数据集市，终端用户能够获取任何或者全部所需获得的数据来完成分析。    该理论认为，数据集市建立起来更简便快捷，一旦建立，就从数据集市中获取数据，而不用建立    和维护一个中央数据仓库。就像在数据仓库等技术领域大多数理论那样，这个概念有一些优点，    但是紧随其后的是显而易见的问题。    一个最重要的考虑是仍然打算确保在所有这些数据集市中获取的数据能被正确使用和整合。 &#

30、160;  在当今世界最艰巨的任务是方案的何去何从，以及执行官、经理、员工在商务和技术两方面何去何从等。    企业级数据仓库(EDW，Enterprise Data     Warehouse)，对于数据集市的定位也基本形成共识，那就是数据集市应该从属于企业级数据仓库。    所谓EDW，基本的要求是整个企业能够共享统一的数据存储模型，为各级业务人员提供一致的信息视图。    实施时可以先按照需求的轻重缓急选择部分

31、业务主题，然后逐步扩展到涵盖全部业务。               BI要想大做小，从最迫切的业务入手。无论是上哪种管理软件，几乎都会听到同样的声音：不要贪大求全，从最迫切的业务入手，BI也不例外，它可以做成一个独立的庞大系统，把企业中所有的业务数据全部放在一个数据仓库里，进行多维分析；也可以将其嵌入到各项单独的业务数据中，进行单独的业务分析。咨询顾问的意见是先把最紧要的业务管理起来，以便迅速响应市场需求，做出最佳决策。积累了一定经验后，再逐渐增加BI系统

32、继续对其他业务进行决策分析，这样可以在一定程度上规避风险，因为上BI也要进行流程的重整，    缺少数据分析师,这些数据将从何而来.Think Big , Start small.    但是我们根本都没有think . ROLAP    基于Codd的12条准则，各个软件开发厂家见仁见智，其中一个流派，认为可以沿用关系型数据库来存储多维数据，于是，基于稀疏矩阵表示方法的星型结构（star schema）就出现了。后来又演化出雪花结构。为了与多维数据库相区别，则把基于关系型数

33、据库的OLAP称为Relational OLAP，简称ROLAP。代表产品有Informix Metacube、Microsoft SQL Server OLAP Services。         MOLAP    Arbor Software严格遵照Codd的定义，自行建立了多维数据库，来存放联机分析系统数据，开创了多维数据存储的先河，后来的很多家公司纷纷采用多维数据存储。被人们称为Muiltdimension OLAP，简称MOLAP，代表产品有Hyperio

34、n(原Arbor Software) Essbase、Showcase Strategy等。          1.ROLAP          ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来

35、生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。          2.MOLAP          MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多

36、维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。          3.HOLAP          由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OL

37、AP结构提出了难题。为此一个新的OLAP结构混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。         Client OLAP    相对于Server OLAP而言。部分分析工具厂家建议把部分数据下载到本地，为用户提供本地的多维分析。代表产品有

38、Brio Designer，Business Object。         DSS    决策支持系统（Decision Support System），相当于基于数据仓库的应用。决策支持就是在收集所有有关数据和信息，经过加工整理，来为企业决策管理层提供信息，为决策者的决策提供依据。         ETL    数据抽取（Extrac

39、t）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。         Ad hoc query    即席查询，数据库应用最普遍的一种查询，利用数据仓库技术，可以让用户随时可以面对数据库，获取所希望的数据。        

40、60;EIS    主管信息系统（Executive Information System），指为了满足无法专注于计算机技术的领导人员的信息查询需求，而特意制定的以简单的图形界面访问数据仓库的一种应用。         BPR    业务流程重整（Business Process Reengineering），指利用数据仓库技术，发现并纠正企业业务流程中的弊端的一项工作，数据仓库的重要作用之一。  

41、0;           Data Mining    数据挖掘，Data Mining是一种决策支持过程，它主要基于AI、机器学习、统计学等技术，高度自动化地分析企业原有的数据，做出归纳性的推理，从中挖掘出潜在的模式，预测客户的行为，帮助企业的决策者调整市场策略，减少风险，做出正确的决策         CRM    

42、;客户关系管理（Customer Relationship Management），数据仓库是以数据库技术为基础但又与传统的数据库应用有着本质区别的新技术，CRM就是基于数据仓库技术的一种新应用。但是，从商业运作的角度来讲，CRM其实应该算是一个古老的"应用"了。比如，酒店对客人信息的管理，如果某个客人是某酒店的老主顾，那么该酒店很自然地会知道这位客人的某些习惯和喜好，如是否喜欢靠路边，是否吸烟，是否喜欢大床，喜欢什么样的早餐，等等。当客人再次光临时，不用客人自己提出来，酒店就会提供客人所喜欢的房间和服务。这就是一种CRM。    &

43、#160;    Meta Data    元数据，关于数据仓库的数据，指在数据仓库建设过程中所产生的有关数据源定义，目标定义，转换规则等相关的关键数据。同时元数据还包含关于数据含义的商业信息，所有这些信息都应当妥善保存，并很好地管理。为数据仓库的发展和使用提供方便。              Data Mart, 数据集市    

44、60;   也被称为“小数据仓库”，DW的一个子集，主要面向部门级业务。例如在销售部门的应用时，可能不需要分析某个产品的原材料。分析地区税收时，不需要分析能源消耗情况。         OLAP, Online Analytical Processing, 联机分析处理    也称为多维分析。基于一个主题“立方体”，该“立方体”若干个维，例如时间维，区域维，产品维等。这些维又可以进行分层。例如时间维包含年、旬、月、周、天，甚至可以到小时这一层。在

45、“立方体”中存储的事实值，某些值就是合计值了，在进行查询时，就不需要利用SQL将所有记录搜出来，再进行统计运算，这样就大大提高了最基本的查询能力了。同时，利用一些聚类算法等，还能发现一些“有意思的”结论，这就是DM/KDD（后面有讲）。    OLAP会有另起一篇来详细讨论，主题的选择，“立方体”的建立，维度设定，和DM怎样结合等都是需要好好思考的。         Ad-hoc Query, 即席查询    也就是基于前面O

46、LAP中谈到的“立方体”，因为统计值直接保存在DW中，就能大大提高查询能力。快速的查询，也许就叫即席查询了，_！         .to be continued !            已经公开 2007年7月11日 21:05 作者: SAP屠夫    评论       &

47、#160;         # SAP屠夫                          常见的几种数据仓库建模  一.直接报表型(Direct Reporting)      

48、0;  将数据仓库看成是简单的报表集中器,结构简单,可多维分析.二.独立数据集市部门级数据仓库(Data Mart)         认为数据仓库就是Data Mart的集合,按照业务主题建立数据集市,           跨业务主题分析不方便.三.企业级数据仓库(EDW)   (1)Hub and Spoke(集线器与车轮状)结构.   (2)高度统一的企业级数据仓库结构.&

49、#160;     这是目前比较流行的两种主流数据仓库建模体系,一.集线器结构(Hub and Spoke) 这种数据模型是建立一中央数据仓库然后根据报表需求分主题建立数据集市.类似建立报表立方体,不能满足大型的灵活性的数据仓库.二.统一的企业级数据仓库EDW中包含一层根据3NF建立的数据清洗层,数据完整后可以根据报表需求建立数据集市或将中央数据仓库的数据复制到专门的在线分析的用于报表目的的信息立方体中.关于统一的EDW有很多类似逻辑结构图,这是主流的数据仓库结构图.缺点:假设建立清洗ODS层,则庞大的清洗逻辑必须在BW中用ABAP编写更新规则.层次太多不方便维护

50、                     2007-07-11 22:11                        # 含泪的云    

51、;                    先收了再说                     2007-07-12 11:21      &

52、#160;                 # 大荒孤燕                        自打实施驾驶舱,这篇文章我也看了好多遍了,但数据分析不是很好做的.太多因素.  

53、60;                  2007-07-12 14:12                        # hoolilay     

54、0;                  我也学过数据挖掘，但总觉得很难！想真正用起来很难！                     2007-07-12 16:38    

55、0;                   # SAP屠夫                        "数据分析不是很好做的",如果各系统设计的逻辑关联不紧密,估计做数

56、据挖掘的会含冤而死,含恨而亡.                     2007-07-12 21:00                        # SAP屠夫 &

57、#160;                      数据仓库设计概念     元数据对象图.     元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将

58、其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。     技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据.     元数据作用     在数据仓库系统中，元数据机制主要支持以下五类系统管理功能：（）描述哪些数据在数据仓库中；（）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（）记录并检测系统数据一致性

59、的要求和执行情况；（）衡量数据质量。     元数据管理任务     元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模块和工具之间的工作。     你通过RSA1|RSOR查看BW元数据,      元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递

60、，协调各模块和工具之间的工作。由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。     KPI Vs Key Figure .     KPI (Key Performance Indicator)关键绩效指标是一个可衡量的业务指标,Key Figure是B

61、W的一个技术术语,KPI从Key Figure获得数据     信息对象,特征,关键指标(InfoObject, Characteristic,Key figure)                信息对象包括特征和关键指标,一个特征可能有自己的主数据,文本,层次或复合超级信息对象.     特征可以理解为关键指标的描述,典型地,客户编码,物料编码都是特征,

62、相关的时间特征,单位也是特征,特征可组成不同维度.             3.关键指标一般是数量,金额, 比如销售单价,销售数量.也可是编号,日期或时间型字段.     如果熟悉PA的朋友一定对KEA5(Characteristic特征),KEA6(Value fields值字段)不陌生.     Key figure 类似value field .    

63、;       ORM元数据管理             对象关系映射（Object Relational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，

64、而这些在手写的持久层并不存在。更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。           对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，

65、在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。           面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。        &

66、#160;  让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。     如上图:     1. 数据抽取工具(ETL Service)：把业务系统中的数据抽取、转换、集成到数据仓库中，如Ardent的DataStage、CA（原Platinum）的Decis

67、ion Base和ETI的Extract等。这些工具仅提供了技术元数据，几乎没有提供对业务元数据的支持。2. 前端展现工具(Presentation Service)：包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。3. 分析建模工具：为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义

68、。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。4. 数据存储工具：元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间. 业务数据则以ODS或InfoCube保存在数据仓库服务器.                 数据

69、仓库领域中两个最主要的元数据标准：     MDC的OIM标准和OMG的CWM标准。     4.1 MDC的OIM存储模型MDC成立于1995年，是一个致力于建立与厂商无关的、不依赖于具体技术的企业元数据管理标准的非赢利技术联盟，该联盟有150多个会员，其中包括微软和IBM等著名软件厂商。1999年7月MDC接受了微软的建议，将OIM作为元数据标准。OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用。它涉及了信息系统（从设计到发布）的各个阶段，通过对元数据类型的标准描述来达到工具和知识库之

70、间的数据共享。OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述，并被组织成易于使用、易于扩展的多个主题范围（Subject Areas），这些主题范围包括：? 分析与设计（Analysis and Design）：主要用于软件分析、设计和建模。该主题范围又进一步划分为：UML包（Package）、UML扩展包、通用元素（Generic Elements）包、公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等。 对象与组件（Object an

71、d? Component）：涉及面向对象开发技术的方方面面。该主题范围只包含组件描述建模（Component Description Modeling）包。? 数据库与数据仓库（Database and Warehousing）：为数据库模式管理、复用和建立数据仓库提供元数据概念支持。该主题范围进一步划分为：关系数据库模式（Relational Database Schema）包、OLAP模式（OLAP Schema）包、数据转换（Data Transformations）包、面向记录的数据库模式（Record-Oriented Database Schema）包、XML模式（XML Sche

72、ma）包和报表定义（Report Definitions）包等。 业务工程（Business? Engineering）：为企业运作提供一个蓝图。该主题范围进一步划分为：业务目标（Business Goal）包、组织元素（Organizational Elements）包、业务规则（Business Rules）包、商业流程（Business Processes）包等。 知识管理（Knowledge? Management）：涉及企业的信息结构。该主题范围进一步划分为：知识描述（Knowledge Descriptions）包和语义定义（Semantic Definitio

73、ns）包。上述主题范围中的包都是采用UML定义的，可以说UML语言是整个OIM标准的基础。虽然OIM标准并不是专门针对数据仓库的，但数据仓库是它的主要应用领域之一。目前市场上基于该标准的元数据管理工具已经比较成熟，例如微软的Repositry和CA的Repositry均采用了OIM标准。     4.2 OMG组织的CWM模型OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换

74、。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：(1) UML：它对CWM模型进行建模。(2) MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。(3) XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。OMG元数据知识库体系结构如图3所示。     CWM为数据仓库和商业智能（BI）工具之间共享元数据，制定了一整套关于语法和语义的规范。它主要包含以下四个方面的规范：(1) CWM元模型（Metamode

75、l）：描述数据仓库系统的模型；(2) CWM XML：CWM元模型的XML表示；(3) CWM DTD：DW/BI共享元数据的交换格式(4) CWM IDL：DW/BI共享元数据的应用程序访问接口（API）下面重点讨论CWM元模型的组成，它与OIM规范一样，也是由很多包组成的。组成CWM元模型的包结构如图4所示。     (1) 元模型（MetaModel）包：构造和描述其它CWM包中的元模型类的基础。它是UML的一个子集，由以下四个子包组成：a) 核心（Core）包：它的类和关联是该模型的核心，其它所有的包都以它为基础。b) 行为（Behavioral

76、）包：包括描述CWM对象行为的类与关联，并且它为描述所定义的行为提供了基础。c) 关系（Relationships）包：包括描述CWM对象之间关系的类与关联。d) 实例（Instance）包：包括表示CWM分类器（Classfier）的类与关联。(2) 基础包（Foundation）：它包括表示CWM概念和结构的模型元素，这些模型元素又可被其他CWM包所共享，它由以下六个子包组成：a) 业务信息（Business Information）包：包括表示模型元素业务信息的类与关联。b) 数据类型（Data Types）包：包括表示建模者可以用来创建所需数据类型的结构的类与关联。c) 表达式（Exp

77、ressions）包：包括表示表达式树的类与关联。d) 关键字和索引（Keys and Indexes）包：包括表示键和索引的类与关联。e) 软件发布（Software Deployment）包：包括软件如何在数据仓库中发布的类与关联。f) 类型映射（Type Mapping）包：包括表示不同系统之间数据类型映射的类与关联。(3) 资源包（Resource）：用于描述数据资源的包，它包括以下四个子包：a) 关系（Relational）包：包括表示关系型数据资源的元数据的类与关联。b) 记录（Record）包：包括表示记录型数据资源的元数据的类与关联。c) 多维（Multidimensional

78、）包：包括表示多维数据资源的元数据的类与关联。d) XML包：包括表示XML数据资源的元数据的类与关联。(4) 分析（Analysis）包：它由以下五个子包组成：a) 转换（Transformation）包：包括表示数据抽取和转换工具的元数据的类与关联。b) OLAP包：包括表示OLAP工具的元数据的类与关联。c) 数据挖掘（Data Mining）包：包括表示数据挖掘工具的元数据的类与关联。d) 信息可视化（Information Visualization）包：包括表示信息可视化工具的元数据的类与关联。e) 业务术语（Business Nomenclature）包：包括表示分类业务的元数据

79、的类与关联。(5) 管理（Management）包：用于描述数据仓库管理的包，它包括以下两个子包：a) 仓库过程（Warehouse Process）包：包括表示仓库过程的元数据的类与关联。b) 仓库操作（Warehouse Operation）包：包括表示仓库操作结果的元数据的类与关联。在数据抽取过程中，数据从各个业务系统中被统一转换存储到中央数据仓库中。CWM中的转换模型定义了数据在源和目的之间移动的过程，其中不仅包括源和目标之间的参数，还包括转换中的业务逻辑。这些业务逻辑可能包括一些商业规则、类库甚至是用户脚本。数据仓库如果有一个规范的转换模型将给工具软件厂商和专业服务提供商带来极大的好

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

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

82、经合并，今后所有的工具都将遵循统一的CWM标准，不过支持CWM的工具才刚刚出现，而支持OIM标准的工具已经相对成熟。     5. 元数据管理的相关研究工作目前元数据的研究集中在：数据和数据库管理11,12,13、元数据模型14,15,16、数据集成17,18、元数据工具19。在各研究领域中都存在一些问题。在数据仓库的研究课题当中，有许多是针对元数据的研究。文献5描述了一个在数据仓库环境中，基于微软的Repositry的、元数据驱动的数据转换方法，它包含了技术元数据与业务元数据；文献6中描述了一个基于元数据的数据仓库安全的解决方法，它只限定在技术元数据级

83、别；更有名的一个研究项目是数据仓库质量项目（Data Warehouse Quality），这个项目的核心是通过元数据模型来衡量整个数据仓库中的数据质量。它是基于一个演绎数据库CONCEPTBASE的，并且使用该数据库特定的逻辑语言进行描述，目前该项目距离实用的阶段还比较远。                     2007-07-12 21:22    &

84、#160;                   # SAP屠夫                        数据仓库设计概念     元数据对象图.

85、     元数据（Metadata）是关于数据的数据。在数据仓库系统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。     技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据.     元数据作用   

86、;  在数据仓库系统中，元数据机制主要支持以下五类系统管理功能：（）描述哪些数据在数据仓库中；（）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（）记录并检测系统数据一致性的要求和执行情况；（）衡量数据质量。     元数据管理任务     元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模块和工具之间的工作。   &#

87、160; 你通过RSA1|RSOR查看BW元数据,      元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据仓库建模工具、数据获取工具、前端工具等之间的消息传递，协调各模块和工具之间的工作。由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。