BIEE入门 超级好的文档.docx

BIEE入门 超级好的文档.docx

《BIEE入门 超级好的文档.docx》由会员分享，可在线阅读，更多相关《BIEE入门 超级好的文档.docx（36页珍藏版）》请在冰豆网上搜索。

BIEE入门超级好的文档

BIEE项目迁移部署

ü        在目标服务器上安装OracleBIEE并备份Repository、Catalog及XMLPublisher报表；

ü        Repository存放在~/OracleBI/server/Repository文件目录下，复制.rpd文件；

ü        Catalog存放在~/OracleBIData/web/catalog，复制root文件夹；

ü        Publisher报表存放在~/OracleBI/xmlp/XMLP/Reports文件目录下,复制Reports文件夹

ü        迁移过程：

先停所有BIEEServer，将备份的文件复制到相应的BIEE安装目录；

ü        修改配置文件中的参数。

ü        完成后启动BIEE服务，如果不发生报错即迁移成功

BIEE入门篇之一BIEE的安装

最早拿到的安装文件的时候，其实是Siebel7.8，安装界面如下：

安装也比较麻烦，安装了Siebel之后，还需要安装tomcat，当然没装jdk，那还得首先装jdk才行。

由于不是免费产品，所以在安装前需要获得一个授权文件，这个文件一般不掏钱是拿不到的。

登录界面如下：

当时觉得Siebel不愧是CRM领域的专家，其产品在可用性上做的还是不错，起码效果很足，可以在Web界面上随意的托拽，图形、曲线、图表功能强大，界面美观。

   后来拿到的是Oracle经过初步整合的产品，正式名字叫OracleBIEE（Oracle商务智能企业版），安装文件可以在Oracle网站上下载到，Windows下的安装文件名是biee_windows_x86_101330_disk1.zip，大小约1.3GB。

   解压后，会有三个文件夹，如下图：

其中Client_Ancillary文件夹中有BriefingBookReader（BIEE提供报表快照的保存，快照文件使用该Reader工具来打开）和开放接口的安装文件。

Server文件夹中是BIEE的主体服务器的安装文件。

而Server_Ancillary是BIEE配套的桌面组件BIOFFICE和BIPublisher，可以用来进行桌面办公协同和生成高级报表。

   直接进入Windows/Server/Oracle_Business_Intelligence，点击运行setup.exe文件进行安装。

点击Next，进入下一步，设置安装路径，尽量避免中文路径和目录名称中出现特殊字符，安装类型，如果仅是自己研究，一般选择Basic，使用该种类型的安装，BIEE的WebServer将有OracleOc4j组件来提供，如果选择高级类型，则需要前置安装OracleAS10g。

选择后，点击Next进入下一步，选择安装方式，自己研究则选择默认的Complete即可。

其后，进入下一步，需要安装JDK并指定Java_Home，如果未安装JDK，此时可先去下载JDK，安装JDK，并设定Java_Home环境变量。

我在这里使用的是JDK6.0。

Java环境设置完成后，再回到BIEE安装界面，继续设置oc4jadmin的密码，使用该密码可登录到Oc4j的管理界面，执行对Oc4j服务器的管理工作。

继续上面的安装后，进入下一步，则需要设置当前系统的用户的密码，在这里输入登录Windows的密码即可。

如果仅是个人研究，可在该界面下方，将服务类型均改为手动，否则每次在开机时都会启动BIEE服务，相当的慢。

继续Next后，设定安装语言为简体中文。

点击Next进入程序安装过程，首先安装程序如果检测到使用的系统中未安装.netFramework2.0的话，会先安装微软的.netFramework2.0组件。

终于看到了BIEE的安装进度条了！

在这里要注意一点，BIEE的安装进度条显示有问题，很快就会达到100%，但是后面的安装动作会持续接近20分钟，在此期间，偶尔会看到界面上有安装文件的提示，其他时间你只能看到你的硬盘灯在不停闪烁，耐心等待即可。

直到出现下面的界面，则安装过程就算是告一段落了。

安装结束后，首先修改一下注册表，将启动加载位置上的OC4J删除，否则每次启动机器的时候，虽然前面已经将服务置为手动，但是OC4J仍旧会加载。

安装结束的时候，会提示需要重启Windows。

按照提示重启后，可以试验一下BIEE是否能够正常使用。

