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

物理层：对应于数据源的定义，可以建立多个不同系统的数据源，比如一个数据源时essbase，一个数据源是Oracle数据库，而另一个数据源时DB2。 ? 逻辑层：从多个物理数据源里抽象出来的多维数据模型，主

要为了业务需求服务，一般是一个星型模型或雪花模型，在逻辑层可以从多个物理数据源形成一个统一的单个多维模型。 ? 表现层：把多维模型以业务的术语展现给最终报表建立的用

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

?

BI Server（BI服务器）

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

Star=RPD文件名

文件名来找到该数据模型定义文件。 物理层和数据源

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

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

当从关系数据库来导入数据模型的时候，一般而言事实表和维度表之间都存在着主外键的关系，在BIEE里创建物理层的时候可以通过导入的方式来把这些事实表和维度表之间的关系直接导入到物理层里，这样BIEE就可以在创建逻层的时候自动地认识到哪些是事实表，哪些是维度。但是维度的层次关系一般而言还是需要自己去定义；而从Essbase或者Oracle OLAP导入数据模型的时候就要容易一些，因为导入会把维度的层次关系直接从Essbase里抓出来，就不需要额外去建立维度的层次关系就可以直接使用Essbase里的设计了！

BI Presentation Service（BI展现层服务）

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

BIEE入门（二）物理层的定义

By chuliang on January 25, 2008 8:54 PM | Permalink | Comments (0) | TrackBacks (0)

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

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

? 源系统的连接方式（指定所对应的源系统的连接信息，如用

户名，密码，端口等） ? 以及导入源系统的数据的定义（源系统里表的结构，主外键

关系等）

?

定义物理层的方式是从file-》import。。。-》from database然后通过向导选择正确的数据库类型并输入连接信息。

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

物理层的额外配置

数据源

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

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

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

? ? ?

定义最大连接数 连接idle时间

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

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

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

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

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

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

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

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

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

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

Categories:

? BIEE plus Tags: