Comparing facts of different dimension levels - drilldown problem.

With our customer, we do a lot of comparisons of sales budgets vs. actual sales. The sales budgets are given per month, like this:
Sales budgets: Jan 09: 40,000 EUR, Feb 09: 45,000 EUR, Mar 09: 20,000 EUR... and so on.
There is a time dimension (year -> quarter -> month -> day). Since BI does not seem to allow binding facts to other dimension levels than the lowest one (day in my example), I used a trick and modelled these sales budgets as a fact table: (expected sales, last_day_of_month)
So I have this:
Sales budgets: 01/31/09: 40,000 EUR, 02/28/09: 45,000 EUR... and so on.
This way, I can connect both actual sales and sales budgets to the same time dimension. With this, I can create an answers report that compares the two facts easily.
The problem is now that the customer wants to drill down. This is no problem with year->quarter->month. But then, BI naturally allows to drill further to day, and in this case, BI compares the sales budget of 01/31/09 with the sales on 01/31/09, producing wrong values.
I either need a solution to prevent BI from drilling down from the month level in this special answer report, or maybe I am making an error with my modelling. Are there any ideas on how to do this better?

Hi,
I'd model the repository differently, by modeling the actual sales fact on the lowest day level, and sales budget fact on monthly level. That's how I've understood the data really is defined, right? (Lowest level physical time table you already have but for sales budget you need to create also a physical time table which is on the month level. First define the correct physical joins. Then define the logical table sources in the BM layer accordingly.) In order to be able show the sales budget together with lowest level you can create the sales budget measure as a level based measure (fix the measure to the level month in the column properties-->Level in the Administration tool).
If you just want to prevent users from drilling-down on a specific dashboard report you can go to properties of the column(s) in that report and set the interaction type for both title and values to "No interaction" in the second tab of the properties menu in the front-end.
Hope this helps!
Cheers,
Ilmari

Similar Messages

2 facts with different dimensions in 1 logical table

hello,
im trying to accomplish the set up as described per blog:
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
i.e. i have 2 facts, F1: D1 ; F2: D1,D2,D3;
i followed the instructions and all seem to be working fine;
however: when i put the total on the report in Answers: D1,D2, F1, F2 then the measures from F1 that are repeated every row for D2 are being added , like regular sum on the column; this is not correct;
the only correct result i can get if manually i change the Aggregation Rule to :Server Complex Aggregate on all F1 measures;
id like to ask if this is a bug of this OBI version? 10.1.3.2
i wish not to instruct my users to change the aggregation rule; id like to have the set up via rpd such, that they dont have to manipulate the aggregation rules;
did anyone got the above working with correct totals without changing the aggregation rule?
if so, id appreciate any tips on how to achieve that
thanks
rgds

Basically, you need to :
* create your physical schema with the relationship
* drag and drop your Forecast Facts measure in the same logical table than your sales fact
* define your Forecast measure as level based measure (logical column/levels/properties) with the grain of the forecast table
Documentation
http://download.oracle.com/docs/cd/E12103_01/books/admintool/admintool_BusModSetup12.html
And you have an example in OBE series with quota in excel sheet :
http://www.oracle.com/technology/obe/obe_bi/bi_ee_1013/bi_admin/biadmin.html#t8
Success
Nico

OBIEE Group By on 2 facts and concatenated columns from different dimensions