首先到“服务”，启动OracleBIServer、OracleBIPresentationServer、OracleBIJavaHost三个服务。

然后，使用开始菜单项中的“StartOC4J”

待Oc4j启动完成后，再点击“WelcometoOracleBIEE”，在打开的浏览器页面中点击“OracleBIInteractiveDashboards”。

在打开的新的浏览器窗口中，会出现BIEE的登录界面，其界面风格已经与OracleEBSR12的很相似。

在安装好后，BIEE自带有一个demo，使用Administrator登录，默认的初始密码是空或者Administrator，记不清了，自己试一下：

）。

注意区分大小写！

该demo的数据源使用的xml文件数据库，展示效果就不切图了，如果想看的话，自己下一个装起来就看到，呵呵，留点念想吧！

：

BIEE入门篇之二BIEE的迁移部署

在这里讲一下BIEE的部署。

BIEE的数据库层管理和逻辑建模均是在rpd文件中进行管理，如下图所示：

rpd文件存放在$ORACLE_BI_HOME/server/Repository路径下。

具体的rpd文件名指向则由$ORACLE_BI_HOME/server/Config/NQSConfig.INI中进行指定。

如下图：

迁移时只需要将原BIEE系统中的rpd文件拷贝到新的biee系统下，然后修改新系统中的NQSConfig.INI指向新的rpd文件即可。

另，还需要调整rpd文件中数据库连接池的数据源名称，如果是使用Oracle数据库的话，则Datasource处填写Oracle的服务名。

BIEE的web展现层组件，存放在$ORACLE_BI_DATA/web/catalog目录下，依据主题区域的名称分文件夹存放，如下图：

则在迁移时需要将rpd文件中主题对应的webcatalog拷贝到新系统中的相应目录下，主题如下图所示的文件夹：

完成catalog的拷贝后，还需要修改$ORACLE_BI_DATA/web/config/instanceconfig.xml中的catalog指向，

另外，如果有其他的开发，比如custommessage、回写等设置，则也需要将相应目录下的文件拷贝到新系统中，并调整相应的设置。

做为进一步的知识点，在此初级技术的介绍文章中不做赘述.

BIEE入门篇之三了解BIEE的开始菜单

BIEE安装完成后在，开始菜单中各项如下图所示：

第一项：

Administration该条目启动的即是BIEEAdminTool，运行后如下图：

其中黄色文件夹可打开offline的rpd文件，只能打开Windows本地的rpd文件。

蓝色文件夹可打开online的rpd文件，可以打开远程服务器上的rpd文件。

首先配置ODBC数据源，选择驱动类型为OracleBIServer，如下图：

再设置DSN，设置指向的BIServer。

再点击Next，直到完成。

完成后，打开Administration工具，选择打开online，则出现新配置的DSN，选择新的DSN，输入用户名密码，即可打开，如下图：

具体的AdminTool的使用，将在后续的开发教程中进行详细讲解。

第二项：

AdministrationHelpFile该条目启动AdminTool的说明文档，是英文的，但是说明的非常详细，是第一手的参考资料，建议有时间仔细阅读相关内容。

第三项：

CatalogManager管理Catalog的工具，可以打开online或offline的catalog目录，并可以直接修改其中的xml文件的内容。

详细的内容需要在高级开发部分掌握，初级学习阶段，一般不使用该工具。

第四项：

JobManager使用该工具，可执行BIEE的执行计划。

具体的配置请参考OracleBusinessIntelligenceSchedulerGuide文档。

首先在启动JobManager后，打开File>ShcedulerConfiguration进行设置，如下图所示：

再运行$ORACLE_BI_HOME/server/Schema/SAJOBS.Oracle.sql在数据库中建立Job相关的数据库对象。

在这里我使用的是Oracle数据库，如使用的是其他类型的数据库，则运行相应标识的脚本。

然后启动OracleBIScheduler服务。

启动服务后，运行JobManager，打开File>OpenSchedulerConnection,设置后，点击OK，则可以配置已连接上的BIEE服务的Schedule的设置，在其中添加相应的job，可执行相应类型的脚本，如下图：

如果启动Scheduler服务失败，则可以查看$ORACLE_BI_HOME/server/Log/NQScheduler.log文件，依据错误提示，调整系统设置。

第五项：

ODBCClient连接方法如下图：

