OBIEE BMM Layer

In the OBIEE repository, if you create FKs in the physical layer between tables, you shouldn’t have to create them in the business model, correct? It is crazy that the FKs that exist in the physical layer don’t even show in the business model and the consistency check fails. Any ideas ?

Hi user,
IF u developed the repository in offline mode and which u had given the mappings in physical layer and moved the tables to bmm.After u made this as the current repository(ie online mode).At this time the logical joins will be created automatically.Once this is in online mode if u had given any mappings in physical diagram then it wont affect in the business diagram.So here u need to give the logical join in business diagram in bmm layer for those mappings created in physical diagram.

Similar Messages

Left outer join usage in obiee BMM layer

Hi All,
We lately started using left outer join in our bmm layer , to meet the requirement expectation .
problem : We have two tables Fact A , Dim B . There is an join int_id column to join them . Problem is... in table Dim B , we have 3 millions rows of Int_id and in fact table it is loaded for only data available(1 million rows).
Due to this we are dropping rows in the report ..as it is only getting data where fact.int_id = dim.int_id. So we used left outer join to solve to one particular report .(we know we can do ETl to load dummy int_id and make it null , but it is huge effort ..so we did left outer join)
These days , same kind of reports are in requirement . if i keep on doing same left outer join to meet the requirement in BMM layer ? is there any disadvantages due to this ? any performance degrade due to this ? please throw few lines on left outer join and its usage ?
Thanks,
Sri

Remodel your tables that might be a partition or any other way and follow in BI as per your new model.
Simply: Go for ETL kind of solution

Need help in OBIEE BMM layer logic implementation

Hi All,
I have a requirement in my RPD development.
I have two tables account and site.
Table_Name:*Account*
Column_Name:
AccountID     Store_Name     Site Data_1_Name     Site_Data_2_Name     Site_Data_3_Name
264364     Wegmans_ Food_Markets     GSF     Floor_Type     BSC
999999     Walmart     Floor_Type     BSC
999998     Walgreens     BSC     Avg_Cust_Count     GSF
Table_Name:*Site*
Column_Name:
Site_ID     Store_Name     Account_ID     Account_Name     Site_Name     Site Data_1_Value     Site Data_2_Value     Site Data_3_Value
264367     Wegmans_Food_Markets     264364     Wegmans_Food_Markets     Alberta_Drive_#82     96114     Vinyl     Kellermeyer
264368     Wegmans_Food_Markets     264364     Wegmans_Food_Markets     Alberta_Drive_#83     96109     Poly_Vinly     ABC
123     Walmart     999999     Walmart     Alberta_Drive#1000     Vinly     XYZ
1678     Walgreens     999998     Walgreens     Calgary_ Drive#9009     ABC     10000     56565
Site Logical/ Presentation Table in OBIEE
Site_ID     Store_Name     Account_ID     Account_Name     Site_Name GSF     Floor_Type     BSC
264367     Wegmans_Food_Markets     264364     Wegmans_Food_Markets     Alberta_Drive_#82     96114     Vinyl     Kellermeyer
264368     Wegmans_Food_Markets     264364     Wegmans_Food_Markets     Alberta_Drive_#83     96109     Poly Vinly     ABC
123     Walmart     999999     Walmart     Alberta_Drive#1000          Vinly     XYZ
1678     Walgreens     999998     Walgreens     Calgary_ Drive#9009     56565          ABC
for account table we have the Site Data_1_Name ..Site Data_3_Name columns values which is the column name for the values in Site table(i.e the values in the columns "Site Data_1_Value..Site Data_1_Value") . this values change dynamically based on the column name(Site Data_1_Name ..Site Data_3_Name ) in Account Table . how do i map this column values in RPD level ? or do we have any logic to implement this. PLEASE HELP ME TO SOLVE THIS ...
Thanks in advance ,
Mohan Mano

HI mohan the information you provided holding some sensitive data please delete some of them otherwise you might be in trouble.
Make join between the account_ID and the SITE_ID based on the inner join columns which match in both tables will retrieved in the report. If you want to see the null values as well you can use outer join.
Thanks,
chak