Hi
I have a different kind of problem involving 2 fact tables with different dimensional attributes.
Fact 1 has Dim Attributes ( Cust,Facility )
Measure - Gross Amount
Fact2 has Dim attributes (Cust,Facility and Risk Group )
Measure : Exposure Amount
Since we have 2 facts with different dimensions,
to exclude the 'Risk Group' dimension column from the group by for the Fact1,
we set the 'Gross Amount' measure to total level (Risk Group Dimension ) in contents tab.
So the values from both the fact tables appears in the same report correctly.
But in the same report we have another requirement where the rating column from the customer dimension has to be concatenated with the ratings column in the facility dimension.
We have to concatenate customer.rating with the facility.rating and display it in the report.
when we just pull the individual columns from the dimensions into the report it works fine.
But when we try to concatenate the 2 columns and show it in the report,
the concatenated column does not appear in the select or the group by in the SQL Fact2.( Generated by OBIEE )
The other fact1 has the concatenated column in the select as well as the group by clause ( Generated by OBIEE )
As a result the report shows the concatenated values only for the results from the Fact1. But the results from Fact2 does not have the concatenated column values.
The report should look like the below:
Custor.Name,     Customer.Id,     Facility.Name,     Facility.Id,     Customer.Rating/Facility.Rating,     Risk Group,     Gross Amount,     Exposure Amount
===========    =========      ===========     =========   ========================      =========     ===========     ===============
JPMC                123                    GROSS               123               08/10                                                  LNL                    45,000               25,000
CLAIRE               456                    NET                    456               07/10                                                  RNK                    50,000               30,000
Thanks,
Chandra

As suggested you really want to move your none-aggregated fact attributes to a logical dimension (using the same physical table as the logical fact). Map this in the BMM layer as a snowflake, Place a hierarchy on this dimension with (at minimum) Total -> Detail levels, then on the other fact table you want to include in the report, set the content level on your other fact measures to the 'Total' level for your new logical Dim and it will allow them to be present in the same report.

Join fact table with higher dimension level

how do i join fact tables with higher dimension levels with discoverer?
fact with detail at level C
measure X
dimension with
D->C->B->A
E->C
level
A B C
1------1------1
2------2------1
3------2------1
join between fact X and dimension level C
X=3*C because of sum(X) in discoverer and 3xC in dimension
is there a way to get correct values for X without creating a dimension like
D->C
E->

another way of asking this is whether you can create a summary table in Discoverer at a higher level than a dimension's fundamental grain. In other words - the summary examples in the documentation all describe leaving out one or more of your dimensions... they are either left in or completely taken out. But, some of the most effective summarization occurs when you summarize daily data to a monthly level. Assuming that I have a sales table (at a daily level, and a key value sales_date), and a table date_dim (primary key sales_date), I would like to create a summary sales_month_summary where the sales are grouped on month_year (which is a field in the sales_date table).
How is this done? I suspect that we can't use the date_dim table with the summary (due to the problems noted by the poster above). Do we have to create another table "month_dim"? Do we have to fold all of the desired date attributes (month, quarter, year) into the summary? Obviously we'd like to re-use all of the pertinent already existing date items (quarter, month, year, etc.), not recreate them over again, which would result in essentially two sets of items in the EUL. [One used for this month summary, and another used for the detail.]
I searched the forum - someone asked this same question back in 2000 - there was no answer provided.
The only other thought I have is to "snowflake" the date_dim into two tables and two folders, one at a date level, another at the month level. Then the detail tables can connect to date_dim (which is linked to month_dim), while the summary data can connect directly to month_dim.

Relating facts to different levels of a dimention

Dear All,
I need to relate a fact to optionally different levels of a hierarchy in a dimension
that's sales plan may be put on the level of a salesman or a distributor or a channel and so on ...
I think that it could be implemented by adding a dummy record in a each level that represent the parent .. but i don't konw how to add this dummy record in owb ...
can you help ..
Regards,
Shaimaa

Hi Shaimaa,
this is actually a very difficult business question. Technically, it's straightforward.
The easy part is to create one fact table per dimension level where you have a plan. So, you would have a SalesPersonPlanFact, a SalesManagerPlanFact, and so on. That will work technically . . .
But it won't really work. :-(
The reason is that the way these plans are created. Typically, the Boss and his guys work out a master plan. Then it gets broken into bits, and each department does their own sub-plan. All the way down, until it gets to individual sales plans. And at every step of the way, the plan gets tweaked, modified, 'special cases' put in.
The result is that they never add up. How you resolve that is a business issue, not a technical one.
Me? What I do is tell people that they won't add up, and then say that it doesn't matter anyway. The reason I give is that the purpose of the plan is to measure actual sales performance against plan, and that we can do. Sales take place at the most atomic level for which there is a plan, and these we can match and consolidate plan against actuals. The consolidated results are then MVed and thus present a high-performance single picture of 'the truth'.
Realistically, you're building a second-level snapshot (could be aggregated, could be periodic, could be both), and that's your reporting structure.
I suspect you may need to go and have a re-think about your value chain, and do much communication with your sponsors so that they understand what's achievable and of real worth to the business. After all, your business as a data warehouse architect is to ensure you're publishing the right data.
Cheers,
Donna