最常用的是使用Utility>EnterSQLQuery工具，该工具可以直接运行BIEE形式的高级SQL，用来直接调试、修改catalog的查询。

菜单中其余三项没什么可以详细解说的了，点点就知道了：

）

BIEE入门

（一）架构

BychuliangonJanuary24,20089:

57PM|Permalink|Comments

（2）|TrackBacks（0）

BIEE作为Oracle的新的商业智能平台企业版，起源于Oracle所收购的Siebel公司，BIEE原来叫做SiebelAnalytic，但是Siebel也不是它的发明者，它是Siebel在2001年收购的另一个公司叫nQuiresoftware的产品，这个从它的配置文件的名称就可以看出来（NQSConfig，还一直保留着nQuiresoftware的痕迹）。

但是这个产品无论是在Siebel还是在Oracle都得到了发扬光大，我的理解是，也许它不一定是最好的BI工具，但是却是一个非常有创造力的工具，它对于物理层，逻辑层，展现层的理解和定义创造了一个非常简洁而清晰的数据模型，使用这个数据模型可以完整地连接企业内各个异构数据源和前台的业务使用人员，使商业智能真正能够在企业范围内得到大规模部署和使用：

就是报表的“开发”以一种非常容易的方式交还给业务人员，他们就可以随时产生自己所需要的智能数据报表，而不是把需求再提交给开发人员，而开发人员，在定义好了商业智能的元数据之后，就可以避免对业务人员的连续不断的需求疲于应付了！

请注意，这个并不是广告语，如果你真正理解了BIEE的架构和部署，你也会有相同的感觉的，所以，觉得BIEE前台报表开发过于简单的人也许并不理解这才是BIEE的真正优势！

BIEEarchitecture （BIEE架构）

BIEE的架构非常简单，如下图：

窗体顶端

目录资料库

窗体底端

窗体顶端

窗体底端

窗体顶端

窗体底端

我觉得这这个架构里，最重要的最核心的应该是BIServer和由BIServer所操作的Repository。

一般的数据仓库或者商业智能关心的一个核心问题是特定领域的分析数据模型的建模，这个建模的过程在BIEE里主要是通过BIadmintool来进行，而整个建模的成果则是称之为repository的一个文件。

BIadmintool是一个图形工具，主要用于建立和维护repository，BIEE的repository相当于BIEE的元数据层，而且从很多信息来看很可能将会被作为未来Oracle的商业智能解决方案的中心元数据层，在Repository里主要包含了：

∙数据源的定义

∙多维数据模型的定义

∙业务展现层的定义

而整个元数据的定义可以清楚地看到数据如何从源头被一步一步地转换最终以业务人员能够理解的方式方式展现给最终用户，BIEE的repository设计得非常简洁和合理，分别对应于以上的大三个部分分为三个层次的定义：

∙物理层：

对应于数据源的定义，可以建立多个不同系统的数据源，比如一个数据源时essbase，一个数据源是Oracle数据库，而另一个数据源时DB2。

∙逻辑层：

从多个物理数据源里抽象出来的多维数据模型，主要为了业务需求服务，一般是一个星型模型或雪花模型，在逻辑层可以从多个物理数据源形成一个统一的单个多维模型。

∙表现层：

把多维模型以业务的术语展现给最终报表建立的用户，从展现层的定义中我们不难发现，其实BIEE的开发主要集中于元数据层的开发，而最终报表和展现甚至可以让最终的业务用户自己来完成，这个也说明了BIEE的展现层开发是相当容易的！

BIServer（BI服务器）

由admintool建立的Repository最终由BIServer来使用，BIServer运行的时候会打开Repository文件，分析服务通过配置文件NQSConfig.ini中的

Star=RPD文件名

文件名来找到该数据模型定义文件。

物理层和数据源

作为一个BI服务器，BIEE的BIServer和传统意义上的Essbase或OracleOLAP的地位并不相同，最大的差别是无论是Essbase或者是OracleOLAP，本身都包含了数据的建模，存储，处理等服务，但是BIEEBIServer本身却并不存储数据，而只是“指向数据”，用户的分析请求会自动的由分析服务组织成合适的SQL发送到定义在物理层的数据源，由数据源执行，当然BIServer本身还可以对多个数据源返回的结果重新组织和“装配”，最后把组织装配后的结果返回展现层。