Join issue OBIEE (BMM Layer)

Hi All -
1. I have following tables:
D1 - Dimension Table
D2 - Dimension Table
D3 - Dimension Table
F1 - Fact Table
We have join between - D1 - F1, D2, F1 & D3 - F1
2. We have some more tables :
D4 - dimension Table
F2 - Fact Table
We have join between - D4 - F2
3. We have some more tables :
D5 - Dimension Table
F3 - Fact Table
We have join between - D5 - F3
Now the scenario is we need to enable joins between all these tables in the logical layer. i created dimensional hierarchies and assigned at the total level for the fact tables. but it is not working.
can anybody please lookinto this issue?
Thanks

I noticed that if you create the FK in the physical layer BEFORE moving the columns into the Business Model layer it will keep them when you bring them over, but if you create the columns in the BM layer then made the physical joins you have to go back and join in the BM layer.
Unfortunately if you'll lose anything in the Presentation or Business Model layer if you remove it from the BM and want to re-join.

Count on a column In BMM Layer of Obiee

Hi All,
How to implement below SQL in OBIEE BMM layer
SELECT   COUNT ( * )
            FROM dept, emp
           WHERE       emp.origrecordid = dept.depno
                 AND emp.empname = 'xyz'
Please help me on this

create a metric with expression
count(employee_id)
the value for this metric will vary based on columns selection on Answers
~ http://cool-bi.com

Sum Aggregation Error in Physical & BMM Layer in OBIEE 11g with Essbase 11

Hi everyone,
I'm using OBIEE 11g with Essbase 11 as the data source. I'm using Sample Basic database from the Essbase as my data source. If I'm using the hierarchy for the measures (so I don't flatten the measures), and when I changed the aggregation in both physical and BMM layer from Aggregate_External to Sum, I can't create a report at all from the Answers.
Does anyone encounter the same thing? Any ideas/solution about this? Please help.
Thanks a lot!

Hi Deepak,
When I picked the "Basic - measure" alone, I got this error.
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 96002] Essbase Error: Unknown Member Basic - measure used in query (HY000)
SQL Issued: SELECT 0 s_0, "Sample Basic"."Basic"."Basic - measure" s_1 FROM "Sample Basic".
When I picked the "Gen1,Measures" alone from the measure dimension, I got this error:
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 46008] Internal error: File server\Query\Optimizer\ServiceInterfaceMgr\SIMDB\Src\SQOIMDXGeneratorGeneric.cpp, line 2610. (HY000)
SQL Issued: SELECT 0 s_0, "Sample Basic"."Measures"."Gen1,Measures" s_1, SORTKEY("Sample Basic"."Measures"."Gen1,Measures") s_2 FROM "Sample Basic"
But when I queried the dimensions one by one (only single dimension each), no error was shown.
This only happens if I use Sum in the physical and BMM layer. If I use External_Aggregation, these errors do not happen. And if I flatten the measures, these errors also do not happen.

How to determine the logical Keys of logical fact table in BMM layer?

Hello guys
I'd like to know more about how to know what columns of the logical fact table should be used as key in BMM layer. How OBIEE behaving differently when different keys are selected?
In my situation, I have 1 fact table that physically joins to 20 dimensions in physical layer. Therefore, in physical layer, this fact table has about 20 foreign keys but no primary keys..
In the logical layer, this fact table is logically joined to the same group of dimension tables. So in this case, how do I know what columns in logical fact table I should use as keys?
Please advice
Thanks

thanks for the reply...
The interesting thing I notice is that, when I start using fragmentation with the fact tables in its LTS, if not primary key is defined in the logical fact table, then I will be getting errors:
[nQSError: 10058] A general error has occurred. [nQSError: 14023] None of the fact sources for columns are compatible with the detail filter []. (HY000)
When I create the key by choosing random columns from the fact table as the logical key columns, this error goes way and the correct SQL is generated according to the frag..
Because of such behavior, I'd really like to know how logical key really works in BMM layer.

Arranging Hierarchy tables in BMM layer

Hi
I have a different structure of dimensions in the database.
Year->Season->Quarter->Month->Week
For every level in Hierarchy I have table i.e, Dim_Year, Dim_Season, Dim_Quarter, Dim_Month, DIm_Week
They are joined in physical layer in as per the hierarchy thats is Dim_Year is joined to DIm_Season by Year_id, Dim_Season is joined to Dim_Qaurter by Season id and so on.
In BMM layer I have to craete an Hierrarchy.
How should i keep these tables
Option1: Pull the all the tables separately
Create comples join between all the dim tables year->Season->Quarter->Month->Week
Create hierarchy from these tables
Option2:
Create a logical tables as Time
Pull all the tables into Time table with different Logical table sources.
Then create a hierarchy from these tables.
This will avoid the comples join in BMM layer
Please suggest which option will lead to less performance issue and which is ideal approach in such scenarios.
Thanks in Advance

Hi,
I am new to OBIEE but still I am suggesting one option....
Drag and drop any one of the Time table (for ex Dim_Year) from physical layer to bmm layer. create a complex join of this table with the other tables in the bmm layer. then simply drag and drop the columns from other tables (Dim_Season, Dim_Quarter, Dim_Month, DIm_Week) from the physical layer one by one on the LTS of Dim_Year.
Hope I haven't given you a funny answer.
Edited by: user9149257 on Mar 8, 2010 9:20 PM

Display of yellow colour icon to a table in BMM layer

Hello all,
Please ignore my previous thread. By mistake it went without any description of problem. Sorry for that.
I have two tables org details, emp details
org details having columns like orgname, year, quarter1 results, quarter 2,quarter 3, quarter 4
emp details having columns like org, year, emp in quarter1, quarter2,quarter 3, quarter 4.
Spread sheet as datasource and imported to physical layer....when i drag drop to BMM layer...emp details table icon showing yellow.
But it's not a fact table...those two are normal tables....why is it showing yellow colour icon?
please let me know the concept of how OBI administrator tool decides that the table is fact table or dimension table.
regards
chandra kanth.

By default OBIEE will show yellow colour.Once you create joins in BMM layer then it will show colours accordingly.Table on n side in 1:n join will be shown as yellow(Fact).So create joins in BMM layer.
Regards,
Sandeep

Please Help in Joins and content tab (BMM Layer).

Hi all,
I am a newbie in OBIEE. I am working on a project in our organisation for existing database schema in oracle. We are planning to use OBIEE for reporting purpose.
Here's my problem.......
I have Three dimensions and Two Fact tables in my schema.
out of these one dimension is conformed Dimension.
Product_Reporting_Line, Geography, Policy_Cover_Type are Dimensions and ClaimFact,*PolicyFact* are facts.
Product_Reporting_Line is joined to Claim Fact and Policy_Cover_Type is joined to PolicyFact..
Geography is joined to both Claim Fact and PolicyFact.
Here's how it looks.....
Product_Reporting_Line-----< Claim Fact >-------Geography--------< PolicyFact >-------Policy_Cover_Type
I have a report in which columns from all the tables have to be taken.
In the Fact tables F1 and F2, there are some columns for which aggregation rule is not set (varchar Data for example Claim Number from ClaimFact and Policy Number from PolicyFact).
How should I design BMM layer. I want to know how the content tabs should be set.
Can anybody suggest me how should I do this?
Edited by: LavaRider on Jul 12, 2010 6:12 AM

Hi Kart,
I didn't do it the other way, I did it the the way you suggested me..
I have set the content for the Policy_Fact LTS to the Total level of Product_Reporting_Line dimension.
also I have set the* content* for the ClaimFact LTS to the total level of Policy_Cover_Type.
When I set the level *(Level tab of logical columns properties)* of Measues to the total level then it works....
i.e.
I have set the levels of the logical columns of Policy Fact table to the total level of Product_Reporting_Line and also set the levels of the logical columns of Claim_Fact to the Total level of Policy_Cover_Type.
I want to ask you Do we have to set the content in the LTS as well as in the Level (tab) of the measures?
Thanks for giving your precious time for me, I really appreciate that