One Dimension with Facts at different levels

I currently have a single dimension with 5 levels. I have two fact tables that both connect to the dimension table but at different levels.
For example. If we have a Dimension Country -> Region -> City and then two fact tables. One that has facts at the Region level and one that has facts at the City level.
Is there a way to be able to have an answer that contains facts from both fact tables. So if there was a fact from City and the Region level? Everything I seem to try does not work. Would I have to create an additional aggregate table that aggregates the City level data up to the Region? Or is there a way to show the data at the lowest level and show either nulls or duplicate values for the additional records.
Any help is greatly appreciated

This has helped a little. I am now getting values from both levels. However, because i am summing the two values. The value from the upper level is now summing duplicate values. For example.
Value 1 on its own
Level1 Level 2 Level 3 Value 1
1234 10 10 13.05
1234 20 10 70.00
1234 20 20 70.00
1234 30 10 105.00
1234 30 20 105.00
Value 2 on its own
Level1 Level 2 Level 3 Value 2
1234 10 10 0.50
1234 20 10 2.00
1234 20 20 2.00
1234 30 10 3.00
1234 30 20 3.00
What I am getting
Level1 Level 2 Level 3 Value 1 Value 2
1234 10 10 13.05 0.50
1234 20 10 140.00 2.00
1234 20 20 140.00 2.00
1234 30 10 210.00 3.00
1234 30 20 210.00 3.00
Desired Outcome
Level1 Level 2 Level 3 Value 1 Value 2
1234 10 10 13.05 0.50
1234 20 10 70.00 2.00
1234 20 20 70.00 2.00
1234 30 10 105.00 3.00
1234 30 20 105.00 3.00
Now, the problem with this is that Value 1 is a fact at Level 2 and Value 2 is a fact at Level 3. I have one dimension table and two fact tables. The join between the fact table for Value two and the dimension table is the same as the join between the dimension table and Value 1 only it is missing the last level of detail.
I have then set the logical table source content tabs for each fact table to the corresponding levels.
I thought this would be enough but i still don't get the desired result. I am not sure if this is possible with one dimension table.
Any ideas would be greatly appreciated.
Edited by: user10800227 on Jan 11, 2010 12:43 PM

OBIEE Facts at different levels.

Hi,
I am bringing columns from three tables: Two facts and one Dimension table to create a OBIEE Report.
The fact tables Workforce Event Fact and Employee Daily Snap Fact are at different levels, but both of them have proper joins with Dimension Employee Dim.
When i am pulling columns from D1 and any one of these two facts, i am not facing any problem in seeing results. But when i bring columns from all of these three tables, i am getting this error,
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table Workforce Event Fact) does not contain mapping for [Employee Daily Snap Fact.Exempt Indicator]. (HY000)
Is there anything i have to do in Business Model layer to avoid this error. Many people suggesting to assign an aggregation level for these two facts. But i am not having any Dimensional Hierarchy defined.
Thanks
Swami

Hi swami,
Many people suggesting to assign an aggregation level for these two factsThis is a workaround i think where you need to create aggregate tables(not levels) and then use them for your purpose.(OR) you dint define the logical source table properly either correct it.
Another work around i could suggest is,take the 2 fact tables columns needed into one alias table and make it as fact and join this fact table to dimension table and you can get all columns.
Hope it helps you.
Best Wishes,
Kranthi.

Joining Facts With Different Grains to NonConfirming Dimensions - Mystery

