Conformed dimensions across several fact tables

Hi, not exactly sure how to phrase my question, so I'll just start babbling and maybe it'll come across. In our OBIEE repository (from BI applications "project analytics"), we have dimensions of CONTRACT, CONTRACT LINE, PROJECT, and TASK (CONTRACT and CONTRACT_LINE really come from a single dimension table, but are different rows and so really can be thought of as coming from two different dim tables). TASKs are really children of projects - but they were broken out into a separate dimension in the data model (no idea why....). Also, in our business, a task can be tied to one and only one contract line.
Now here's the rub - because TASK is a separate dimension from PROJECT, there is really nothing that relates them except through a fact table. This is a real pain, as it has two limitations:
1) If a "fact" for that combination of PROJECT / TASK hasn't happened yet, then no row in fact table = nothing that says they are related
2) Even if you do have a fact for everything - now our query is scanning through a fact table of (in our case) 300+ million rows, just to say which task is tied to which project
I'd like to solve this by creating a very simple "factless fact" which has columns for CONTRACT, CONTRACT LINE, PROJECT, and TASK, and simply inserts the appropriate surrogate IDs (wids) into this. Thus, instead of a 300+ million row fact table, we should be down to only 400,000 or so task / project / line / contract combos.
Now here's my question: I have a "combined" subject area that includes a project cost, project revenue, project billing, and in theory this new fact table I'm talking about. I'd want to set the new fact table to be the "implicit" fact - so that if someone just asks a questions like "show me contract lines, and which projects and tasks are assigned to it" - it would go to the new, slim, fast fact table.
But I'm concerned about what happens when someone then throws in a cost amount, revenue amt, etc. onto the query. I'm assuming that OBIEE will be smart enough to understand it should forget the implicit fact, and start using the "real" facts. Or maybe use all of them including the new fact.
I'm just trying to see if I can anticipate this causing any issues.
Thx,
Scott

You are correct, the implicit fact will only be used when there isn't any other fact measure defined in your query. Unfortunatelly you can only define an implicit fact per SA, we would love to be able to have more flexibility such as defining them per dimension etc. Another way to "force" OBIEE to select from an specific fact is to select a column from it in your Answers query. You don't to see this column in output so you can hide it. Of course this "hack" is not really very user friendly as it makes adhoc query building much more complex.

Similar Messages

Dimension which belongs to only one of the several fact tables

Hi,
I'm newbie in BI. I have good knowledge of DW and Administration (OCP).
Firstly could you give me, please some link expalining aspects of creating "Business Model And Mapping" better than SE Tutoarial.
Now how my problems looks like :
I have several fact tables and dimensions.
But not all dimensions are shared among all facts.
So when i try to put in Answers measurements from all facts it's ok - results are retrieved.
But when i try to add to report some Dimensions attributes which belongs to only one of the facts all facts measurements are gone except measurements for fact table to which dimension attribute is linked to.
I think i know what is the reason but i don't know how to simply solve it :
Below is session trace excerpt only with facts measurements :
RqList
Liczba Transakcji:[DAggr(Fakty - Transakcje (ZSFK).Liczba Transakcji by [ Słownik - Daty.Nr Miesiąca, Słownik - Daty.Miesiąc Rozliczenia, Słownik - Outlety.Outlet Numer (MID), Słownik - Outlety.Outlet Nazwa, Słownik - Terminale.Nr Terminala, Słownik - Daty.Rok Rozliczenia] )] as c7 GB,
Kwota Opłaty Netto:[DAggr(Fakty - Opłaty za Terminale (CBD).Kwota Opłaty Netto by [ Słownik - Daty.Nr Miesiąca, Słownik - Daty.Miesiąc Rozliczenia, Słownik - Outlety.Outlet Numer (MID), Słownik - Outlety.Outlet Nazwa, Słownik - Terminale.Nr Terminala, Słownik - Daty.Rok Rozliczenia] )] as c11 GB,
Below iis session trace excerpt with facts measurements and added dimension attribute:
RqList
Liczba Transakcji:[DAggr(Fakty - Transakcje (ZSFK).Liczba Transakcji by [ Słownik - Rodzaje Walut.KOD_WALUTY, Słownik - Daty.Nr Miesiąca, Słownik - Daty.Miesiąc Rozliczenia, Słownik - Outlety.Outlet Numer (MID), Słownik - Outlety.Outlet Nazwa, Słownik - Terminale.Nr Terminala, Słownik - Daty.Rok Rozliczenia] )] as c7 GB,
Kwota Opłaty Netto:[DAggr(Fakty - Opłaty za Terminale (CBD).Kwota Opłaty Netto by [ Słownik - Rodzaje Walut.KOD_WALUTY, Słownik - Daty.Nr Miesiąca, Słownik - Daty.Miesiąc Rozliczenia, Słownik - Outlety.Outlet Numer (MID), Słownik - Outlety.Outlet Nazwa, Słownik - Terminale.Nr Terminala, Słownik - Daty.Rok Rozliczenia] )] as c12 GB,
Second plan is the plan when report retrieves only results for one fact table and null's for others
Problem is with attribute : "Słownik - Rodzaje Walut.KOD_WALUTY" which is from dimension which belongs only to one fact table.
So other fact table are not linked to this dimension and therefore this plan cannot retrieve results for them.
It is obvious that some of the facts cannot share some dimensions with others but i would like to join them on other common attribute
and my question is how ?
Thanks's in advance Arkadiusz Masny
Edited by: Arkadiusz Masny on Dec 10, 2009 6:49 AM

