Multiples LTS

Hi Techies,
i have a fact table A in physical layer which has join with DAY ,MONTH AND YEAR dimensions.
in BMM
i have created a logical table date with above three as logical sources(day,month and year) and one fact table with three LTS's(for these three physical source is A only) where the level for date is set at day ,month and year respectively .(normally it need one fact but i have created three to satisfy some other requirement)
iam picking month and any column from fact it is picking the day dimension not the month...
suggest me how can i achieve this ????
Thanks In Advance

Check your column mapping for date dimension. Your Month column should be only mapped to the month LTS.
thanks,
Deep

Similar Messages

Using Multiple LTS in BMM Layer - OBIEE 10g

Hi,
I have 3 tables heirarchies as follows, Project Detail --> Activity Detail --> Sub-Activity Detail. Sub-Activity being the lowest level. But the project also has some fact data, like the Total-Project-Cost, if I include that in my report, the query also joins Sub-Activity-Detail and as a result the Total-Project-Cost is summing up based on the number of rows in Sub-Activity-Detail. To eliminate this, I am planning on doing one more LTS, so when I choose Total-Project-Cost, it does not go to Activity or Sub-Activity. Here are my questions with this approach,
1. Is it possible in 10g?
2. Do I have to do multiple LTS in the fact as well as Dimension table?
3. Is there any other approach you would suggest?
Thank you for your time and help.

Hi
you can build a level based measure for Total Project Cost and in aggregation tab chose the appropriate content level as defined in your hierarchy. Now this measure will sum up only for the level you have chosen. Go through these links for reference -
http://gerardnico.com/wiki/dat/obiee/measure_level_based
http://oraclebizint.wordpress.com/2007/12/03/oracle-bi-ee-101332-level-based-measures-lbms/
Assign points if found helpful.

Regarding LT and multiple LTS

Hi Experts,
What is the difference between logical table and logical table source in BMM layer in which scenarios we have to add multiple LTS to the logical table in BMM layer can any one make me clear regarding this.
Thanks in Advance
Edited by: Rafi.BI on Jan 16, 2013 10:40 PM
Edited by: Rafi.BI on Jan 16, 2013 10:41 PM

Hi rafi.
LTS - Means Logical table Source.
For each Logical table created in BMM Layer, there will be 1 or more Source tables coming from Physical Layer.
Many of the cases there will be 1 physical table for 1 logical table in BMM layer. But there will be a scenario where you will have to recieve the date from different physical table ( that is diiferent department will provide different physical table).
In this scenario you will be having 2 physical source table ( Multiple Logical table ) in your BMM layer.
Simailarly M LTS can be used for many other perposes. ex to eleiminate snowflake etc etc.
mark if correct/Helps
fiaz

Question about multiple LTS

Hi,
I am currently working with the rpd and a general doubt pops up... in the physical layer I have dimensions related, like for example Person, related to another dimension City and for example Age (with Foreign Key join):
City -< Person
Age -< Person
So in order to have a true star schema in the BMM, I need to create a single logical table with these three physical tables, right? The question is how.
I can add the physical tables as 3 logical table sources, or have one single logical table source, mapped to these three physical tables.
What is the difference, if any? Can someone explain, please? I always use the first choice (multiple logical table sources, each of them mapped to one physical table), but is it better to have just one single logical table source?
Thanks in advanced :)

I'm not surprised that it works fine, but there is a chance that it can lead to some problems. Let me explain.
You now have three LTS in your Logical dimension table Person.
Person
Age
City
When you create a report with columns from City and the Fact table, the BI Server will need to set up a join path between Fact and City table. There is no other option then via the physical Person table. So the BI Server decides for you to create a join between fact and person and person and city.
When the City is joined to other tables in the physical layer then the BI Server might create another join path between Fact and City, because it thinks it is more efficient. This can lead to inccorect results.
When you add the three physical tables to one LTS, you explicitly tell the BI Server, to create a join path from Fact to City table via the Person table.

Issue with Multiple LTS for a fact table and filters