Hi ,
Taxonomy Used is - CD stands for Confirmed Dimension && NCD stands for Non Confirmed Dimension.
I have 3 Dimensions (CD1,NCD2,NCD3) and 2 facts (F1 & F2).
==> Fact F1 can be joined to only CD1 and NCD2 dimensions. Grain of Fact F1 is same as CD1 i.e., Nbr of records matches 1 to 1 between CD1 and F1F2
==> Fact F2 can be joined to only CD1 and NCD3 dimensions. Grain of Fact F2 is CD1 & NCD3. There could be multiple records for same value of CD1 within Fact F2, and similarly there could be multiple records for same value of NCD3. But there will always be just 1 and only 1 record for combination of CD1 and NCD3.
Report Requirements:-
1) Get few Metrics from F2 and few from F1 while applying a filter on NCD2. so below columns are needed :-
Dimension Column from NCD2 || Metric from Fact1 || Metric from Fact2
So need to understand how to enforce the relationship between Fact F2 and Dimension NCD2
2) Get few Metrics from F2 and few from F1 while applying a filter on NCD2 and also Display NCD3. so below columns are needed :-
Dimension Column from NCD2 || Dimension Column from NCD3 ||Metric from Fact1 || Metric from Fact2
==> In above case it is perfectly acceptable if Metric from Fact 1 repeats again as Fact1 is at higher Grain as compare to Fact2.
Edited by: user10799880 on Apr 15, 2013 9:37 PM

Hi,
refer to this
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
mark helps
thanks

Multiple Fact Tables and Dimension Tables

I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
Thank you in advance for anyones time. :)
Dimension Tables
WorkOrder_D
Operation_D
Resource_D
Organization_D
Fact Tables
WorkOrder_F
Operation_F
Resource_F
Joins
WorkOrder_D -> Operation_D
Operation_D -> Resource_D
WorkOrder_D -> WorkOrder_F
Operation_D -> Operation_F
Resource_D -> Resource_F
Organization_D -> WorkOrder_D
Organization_D -> Operation_D
Organization_D -> Resource_D

Hi,
Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

Aggregating data loaded into different hierarchy levels

I have some problems when i try to aggregate a variable called PRUEBA2_IMPORTE dimensinated by time dimension (parent-child type).
I read the help in DML Reference of the OLAP Worksheet and it said the follow:
When data is loaded into dimension values that are at different levels of a hierarchy, then you need to be careful in how you set status in the PRECOMPUTE clause in a RELATION statement in your aggregation specification. Suppose that a time dimension has a hierarchy with three levels: months aggregate into quarters, and quarters aggregate into years. Some data is loaded into month dimension values, while other data is loaded into quarter dimension values. For example, Q1 is the parent of January, February, and March. Data for March is loaded into the March dimension value. But the sum of data for January and February is loaded directly into the Q1 dimension value. In fact, the January and February dimension values contain NA values instead of data. Your goal is to add the data in March to the data in Q1. When you attempt to aggregate January, February, and March into Q1, the data in March will simply replace the data in Q1. When this happens, Q1 will only contain the March data instead of the sum of January, February, and March. To aggregate data that is loaded into different levels of a hierarchy, create a valueset for only those dimension values that contain data. DEFINE all_but_q4 VALUESET time
LIMIT all_but_q4 TO ALL
LIMIT all_but_q4 REMOVE 'Q4'
Within the aggregation specification, use that valueset to specify that the detail-level data should be added to the data that already exists in its parent, Q1, as shown in the following statement. RELATION time.r PRECOMPUTE (all_but_q4)
How to do it this for more than one dimension?
Above i wrote my case of study:
DEFINE T_TIME DIMENSION TEXT
T_TIME
200401
200402
200403
200404
200405
200406
200407
200408
200409
200410
200411
2004
200412
200501
200502
200503
200504
200505
200506
200507
200508
200509
200510
200511
2005
200512
DEFINE T_TIME_PARENTREL RELATION T_TIME <T_TIME T_TIME_HIERLIST>
-----------T_TIME_HIERLIST-------------
T_TIME H_TIME
200401 2004
200402 2004
200403 2004
200404 2004
200405 2004
200406 2004
200407 2004
200408 2004
200409 2004
200410 2004
200411 2004
2004 NA
200412 2004
200501 2005
200502 2005
200503 2005
200504 2005
200505 2005
200506 2005
200507 2005
200508 2005
200509 2005
200510 2005
200511 2005
2005 NA
200512 2005
DEFINE PRUEBA2_IMPORTE FORMULA DECIMAL <T_TIME>
EQ -
aggregate(this_aw!PRUEBA2_IMPORTE_STORED using this_aw!OBJ262568349 -
COUNTVAR this_aw!PRUEBA2_IMPORTE_COUNTVAR)
T_TIME PRUEBA2_IMPORTE
200401 NA
200402 NA
200403 2,00
200404 2,00
200405 NA
200406 NA
200407 NA
200408 NA
200409 NA
200410 NA
200411 NA
2004 4,00 ---> here its right!! but...
200412 NA
200501 5,00
200502 15,00
200503 NA
200504 NA
200505 NA
200506 NA
200507 NA
200508 NA
200509 NA
200510 NA
200511 NA
2005 10,00 ---> here must be 30,00 not 10,00
200512 NA
DEFINE PRUEBA2_IMPORTE_STORED VARIABLE DECIMAL <T_TIME>
T_TIME PRUEBA2_IMPORTE_STORED
200401 NA
200402 NA
200403 NA
200404 NA
200405 NA
200406 NA
200407 NA
200408 NA
200409 NA
200410 NA
200411 NA
2004 NA
200412 NA
200501 5,00
200502 15,00
200503 NA
200504 NA
200505 NA
200506 NA
200507 NA
200508 NA
200509 NA
200510 NA
200511 NA
2005 10,00
200512 NA
DEFINE OBJ262568349 AGGMAP
AGGMAP
RELATION this_aw!T_TIME_PARENTREL(this_aw!T_TIME_AGGRHIER_VSET1) PRECOMPUTE(this_aw!T_TIME_AGGRDIM_VSET1) OPERATOR SUM -
args DIVIDEBYZERO YES DECIMALOVERFLOW YES NASKIP YES
AGGINDEX NO
CACHE NONE
END
DEFINE T_TIME_AGGRHIER_VSET1 VALUESET T_TIME_HIERLIST
T_TIME_AGGRHIER_VSET1 = (H_TIME)
DEFINE T_TIME_AGGRDIM_VSET1 VALUESET T_TIME
T_TIME_AGGRDIM_VSET1 = (2005)
Regards,
Mel.

