很多国有大企业的ERP实施是伴随着一大堆分析报表的,如果ERP实施不考虑众多的报表指标和报表间复杂的钩稽关系, 而仅仅是满足财务的核算, 就非常可能面临失败, 早期的国外ERP中一般会在各模块提供众多的系统分析报表系统,比如信息系统或专业的报表分析工具, 但是这些在线分析报表如果和业务分析处理系统处在同一服务器,则严重浪费资源,于是产生了所谓的DW数据仓库, 现在DW换了个新叫法BI(商业智能). 在一个大型集团,如果基础数据不全、管理不规范,核算不标准的情况下就实施BI,成功率将非常小.
一.什么是数据仓库(Data Warehouse)?
你可能得到很多关于数据仓库的定义,但我还是愿意引申”数据仓库之父”的William H. Inmon 在1991年 出版的“Building the Data Warehouse”一书中所提出的定义.
*http://www./home/ 是Inmon的个人主页,一看就知道是个喜欢折腾技术的人….
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的、用于支持管理决策的数据集合。
根据数据仓库的定义,它被描述成一个用来支持符合企业发展的管理决策的综合的解决方案.
为什么使用数据仓库(DW)?有这么些原因
(1).企业规模庞大.
(2).业务数据庞大.
(3).各分子公司系统异构.
(4).各种类型业务数据来源,数据需要汇总整合.
(5).ERP数据库性能原因,生产系统性能的降低.
(6) ERP.数据库通常不是为分析的目的设计的
ERP系统一般认为是OLTP系统,它不是专门为交叉主题分析报告而设计的.
交叉主题分析数据通常来自不同的模块,报表公式逻辑将负责且分散.
(7).性能为体,复杂的管理层决策报表可能需要从多个模块获得数据,这样的报表开发通常因为业务数据量过多而导致运行速度极慢,如果ABAPer在程序性能优化方面没有经验,甚至报表根本就无法得出,而且会严重消耗R/3资源.
(8).用户频繁变动需求原因,为了某种分析目的,用户要求报表经常增加几个新字段那是很正常的,不同用户甚至对于同一个报表的取数逻辑的理解不同是正常的,不同领导对相似报表要求的报表行项目可能是不同的,不同企业对同一业务在R/3的处理方式是不一致.
一个在线分析系统OLAP系统(你可认为DW系统也就是一个OLAP系统)应该有这么些系统:
(1).市场和销售分析（Marketing and Sales analysis）
(2).基于历史数据的营销（Database marketing）
(3).各种财务报告与合并报表（Financial reporting and consolidation）
(4).各类成本费用分析类的管理报告（Management reporting）
(5).利益率分析（Profitability analysis）
(6).质量分析（Quality analysis）
(7).存货分析(Inventory analysis)
......
一个大型ERP厂商应该能同时提供完善的在线分析系统又不影响在线交易系统性能.
集团企业都会寻找整合的高度集成的管理软件，而不是简单的反应式的零散的管理产品.
说到OLAP，就谈下OLTP，数据处理大致可以分成两大类：在线事务处理OLTP（on-line tranSAction processing,R/3可看成一个OLTP系统）、在线分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
摘自某网络的一段描述， 下表列出了OLTP与OLAP之间的比较。
|
|
OLTP
|
OLAP
|
|
用户
|
操作人员,低层管理人员
|
决策人员,高级管理人员
|
|
功能
|
日常操作处理
|
分析决策
|
|
DB 设计
|
面向应用
|
面向主题
|
|
数据
|
当前的, 最新的细节的, 二维的分立的
|
历史的, 聚集的, 多维的集成的, 统一的
|
|
存取
|
读/写数十条记录
|
读上百万条记录
|
|
工作单位
|
简单的事务
|
复杂的查询
|
|
用户数
|
上千个
|
上百个
|
|
DB 大小
|
100MB-GB
|
100GB-TB
|
OLAP产品和OLAP准则
最早的OLAP产品可以追溯到1970，但真正形成一个大的OLAP市场则是在90年代以后. 联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的，他同时提出了关于OLAP的12条准则，OLAP作为一类产品同联机事务处理 (OLTP) 明显区分开来。
Codd提出OLAP的12条准则来描述OLAP系统：
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成(目前BEx对中国式的格式报表显然不灵活)
准则12 不受限的维与聚集层次(受数据库限制一般DW提供13个自定义纬度).
DW&OLAP的关系
数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取
让我们回过头来结合某BW来理解数据仓库的这几个重要特征:
(1).面向主题(Subject_orient)
主题是一个针对一决策问题而设置的分析对象,比如一个销售利润分析,如果你在SAP中写过类似报表,你可能需要使用客户,物料,销售订单和客户发票等表,
加一些数据冗余。
(2).集成的数据(Integrated)
数据仓库中存贮的数据是从原来分散的各个子系统中提取出来的，但并不是原有数据的简单拷贝，而是经过统一、综合。其一，数据仓库的数据不能直接从原有数据库系统中得到。原有数据库系统记录的是每一项业务处理的流水帐，这些数据不适合于分析处理，在进入数据仓库之前必须经过综合、计算，抛弃分析处理不需要的数据项，增加一些可能涉及的外部数据,在BW中这些可以通过各种手段比如更新规则,传输规则实现.
其二，数据仓库每一个主题所对应的源数据在原分散数据库中有许多重复或不一致的地方，必须将这些数据转换成全局统一的定义，消除不一致和错误的地方，以保证数据的质量。
对源数据的集成是数据仓库建设中最关键，也是最复杂的一步。
(3).数据更新性
数据仓库的数据一般不可更新，最终用户只能通过分析工具进行查询、分析，一般不允许直接修改其中存贮的数据,管理员可定期删除归档一些历史数据
(4)数据随时间不断变化(Time_variant)
数据仓库中的数据随时间变化而定期地被更新，每隔一段固定的时间间隔后，运作数据库系统中产生的数据被抽取、转换以后集成到数据仓库中，可以采用完全和增量更新,可以根据需要自定义更新周期.
.一些常见BI术语(来自网络)
BI
商业智能（Business Intelligence），指数据仓库相关技术与应用的通称。指利用各种智能技术，来提升企业的商业竞争力。
Data mart
数据集市，或者叫做"小数据仓库"。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只是面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。
数据集市:是用来分析特定业务主题或功能目标的公司数据的专门项目的数据收集。这些数据是粒度化的,历史的,整体的,全体的.
数据集市面向部门级业务，并且只是面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。
自下而上，"Think Big,Start Small".
另一种解决数据库方案早期问题的方法是数据集市的发展
(1)独立的数据集市
一个独立的数据集市是建立使用一个中央的、企业级数据库作为数据来源的数据集市。
所特别建立的单独的数据集市是供单个的部门使用或者是为了满足面向专门项目的分析方案的需要，
但是大多数机构在其商务智能环境中愿意拥有多个数据集市。然而，不管在机构内有多少数据集市存在，
所有的数据集市的数据都来自EDW。
(2)非独立的数据集市
(3)作为数据库的数据集市
“数据集市是仓库”,在数据库团体中一种学院派的想法是数据仓库是由公司中的数据集市构成的。
用这种方式，公司建立数据集市，终端用户能够获取任何或者全部所需获得的数据来完成分析。
该理论认为，数据集市建立起来更简便快捷，一旦建立，就从数据集市中获取数据，而不用建立
和维护一个中央数据仓库。就像在数据仓库等技术领域大多数理论那样，这个概念有一些优点，
但是紧随其后的是显而易见的问题。
一个最重要的考虑是仍然打算确保在所有这些数据集市中获取的数据能被正确使用和整合。
在当今世界最艰巨的任务是方案的何去何从，以及执行官、经理、员工在商务和技术两方面何去何从等。
企业级数据仓库(EDW，Enterprise Data
Warehouse)，对于数据集市的定位也基本形成共识，那就是数据集市应该从属于企业级数据仓库。
所谓EDW，基本的要求是整个企业能够共享统一的数据存储模型，为各级业务人员提供一致的信息视图。
实施时可以先按照需求的轻重缓急选择部分业务主题，然后逐步扩展到涵盖全部业务。
BI要想大做小，从最迫切的业务入手。无论是上哪种管理软件，几乎都会听到同样的声音：不要贪大求全，从最迫切的业务入手，BI也不例外，它可以做成一个独立的庞大系统，把企业中所有的业务数据全部放在一个数据仓库里，进行多维分析；也可以将其嵌入到各项单独的业务数据中，进行单独的业务分析。咨询顾问的意见是先把最紧要的业务管理起来，以便迅速响应市场需求，做出最佳决策。积累了一定经验后，再逐渐增加BI系统继续对其他业务进行决策分析，这样可以在一定程度上规避风险，因为上BI也要进行流程的重整，
缺少数据分析师,这些数据将从何而来.Think Big , Start small.
但是我们根本都没有think . ROLAP
基于Codd的12条准则，各个软件开发厂家见仁见智，其中一个流派，认为可以沿用关系型数据库来存储多维数据，于是，基于稀疏矩阵表示方法的星型结构（star schema）就出现了。后来又演化出雪花结构。为了与多维数据库相区别，则把基于关系型数据库的OLAP称为Relational OLAP，简称ROLAP。代表产品有Informix Metacube、Microsoft SQL Server OLAP Services。
MOLAP
Arbor Software严格遵照Codd的定义，自行建立了多维数据库，来存放联机分析系统数据，开创了多维数据存储的先河，后来的很多家公司纷纷采用多维数据存储。被人们称为Muiltdimension OLAP，简称MOLAP，代表产品有Hyperion(原Arbor Software) Essbase、Showcase Strategy等。
1.ROLAP
ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。
2.MOLAP
MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。
3.HOLAP
由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。
Client OLAP
相对于Server OLAP而言。部分分析工具厂家建议把部分数据下载到本地，为用户提供本地的多维分析。代表产品有Brio Designer，Business Object。
DSS
决策支持系统（Decision Support System），相当于基于数据仓库的应用。决策支持就是在收集所有有关数据和信息，经过加工整理，来为企业决策管理层提供信息，为决策者的决策提供依据。
ETL
数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
Ad hoc query
即席查询，数据库应用最普遍的一种查询，利用数据仓库技术，可以让用户随时可以面对数据库，获取所希望的数据。
EIS
主管信息系统（Executive Information System），指为了满足无法专注于计算机技术的领导人员的信息查询需求，而特意制定的以简单的图形界面访问数据仓库的一种应用。
BPR
业务流程重整（Business Process Reengineering），指利用数据仓库技术，发现并纠正企业业务流程中的弊端的一项工作，数据仓库的重要作用之一。
Data Mining
数据挖掘，Data Mining是一种决策支持过程，它主要基于AI、机器学习、统计学等技术，高度自动化地分析企业原有的数据，做出归纳性的推理，从中挖掘出潜在的模式，预测客户的行为，帮助企业的决策者调整市场策略，减少风险，做出正确的决策
CRM
客户关系管理（Customer Relationship Management），数据仓库是以数据库技术为基础但又与传统的数据库应用有着本质区别的新技术，CRM就是基于数据仓库技术的一种新应用。但是，从商业运作的角度来讲，CRM其实应该算是一个古老的"应用"了。比如，酒店对客人信息的管理，如果某个客人是某酒店的老主顾，那么该酒店很自然地会知道这位客人的某些习惯和喜好，如是否喜欢靠路边，是否吸烟，是否喜欢大床，喜欢什么样的早餐，等等。当客人再次光临时，不用客人自己提出来，酒店就会提供客人所喜欢的房间和服务。这就是一种CRM。
Meta Data
元数据，关于数据仓库的数据，指在数据仓库建设过程中所产生的有关数据源定义，目标定义，转换规则等相关的关键数据。同时元数据还包含关于数据含义的商业信息，所有这些信息都应当妥善保存，并很好地管理。为数据仓库的发展和使用提供方便。
Data Mart, 数据集市
也被称为“小数据仓库”，DW的一个子集，主要面向部门级业务。例如在销售部门的应用时，可能不需要分析某个产品的原材料。分析地区税收时，不需要分析能源消耗情况。
OLAP, Online Analytical Processing, 联机分析处理
也称为多维分析。基于一个主题“立方体”，该“立方体”若干个维，例如时间维，区域维，产品维等。这些维又可以进行分层。例如时间维包含年、旬、月、周、天，甚至可以到小时这一层。在“立方体”中存储的事实值，某些值就是合计值了，在进行查询时，就不需要利用SQL将所有记录搜出来，再进行统计运算，这样就大大提高了最基本的查询能力了。同时，利用一些聚类算法等，还能发现一些“有意思的”结论，这就是DM/KDD（后面有讲）。
OLAP会有另起一篇来详细讨论，主题的选择，“立方体”的建立，维度设定，和DM怎样结合等都是需要好好思考的。
Ad-hoc Query, 即席查询
也就是基于前面OLAP中谈到的“立方体”，因为统计值直接保存在DW中，就能大大提高查询能力。快速的查询，也许就叫即席查询了，^_^！
....to be continued !
评论
常见的几种数据仓库建模
一.直接报表型(Direct Reporting)
将数据仓库看成是简单的报表集中器,结构简单,可多维分析.
二.独立数据集市部门级数据仓库(Data Mart)
认为数据仓库就是Data Mart的集合,按照业务主题建立数据集市,
跨业务主题分析不方便.
三.企业级数据仓库(EDW)
(1)Hub and Spoke(集线器与车轮状)结构.
(2)高度统一的企业级数据仓库结构.
这是目前比较流行的两种主流数据仓库建模体系,
一.集线器结构(Hub and Spoke)
•这种数据模型是建立一中央数据仓库然后根据报表需求分主题建立数据集市.
类似建立报表立方体,不能满足大型的灵活性的数据仓库.
二.统一的企业级数据仓库
EDW中包含一层根据3NF建立的数据清洗层,数据完整后可以根据报表需求建立数据集市或将中央数据仓库的数据复制到专门的在线分析的用于报表目的的信息立方体中.
关于统一的EDW有很多类似逻辑结构图,这是主流的数据仓库结构图.
缺点:
假设建立清洗ODS层,则庞大的清洗逻辑必须在BW中用ABAP编写更新规则.
层次太多不方便维护
自打实施驾驶舱,这篇文章我也看了好多遍了,但数据分析不是很好做的.......太多因素.
由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。
2. 前端展现工具(Presentation Service)：包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
3. 分析建模工具：为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
4. 数据存储工具：元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间. 业务数据则以ODS或InfoCube保存在数据仓库服务器.
MDC成立于1995年，是一个致力于建立与厂商无关的、不依赖于具体技术的企业元数据管理标准的非赢利技术联盟，该联盟有150多个会员，其中包括微软和IBM等著名软件厂商。1999年7月MDC接受了微软的建议，将OIM作为元数据标准。
OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用。它涉及了信息系统（从设计到发布）的各个阶段，通过对元数据类型的标准描述来达到工具和知识库之间的数据共享。OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述，并被组织成易于使用、易于扩展的多个主题范围（Subject Areas），这些主题范围包括：
分析与设计（Analysis and Design）：主要用于软件分析、设计和建模。该主题范围又进一步划分为：UML包（Package）、UML扩展包、通用元素（Generic Elements）包、公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等。
对象与组件（Object and? Component）：涉及面向对象开发技术的方方面面。该主题范围只包含组件描述建模（Component Description Modeling）包。
数据库与数据仓库（Database and Warehousing）：为数据库模式管理、复用和建立数据仓库提供元数据概念支持。该主题范围进一步划分为：关系数据库模式（Relational Database Schema）包、OLAP模式（OLAP Schema）包、数据转换（Data Transformations）包、面向记录的数据库模式（Record-Oriented Database Schema）包、XML模式（XML Schema）包和报表定义（Report Definitions）包等。
业务工程（Business? Engineering）：为企业运作提供一个蓝图。该主题范围进一步划分为：业务目标（Business Goal）包、组织元素（Organizational Elements）包、业务规则（Business Rules）包、商业流程（Business Processes）包等。
知识管理（Knowledge? Management）：涉及企业的信息结构。该主题范围进一步划分为：知识描述（Knowledge Descriptions）包和语义定义（Semantic Definitions）包。
上述主题范围中的包都是采用UML定义的，可以说UML语言是整个OIM标准的基础。虽然OIM标准并不是专门针对数据仓库的，但数据仓库是它的主要应用领域之一。目前市场上基于该标准的元数据管理工具已经比较成熟，例如微软的Repositry和CA的Repositry均采用了OIM标准。
OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：
(1) UML：它对CWM模型进行建模。
(2) MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。
(3) XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。
OMG元数据知识库体系结构如图3所示。
(1) CWM元模型（Metamodel）：描述数据仓库系统的模型；
(2) CWM XML：CWM元模型的XML表示；
(3) CWM DTD：DW/BI共享元数据的交换格式
(4) CWM IDL：DW/BI共享元数据的应用程序访问接口（API）
下面重点讨论CWM元模型的组成，它与OIM规范一样，也是由很多包组成的。组成CWM元模型的包结构如图4所示。
a) 核心（Core）包：它的类和关联是该模型的核心，其它所有的包都以它为基础。
b) 行为（Behavioral）包：包括描述CWM对象行为的类与关联，并且它为描述所定义的行为提供了基础。
c) 关系（Relationships）包：包括描述CWM对象之间关系的类与关联。
d) 实例（Instance）包：包括表示CWM分类器（Classfier）的类与关联。
(2) 基础包（Foundation）：它包括表示CWM概念和结构的模型元素，这些模型元素又可被其他CWM包所共享，它由以下六个子包组成：
a) 业务信息（Business Information）包：包括表示模型元素业务信息的类与关联。
b) 数据类型（Data Types）包：包括表示建模者可以用来创建所需数据类型的结构的类与关联。
c) 表达式（Expressions）包：包括表示表达式树的类与关联。
d) 关键字和索引（Keys and Indexes）包：包括表示键和索引的类与关联。
e) 软件发布（Software Deployment）包：包括软件如何在数据仓库中发布的类与关联。
f) 类型映射（Type Mapping）包：包括表示不同系统之间数据类型映射的类与关联。
(3) 资源包（Resource）：用于描述数据资源的包，它包括以下四个子包：
a) 关系（Relational）包：包括表示关系型数据资源的元数据的类与关联。
b) 记录（Record）包：包括表示记录型数据资源的元数据的类与关联。
c) 多维（Multidimensional）包：包括表示多维数据资源的元数据的类与关联。
d) XML包：包括表示XML数据资源的元数据的类与关联。
(4) 分析（Analysis）包：它由以下五个子包组成：
a) 转换（Transformation）包：包括表示数据抽取和转换工具的元数据的类与关联。
b) OLAP包：包括表示OLAP工具的元数据的类与关联。
c) 数据挖掘（Data Mining）包：包括表示数据挖掘工具的元数据的类与关联。
d) 信息可视化（Information Visualization）包：包括表示信息可视化工具的元数据的类与关联。
e) 业务术语（Business Nomenclature）包：包括表示分类业务的元数据的类与关联。
(5) 管理（Management）包：用于描述数据仓库管理的包，它包括以下两个子包：
a) 仓库过程（Warehouse Process）包：包括表示仓库过程的元数据的类与关联。
b) 仓库操作（Warehouse Operation）包：包括表示仓库操作结果的元数据的类与关联。
在数据抽取过程中，数据从各个业务系统中被统一转换存储到中央数据仓库中。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标准的工具已经相对成熟。
目前元数据的研究集中在：数据和数据库管理[11,12,13]、元数据模型[14,15,16]、数据集成[17,18]、元数据工具[19]。在各研究领域中都存在一些问题。
在数据仓库的研究课题当中，有许多是针对元数据的研究。文献〔5〕描述了一个在数据仓库环境中，基于微软的Repositry的、元数据驱动的数据转换方法，它包含了技术元数据与业务元数据；文献〔6〕中描述了一个基于元数据的数据仓库安全的解决方法，它只限定在技术元数据级别；更有名的一个研究项目是数据仓库质量项目（Data Warehouse Quality），这个项目的核心是通过元数据模型来衡量整个数据仓库中的数据质量。它是基于一个演绎数据库CONCEPTBASE的，并且使用该数据库特定的逻辑语言进行描述，目前该项目距离实用的阶段还比较远。
由以上几节我们了解到元数据几乎可以被称为是数据仓库乃至商业智能（BI）系统的“灵魂”，正是由于元数据在整个数据仓库生命周期中有着重要的地位，各个厂商的数据仓库解决方案都提到了关于对元数据的管理。但遗憾的是对于元数据的管理，各个解决方案都没有明确提出一个完整的管理模式；它们提供的仅仅是对特定的局部元数据的管理。
2. 前端展现工具(Presentation Service)：包括OLAP分析、报表和商业智能工具等，如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO，以及Brio等。它们通过把关系表映射成与业务相关的事实表和维表来支持多维业务视图，进而对数据仓库中的数据进行多维分析。这些工具都提供了业务元数据与技术元数据相对应的语义层。
3. 分析建模工具：为非技术人员准备的业务建模工具，这些工具可以提供更高层的与特定业务相关的语义。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。
4. 数据存储工具：元数据通常存储在专用的数据库中，该数据库就如同一个“黑盒子”，外部无法知道这些工具所用到和产生的元数据是如何存储的。还有一类被称为元数据知识库（Metadata Repository）的工具，它们独立于其它工具，为元数据提供一个集中的存储空间. 业务数据则以ODS或InfoCube保存在数据仓库服务器.
MDC成立于1995年，是一个致力于建立与厂商无关的、不依赖于具体技术的企业元数据管理标准的非赢利技术联盟，该联盟有150多个会员，其中包括微软和IBM等著名软件厂商。1999年7月MDC接受了微软的建议，将OIM作为元数据标准。
OIM的目的是通过公共的元数据信息来支持不同工具和系统之间数据的共享和重用。它涉及了信息系统（从设计到发布）的各个阶段，通过对元数据类型的标准描述来达到工具和知识库之间的数据共享。OIM所声明的元数据类型都采用统一建模语言UML（Universal Modeling Language）进行描述，并被组织成易于使用、易于扩展的多个主题范围（Subject Areas），这些主题范围包括：
分析与设计（Analysis and Design）：主要用于软件分析、设计和建模。该主题范围又进一步划分为：UML包（Package）、UML扩展包、通用元素（Generic Elements）包、公共数据类型（Common Data Types）包和实体关系建模（Entity Relationship Modeling）包等。
对象与组件（Object and? Component）：涉及面向对象开发技术的方方面面。该主题范围只包含组件描述建模（Component Description Modeling）包。
数据库与数据仓库（Database and Warehousing）：为数据库模式管理、复用和建立数据仓库提供元数据概念支持。该主题范围进一步划分为：关系数据库模式（Relational Database Schema）包、OLAP模式（OLAP Schema）包、数据转换（Data Transformations）包、面向记录的数据库模式（Record-Oriented Database Schema）包、XML模式（XML Schema）包和报表定义（Report Definitions）包等。
业务工程（Business? Engineering）：为企业运作提供一个蓝图。该主题范围进一步划分为：业务目标（Business Goal）包、组织元素（Organizational Elements）包、业务规则（Business Rules）包、商业流程（Business Processes）包等。
知识管理（Knowledge? Management）：涉及企业的信息结构。该主题范围进一步划分为：知识描述（Knowledge Descriptions）包和语义定义（Semantic Definitions）包。
上述主题范围中的包都是采用UML定义的，可以说UML语言是整个OIM标准的基础。虽然OIM标准并不是专门针对数据仓库的，但数据仓库是它的主要应用领域之一。目前市场上基于该标准的元数据管理工具已经比较成熟，例如微软的Repositry和CA的Repositry均采用了OIM标准。
OMG是一个拥有500多会员的国际标准化组织，著名的CORBA标准即出自该组织。公共仓库元模型（Common Warehouse Metamodel）的主要目的是在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换。2001年3月，OMG颁布了CWM 1.0标准。CWM模型既包括元数据存储，也包括元数据交换，它是基于以下三个工业标准制定的：
(1) UML：它对CWM模型进行建模。
(2) MOF（元对象设施）：它是OMG元模型和元数据的存储标准，提供在异构环境下对元数据知识库的访问接口。
(3) XMI（XML元数据交换）：它可以使元数据以XML文件流的方式进行交换。
OMG元数据知识库体系结构如图3所示。
(1) CWM元模型（Metamodel）：描述数据仓库系统的模型；
(2) CWM XML：CWM元模型的XML表示；
(3) CWM DTD：DW/BI共享元数据的交换格式
(4) CWM IDL：DW/BI共享元数据的应用程序访问接口（API）
下面重点讨论CWM元模型的组成，它与OIM规范一样，也是由很多包组成的。组成CWM元模型的包结构如图4所示。
a) 核心（Core）包：它的类和关联是该模型的核心，其它所有的包都以它为基础。
b) 行为（Behavioral）包：包括描述CWM对象行为的类与关联，并且它为描述所定义的行为提供了基础。
c) 关系（Relationships）包：包括描述CWM对象之间关系的类与关联。
d) 实例（Instance）包：包括表示CWM分类器（Classfier）的类与关联。
(2) 基础包（Foundation）：它包括表示CWM概念和结构的模型元素，这些模型元素又可被其他CWM包所共享，它由以下六个子包组成：
a) 业务信息（Business Information）包：包括表示模型元素业务信息的类与关联。
b) 数据类型（Data Types）包：包括表示建模者可以用来创建所需数据类型的结构的类与关联。
c) 表达式（Expressions）包：包括表示表达式树的类与关联。
d) 关键字和索引（Keys and Indexes）包：包括表示键和索引的类与关联。
e) 软件发布（Software Deployment）包：包括软件如何在数据仓库中发布的类与关联。
f) 类型映射（Type Mapping）包：包括表示不同系统之间数据类型映射的类与关联。
(3) 资源包（Resource）：用于描述数据资源的包，它包括以下四个子包：
a) 关系（Relational）包：包括表示关系型数据资源的元数据的类与关联。
b) 记录（Record）包：包括表示记录型数据资源的元数据的类与关联。
c) 多维（Multidimensional）包：包括表示多维数据资源的元数据的类与关联。
d) XML包：包括表示XML数据资源的元数据的类与关联。
(4) 分析（Analysis）包：它由以下五个子包组成：
a) 转换（Transformation）包：包括表示数据抽取和转换工具的元数据的类与关联。
b) OLAP包：包括表示OLAP工具的元数据的类与关联。
c) 数据挖掘（Data Mining）包：包括表示数据挖掘工具的元数据的类与关联。
d) 信息可视化（Information Visualization）包：包括表示信息可视化工具的元数据的类与关联。
e) 业务术语（Business Nomenclature）包：包括表示分类业务的元数据的类与关联。
(5) 管理（Management）包：用于描述数据仓库管理的包，它包括以下两个子包：
a) 仓库过程（Warehouse Process）包：包括表示仓库过程的元数据的类与关联。
b) 仓库操作（Warehouse Operation）包：包括表示仓库操作结果的元数据的类与关联。
在数据抽取过程中，数据从各个业务系统中被统一转换存储到中央数据仓库中。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标准的工具已经相对成熟。
目前元数据的研究集中在：数据和数据库管理[11,12,13]、元数据模型[14,15,16]、数据集成[17,18]、元数据工具[19]。在各研究领域中都存在一些问题。
在数据仓库的研究课题当中，有许多是针对元数据的研究。文献〔5〕描述了一个在数据仓库环境中，基于微软的Repositry的、元数据驱动的数据转换方法，它包含了技术元数据与业务元数据；文献〔6〕中描述了一个基于元数据的数据仓库安全的解决方法，它只限定在技术元数据级别；更有名的一个研究项目是数据仓库质量项目（Data Warehouse Quality），这个项目的核心是通过元数据模型来衡量整个数据仓库中的数据质量。它是基于一个演绎数据库CONCEPTBASE的，并且使用该数据库特定的逻辑语言进行描述，目前该项目距离实用的阶段还比较远。
简单介绍一下BI的大概设计思路及其它和ERP的关系,首先熟悉下面几个概念,如下图:
1.源系统(Source System)
数据源
常用的四种数据源类型:
1.业务数据类型,通过它传输R/3业务交易数据.
2.属特类型,特征属性就是特征的主数据.
3.文本类型,特征的文本.
4.特征的层次节点类型(目前BW版本层次只能使用Direct update).
ETL的设计
数据抽取工具的设计无意是件非常困难的事情.如何设计一个好的ETTL,Kimball老兄提供了如下一些经验:
Something ETL Designer must know:
Analysis
1. What is a logical data mapping and what does it mean to the ETL team?
2. What are the primary goals of the data discovery phase of the data warehouse project?
3. How is the system-of-record determined?
Architecture
4. What are the four basic Data Flow steps of an ETL process?
5. What are the permissible data structures for the data staging area? Briefly describe the pros
and cons of each.
6. When should data be set to disk for safekeeping during the ETL?
Extract
7. Describe techniques for extracting from heterogeneous data sources.
8. What is the best approach for handling ERP source data?
9. Explain the pros and cons of communicating with databases natively versus ODBC.
10. Describe three change data capture (CDC) practices and the pros and cons of each.
Data Quality
11. What are the four broad categories of data quality checks? Provide an implementation
technique for each.
12. At which stage of the ETL should data be profiled?
13. What are the essential deliverables of the data quality portion of ETL?
14. How can data quality be quantified in the data warehouse?
Building mappings
15. What are surrogate keys? Explain how the surrogate key pipeline works.
16. Why do dates require special treatment during the ETL process?
17. Explain the three basic delivery steps for conformed dimensions.
18. Name the three fundamental fact grains and describe an ETL approach for each.
19. How are bridge tables delivered to classify groups of dimension records associated to a single
fact?
20. How does late arriving data affect dimensions and facts? Share techniques for handling each.
Metadata
21. Describe the different types of ETL metadata and provide examples of each.
22. Share acceptable mechanisms for capturing operational metadata.
23. Offer techniques for sharing business and technical metadata.
Optimization/Operations
24. State the primary types of tables found in a data warehouse and the order which they must be
loaded to enforce referential integrity.
25. What are the characteristics of the four levels of the ETL support model?
26. What steps do you take to determine the bottleneck of a slow running ETL process?
27. Describe how to estimate the load time of a large ETL job.
Real Time ETL
28. Describe the architecture options for implementing real-time ETL.
29. Explain the different real-time approaches and how they can be applied in different business
scenarios.
30. Outline some challenges faced by real-time ETL and describe how to overcome them.
From <<ETL Toolkit>>--- Written By Kimball
转换和加载 (ETL, Extract, Transform, Load) 是构建数据仓库过程中最复杂也是至关重要的一个步骤，我们通常用两种办法来处理ETL流程: 一种是异步(Asynchronous) ETL方式, 也称为文本文件(Flat file)方式。另外一种是同步(Synchronous) ETL方式，也称为直接传输 (Direct transfer) 方式。根据项目的各自特点，合理选择恰当的数据抽取流程，确定抽取过程中的监督核查机制，对于DW项目的成功可以起到事半功倍的作用。
同步并不等于实时，ERP系统是一个7×24小时都有新数据插入的系统，如何解决同步呢？一种解决办法是设置一个时间区间，定义每次抽取的开始和结束时间值，数据抽取可采用增量抽取的方式，系统记录最近上一次的数据抽取时间。
DS层，一般大家都能够认同它是一种操作型比较强的、未保留历史或者保留近期历史的数据。所谓操作型，是相对分析型而言的。后者多是汇总的、便于分析统计的结构。操作型的另一个特点就是经常会被更新，而分析型数据很少如此。然而，对于ODS的认识，也有不同。
常见的争议包括： ODS是否应该被最终用户访问？ODS存在的目的是仅仅供DW层获取经过清洗的数据，还是能够让用户从中得到统计报表？关于前一个问题，在笔者以前做经营分析的时候，就曾遇到这样的争议；关于后一个问题，如果让它仅仅具备前一项功能，倒是结构清晰、易于管理，是一种好的设计风格，但恐怕不能满足用户灵活的需求。而如果可以让用户查询统计，可能造成它统计的数据和DW统计的数据不一致。
对于DW层，一般大家都会认同，这是保留历史数据的地方。但它是按照第三范式还是维度建模呢？当然，最大的不同就是：是需要一个中心DW，还是一个由若干数据集市组成的“虚拟”的DW。至于DM层，对此基本有一致的认同，这是面向最终用户分析统计的，采用维度建模再好不过。
可因为对DW层建模方法的不同观点，因此也就出来了所谓CDW的提法。想想，如果DW是按照第三范式建模，而DM是按照维度建模的话，那么它们之间该如何过渡？看上去，CDW确实也有存在的必要，在这个区域，需要形成满足总线架构所需的一致性维度（Confirmed Dimension）和一致性事实（Confirmed Fact）。
但问题是，第三范式和维度建模难道就真得水火不相容？笔者更相信一个道理—架构中没有绝对的设计原则。所谓第三范式，只是指出一种理想的ER（实体-关系模型）设计模式，但实际做设计时，设计师大多会去做一些平衡，他们也许会说，“为了性能、应用方便，会考虑适当的冗余。”可这适当冗余不也就破坏了第三范式吗？而且这个“适当”谁也说不准是多少。因此，可以理解EDW并不是绝对的第三范式，而所谓维度建模又能够和第三范式有多少冲突呢？在其本身概念里面，星型模式是一种不太符合第三范式的ER结构，但只是不“太”，如果改成雪花模式，是不是也就是第三范式了呢？