作为源数据的提供者可以是普通数据库数据，关系型数据，OLAP服务，文本文件，excel文件，XML文件或者符合XMLA规范的数据源等等，当在物理模型里定义多个和多种类型的数据源的时候，数据源的多样性完全可以由逻辑层进行掩藏，从而最终的商业智能报表开发者或者使用者可以完全不知道最终的信息来源于多种不同的系统。

当从关系数据库来导入数据模型的时候，一般而言事实表和维度表之间都存在着主外键的关系，在BIEE里创建物理层的时候可以通过导入的方式来把这些事实表和维度表之间的关系直接导入到物理层里，这样BIEE就可以在创建逻层的时候自动地认识到哪些是事实表，哪些是维度。

但是维度的层次关系一般而言还是需要自己去定义；而从Essbase或者OracleOLAP导入数据模型的时候就要容易一些，因为导入会把维度的层次关系直接从Essbase里抓出来，就不需要额外去建立维度的层次关系就可以直接使用Essbase里的设计了！

BI PresentationService（BI展现层服务）

BIEE的BI展现层是Web服务器的一个扩展模块，就如Siebel应用里的SWSE一样，BI展现层接收BI服务器的数据然后把把数据组织称HTML或者图表展现给最终用户，BI展现层也需要操作一个文件（catalog文件，以.webcat结尾），这个文件存储了用户通过管理界面定义的应用的dashboard，通过BIAnwsers定义出来的各种报表，以及这些仪表盘，报表和用户或者组的权限对应关系。

BIEE入门

（二）物理层的定义

BychuliangonJanuary25,20088:

54PM|Permalink|Comments（0）|TrackBacks（0）

使用BIEE的第一步是使用admintool去建立一个多维数据模型，而建立多维数据模型的第一步则是建立物理层，请注意因为BIEE本身并不存储数据，所以所谓BIEE物理层的意义是需要在BIEE里建立各个源系统的描述：

∙如源系统的类型（各种关系数据库或各种多维数据库）

∙源系统的连接方式（指定所对应的源系统的连接信息，如用户名，密码，端口等）

∙以及导入源系统的数据的定义（源系统里表的结构，主外键关系等）

定义物理层的方式是从file-》import。

。

。

-》fromdatabase然后通过向导选择正确的数据库类型并输入连接信息。

在最简单的时候，这样就可以完成整个物理层的定义了，接着可以继续进行逻辑层的定义工作，但是其实物理层还是有一些额外的配置值得交代。

物理层的额外配置

数据源

额外的物理层配置的第一个地方就是关于数据源的属性，因为BIEE被设计用于连接各种各样的数据源，而每个数据源的特性都是不一样的，比如哪怕同样是关系数据库，Oracle和DB2的很多特性就不一样，为了能够充分发挥一个特定的数据源的能力，BIEE的物理层数据源里允许人为配置数据源所支持的各种额外特性，如下图：

窗体顶端

窗体底端

通过这样的配置，BIServer将可以充分使用不同数据源的各种能力，生产数据源所支持的特性的SQL来提高处理效率，但是对于配置这些属性还是要小心，因为如果配置了数据源不能支持的属性，则在针对该数据源查询的时候将会返回错误！

连接池

物理层第二个需要说明的是：

在import的时候，源系统的大部分数据结构和主外键信息都会自动地输入到Repository里，而物理层通过一个连接池的定义来和源系统连接，BIServer使用连接池的定义和源系统进行连接，这个“连接池”和一般的应用服务器的连接池定义有相似之处，除了同样可以：

∙定义最大连接数

∙连接idle时间

∙交易隔离类型（如脏读，序列化等）

还有一个有意思的地方是，可以定义连接数据源所需要执行的额外脚本，或者在执行查询之前和查询之后都可以定义需要额外执行的SQL语句，如下图（点击查看大图）：

窗体顶端

窗体底端

这样就可以在每次查询之前或之后去执行一些特定的SQL语句，从而提供了更多的可能性。

物理层的表

物理层的第三个需要说明的地方是关于物理层表的定义：