Hello,
I am facing an issue with obiee 10g.
In my model, I have a huge FACT table F1 (partitioned and indexed). The average response time for the queries, which targeted it, was ~30-60 seconds, which was not really convincing our end user.
So, we decided to create a materialized view, which removes some dimensions that are not used by default, but might be used if the end user adds some filters. I added the Materialized view in the Physical Layer and in the corresponding Logical Table Source.
I then tried to see if it works, but I was a bit surprised by the result. Indeed,
-> If the report does not reference a truncated dimension, it targets the materialized view. -> Perfect
-> If the report does reference a truncated dimension in the columns, it targets the Fact Table. -> Perfect
-> If the report does reference a truncated dimension in the Filters, it targets the materialized view. For this reason, the filter is never resolved and no join on the dimension table is applied, whereas it exists in logical SQL generated. -> Ko.
A suggestion could be to add the filters into the columns, but I am not satisfied by this response because it will never use the materialized view in that case.
An other suggestion could be to use query rewrite, but I 'd like to have the full control on the generation of the queries.
Does someone know if the filters are not evaluated to determine which LTS to use? How can I force this evaluation?
Regards,

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Using multiple LTS

Hi All,
I have a few conceptual questions. I have found that I can use 2 dimension from physical layer in one logical table using two LTS or by just using one LTS. If i drag and drop the fields from physical table into logical table, new LTS is created. When, I drag and drop the field in the existing LTS, there will be one LTS for two physical tables.
I would like to know the differences between these approach and which one is the best approach to follow.
Thanks,
Surya

Approach is depends on your desig.
The best approach is logical table having 2 LTS(when you expand source folder you see all sources), in this case BI uses its intelligence to pick the source based on your column selection in answers.
ex: Fact and Aggregate tables
Other case you are forcing BI to use that particular join(or source), irrespective of the column selection of the table.
ex: Fact and fact extension
Pls mark correct :)

Setting Logical Level in LTS

Hi all,
Usually we set the Logical Level (Content Tab) for the LTS in the Fact table.
Is there any best practice to set it for the LTS in Dimension tables too? If yes, why do we do that?
Please clarify on this. This is very urgent.
Regards.

one thing is If you have multiple LTS in a single dimension like detail dim and aggregated dim. then you have to set the content levels for each LTS. Its always a good practice to mention which level the dimension is in any case.

Multiple Facts in single subject area

Hi everyone,
Is there an optimal way to get multiple facts into a single subject area? The only way I've managed to get multiple facts into a single subject area is to go the route of creating hierarchies for all dimensions, setting up all the content levels for both the fact and dimension tables and finally creating aggregated measures for all the fact tables. However, when you setup these different hierarchies and content levels, the queries which are generated tend to get fairly nasty and seem to be slow. Another pesky issue is that I've had to create pseudo columns for all facts, so that if a report is using one dimension from FACT A and one dimension from FACT B, then you have to include this pseudo column from both facts so that OBIEE knows which tables are involved in the query. Without including these pseudo columns in the report, the OBIEE engine gets a little confused and puts up an error.
I'd prefer to find a better way to do the multiple fact implementation without having to have the massive queries and pseudo columns, but I'm not sure what the other options out there are. Anyone know the best way to accomplish this?
-Joe

Hi Wildmight,
You are exactly right.
Here's an example of what I'm trying to accomplish. We have a TIME SHEET fact table which has things like a work date, an employee ID, a work order number and the hours which were worked. The work orders can be against one or more pieces of equipment. There is a second fact table which models the one to many relationship between work orders and equipment.
The model would look a little like this:
Join on WORK ORDER NUMBER Join on WORK ORDER NUMBER
TIME SHEET FACT <-----------------------------------------------WORK ORDER Dimension ----------------------------------------------> WORK ORDER EQUIPMENT FACT
We would like to create a report that shows the number of hours from the time sheets fact grouped by the piece of equipment from the work order equipment fact. I've been able to setup this report using the method I described in my first post, but like I said, the generated SQL is massive and seems somewhat unnecessary.
I think I'd have to say the grains of the facts are different since they providing to different pieces of information.
I haven't done too much multiple LTS experimentation. I'm working from a single data warehouse source which should be robust enough to handle any reporting requirements. Even though I know OBIEE can do some clever combining of tables using the LTS; if data sets need to be consolidated, I'm trying to keep that work in the database via ETLs in order to keep the work that OBIEE has to do down to a minimum.
-Joe

If Logical level mappings are blank in an LTS , what does it mean?

Hi All,
I was trying to find this out in the forum but couldn't.
In my LTS, on the content tab, if i don't specify any "Aggregation, group by" information for the dims associated with my Fact table and keep it blank, then what does it mean? Would OBIEE treat this as at the detail level by default? So to test this, I created a logical fact and for its LTS, i didn't associate any logical level for dimensions. The query didn't give me any error and worked fine by using the correct join details.
Also when do we associate an LTS with the Total Level for a dim, what's the use because as I understand, this means all our measures from that LTS would be calculated for the total level of the dim and we can do this by creating level based measure and associating it with the total level of the dim.
I'll be thankful if somebody could explain me this in detail or direct me to a relevant documentation/ blog
Thanks,
Ronny

Hi,
When you have only one logical Table Source(LTS).
You don't specify the logical levels. By default it would consider the detail level of the logical levels mapped to the fact table.
When you have Multiple logical Table Source(LTS).
The concept of Multiple LTS comes into picture when you have multiple sources. The BI server picks the optimum logical source depending upon the fields (columns) selected. And also depends on the Number of element set while creating the dimension hierarchies. Refer-http://gerardnico.com/wiki/dat/obiee/level_number_element
For example- Suppose you have two logical table source Fact 1 and Fact 2 and logical levels( dimension hierarchies are created for two dimensions Dim 1 and Dim 2).
For the first Fact 1 source logical level is mapped only with Dim 1 and Fact 2 is mapped to Dim 2.
(You need to decide which fact source to hit depending upon the dimensions used in the report.)
Then in the report when you select Dim 1 (by means of column selector/filters) then Fact 1 source will be hit and same appears in the query.
Then in the report when you select Dim 2 (by means of column selector/filters) then Fact 2 source will be hit and same appears in the query.
One more situation where you have mapped Fact 1 with Dim 1 First level of aggregation and Fact 2 with Dim 1 with Detailed level. Then the BI server picks depending upon the user's request. If the request data can be pulled from the detailed level ( which tends to be optimum then picks from the second source).
So, its always better to set the logical source and check the query, if its hitting the correct sources according to the requirements.
Regards,
MuRam

Multiple facts with shared/non shared dimensions

Hello All,
I have a scenario where we are using multiple facts in OBIEE. Fact1(Inventory Onhand) is joined to all shared dimensions, and Fact2( Forecasting Values) is joined to few shared dimesnions so the joins are like:
Fact1 with Dim1, Dim2, Dim3, Dim4, Dim5, Dim6..
Fact2 with Dim1,Dim3, Dim5
I have given the physical joins in the physical layer, later in the logical layer I pulled the fact2 in to to the fact1(multiple LTS) and then set the aggregattion levels for the non conformed dimensions. This was working fine for me but the customer was not happy with this. He doesnt want to have different levels of data in to a single fact.
What are the allternate possible solutions to implement this in the busines layer?
Any ideas/inputs are highly appreciated.
- Abhi

Hi,
I have done the same as explained above. But here the issue is we are getting duplicate data.
For Ex: if i have one common dimmension attribute and two non confirmed dimension attributes with a measure. For non confirmed dimension have different value and for all these values the common dimension attribute is same. Then the common attribute will repeat for all non confirmed dimensions.so, here automatically the Corresponding measures also repeating.
Common Attr non-Confirm Attr1 non-Cnfirm Attr2 measure
123 abc xyz 1000
123 bac yzx 1000
123 pqr mno 1000
If you observe the above exapmple the confirm dime attr is same for both non confirm dime attrs, so the measure values also repeating here. If i see the data base i have measure data only for ABC record. For Remaining two records it is 0, but here the value 1000 is showing for remaining two records as well.
Please let me know if any one face this issue earlier.
Regards,
Aari

A single OBIEE report firing Multiple Queries

HI All,
I tried the search option and did not find any questions which gives me what I am looking for. If I missed it and the question is already asked, please redirect me to the thread.
I had a report which had a data issues. When i checked the log, I was shocked to see it firing 10 different queries. Could you guys please tell me exactly when OBIEE decides to split a single query and fire multiple ones?
Here's some info on the report:
1. All the columns are from the same subject area.
2. All the physical tables are in the same database in the physical layer.
3. All the tables are from the same physical catalog even.
4. Majority of the columns are from the same fact. The fact table however has multiple LTS(Over 30) involving both fragmentation and content filters.
Could you guys please let me know why multiple queries are fired in the above case as well as generally by OBIEE?
Thanks,
Abhiram.