It's normal behavior. How would fact measure know the value for accurate "non-fact" dimension
Workaround:
First solution is:
Add into logical source of each fact (in logical layer) tables to which belongs dimension attribute and join dimenstion to that fact.
Second you may:
Create fact table which join all needed dimensions with some useless fact ( i.e. count). Next you have to set option "Implicit Fact Column" in presentation catalog to use this fact table.
I can explain it to you in Polish by mail or phone
You bring me a next topic for my blog (in Polish) http://obiee.pl so I'll write sth about such behavior :)
Regards

3 confirmed Dimensions and 2 fact tables

Hi experts,
how can we connect 3 confirmed Dimensions and 2 fact tables without loops and traps please give me a solution

Hi,
Dimensions Tables : Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:
    Customer_key
    Customer_full_name
    Customer_city
    Customer_state
    Customer_country
Fact Tables :a fact table consists of the measurements, metrics or facts of a business process. It is often located at the centre of a star schema or a snowflake schema, surrounded by dimension tables.
Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of an educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.
Context Versus Alias Overview :
http://www.dagira.com/2009/07/22/context-versus-alias-overview/
How to create context :
http://www.bidw.org/business-objects/universe-design/understanding-context-and-its-use-in-business-objects-universe/
You can also look on the eFashion universe for more information.
Thanks,
Amit

How many line item dimensions can a fact table have?

Hi,
How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
Pls reply.
Thanks
Praveen

It includes all dimensios, including line item dimensions.
If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
Ravi Thothadri

What is correct way to join a start/end date driven dimension to a fact table in data foundation?

I have a bad universe or a data design issue.
Several versions of hierarchies reporting store entities in reporting Fact measures.
Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                            START_DATE
                                                                            END_DATE
                                                                            STORE_NUMBER
                                                                            ORG_HIERARCHY
                                                                            CURR_FLG   (Y/N)
Fact table :                                                         ORG_KEY
                                                                             CALENDAR_KEY
                                                                             TRANS_DATE
                                                                             $amount
Calendar Dimension:                                            CALENDAR_KEY
                                                                              DAY_DATE
                                                                               FY_WEEK          (201452)
                                                                                FY_PERIOD      (201412)
                                                                                FY_QUARTER   (201401)
                                                                                 FISCAL_YEAR    (2014)
Users WISH:
Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
Daily (Would be Calendar.Day_Date in Filter) ,
Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK as entered,
Month to date,
Year to date,
AdHoc queries.
My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail. I have not gotten @Prompts to work in joins, derived tables, etc. in the data foundation. Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked.
Please help!   ANY ideas would be appreciated.   .