Mel,
There are several different types of "data loaded into different hierarchy levels" and the aproach to solving the issue is different depending on the needs of the application.
1. Data is loaded symmetrically at uniform mixed levels. Example would include loading data at "quarter" in historical years, but at "month" in the current year, it does /not/ include data loaded at both quarter and month within the same calendar period.
= solved by the setting of status, or in 10.2 or later with the load_status clause of the aggmap.
2. Data is loaded at both a detail level and it's ancestor, as in your example case.
= the aggregate command overwrites aggregate values based on the values of the children, this is the only repeatable thing that it can do. The recomended way to solve this problem is to create 'self' nodes in the hierarchy representing the data loaded at the aggregate level, which is then added as one of the children of the aggregate node. This enables repeatable calculation as well as auditability of the resultant value.
Also note the difference in behavior between the aggregate command and the aggregate function. In your example the aggregate function looks at '2005', finds a value and returns it for a result of 10, the aggregate command would recalculate based on january and february for a result of 20.
To solve your usage case I would suggest a hierarchy that looks more like this:
DEFINE T_TIME_PARENTREL RELATION T_TIME <T_TIME T_TIME_HIERLIST>
-----------T_TIME_HIERLIST-------------
T_TIME H_TIME
200401 2004
200402 2004
200403 2004
200404 2004
200405 2004
200406 2004
200407 2004
200408 2004
200409 2004
200410 2004
200411 2004
200412 2004
2004_SELF 2004
2004 NA
200501 2005
200502 2005
200503 2005
200504 2005
200505 2005
200506 2005
200507 2005
200508 2005
200509 2005
200510 2005
200511 2005
200512 2005
2005_SELF 2005
2005 NA
Resulting in the following cube:
T_TIME PRUEBA2_IMPORTE
200401 NA
200402 NA
200403 2,00
200404 2,00
200405 NA
200406 NA
200407 NA
200408 NA
200409 NA
200410 NA
200411 NA
200412 NA
2004_SELF NA
2004 4,00
200501 5,00
200502 15,00
200503 NA
200504 NA
200505 NA
200506 NA
200507 NA
200508 NA
200509 NA
200510 NA
200511 NA
200512 NA
2005_SELF 10,00
2005 30,00
3. Data is loaded at a level based upon another dimension; for example product being loaded at 'UPC' in EMEA, but at 'BRAND' in APAC.
= this can currently only be solved by issuing multiple aggregate commands to aggregate the different regions with different input status, which unfortunately means that it is not compatable with compressed composites. We will likely add better support for this case in future releases.
4. Data is loaded at both an aggregate level and a detail level, but the calculation is more complicated than a simple SUM operator.
= often requires the use of ALLOCATE in order to push the data to the leaves in order to correctly calculate the aggregate values during aggregation.

