在正常的应用中有很多时候是用到多对多关系的,比如订单,商品,顾客之间的关系,BIEE中的逻辑层是要求实现星型模型的,正常来说都是一对多的表关联,接下来为大家演示BIEE建模过程中如何处理多对多的关系的,首先准备3张表,,cust_c当做客户表,cust_o当做是商品表,o_sl是指商品单价,而cust_ctoo是客户的订单表,其中amount是指购买商品数量.cust_ctoo

BIEE中BMM层建立维度层次的时候,相信大家都看过the number of elements,对于新手来说也许不知道这东西是用来做什么的,其实说白了就是用来做优化的,相信你会问,那我怎么做优化吖,这数字该怎么填才会优化吖,这里我发现了一个小功能点给大家做建议.

当建完一个维度层次之后,对该维度层次右键点击有个Esrimate Levels,之后他会出现根据你所建立的层次给与一个数字,你就可以根据数字填在不同的the number of elements中啦,是不是很方便呢,其实数字给的和建议的数字差一点点也没关系的,影响不大,至少我试的是这样子....大牛别

在逻辑层中可以通过在事实表中做一个度量列引用现有的度量列,比如cost,新建一个logical column new_cost引用cost,new_cost可以设定其levels,一个measure column设定了不同的维度层次的levels后展现的效果是不一样的,因为默认的聚合规则,我这里模仿做个比率的效果.

原有的度量列: cost,新生成的度量列: cost_year和cost_month引用cost,cost_share引用100*cost_month/cost_year。

之后再cost_year,中指定在time维度中的levels的层次为year,cost_month中的为month,之后把字段拉到展现层就OK了,大概效果如下,做了季度

      关于这个Implicit Fact column知识点是在presentation catalog中的,他主要的作用是什么呢？废话不多说,直接上.

      比如你在做单维度查询（就是只查询维度列,维度列来自2个以上的维度表）,此时没度量值,在正常的模型中经常多出现多个事实表,要是进行查询的俩个维度列他们同时与俩个以上的事实表进行关联的话,那么此时会出哪个事实表中的值呢,BI SERVER默认的处理机制是会选取最节省资源的事实表进行连接的,比如较少关联的, 而当一个字段被设定成为一个Impli

BIEE中的table source是在BMM层中很常用到的功能,经常用于将多个物理表糅合成一个逻辑表,但是其对应规则确实有点让人纳闷,今天我做了些小实验,希望看过的大牛有错误提醒下.

     在逻辑表中一个逻辑列可以同时在不同的table source中进行映射,那么有人就会问,如果我查看这个列的话,他是会用到哪个物理表的呢,正常的来说,只要在content中谁设置了content内容,就会找哪个table source,又有人会问,我要是都不设置呢,此时BIEE中很多地方都拥有的特点----（靠前原则）,就是看哪个table source靠前了,本

1.首先星型模型是可以让事实表与维度表之间的连接关系简化，因为他们之间的连接层次只有俩层而已
从而达到提高查询效率的问题.
2.不知道为什么2层就能减少连接关系和提高效率？ 比如事实表为销售记录，里面有PRODUCT_ID连接到PRODUCTS表.
PRODUCTS表有品牌，分类等。如果你在PRODUCTS表里面搞一个BRAND_ID, 然后又连接到BRANDS表，去取BRAND_NAME那就不是简单的两层，变成了雪花式的连接。
星型设计就要求取消BRANDS表，把BRAND_NAME等品牌信息保存到PRODUCTS中（冗余数据），实现逆规范化。

这样你在查

环境： xp sp3 +cognos8.3+sun one

简述：

在本机学习环境上安装Cognos 8.3并进行了content store及IIS的配置之后。涉及到了用

              BIP中的是可以通过BI SERVER验证存储在资料库中的用户的,当然前提是相对应的用户得在BIP中有对应的权限啦,只要经过BI server验证的BIP,则会自动在资料库中生成对应的用户组的,而在不小心出错的前提后,一般是采用super user的形式登陆BIP去修改配置信息,此用户拥有对BIP的全部权限.

            问题现象: 可以创建新报表,配置报表信息的时候提示: failed to load: 对应.xdo.