It is recommended not to edit DB features. If you need to change them you might need to take help of oracle support.
Else you might induce more erratic behavior.
Not in agreement here. Depending on how that data sources beneath OBIEE are physically set up and parametrized you may be forced to change this in order to assure performance for example. Not all your BI-analyzed sources will be purpose-built for analytics and hence follow usual modellization rules or approaches. Oracle put the features in the DB objects for exactly that reason. And obviously you don't go and change the features "just like that".
since fact measures are from multiple LTS, every time you bring a measure from different LTS it is treated as another star. So what OBIEE does is it queries each star separately using alias and then stitch them logically. Thats the reason for fragmented queries and a singel long sql in the end with stitches the other sql results in the end.
True, but the OP was talking about "firing 10 different queries". Which is a bit vague but sounds more like distinct select statements rather than stich-joined WITHs...that's why I directed him towards the features which can actually change this dramatically. Problem is, that the OP hasn't made that exact point clear yet.

Multiple sources for Logical Tables

The order of the sources in the logical table(in case of multiple sources) will it affect the query results??

Hi,
OBIEE pick the LTS using this algorithm:
1) every logical fact table is set to a dimension level, every level in the dimension has a number of elements at that level
2) OBIEE multiply for every LTS all the numbers of elements defined for a specific LTS
3) OBIEE pick the LTS that has the lower valure (like a cost of access, it picje the most aggregated table)
4) if there are multiple LTS with the same cost, OBIEE choses the first in order of defiition
Regards,
Gianluca

Multiple facts in EIS

I have a customer with a datawarehouse solution with a number of star schemas. However in the EIS documentation the recommendation/requirement is to use only one fact table. I want to build an Essbase cube based on two different facts. To merge the two star schemas in to one could be tough and would be in opposition to the design recommendations from DW literature authors like Kimball. Are there any known workarounds?

Hi Wildmight,
You are exactly right.
Here's an example of what I'm trying to accomplish. We have a TIME SHEET fact table which has things like a work date, an employee ID, a work order number and the hours which were worked. The work orders can be against one or more pieces of equipment. There is a second fact table which models the one to many relationship between work orders and equipment.
The model would look a little like this:
Join on WORK ORDER NUMBER Join on WORK ORDER NUMBER
TIME SHEET FACT <-----------------------------------------------WORK ORDER Dimension ----------------------------------------------> WORK ORDER EQUIPMENT FACT
We would like to create a report that shows the number of hours from the time sheets fact grouped by the piece of equipment from the work order equipment fact. I've been able to setup this report using the method I described in my first post, but like I said, the generated SQL is massive and seems somewhat unnecessary.
I think I'd have to say the grains of the facts are different since they providing to different pieces of information.
I haven't done too much multiple LTS experimentation. I'm working from a single data warehouse source which should be robust enough to handle any reporting requirements. Even though I know OBIEE can do some clever combining of tables using the LTS; if data sets need to be consolidated, I'm trying to keep that work in the database via ETLs in order to keep the work that OBIEE has to do down to a minimum.
-Joe

Content tab for a fact table

Hi
Please , help me in knowing the use of content tab for a fact table in the repository in OBIEE.
Thanks.

if you have multiple LTS then you should set the content level approprately otherwise you can get errors during consistency checks.not able to find any link which talks only about content level.see these links and let us know if you have any doubts
http://kr.forums.oracle.com/forums/thread.jspa?threadID=604637
Content tab is also handy when you are using aggregate tables.
Regards,
Sandeep

Filter expression producing different results after upgrade to 11.1.1.7

