◆面向主题：操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。

◆集成的：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

◆相对稳定的：数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

◆反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

数据仓库是一个过程而不是一个项目。

数据仓库系统是一个信息提供平台，他从业务处理系统获得数据，主要以星型模型和雪花模型进行数据组织，并为用户提供各种手段从数据中获取信息和知识。

从功能结构化分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。
OLAP逻辑概念和典型操作
OLAP展现在用户面前的是一幅幅多维视图。
维（Dimension）：
是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。
维的成员（Member）：
维的一个取值，是数据项在某维中位置的描述。（“某年某月某日”是在时间维上位置的描述）。
度量（Measure）：
多维数组的取值。（2000年1月，上海，笔记本电脑，$100000）。
OLAP的基本多维分析操作有钻取（Drill-up和Drill-down）、切片（Slice）和切块（Dice）、以及旋转（Pivot）等。
钻取：
是改变维的层次，变换分析的粒度。它包括向下钻取（Drill-down）和向上钻取（Drill-up）/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而Drill-down则相反，它从汇总数据深入到细节数据进行观察或增加新维。
切片和切块：
是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个或以上，则是切块。
旋转：是变换维的方向，即在表格中重新安排维的放置（例如行列互换）

数据仓库与OLAP的关系是互补的，现代OLAP系统一般以数据仓库作为基础，即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。
OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。
1.ROLAP
ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube, rollup)等等。
2. MOLAP
MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（Physical OLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（Virtual OLAP）。
3. HOLAP
由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

所以经过讨论最终决定，不采用复制表的模式，而是采用数据字段冗余的方法来解决此问题，就是将Dim_A的表结构调整为：

对于问题1，一种方法是将dim_d再复制一份。原因是：复制后，虽然两表内容一样，但可以表示两种维度，正如你的dim_a中，虽然d_id_1和d_id_2的元素不可能超出dim_d,但它们可以理解为两个不同的维度。这样，你只要直接把基于这两个相同维表的实体拖到dim_a就可以了.

根据上面的原因，初步得出结论，就是只能在ETL的过程进行表的复制，就是说如果碰到问题中类似的问题，既在表A中的一条记录存在两个字段同时对应另一张表B的同一个字段的两条记录，需要将在ETL过程中将表B进行复制，并且内容完全一样。


以前的出现问题时的ETL过程图


进行了表复制后的ETL过程图

以上实例采用Informatica进行的演示。

Dear Mr. ×××

您好！ 

对于问题1，一种方法是将dim_d再复制一份。原因是：复制后，虽然两表内容一样，但可以表示两种维度，正如你的dim_a中，虽然d_id_1和d_id_2的元素不可能超出dim_d,但它们可以理解为两个不同的维度。这样，你只要直接把基于这两个相同维表的实体拖到dim_a就可以了.

 对于问题2,一种方法是直接将元数据库做迁移。关于元数据库和mstr项目的详细知识，你可以看一下mstr下的product manuel。

MicroStrategy Support Dept.

 您好：

   我们×××××××××的项目组，现在项目进行中遇到一些问题，具体如下：

 第一：

 我们目前的表结构为：

Dim_A

 Dim_D

 请问我该如何创建实体以及实体之间的关系，从而实现下面的表结果：

 第二：

在一台服务器上做完的项目如何移植到另一台服务器上？

谢谢！

要使 Oracle 10g 发行套件介质可以在服务器上使用，最简单的方法是将其直接下载到服务器。

使用图形登录以 oracle 身份登录。

创建一个目录以存放 Oracle 10g 发行套件：

				mkdir 10g_db
		

要从 OTN 下载 Oracle 数据库 10g，请将浏览器（Mozilla 比较好用）指向 http://www.oracle.com/technology/software/products/database/oracle10g/htdocs/linuxsoft.html。填写 Eligibility Export Restrictions 页面，并阅读 OTN 许可协议。如果您接受限制和许可协议，则单击 I Accept。

单击 ship.db.cpio.gz 链接，并将该文件保存在为此目的创建的目录 (10g_db) 中 — 如果尚未登录到 OTN，则此时可能提示您登录。

解压缩此文件：

				cd 10g_db
gunzip ship.db.cpio.gz
cpio -idmv < ship.db.cpio
		

安装软件

使用 oracle 帐户登录。

指定数据库名称 (ORACLE_SID)。该名称通常不多于五个字符。对此安装使用 demo1。

设置环境变量：

• Borne shell 和 Korn shell
  

  ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
  ORACLE_SID=demo1; export ORACLE_SID

• C shell
  

  setenv ORACLE_BASE /u01/app/oracle
  setenv ORACLE_SID demo1

例如：
$ cd $HOME/10g_db

将目录更改为 Disk1。

例如：
$ cd Disk1

启动 Oracle 通用安装程序。

$ ./runInstaller

1. 欢迎
   • 单击 Next。
2. 指定清单目录和证书
   • 如果您一直在依循本指南中的步骤，则使用默认值即可。否则，编辑清单目录的路径，以指向正确目录。
   • 操作系统组名称应为 oinstall。
3. 如果这是首次在此机器上安装 Oracle，则您将收到一个弹出窗口，提示需要以 root 用户身份运行 orainstRoot.sh 脚本。以 root 用户身份登录，更改到窗口中指定的目录，执行该脚本，然后继续操作。
4. 指定文件位置
   • 如果您一直在依循本指南中的步骤，则使用默认值即可。否则，在继续操作前确保源路径和目标路径正确。
5. 选择安装类型
   • 接受默认值 Enterprise Edition。
6. 与特定产品相关的先决条件的检查
   • 如果您一直在依循本指南中的步骤，则所有检查都应顺利通过。如果一个或多个检查失败，则在继续操作前纠正该问题。
7. 选择数据库配置
   • 接受默认值 Create a starter database 和 General Purpose。
8. 指定数据库配置选项
   • 输入数据库的全局数据库名称。该名称应包含 ORACLE_SID 和服务器域名（例如，demo1.orademo.org，其中 demo1 是 ORACLE_SID，orademo.org 是域名）。
   • 输入全局数据库名称时，SID 框将自动填充。
   • 接受默认的数据库字符集。
   • 选择 Create database with sample schemas。
9. 选择数据库管理选项
   • 选择 Use Database Control for Database Management。
10. 指定数据库文件存储选项
    • 选择 File System，然后输入数据库文件要使用的路径名（在本例中为 /u02/oradata）。
11. 指定备份和恢复选项
    • 选择 Do not enable Automated backups。
12. 指定数据库模式口令
    • 选择 Use the same password for all the accounts。
    • 选择一个口令，然后输入两次进行确认。
13. 摘要
    • 显示已安装产品的摘要。
    • 单击 Install。
14. 安装
    • 此屏幕历经安装和链接 Oracle 软件的几个阶段。
    • 安装过程结束时弹出一个窗口显示配置信息。记下 Enterprise Manager URL，然后单击 OK 关闭该窗口。
    • 弹出一个“Setup Privileges”窗口，提示需要以 root 用户身份运行配置脚本。以 root 用户身份登录，切换到该窗口中指示的目录，然后执行 root.sh 脚本。该脚本提示输入本地 bin 目录的位置。按 Enter 键接受默认值。当脚本完成时，返回到 Setup Privileges 窗口并单击 OK。（如下所示。）
15. 安装结束
    • 记下摘要中显示的 URL，并在准备好时单击 Exit。
16. 恭喜！您的新 Oracle 10g 数据库已经启动并可以使用。

  下列 10 个问题给出了 BO 和 MicroStrategy 之间的一些非常有针对性的比较。

1、 MicroStrategy Web 的全部功能：格式化，过滤，度量创建，报表创建和钻取都是基于零下载的 Web 环境。 BO 提供了相同的零下载的环境吗？