Optimizing data grouping on BMM Layer

Hi.
I'm faced with the next task.
*(1)* Business goal
Display number of customers registered and activated by periods. The request in Answers should contain:
*{Period, NumberOfContacts_Registered, NumberOfContacts_Activated}*
*(2)* At Physical Layer I can provide data in two ways:
*2.1.* In single table like {customer_id, registration_date, activation_date..}
*2.2.* In two tables like {customer_id, registration_date..} and {customer_id, activation_date..}
*(3)* The question is about the most effective way of organizing data on BMM Layer.
I'm interested in whether I can organize single logical table to represent desired data in Answers. For example, logical table with columns {customer_id, registration_date, activation_date..} and then define complex join with logical table "Periods".
For now, I had an occasion to define two logical tables - with columns like in Paragraph 2.2. But it seems to be more effective way to do this.
Could anyone give me a piece of advise how to resolve this task more effectively (in preference, with single logical table).
Regards,
Alex.

hi Jeremy,
Use this '01-JAN-08' format in answers filter
Let me know if you have issues
OBIEE will replace with time stamp adds if its a timestamp/datetime data type
Thanks,
Saichand.v

How should I deal with it in the BMM Layer

Hi all,
I need a suggestion in a problem.
Here is the scenario,
In the physical layer, There are some fact to fact joins.
ProductFact ----< PolicyFact ----< PolicyCoverFact ----< ClaimFact ----< ClaimPaymentFact ----< CorrespondenceFact
There are some conformed dimension tables given below
Geography is joined to ProductFact, ClaimFact
Organisation is joined to PolicyCoverFact, CorrespondenceFact
Currency is joined to PolicyFact, ClaimPaymentFact
Also there are non-conformed dimensions such as,
ProductType is joined to ProductFact
PolicyCoverType is joined to PolicyCoverFact
and there are many more......What I know is when there are fact to fact joins, we should make a logical table in the BMM layer and add both fact tables to the same LTS, But in this case, almost all the fact tables are joined directly.
How should I deal with these fact to fact joins in the BMM layer? Any suggestions?
Edited by: LavaRider on Aug 25, 2010 2:47 AM

LavaRider wrote:
I have to create many LTS for the fact table......
1 LTS for ProductFact
1 LTS for ProductFact & PolicyFact (which contain ProductFact and PolicyFact as sources)
1 LTS for ProductFact , PolicyFact & PolicyCoverFact ........
and so on.....
have I understood correctly? Is that what you mean?Yes, the reason why I said to "keep" the firsts fact table in each source is to make the dimension work.
For example, if the "product dimension" is only linked to "product fact", but not "policy fact" then you won't be able to do a report based on "product dimension" and "policy fact". Right ? To be able to do this report, OBIEE must do a join with "product fact" (this fact table become an intersection table). That's why you will add product fact in the "policy fact" source. Same for others source.
But the name of "ProductFact & PolicyFact" source can be "policy fact". Because each row of this source is a policy fact.
For the 3rd table, each row is a "policy cover fact". But to be able to join with "product dimension" and "policy dimension", you need to integrate "policy fact" and "product fact" tables in the logical source.
and so on.

BMM layer creation (Star Schema Physical Layer) - What to add/not add?