{Note that abbrevations in brackets are just for short form further down the answer}
Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
Create an alias of Calendar Dim and call it Transaction Date (TD)
Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
The above predefined condition when added to your data query will return only yesterday's transactions.
However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
If you have any more questions about how this approach would work please shout.
As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

Relationship between Dimension without linking Fact table

Hi,
My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
including any measures from fact table .
Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but not linked to each other directly but can I get right result when I want to know what are the manufacturer for each product? or list of
customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
regards
Sanjoy ghosh

Hi Sanjoy -
The answer to your questions depends on your dimensional design and exactly what the fact table represents. Fact tables naturally capture the intersection of the different dimensions. This is true whether you physically implement a
PK - FK relationship in the relational db.
In your case, since customer is involved, sounds like a sales transaction fact. If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely. Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
across to product. If you need to solve this question, you have some other options:
- flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
- embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
to be flattened onto the product)
- build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates. This would allow you to capture rich details about each dimension separately
and use the factless fact to record)
Let me know if that helps.
Brent Greenwood, MS, MCITP, CBIP
// Please mark correct answers and helpful posts //
http://brentgreenwood.blogspot.com

Problem using same dimension in 2 Fact tables

Hi,
I am facing this strange problem with the out-of-box BMM metadata mapping :
The "Dim_W_GL_ACCOUNT_D" is joined to "Fact_W_GL_OTHER_F" and "Fact_W_GL_BALANCE_F" facts. Both these fact tables have a inner join to "Dim_W_GL_ACCOUNT_D". The change I have made in th BMM is - I added 2 new logical dimensions DimA and DimB and joined these to the above 2 fact tables.
The O-O-Box "GL Account Balance" Report works fine which has 3 logical columns (GL Account Number, Financial Statement Item, GL Account Category) from the "Dim_W_GL_ACCOUNT_D" and 1 Fact column "Closing Amount" which points to the "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" fact.
When I add 1 logical column each from my 2 new Dims I created, the report output shows the Fact column "Closing Amount" as $0.0. Upon investigating the log, the query shows it is using the "Fact_W_GL_OTHER_F" instead of "Fact_W_GL_BALANCE_F" fact which has the "Closing Amount" column. I am not sure how. When I drop the logical column "GL Account Number" and keep my 2 new logical columns in the request, the "Closing Amount" is shown correctly. I also saw there is a Dim Hierarchy for "GL Accounts" --- the "GL Account Number" is on a lower level than the "Financial Statement Item" and "GL Account Category" columns from the same logical dimension table which are 1 level higher.
How do I make the request pull data at the "GL Account Number" level and still have the query fetch data from "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" (Closing Amount) with my 2 new logical columns included?
Any help is appreciated. Thanks a bunch.

The dimensions I added are aliases of their respective W_XXX_D tables and I have the content levels set for the LTS of my Dims (DimA and DimB) at the detail level. One thing I am not able to figure out is why is it going after "W_GL_OTHER_F /* Fact_W_GL_OTHER_F */" when it should go to W_GL_BALANCE_F and W_GL_BALANCE_A.
The "GL Account Number" is sourced from the W_GL_ACCOUNT_D table and the other columns "Fin Statement Item" (FIN_STMT_ITEM_CODE) and "GL Account Category" (GL_ACCOUNT_CAT_CODE) are sourced from that same table too. But these 2 cols are on a higher level of hierarchy than the "GL Account Number" in the "GL Accounts" Dim-Hierarchy. But, as soon as I remove the "GL Account Number" logical column from the report the closing amounts show fine although the "Fin Statement Item" and "GL Account Category" cols from the W_GL_ACCOUNT_D table remain. Then the query does not show the W_GL_OTHER_F table in the log. Is there something I need to do to this dim-hierarchy?

What is technical advantage 0f having 16 dimension tablefor an fact table

Hi ALL,
Clarify my doubt.
Regards
DEEPAK