Hello,
We recently did an upgrade and noticed that on a number of reports where we're using the FILTER expression that the numbers are very inflated. Where we are not using the FILTER expression the numbers are as expected. In the example below we ran the 'Bookings' report in 10g and came up with one number and ran the same report in 11g (11.1.1.7.0) after the upgrade and got two different results. The data source is the same database for each envrionment. Also, in running the physical SQL generated by the 10g and 11g version of the report we get different the inflated numbers from the 11g SQL. Any ideas on what might be happening or causing the issue?
10g report: 2016-Q3......Bookings..........72,017
11g report: 2016-Q3......Bookings..........239,659
This is the simple FILTER expression that is being used in the column formula on the report itself for this particular scenario which produces different results in 10g and 11g.
FILTER("Fact - Opportunities"."Won Opportunity Amount" USING ("Opportunity Attributes"."Business Type" = 'New Business'))
-------------- Physical SQL created by 10g report -------- results as expected --------------------------------------------
WITH
SAWITH0 AS (select sum(case when T33142.OPPORTUNITY_STATUS = 'Won-closed' then T33231.USD_LINE_AMOUNT else 0 end ) as c1,
T28761.QUARTER_YEAR_NAME as c2,
T28761.QUARTER_RANK as c3
from
XXFI.XXFI_GL_FISCAL_MONTHS_V T28761 /* Dim_Periods */ ,
XXFI.XXFI_OSM_OPPTY_HEADER_ACCUM T33142 /* Fact_Opportunity_Headers(CloseDate) */ ,
XXFI.XXFI_OSM_OPPTY_LINE_ACCUM T33231 /* Fact_Opportunity_Lines(CloseDate) */
where ( T28761.PERIOD_NAME = T33142.CLOSE_PERIOD_NAME and T28761.QUARTER_YEAR_NAME = '2012-Q3' and T33142.LEAD_ID = T33231.LEAD_ID and T33231.LINES_BUSINESS_TYPE = 'New Business' and T33142.OPPORTUNITY_STATUS <> 'Duplicate' )
group by T28761.QUARTER_YEAR_NAME, T28761.QUARTER_RANK)
select distinct SAWITH0.c2 as c1,
'Bookings10g' as c2,
SAWITH0.c1 as c3,
SAWITH0.c3 as c5,
SAWITH0.c1 as c7
from
SAWITH0
order by c1, c5
-------------- Physical SQL created by the same report as above but in 11g (11.1.1.7.0) -------- results much higher --------------------------------------------
WITH
SAWITH0 AS (select sum(case when T33142.OPPORTUNITY_STATUS = 'Won-closed' then T33142.TOTAL_OPPORTUNITY_AMOUNT_USD else 0 end ) as c1,
T28761.QUARTER_YEAR_NAME as c2,
T28761.QUARTER_RANK as c3
from
XXFI.XXFI_GL_FISCAL_MONTHS_V T28761 /* Dim_Periods */ ,
XXFI.XXFI_OSM_OPPTY_HEADER_ACCUM T33142 /* Fact_Opportunity_Headers(CloseDate) */ ,
XXFI.XXFI_OSM_OPPTY_LINE_ACCUM T33231 /* Fact_Opportunity_Lines(CloseDate) */
where ( T28761.PERIOD_NAME = T33142.CLOSE_PERIOD_NAME and T28761.QUARTER_YEAR_NAME = '2012-Q3' and T33142.LEAD_ID = T33231.LEAD_ID and T33231.LINES_BUSINESS_TYPE = 'New Business' and T33142.OPPORTUNITY_STATUS <> 'Duplicate' )
group by T28761.QUARTER_YEAR_NAME, T28761.QUARTER_RANK),
SAWITH1 AS (select distinct 0 as c1,
D1.c2 as c2,
'Bookings2' as c3,
D1.c3 as c4,
D1.c1 as c5
from
SAWITH0 D1),
SAWITH2 AS (select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
D1.c5 as c5,
sum(D1.c5) as c6
from
SAWITH1 D1
group by D1.c1, D1.c2, D1.c3, D1.c4, D1.c5)
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4, D1.c5 as c5, D1.c6 as c6 from ( select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4,
D1.c5 as c5,
sum(D1.c6) over () as c6
from
SAWITH2 D1
order by c1, c4, c3 ) D1 where rownum <= 2000001
Thank you,
Mike
Edited by: Mike Jelen on Jun 7, 2013 2:05 PM

Thank you for the info. They are definitely different values since ones on the header and the other is on the lines. As the "Won Opportunity" logical column is mapped to multiple LTS it appears the OBI 11 uses a different alogorthim to determine the most efficient table to use in the query generation vs 10g. I'll need to spend some time researching the impact to adding a 'sort' to the LTS. I'm hoping that there's a way to get OBI to use similar logic relative to 10g in how it generated the table priority.
Thx again,
Mike

Multiples LTS

Similar Messages

Maybe you are looking for