Comments on: Oracle BI EE 10.1.3.4.1 – Enforcing and Non-Enforcing Outer Joins http://www.rittmanmead.com/2009/09/21/oracle-bi-ee-10-1-3-4-1-enforcing-and-non-enforcing-outer-joins/ Delivered Intelligence Wed, 17 Mar 2010 13:47:41 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Venkatakrishnan J http://www.rittmanmead.com/2009/09/21/oracle-bi-ee-10-1-3-4-1-enforcing-and-non-enforcing-outer-joins/comment-page-1/#comment-10792 Venkatakrishnan J Tue, 29 Sep 2009 13:47:24 +0000 http://www.rittmanmead.com/?p=3092#comment-10792 @Renga - You are right. This is just one use case of a snow-flaked BMM and not a final & binding one. The advantage of the snowflaked one is your dimensions are automatically derived for you. In the case of multiple LTS within a logical table, one would have to manually build the levels. There are other ways of achieving the same outer joins on request. Multiple LTS's can easily become un-manageable when you have multiple aggregate tables, multiple data sources combined together. Depending on the version of BI Server, the logical execution path can vary if you have multiple LTS's for a logical table. Having said that, your solution would surely work as well. -Venkat @Renga – You are right. This is just one use case of a snow-flaked BMM and not a final & binding one. The advantage of the snowflaked one is your dimensions are automatically derived for you. In the case of multiple LTS within a logical table, one would have to manually build the levels. There are other ways of achieving the same outer joins on request. Multiple LTS’s can easily become un-manageable when you have multiple aggregate tables, multiple data sources combined together. Depending on the version of BI Server, the logical execution path can vary if you have multiple LTS’s for a logical table. Having said that, your solution would surely work as well.

-Venkat

]]> By: Renga http://www.rittmanmead.com/2009/09/21/oracle-bi-ee-10-1-3-4-1-enforcing-and-non-enforcing-outer-joins/comment-page-1/#comment-10789 Renga Tue, 29 Sep 2009 13:20:35 +0000 http://www.rittmanmead.com/?p=3092#comment-10789 Hi Venkat You can define two sources for one logical table and first being just customers and second one is customers outer joined to countries. By doing this way OBIEE will use customers table when customer only attributes used in the query and uses both the customers and countries when request contains attributes from both the table. I don't think you have to bring the snow flake model to logical layer to achieve this. Hi Venkat

You can define two sources for one logical table and first being just customers and second one is customers outer joined to countries. By doing this way OBIEE will use customers table when customer only attributes used in the query and uses both the customers and countries when request contains attributes from both the table. I don’t think you have to bring the snow flake model to logical layer to achieve this.

]]>