BO XI 没有提供报表创建，度量创建，报表格式化或者报表筛选的零下载环境。要启用此功能， WebIntelligence 用户必须下载 Java Applet 或者 ActiveX 控件。 BO 通过 HTML 报表面板提供了简单的基于 HTML 的格式化和报表创建。但是，度量创建，钻取，高级筛选，高级格式化，高级排序，拖拽方式等特性还必须依赖于下载 Applet 以及控件。即使是使用了下载的 Applet ， Crystal 报表也不能在 Web 上进行修改。

更严重的下载问题在于客户不能部署在企业外网上。基于互联网的下载不仅慢，而且受到浏览器和 Java 虚拟机的限制。在某些安全性要求高的环境中，比如金融机构，政府机关，互联网下载是严格被禁止的。

2、 MicroStrategy 只有一个统一的报表查看器。 BO 有 10 个，且各个查看器的功能各不相同： ActiveX Crystal Viewer ， DHTML Crystal Viewer ， Advanced DHTML Crystal Viewer ， Java Viewer ， Java Report Panel ， HTML Report Panel ， HTML Query Panel ， ActiveX OLAPIntelligence Viewer 以及 DHTML OLAPIntelligence Viewer

BO 有 10 个不同的查看器，每个查看器功能均不相同。最终用户将不得不学习使用 10 种不同的查看器。比如，如果用户想访问 OLAP 源，例如 SAP BW ，那么需要学习使用 BO ActiveX OLAPIntelligence Viewer ；如果需要访问关系型数据库，那么需要学习 BO Java Report Panel 。

一个统一的界面对于用户是非常重要的。如果用户不清楚该使用哪种查看器或者如何执行某一种任务，那么这时候软件将会很快被弃用。而且， BO 在 Web 方式下使用起来太困难。

3、 MicroStrategy 在一台 4CPU 的 Windows NT Server 上能够支持 400 个并发用户。 BO 支持多少个并发用户？

根据目前的扩展性测试， BO 在 64 位的 Unix 机器上每颗 CPU 大约支持 25 个并发用户。因此， 1 个 4CPU 的服务器最大支持 100 个用户。 BO 非常低的用户扩展性的原因在于没有中间服务器处理报表流程。而是直接基于 CORBA 架构在 Web 服务器上处理全部的报表操作。

不论 64 位 Unix 处理器的处理能力如何， BO 用户扩展性大约只相当于 MicroStrategy 在 32 位 Windows 平台扩展能力的一半。低用户扩展性导致了硬件成本的极大增加。

4、 MicroStrategy 的平均部署用户数为 750 。而 BO 只有 406 。为什么 BO 的坐席数大约只相当于 MicroStrategy 的一半？

这些数字来自于独立的调查机构 OLAP Report 对大约 1000 个客户的调查。对单独一个客户来讲，可能有一些特殊的组织或环境因素限制坐席数。但是对于如此多的客户调查，应当消除了这些问题的影响。 BO 不能部署同 MicroStrategy 一样多的坐席数的原因还在于技术因素。

如果 BO 最多支持几百个用户，那么就不能将商务智能扩展到整个企业。

5、 MicroStrategy 的数据库规模中位数为 250GB 。而 BO 为 15GB 。为什么 BO 客户的分析不超过 15GB ？

这些数字来自于独立的调查机构 OLAP Report 对大约 1000 个客户的调查。对单独一个客户来讲，可能有一些特殊的组织或环境因素限制坐席数。但是对于如此多的客户调查，应当消除了这些问题的影响。 BO 不能部署同 MicroStrategy 一样多的坐席数的原因还在于技术因素。

尽管报表使用的数据大多数为汇总数据，但是调查显示的差异表明管理人员需要访问明细数据。而报表与分析工具必须能够支持从汇总数据到明细数据的无缝访问。

6、 为什么有超过 27% 的 BO 用户会遇到严重的性能问题？