物理层表的定义对应着数据源的真正的表，除了可以把源系统的表的各种定义属性导入到物理层，BIEE也提供了在物理层定义源系统所不存在的各种关系的重新定义，如定义源系统所不存在的主外键关系来为星型模型做准备，还有一个特性是直接和BIServer的缓冲区直接相关，就是BIServer可以定义缓冲区，当第一次查询的时候数据可以缓冲中BIServer的缓冲区里，第二次查询将不再把查询发到数据源，而是可以直接使用缓冲区的数据，这样将能够有效地减少对于数据源的查询压力和提高查询性能，特别是对一些更新没这么快的数据源而言是一个非常好的选择，如下图：

窗体顶端

窗体底端

从这里你可以看到，其实BIEE的设计有很多地方还是非常好的！

另外，也可以定义一个表使用SQL或者存储过程来生成，而不一定非要是一个实际存在的物理表。

最后需要对物理层进行说明的是关于表和表之间的关系：

 我们都知道为了构建星型模型，在事实表和维表之间存在主外键关系是必要的，所以首先需要检查我们需要分析的源系统里的维表是否有主键（如果没有可以在物理层里定义），然后还要通过物理关系图定义他们之间的外键关系来构建一个星型模型，如下图：

窗体顶端

窗体底端

这个定义主要是通过一个类似画板的东西上进行划线来形成，这样就完成了物理层的定义。

Categories:

∙BIEEplus

Tags:

∙BIServer,

∙BIEE,

∙Physicallayer,

∙Repository

分类：

BIEE加

标签：

BI服务器，

BIEE，

物理层，

知识库

BIEE入门（三）业务模型层

BychuliangonJanuary26,200810:

09PM|Permalink|Comments（0）|TrackBacks（0）

正如它的名字所示（BusinessModelandMappingLayer），业务逻辑层需要把物理层的数据源以一种业务用户的视角来重新组织物理层的各个数据源（所谓的Mapping），同时在业务逻辑层里，我们将需要真正构建数据仓库里的星型模型，包括：

∙事实表

∙维表

∙维表的层次结构（hierarchy）

∙事实表度量（measure）

来提供一个模型供展现层使用，所以在业务逻辑层，用户需要同时具有技术的知识（数据仓库星型模型），又需要有业务的视角（构建一个对于业务而言有意义的星型模型）。

我们先来看看业务模型层和它所对应的物理层的一个比较：

窗体顶端

窗体底端

窗体顶端

窗体底端

窗体顶端

窗体底端

窗体顶端

窗体底端

业务逻辑层的一个关键的定义是：

Captureshowusersthinkabouttheirbusinessusingtheirownvocabulary

需要注意的是，虽然业务模型层同样都是来源于物理层的表和列，但是业务模型层更加强调以业务的观点来看所有的数据。

其中Mapping一词意味著用户需要匹配业务模型层的数据和物理层的数据，一个从业务逻辑层看起来的一个逻辑表，其数据来源可以是由物理层的多个数据源组成；而同样的，一个业务模型层的一列数据，也可以被匹配成物理层不同数据源的多列数据组合而成：

比如假设我们在物理层有三个不同的子系统分别对应不同的地区（华北，华南，华东），则如果我们在业务模型层要定义全国的一个销售额总和的时候，应该就需要把三个子系统的销售额的列在业务模型层相加，才能够形成一个针对全国的分析模型。

这个正是BIEE架构设计里一个非常灵活的地方。

当然，如果我们已经在物理层组织好了一个简单的星型模型数据（使用物理层建模），其实我们可以简单地把它从物理层拖动到业务逻辑层就可以形成一个可用的业务逻辑层的星型模型原型（业务模型层的星型模型会自动延用物理层的建模），然后只需要把这个业务模型拖入到展现层里，我们就能够做出一个最简单的可供查询的数据模型：

是的，在最简单的模型下一切都很简单，我们甚至可以不去建立维表的层次关系，就可以形成一个马上可以投入使用的模型，只是在没有建立维表的层次关系的时候，我们只能做一些一般性的报表，但是报表出来的结果没有办法下转（商业智能报表的一种典型操作）！

业务模型层的一个最常用的词是logical，如果说我们在物理层都是使用表，表的主键外键，表的列的概念的话，那么我们在业务模型层都要在物理层的名词前加上logical一词，如：

∙LogicalTable

∙LogicalColumn

∙LogicalPrimaryKey

∙LogicalJoin

∙。

。

。

等等！

这些词表明的真正含义是指业务模型层，我们的所谓的表，列等概念都是可以定义出来的（可以和物理层的概念并非是一对一的关系