Hi All,
I am just looking for any general feedback on the thought/question below.
I am setting out on creating my first BMM layer and trying to determine what I need to do in this layer that will be different and add value from what I already did in the physical layer. My data model is already defined as a star schema within my data mart source. So in the physical layer I have my facts imported along with the dimensions and I have joined them together as needed. Here is what I think I will setup as I move into the BMM layer:
1. I will add heirarchies as needed to enable drill down within my reports
2. I will need to add my calculations/measures to allow for any type of metric to be returned through a request in Answers
3. I do not see a large need to create logical tables (at least not yet) based on multiple physical source tables as my source is already a star schema and dimensionally modeled. For users that also already source a star schema at the physical layer .. do you find that you do a lot of logical table creation/mapping to add functionality or does your BMM look a lot like you Physical Layer?
Other than steps 1 and 2, I am not really sure how much additional manipulation I might do from the Physical to BMM layer since my Physical is already a star schema. Am I missing anything? Obviously everyone's data model and circumstances are different but I wasn't sure if maybe there were some good thoughts on what I might be missing (if anything)?
One last question .. I am not currently planning to use any aliases at the Physical Layer but I do plan to rename the tables at the presentation layer to be more business verbage like. Why are others using aliases?
Thanks in advance for the help.
K

Alastair, thanks for the advice. I'll definitely keep that in mind as I start to build out the BMM.
One question/issue I just ran into as I was wrapping up my Physical Layer mapping. When I check for global consistency, I am getting an error that is complaining that I have multiple joins defined between the same two tables (which I do). This is because I have the following setup:
TBL_A_FACT
F_ID_HIT
F_HIT_DESC
F_ID_MISSED
F_MISSED_DESC
TBL_B_DIM
F_ID
F_DESC
Table A joins to Table B in two ways:
TBL_A_FACT.F_ID_HIT = TBL_B_DIM.F_ID
TBL_A._FACT.F_ID_MISSED = TBL_B_DIM.F_ID
The F_IDs can be either hit or missed on any given fact record and the total distinct set exist in the dimension.
When I define two foreign key joins in the physical layer based on the relationship above and check Global Consistency, I get an error saying that "TBL_A and TBL_B have multiple joins define. Delete duplicate foreign keys if they exist" and it is listed as an error. I guess this makes sense because when the two tables are used in a request OBIEE would need to know how to join them (using the hit or missed field). What is the best approach for handling this..
- Should I define TBL_A twice in the physical layer as:
TBL_A (Alias TBL_A_HIT)
F_ID_HIT
F_ID_HIT_DESC
TBL_A (Alias TBL_A_MISSED)
F_ID_MISSED
F_ID_MISSED_DESC
Or do something like the above in the BMM layer?
Thanks for the help!
K
And then establish the relationships using these separate tables?

Why do we need to Join in the BMM Layer

Hi,
Somebody asked me the following questions
*"If the joins are already defined in the Physical Layer and ultimately the query will pass thru Physical Layer to the Database and will take the joins defined in the Physical Layer then why do the joins in the BMM layer". This can be a Complex join or a Foriegn Key Join*
Under what conditions do we use Foreign Key Joins in BMM layer ?
How do we use Stored Procedure in OBIEE?
Any answers.
Rgds,
Amit
Edited by: amitsharma73 on May 20, 2010 5:51 PM
Edited by: amitsharma73 on May 20, 2010 5:52 PM
Edited by: amitsharma73 on May 20, 2010 5:52 PM
Edited by: amitsharma73 on May 20, 2010 5:53 PM

This is most likely because the copy's licence has not been verified, and to verify it you need to log in so it can check that you account contains the license.
It's just to prevent torrenting and piracy.

Cardinality in BMM layer

Dear All ,
I have a question in the rpd in OBIEE that is what difference we will get when we have given an option in the BMM layer as 1 to many 0r many to 1 to 1 in the Joining tables .I would like to know that this cardinality will give any difference in the record count in the reports .
Please suggest me what is the usage of the cardinality in sql query out put .
Thanks

Hi,
From the guide "A key property of a logical join is cardinality. Cardinality expresses how rows in one table are related to rows in the table to which it is joined. A one-to-many cardinality means that for every row in the first logical dimension table, there are 0, 1, or many rows in the second logical table. The Administration Tool considers a table to be a logical fact table if it is at the Many end of all logical joins that connect it to other logical tables"
It really matters when you specify the driving tables if left hand side has less reocrds than right hand and makng it as driving table by menitoning the cardinality
Thanks,
Saichand

OBIEE BMM Layer

Similar Messages

Maybe you are looking for