Hi Sudhir,
the limit of 16 key fields comes from the underlying DB ... Most of them do not support more. There is no difference from this point of view using different DBs becauses SAP abstracts the underlying DB BUT does consider their "common" limits, so it's built considering that an ABAP table can't be formed with more than 1 key fields, because some DB don't support this requirement.
As far it concerns the consideration of 248 Chars per Dim ... in a Dimension table there is a surrogate DIMension ID (DIMID) as a key field! Characteristics are "attribute" fields. So this limitation hasn't the same cause.
Hope it's clear
GFV

Conformed dimensions

Hi,
I have two conformed dimensions across two fact tables across two subject areas. When the two dimensions are selected from subject area A and looking at the OBIEE query, the fact from subject area B is also joined. How do I avoid the join to the fact table that exist in subject area B?
Thank You,
AK

In your RPD Admin tool, go to the properties of subject area A.
On the "General" tab, set the "Implicit Fact Column" property to use fact from subject area A.
This will ensure that only the fact from subject area A is used, even if no fact columns are in the query.

Two FACT Tables, Some Common and Non-Common Dimensions

Hello all, a question i am sure you have faced in the past but still wanted to get your feedback.
I have a few FACT tables and some dimensions that are shared (common dimensions). Rest of the dimensions are related to one or the other FACT tables.
What is the best way to present a view where users can pull information from both the FACT tables?
I am successful in pulling the shared (common) dimensions across BOTH FACT tables having the same grain but this view breaks down when i pull information from one Dimension that has not much to do with the other FACT.
What is the best way to present this? Should this be broken in three subject areas?
Subject Area 1 --> Some Dims --> FACT Table A
Subject Area 2 --> Some Dims --> FACT Table B
AND
Subject Area 3 --> ***Only Common Dims*** --> FACT Table A & FACT Table B?
Your feedback is always appreciated.
Regards,
Edited by: user10679130 on Oct 12, 2009 3:27 PM

Please check the forum first for similar threads/questions.
Joining two fact tables with different dimensions into single logical table
http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
This solution keeps both fact tables in the same subject area in the single logical fact table, with common and not-common dimensions.
Regards
Goran
http://108obiee.blogspot.com

Non-Conforming Dimension Model Question 14020

Guys
I have two fact tables combined into a single Logical Fact Table. There is a single conformed dimension for both fact tables, and each fact also has its own non-conformed dimension.
So effectively I have:
D1---<F1>---D2---<F2>---D3
but (F1) and (F2) are combined into single Logical table.
I have set the logical levels for the measures F1 to be Total (D3) and the measures F2 to be Total (D1).
If I select D1, D3 and F1/F2 measures then all works well. If I remove one or both of the measures I then get the dreaded 14020 error. I have tried setting the implicit fact measure for the Presentation Folder but this has no effect.
Is it possible with my current setup to select from the Dimension tables without selecting measures?
Thanks in advance

Hello Matt,
Please follow the below link
http://obiee-blog.info/administration-tool/importance-of-defining-dimensional-hierarchies/
Is this helpful to you.
Thanks

Query across two facts with filter on unconformed dimension

Hi
This question is actually regurgitated from another post as I wrongly tagged it onto the end of an already answered question.
Anyway, I am trying to query across 2 fact tables which have a dimension in common (conformed) and also some dimensions that are not directly joined to BOTH fact tables (seemedly referred to as 'unconformed' in OBIEE).
So in it's simplest form
Fact1, measure1 linked to dim1 & dim2
Fact2, measure2 linked to dim2 only
I have followed the recommended method advertised here and elsewhere of adding the second fact as a LTS of the first in the BMM layer and setting logical levels on measure2 to Total for all dimensions that fact2 is not joined to (in this case dim1).
When a basic query is issued in Answers that filters on the unconformed dimension (dim1), a spurious result set is returned that includes all records for the second fact.
This is quite a standard warehousing reporting query whereby 2 sets of data are queried independently and then joined on their common attributes but in this scenario the BI server seems to always generate a FULL OUTER JOIN and return an unrestriced data set.
Has anyone else come across this strange behaviour?
thanks
Tony