Join multiple fact tables and dimensions and use all tables in report issue

Hi,
I have a report requirements and need to use multiple fact tables and unconformed dimensions as described below
Fact table: F1,F2,F3
Dimensions tables: D1.....D9
F1:(joined to) D1,D2,D3,D4
F2::(joined to)D1,D2,D5,D6
F3::(joined to)D1,D2,D7,D8
D7::(joined to)D9,D8 (dimension D7 joined to two other dimensions D9 and D8
I'm trying to use columns from almost all the fact and dimension tables but getting "Unable to navigate requested expression. Please fix the metadata consistency warnings."
Repository is consistent and no errors and warnings.
How can I configure the repository to develop reports using all fact tables and dimensions?
Appreciate for your help.
Thanks
Jay.
Edited by: Jay on Feb 9, 2012 4:14 PM

So you want me to convert snowflake schema to star. does it solve my problem? individual star queries are working find but when I query multiple stars together getting inconsistency errors. I removed content tables dim level totals for unconformed dimensions in logical fact LTS and set level for measures at total level for unconformed dimensions. it is still in progress and need to test.
Thanks
Jay.

How to compare content in different versions of case?

Need to compare attributes of tables, columns, sequences etc between case115 and case121. Think I should be able to use views like ci_table_definitions to do that so tried setting up an account that dblinks to the different case dbs. Problem seems to be that I get duplicate rows retrieved from those views. If I sqlplus directly into case115
and run exec jr_context.set_workarea('GLOBAL SHARED WORKAREA') it seems to setup session so the view gives single row. So is there some sql to add to a query running from my dev account that would achieve the same filter? Alternativly is the source for jr_context available so I can build that in dev account? Any better ideas?
Thanks , Aidan

Thanks John, I'll look into that approach. This repository is shared by 100s of developers across multiple products so I'm not sure what licence I have to do much in the repository itself. Also although case115 is older version its still being updated - the requirement is not exactly to sync 4 different codelines as new features are added in later codelines but need to do comparisons to verify all essential updates have been made in different levels of schema.
Still be interested if anyone has a method of implementing the filter to avoid duplicate rows retrieved from these views. Currently just using a very basic rownum filter to avoid cartesian:
select ' '
,decode(case115.AUTO_GENERATED,case121.AUTO_GENERATED, null, 'CI_COLUMNS|'||case115_td.name||' | '||case115.name||' | AUTO_GENERATED | case115 | '||case115.AUTO_GENERATED||' | <> case121 | '||case121.AUTO_GENERATED)
,decode(case115.AVERAGE_LENGTH,case121.AVERAGE_LENGTH, null, 'CI_COLUMNS|'||case115_td.name||' | '||case115.name||' | AVERAGE_LENGTH | case115 | '||case115.AVERAGE_LENGTH||' | <> case121 | '||case121.AVERAGE_LENGTH)
.... generated select for all columns in a ci view
from
( select CC.rowid col_rowid, CC.NAME col_name, CC.ivid col_ivid,
CTD.ID ID, CTD.IVID IVID, CTD.NAME NAME, CTD.ALIAS ALIAS,
CTD.USER_DEFINED_PROPERTY_18 USER_DEFINED_PROPERTY_18
from CASE115_TABLE_DEFINITIONS CTD, CASE115_COLUMNS CC
where CTD.name like upper('&table%')
and cc.TABLE_REFERENCE = CTD.id
and cc.rowid = ( select cc_2.rowid from CASE115_COLUMNS cc_2
where cc_2.ID = cc.ID
and rownum = 1)
and CTD.rowid = ( select case115_TD_2.rowid from CASE115_TABLE_DEFINITIONS case115_TD_2
where case115_TD_2.ID = CTD.ID and ROWNUM = 1)) CASE115_TD,
( select CC.rowid col_rowid, CC.NAME col_name, CC.ivid col_ivid,
CTD.ID ID, CTD.IVID IVID, CTD.NAME NAME, CTD.ALIAS ALIAS,
CTD.USER_DEFINED_PROPERTY_18 USER_DEFINED_PROPERTY_18
from CASE121_TABLE_DEFINITIONS CTD, CASE121_COLUMNS CC
where CTD.name like upper('&table%')
and cc.TABLE_REFERENCE = CTD.id
and cc.rowid = ( select cc_2.rowid from CASE121_COLUMNS cc_2
where cc_2.ID = cc.ID
and rownum = 1)
and CTD.rowid = ( select case121_TD_2.rowid from CASE121_TABLE_DEFINITIONS case121_TD_2
where case121_TD_2.ID = CTD.ID and ROWNUM = 1)) CASE121_TD,
CASE115_COLUMNS case115, CASE121_COLUMNS case121
where CASE115.rowid = CASE115_TD.col_rowid
and CASE121.rowid = CASE121_TD.col_rowid
and case115_TD.name = case121_TD.name(+)
and case115_TD.col_name = case121_TD.col_name(+)
ORDER BY CASE115_TD.name, CASE115.order_sequence, CASE115_TD.col_name
So this works from a dev db that dblinks to 4 case repository dbs. Sql generates lots of blank lines that are stripped out. Its pretty slow! So be useful to replace the rownum filter with equivelent of jr_context.set_workarea('GLOBAL SHARED WORKAREA')
Regards, Aidan

Two facts with conformed dimension

Starting new thread per Alistair's request :)
I have two facts
Class Enrollment (who is enrolled in which classes)
External Test Scores (who got what score on what exam)
The only dimension they have in common is "Person".
Is it possible to build a presentation layer that includes both facts, the Person dimension, and dimensions that related to one fact but not the other (e.g. dimension "External Test Type" or dimension "Course")?
How would I set up the BI metadata to answer the question:
What was the average grade for Course ABC for students who scored above a 50 on test XYZ?
So far, for External Test Scores fact, I have created hierarchies(/dimensions) for any related dimension tables that didn't already have hierarchies defined. I then went to the Content tab for External Test Scores and set aggregation levels (lowest level for everything related to the fact, "total" level for everything NOT related to the fact).
I put both facts and the "Person" dimension into a presentation folder. I can query test scores ok, but when I add in a simple "Row Count" column from class enrollment, I get no data back.
Do I now go back and do the same Content tab settings for the Class Enrollment fact? My initial attempts at this yielded consistency check warnings of "Logical table source does not join to any fact source".
Huge thanks for suggestions.
-John

Hi John,
I tend to harp on a lot about the need for a hierachy on every logical dim, even just total -> detail. It allows this (non-conformed) approach for starters, also allows another developer to quickly ascertain the relationship between objects.
About the complex joins, I meant do as you will have done for a normal star with just the conformed dims, so thats Foreign keys where applicable in the Phyiscal layer, and Complex joins where applicable in the BMM layer. I just wanted to make a point that you should do this as per a normal normal star schema with fully conformed dimensions, and merely that the none-conformed dimension will only be connected to its relevant fact table - probably didnt need to say it as it may be more confusing!
Your correct with aggregation rules, ideally all objects in a logical fact should have an aggregation rule - otherwise it should be in a logical dimension.
As to the approach, this is the way i've always handled non-conformed dimensions when the requirement is to see both facts on the same report. Our Peak Indicators OBIEE training material on this subject is as follows :
"order" fact table, dimensioned by Date, Customer, Product.
"inventory" fact table dimensioned by Product only.
Report requirement - Show me all orders where the order_qty (order fact) is greater than the total qty in stock (inventory fact)
So like your example, we sum up both qty's and use a where clause to filter only rows where one fact measure is greater than another measure.
Whats the ideal approach ??
If you had control of the ETL perhaps you could seed an 'unknown' record in the non-conforming dimensions, and then reference this on the other fact table, but I'd say the majority of the time, the customer who wants everything by everything in their subject area needs a little education, its really not good for end users having 10's of folders with 10's of columns - we should be creating analysis subject areas to enable the answering of business questions, theres no reason why we cant combine reports from different subject areas on one dashboard page, all using a common set of prompts, but there really isnt a need to give an end user the whole BMM / DW etc in one go.......unless they are paying of course, and after you've tried to educate them they want it there way :-)