这些数字来自于独立的调查机构 OLAP Report 对大约 1000 个客户的调查。对单独一个客户来讲，可能有一些特殊的组织或环境因素限制坐席数。但是对于如此多的客户调查，应当消除了这些问题的影响。 BO 不能部署同 MicroStrategy 一样多的坐席数的原因还在于技术因素。

即使 MicroStrategy 客户的数据量 10 倍于 BO ，用户量两倍于 BO ，也只有 16% 的 MicroStrategy 客户会遇到性能问题。这个数字与 Cognos 相比甚至更低。

7、 MicroStrategy 允许在 Desktop 中创建的报表在 Web 下修改，反之亦可，只要用户具有相应的权限。 WebIntelligence 用户能够修改 BO 或 Crystal 创建的报表吗？

BO 用户在试图使用其它 BO 工具创建的报表时，至少有 4 种情况会出现问题：

a.       由于非集成的架构， WebIntelligence 用户不能修改，钻取或者导出 BO 创建的报表。这需要单独的许可证。

b.       不同版本的报表存在不兼容问题。比如新版本的 WebIntelligence 不兼容老版本（ v2.x ）的 WebIntelligence

c.       另外，使用 Java Report Editor 创建的，具有多个报表页签或者信息块的文档不能在 HTML Report Editor 中编辑。

d.       Crystal 创建的报表不能通过 Web 方式编辑。

集成性问题的影响在于最终用户如果想要对标准报表做稍许改动都必须请求 IT 部门帮助，使得 IT 部门成为维护和修改已有报表的瓶颈。

8、 MicroStrategy 根据用户请求通过 MicroStrategy Web 或 Desktop ，只传输报表的当前视图。而且， MicroStrategy 在 Web 服务器不存储数据。 BO 如何处理数据传输？

BO 需要下载整个微立方体到 BO 客户端。这意味着从数据库到用户客户端的大数据集传输。这严重影响了网络带宽，以及客户端的内存等资源。另外，由于 BO 客户端没有缓存，所以必须为不同用户创建不同立方体在网络上进行传输。而且，对于 WebIntelligence 用户而言，微立方体，可能包含有敏感数据必须存储在 Web 服务器上。

9、 MicroStrategy 有集中的安全资料库。通过此资料库，管理员控制用户权限，数据安全性以及对象安全性。当有新的数据表添加到数据仓库时，可以自动应用此安全性。 BO 如何解决这样的数据级安全性？语义层元数据安全性与 Business View 的元数据安全性区别是什么？

对于数据仓库包含的每一个表而言， BO 都需要在语义层中手工的为一个用户定义数据访问权限。也就是说必须为每一个用户在表一级插入一个 Where

子句。而对于 Crystal 产品线的 Business Views 而言，管理员必须重新设置其安全性。这在用户量增大时，导致了极大的成本增加。

安全性是一个基本的 IT 服务，应当在企业级 BI 平台上集中管理。多个不同位置间安全性的设置与同步极有可能出现安全性错误，从而导致安全性漏洞。 MicroStrategy 提供了企业级的安全设置，可以集中式管理，减少了维护成本。

10、              MicroStrategy Intelligence Server 是一个统一的多线程服务器。而 BO XI 有 11 个服务器： Central Management Server ， File Repository Server ， Event Server ， Report Job Server ， Program Job Server ， WebIntelligence Job Server ， WebIntelligence Report Server ， Report Application Server ， Destination Job Server ， List of Values Job Server 以及 Page Server 。这些服务器有多少是 6.5 版本以前没有的？

BO XI 是一些新服务器的集合。每个服务器都要消耗内存和硬件资源。每个服务器同样也是潜在的出错点。就算每个服务器的可靠性为 99% ，那么整个 BO XI 的可靠性也仅为 90% （ 0.99^11 ）。

MicroStrategy Intelligence Server 是一个统一的服务器，它通过端到端的群集机制来保证高可靠性。

　　数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

　　数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

　　数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

　　单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

　　显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

　　数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

　　“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

　　“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

　　“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。

　　数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

　　补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

　　1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

　　2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

　　3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。