adding the second fact as a LTS of the first in the BMM layer
Could you try without this step? Just have separate facts and separate LTSs and set
Fact1 LTS to lowest for Dim1
Fact1 LTS to lowest for Dim2
Fact2 LTS to Total for Dim1
Fact2 LTS to lowest for Dim2
?

Multiple facts with some non-conforming dimensions

Hi, in our datamart, I have several fact tables. The JOBS fact table includes dimensions of time, employee, org, and job.
Other fact tables include those 4 base conformed dimensions, plus dimensions specific to the fact. For example, BENEFITS includes a "plan type" dimension, etc.
When reporting, I want counts from the basic JOBS fact table to always show up - even if other data in the report contains the "non-conformed" dimensions. For example, I'd like a report that lists time periods, employee counts (from JOBS fact), and enrolled employee counts (from BENEFITS fact), something like this:
Month Benefit Plan Emps Enrolled Emps
Jan 2009 Health Insurance 10,000 8,000
Jan 2009 401k Plan 10,000 4,000
Jan 2009 AD&D 10,000 1,000
When I try to produce this report, because "benefit plan" is not a dimension tied to the JOBS data, the EMPS column comes out blank. Yes, I can add a total row at the bottm to show it...but I really want the 10,000 to show up on each row (also because I want to calculate a % of people enrolled out of the total population).
What's the best way to accomplish this? Also given that I have 4 or 5 other fact tables, and each of them have their own "personal" dimensions in addition to the conformed ones.
Thanks in advance!
Scott

Hi
The problem you describe is similar to mine (I wrote several threads ago).
That is, if there is a non-conformed dimension in a report then the column from the fact table which is not connected with those non-conformed dimensions containes zeros or blanks.
Was this problem solved? I didn't quite catch one of previuos messages... If you can please repeat it more detailed.
What I tried to do is to set Total level in the Content tab (LTS properties). In this example - I could set Total level to JOBS in the plan type dimension. But it didn't help.
So if you know what to do then please describe it here...

Two fact tables with same dimensions

Good Morning,
I am just assigned to a new project. This is my first maintenance request: two fact tables F1 and F2 that shares same set of dimemsion tables D1 and D2. In the Answers report, if I use a foreign key in either F1 or F2, for example F1.k1, I get an error of meta data inconsistency. But if I use same column from dimension table D1.k1, then no error.
Your help is very much appreciated.
May

This is proberly #3 on the most popular topics list, behind SSO and a variables. Please use the search, what you need to do to set up conformed dimensions with multiple facts in the same report has been covererd many times.

Obiee report across non additive fact tables

I have two fact tables (f1,f2) joined two conformed dimensions d1,d2
d1,d2 have simple hierarchy total and detail levels
f1 --->d1
f1---->d2
f2---->d1
f2---->d2
facts tabel layout
f1 -- c1&c2 are(additive measures)c3&c4 are(non additive measures)
f2----col1&col2 are (additive measures)col3&col4(non additive measures)
I have tried to construct a report with c1,c2,col1,col2 and it works fine
when i try to do c1,c2,c3,c4,col1,col4 second fact table cols are null.
Can someone please guide how to resolve this issue.

there is a rule saying When you are combining multiple fact tables(stars) in a single report, the measures should be aggregated. This is like best practice.
So in your scenario, you have to create 2 logical dimensions from the fact tables.
Create logical dimensions F1D with source physical F1 and add only non aggregated measure(c3,c4), Create a hierarchy with total and detail level.
Create logical dimensions F2D with source physical F2 and add only non aggregated measure(col3,col4), Create a hierarchy with total and detail level.
then for fact table f1 , set level F1d - Detail, F2d - total.
then for fact table f2 , set level F1d - total, F2d - detail.
Update your presentation layer. Make sure these non aggregated columns coming from F1d,F2d instead of logical fact tables.
check for consistency.,Now save,reload/restart server. Check your reports, thats it.
thanks
Madan Thota

Conformed dimensions across several fact tables

Similar Messages

Maybe you are looking for