Relating facts with different grains

I'm having an issue designing a cube/star schema where I need to relate 2 fact tables that are at a different grain.
I currently have a star with 1 fact table (Insurance Premium) and 3 dimensions (Date, Account, Policy). The fact table has 1 row for each policy within each account for every quarter (quarterly snapshot). The measure is Premium.
We need to enhance this star with a new fact table that stores Lost Accounts for each quarter. The difference with this data is that we only get it at the Account Level. So the Fact table will have 1 row for each lost account per quarter. The
measure is Lost Premium.
I created the Lost Business Fact table which relates to the same Date and Account dimension as the Insurance Premium Fact table. In the cube, i created a new measure group for the Lost Premium fact table and related it to the same Date and Account
dimensions.
the 2 issues that I am having are:
1. In the Policy Dimension table, there is a field called AccountBroker, which stores the Broker for the account. So if the account has 5 policies, this table will have 5 rows and the AccountBroker field will be the same for each row. The
end users want to be able to use this field (AccountBroker) in the Lost Premium Fact table so that they can slice and dice the Lost Premium by Account Broker. The issue is that I'm not sure how to relate the Lost Premium Fact to the Policy Dimension
since the Lost Premium Fact is at Account level and the Policy Dimension is at Policy Level.
2. The other issue is that when we receive the Lost Business File for each quarter, the account may not be present in the Premium Fact because it was lost. So for example, for Q1 2014, account 1234 was lost and we receive a record in the Lost
Business File with Account 1234 as being lost and it gets inserted into the Lost Premium Fact. However, when we get the file that loads the Insurance Premium Fact for Q1 2014, this account is not present because it was lost in that quarter, so there
is no way to link the records. My first thought was to maybe take the records from the previous quarter (Q4 2012) and insert those records for Q1 2014 into the Insurance Premium Fact with 0 premium so that they exist and then there will be a match, but
not sure if there is a better design.
any ideas would be appreciated.
thanks
Scott

For me,
DEPT_FACT is not a fact. It's a dimension table because you have a one-to-many relationship and you have a measure in the dimension table (it's an aggregated measure).
And EMP_FACT is also not a fact because you don't have any measure on it.
But if we say that EMP_FACT is a fact. DEPT_FACT is an aggregated table from EMP_FACT.
I will :
* create a logical dimension for the employee with three levels (all, departement and detail)
* create a logical fact table with :
- one logical column for the revenue in the level all departement
- one logical column for the employee
and two physical source :
* DEPT_FACT with the departement level
* EMP_FACT with the level to detail
Success
Nico

Concatenate 2 columns from 2 different dimension tables

Hi,
I have 2 columns one from each dimension table.
Column A from Dimension 1 and Column B from Dimension 2.
In my answers i want the results as "dim1.Col A / Dim2.Col B".
I used the concatenate function and it dint give me the results. Both the columns are Non Numeric columns.
I use 2 fact tables in my analysis and data from both the fact tables are combined in 1 analysis.
There are non confirming dimensions between the 2 facts and hence we used hierarchies and level based measures to overcome the issue of non conforming dimensions between the 2 facts.
Any ideas on how to concatenate the 2 different dimension columns into the report ?
Thanks,
Chandra

never mind, i did it using summary columns, thanks

Comparing facts of different dimension levels - drilldown problem.

Similar Messages

Maybe you are looking for