Denormalized dimension and different fact levels

Thanks for reading...
Scenario is to compare actual and plan sales. Actuals are on the level of cashdesk, plan is on higher level workstation.
Dimension levels are Cashdesk -> Workstation -> Location, and is denormalized.
Question is what is the best practice to get this to work.
1. Create new dimension starting at level Workstation and join the plan to this dimension. At logical layer make two sources for the attributes Workstation and Location.
2. Split (normalize) dimension to three dimensions Cashdesk, Workstation and Location. Join plan to workstation dimension at logical layer. And create common dimension table by joining the three to one dimensions.
3. ???
Thanks for all suggestions.

If Cashdesk -> workstation -> location truly represents a single dimension, then you should not split this into multiple dimensions.
You'll create a single dimension with two logical table sources. First table source will go to a dimension table that includes all three levels, set it's content level to "Cashdesk". Second LTS will go to a table that includes only the workstation and location level info. If no such table exists, you can create it in the physical layer using a view (select distinct workstation attributes and location attributes, but no cashdesk attributes)
Then I would create TWO fact tables - one for the actuals, one for plan. In theory you could smash it all into a single fact table...but I prefer to have different facts when the underlying data is at different grains. Make sure you set the content level properly for the facts - the "Actuals" fact will be at the cashdesk level, the "Plan" fact will be at the workstation level.
This is really easy to show, but hard to describe. Send me an email at [email protected] if you need additional info.
Thx,
Scott

Similar Messages

Summary Report with 4 Dimensions and 5 Facts

Hello OBIEE Czars:
I have a problem.
I am trying to make a summary report with 4 Dimensions and 5 Facts.
Out of that only 2 Dimensions are Confirmed.
Now when I try to bring in all the facts, I get view display error.
I searched forum for similar issues.
So I have tried following so far.
1) Add other dimensions as source and set level to Total for those dims.
- After doing this, I dont get view display error, but I get blank rows for couple of facts.
2) I am already aggregating all the measures.
Please help me out.
This forum has been very helpful so far.
Thanks.
~Vinay

Hi
This method seems fine until you run a request that includes a filter on an unconformed dimension.
The SQL itself should be quite straightforward (see below) but the BI Server instance does not seem to be joining this data correctly after posting the 2 separate queries to the database.
SELECT
x.dim1, x.dim2
x.fact1_agg_measure
y.fact2_agg_measure
FROM
SELECT
dim1, dim2
SUM(fact1.measure) fact1_agg_measure
FROM
dim1,
dim2, --UNCONFORMED+
fact1
WHERE
.... .... join fact1 to dimensions as normal
AND dim2 = 'BUSINESS_IDENTFIER'
GROUP BY
dim1, dim2
) x,
SELECT
dim1
SUM(fact2.measure) fact2_agg_measure
FROM
dim1,
fact2
WHERE
.... .... join fact2 to dimensions as normal
GROUP BY
dim1
) y
WHERE
x.dim1 = y.dim1
The result set returned in Answers is firstly a correctly aggregated record plus ALL rows from the second query above ??
Just wondering if anyone else has come across this issue?
cheers
Tony

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

Conformed / nonconfirmed dimensions and multiple facts

Hi all,
There have been plenty of posts on this issue, I've read a lot about it, but still can't get this working. We're looking at a basic marketing process where we can track the links that have been clicked in marketing emails that have been sent out. What I have is two fact tables, with one conformed dimension between them, and one of the facts having a non-conformed dimension:
Fact 1 linked to Dim - Links
Fact 2 linked to Dim - Links; Dim - Email Name;
In Fact 1 i have defined a measure that counts the number of links clicked
In Fact 2 i have defined a measure that counts the number of links
So, I can take fields from Dim - Email Name, and Fact 2 and this will correctly show me the number of links in that email. I can add in the Link Name from Dim - Links to give me the detail of the links in the email. However, when I then add the # of links clicked from Fact 2, this is shown as zero. Removing the Email Name will cause the # of clicks to be displayed correctly for each link.
I've read this post here:
report based on 2 different Fact tables
which seems to contain my exact problem, but the solution listed hasn't worked for me. I've created hierarchies, set the LTS of Fact 1 to be Detail for Dim - Links, and the LTS of Fact 2 to be Detail for Dim - Links and Dim - Email Name. This doesn't work. I've then set the LTS of Fact 1 to be Total for Dim - Email Name. this doesn't work. I've then set the LTS for the dimension tables to be detail in each case, and this doesn't work either. My business question is pretty simple - for each email, list the links and how many times that link was clicked.
I've started from scratch, I'm only looking at these 4 logical tables, I've got to the stage where I'm restarting BI after every change but I still can't see the problem. Can anyone give me any guidance please?
thanks
Matt

Hi Wildmight,
apologies for not posting for a few days, I've been out of the country. I've just tried all these, with no joy. At the moment then, I have one single Fact table, with two logical sources, LINKS_FACT and CLICKS_FACT. I've set the LTS for LINKS_FACT to be Email Detail and Link Detail, and the LTS for CLICKS_FACT to be Link Detail and Email Total. The single Fact table now has two measure columns, one a count distinct on linkid and one a count on the clicksid.
When I go into answers, I select an email title of May Newsletter, choose the link name, and then select the # of links and number of clicks. The log for this query is:
-------------------- SQL Request:
SET VARIABLE QUERY_SRC_CD='Report';SELECT "Dim - Emails".TITLE saw_0, "Dim Links"."Link Name" saw_1, "Fact - Links"."# of Links" saw_2, "Fact - Links"."# of Clicks" saw_3 FROM "CRM 2.0" WHERE "Dim - Emails".TITLE = 'May Newsletter' ORDER BY saw_0, saw_1
+++Administrator:2a0000:2a0007:----2009/05/19 10:05:08
-------------------- General Query Info:
Repository: Star, Subject Area: CRM 2.0, Presentation: CRM 2.0
+++Administrator:2a0000:2a0007:----2009/05/19 10:05:08
-------------------- Logical Request (before navigation):
RqList
Dim - Emails.TITLE as c1 GB,
Dim Links.Link Name as c2 GB,
# of Links:[DAggr(Fact - Links.# of Links by [ Dim Links.Id, Dim - Emails.Id] SB Dim - Emails Detail,Dim Links Detail)] as c3 GB,
# of Clicks:[DAggr(Fact - Links.# of Clicks by [ Dim Links.Link Name, Dim Links.Id, Dim - Emails.Id, Dim - Emails.TITLE] )] as c4 GB,
Dim - Emails.Id as c5 GB,
Dim Links.Id as c6 GB
DetailFilter: Dim - Emails.TITLE = 'May Newsletter'
OrderBy: c1 asc, c2 asc
+++Administrator:2a0000:2a0007:----2009/05/19 10:05:08
-------------------- Execution plan:
RqList <<3688>> [for database 3023:15084:CRM,31]
D1.c1 as c1 [for database 3023:15084,31],
D1.c2 as c2 [for database 3023:15084,31],
D1.c3 as c3 [for database 3023:15084,31],
D1.c4 as c4 [for database 3023:15084,31]
Child Nodes (RqJoinSpec): <<3705>> [for database 3023:15084:CRM,31]
RqList <<3573>> [for database 3023:15084:CRM,31]
D1.c2 as c1 GB [for database 3023:15084,31],
D1.c3 as c2 GB [for database 3023:15084,31],
D1.c1 as c3 GB [for database 3023:15084,31],
cast(NULL as INTEGER ) as c4 GB [for database 3023:15084,31],
D1.c4 as c5 GB [for database 3023:15084,31],
D1.c5 as c6 GB [for database 3023:15084,31]
Child Nodes (RqJoinSpec): <<3679>> [for database 3023:15084:CRM,31]
RqList <<3738>> [for database 3023:15084:CRM,31]
count(distinct CRM_LINKS_FACT.ID by [ CRM_LINKS.ID, CRM_EMAILS.ID] ) as c1 [for database 3023:15084,31],
CRM_EMAILS.TITLE as c2 [for database 3023:15084,31],
CRM_LINKS.NAME as c3 [for database 3023:15084,31],
CRM_EMAILS.ID as c4 [for database 3023:15084,31],
CRM_LINKS.ID as c5 [for database 3023:15084,31]
Child Nodes (RqJoinSpec): <<3658>> [for database 3023:15084:CRM,31]
CRM_LINKS T26115
CRM_EMAILS T26105
CRM_LINKS T26129
DetailFilter: CRM_EMAILS.ID = CRM_LINKS_FACT.EMAILID and CRM_EMAILS.TITLE = 'May Newsletter' and CRM_LINKS.ID = CRM_LINKS_FACT.ID [for database 0:0]
GroupBy: [ CRM_EMAILS.ID, CRM_EMAILS.TITLE, CRM_LINKS.ID, CRM_LINKS.NAME] [for database 3023:15084,31]
) as D1
) as D1
OrderBy: c1 asc, c2 asc [for database 3023:15084,31]
+++Administrator:2a0000:2a0007:----2009/05/19 10:05:08
-------------------- Sending query to database named CRM (id: <<3688>>):
select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4
from
(select distinct D1.c2 as c1,
D1.c3 as c2,
D1.c1 as c3,
cast(NULL as INTEGER ) as c4,
D1.c4 as c5,
D1.c5 as c6
from
(select count(distinct T26129.ID) as c1,
T26105.TITLE as c2,
T26115.NAME as c3,
T26105.ID as c4,
T26115.ID as c5
from
CRM_LINKS T26115,
CRM_EMAILS T26105,
CRM_LINKS T26129 /* CRM_LINKS_FACT */
where ( T26105.ID = T26129.EMAILID and T26105.TITLE = 'May Newsletter' and T26115.ID = T26129.ID )
group by T26105.ID, T26105.TITLE, T26115.ID, T26115.NAME
) D1
) D1
order by c1, c2

One dimension and two fact report in OBIEE

Dear All,
I have one dimension "region" and two facts (Sales value & Gross margin%). Gross margin% is logical column which has been derived from two other facts column and it's value is in range from Zero to 100.
Now, I want to generate below report. For each gross margin% range of 5%, I want to sum the sales value for each region. Please assist (Just a small snapshot of report)
GM%     Region_1     Region_2
<0     254      619
0-0.05     524      799
Thanks & Regards,
[email protected]

Hi,
Create Bins for Gross% fact column and go to pivot view place Gross% fact column into rows area,region column into columns section and sales value into measures section
hope it works

2 Dimensions and a Fact - Join Paths

I have a scenario and I have been racking my brains out as to if what I am looking for could be set up. I have two dimenisions - Region and System - each System belongs to a Region. So the System Dimenison contains a Region_Key.
I have a Fact table that contains both the Region_Key and the System_Key allowing each dimension above to be joined directly to the Fact table.
Is there any way of creating a model where I could set it up where if someone pulls a column from just the System and Region it only pulls from these two tables (The join doesn't go through the Fact Table). And when a metric is pulled that it uses the direct joins to the Fact table for each table.
I'd appreciate any feedback, thanks alot!

If I am understanding what you are saying, you are saying to duplicate the Region Dim in the Business Layer then join this newly created Logical Table off of the System Dim? So snowflaking it out. But how would that allow me to present the Region column as one column in the Presentation layer? If the user just selected the Region column and a Fact I was hoping the path would just go between that direct join. If they selected only Region and System just have it utilize the dimensional join. Thanks for your response by the way!

OBIEE 11g 11.1.1.7 NON Confirmed dimensions and facts

Hi All,
In OBIEE 10g if we had non-conformed dimensions we used to work with by defining logical level of the conformed dimensions to grand total and confirmed dimensions to detail in the LTS of the fact table
and also set metrics to grand total level.
But in OBIEE 11g doing same is throwing error
[nQSError: 14025] No fact table exists at the requested level of detail
How do we achieve this?
Regards,
deep

You need to create a complex join with non conformed dimension and the fact with 1=1 and set the logical level of the measure to total for a non conformed dimension.
You can refer: https://s3.amazonaws.com/rmc_docs/biforum2011/Mcquigg_Metadata.pdf

One to One relationship between Dimensions and Fact Tables

Hi,
Not a real Discoverer question, but seeing as there is such a huge pool of talent here, I thought I'd ask anyway...
Is the concept of having a one to one join between a Dimension and a Fact Table an Acceptable Thing (tm). I'm not talking about a degenerate dimension, as the Dimension would hold additional attributes.
It's something I'm trying to get my head around and would appreciate any viewpoints.
Thanks,
Andy

Hi Andy,
There is of course no distinction in SQL between 1-1 and 1-n joins, but in your database design you would avoid denormalizing data into a dimension table if it was only ever used once.
From a Discoverer perspective setting the join to 1-1 controls how aggregate queries are constructed. Normally, if you have a master-detail 1-n relationship and you aggregate items in both tables then you will get an incorrect result for the master table because the number of rows are multipled by the n detail records. Similarily if you have 2 detail tables in the query and you aggregate items in a detail table you will get incorrect results. Discoverer recognises these situations and raises an error.
Setting the join as 1-1 tells Discoverer that it will get the correct results in these situations and therefore no error is raised. So it is perfectly acceptable to set the joins as 1-1 as long as you know the implications.
Hope that helps,
Rod West

Dimension and Fact table have the same grain

Hi All,
How can we join a dimension and a fact table if they have the same grain ? In my case it is a contract number.
Thanks

Your Impression is right, In terms of Dimensional Modeling. You have to consider this when you are designing your warehouse tables.
But now if you already have these tables in database, OBIEE does not care how many rows a table have, it just need to know what is fact and what is Dimension and it will generate sql queries based on join conditions.

How do I reuse my Date dimension in every fact and dimension that has dates?

Hi, all,
I have a fact table in the middle of a star and three dimensions. Each of the four objects has a modified date in it. Is there a way for me to create and reuse a Date dimension for every one of the three dimensions and one fact? I want
to be able to slice data by ModifiedDate from D1, ModifiedDate from D2, ModifiedDate from D3, and ModifiedDate from F1 at the same time because I have a very custom date roll-up by which I want to see the data.
I suppose I can re-instance the Date table in the DSV 4 times, but I wanted to know if I can resolve this via a separate Date dimension. Thanks!

Hi,
If say you want to slice the cube on modified date from all dimension D1, D2 and D3 using a single attribute, then try if the following works
create a new date attribute lets say [Slice Date] in Date dimension and later use MDX scope statement somewhat like this
Scope([Date Dim].[Slice Date].CurrentMember);
this = (strtomember('[D1 Dim].[Modified Date]'+right([Date Dim].[Slice Date].CurrentMember.uniquename,len([Date Dim].[Slice Date].CurrentMember.uniquename)-23)),
strtomember('[D2 Dim].[Modified Date]'+right([Date Dim].[Slice Date].CurrentMember.uniquename,len([Date Dim].[Slice Date].CurrentMember.uniquename)-23)),
strtomember('[D3 Dim].[Modified Date]'+right([Date Dim].[Slice Date].CurrentMember.uniquename,len([Date Dim].[Slice Date].CurrentMember.uniquename)-23))
end scope;
Saurabh Kamath

New user, many dimensions and facts question

I am just wondering how others layout their model when they have 30 dimensions and 5 fact tables.
For example:
fact 1 uses 10 dimensions.
fact 2 uses 5 dimensions
fact 3 uses 3 dimensions
Would you use 1 relational model and add all of the entities to the model? As you can imagine, the model gets to be quite busy. I've tried to add multiple relational models, but then I end up duplicating entities and worry about changes being made in only one place for the entity. Is a subview on the relational model per fact table a good way to go?
I'm open to any suggestions.
Thanks!
Brian

Hello Brian,
In fact you can use both options you mentioned:
1- you use one relational model and split it up on in several subviews. In your case a fact per subview could be a good solution.
2- you use one relational model per fact. To prevent duplicate entities among relational models, you can link tables instead of making copies. You can make a link of a table by dragging the table into the subview of another relational model.
You can of course mix both models by using multiple relational models and have in a relational model multiple views.
Joop

Time dimension and chronological key

HI ALL
I WORK ON OBIEE 11G REPORTS
WHAT IS THE EXACT USE OF TIME CHECK BOX AND CHRONOLOGICAL KEY??
AND HOW CAN I USE IT
ANY HELP ??

Hi,
What is the chronological key use?
A. Typically time dimension differs from all other dimensions in one way and that is,
all other dimensions dont care about the order of the values in it.
e.g. in region_dim the values are north, south, west and east. Here nobody wants to see whether north comes first or south comes first. i.e. no order is required here.
in the case of time dimension there needs to be a particular order for all the values present in it.
e.g. 2010 is earliest and 2004 is older. Dec-10 is earliest and jan-10 is older. i.e. the values in the time dimensiion needs to follow a particular sorting order. So the chronological key is the key which tells the obiee that the data is incrementing based on the chronological column.
Here you may get another doubt. i.e. you are having columns like year, half_year, quarter, month, week and day. Here which one should become the chronolgocial key?
Analyse it yourself. If you kept year as chro key then obiee will be confused whether jan-10 is earliest or feb-10 is earliest. Because it knows only that 2010 is earliest and 2009 is older.
So always it should be the lowest level oif the dimension which needs to be the chronological key. In the abouve case it should be date.
You can select either date or date_id(this could be a sequence generator values).
2. what is the use time dimension?
A.If all you want is to achieve drills from Month, Quarter and Year then treat it as a normal dimension and create the levels. But if you want to do calculations like YTD, QTD and MTD then you need to create a time dimension.
http://oraclebizint.wordpress.com/2007/11/05/oracle-bi-ee-101332-understanding-todate-and-ago-achieving-ytd-qtd-and-mtd/
Refer the above link for time dimension.
Award points it is useful.
Thanks
satya
Edited by: Satya Ranki Reddy on May 2, 2012 12:29 AM

How to join Dimensions and Fact Tables in OBIEE

Hi All,
I need to create report which need to get the information from two fact tables and 7 dimensions. The granularity is not same in both the fact tables. One fact table is having common keys between all the dimension tables and second fact table have only two dimension keys but with different names. My requirement is to create the report by taking the measures from both the fact tables.
I have created joins between the second fact table and two dimension tables in physical and BMM layer and also set the highest level for all other dimension tables in the LTS of second fact table. when am creating report by taking the measures from both the fact tables, data is not getting for the measure which taken from the second fact table. Please advice me how to get the data for the measure which taken from the second fact table.
Thanks in Advancec !!

You have to use the level-base measure capabilities.
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/level_based_measure_calculations
For all measures of the second fact table with the lowest grain (with two dimension keys), set for all dimension where you don't have any key the logical level to the "All" or "Total".
And UNSET the highest level of the LTS for the second fact table.
Success
Nico

Fact - dimension and Fact Join

Hi ,
I have a issue in OBIEE 11g here ,
I am trying to query two columns from 2 different fact tables F1 and F2
the join between these tables is F1 - D - F2 , where D is the confirmed dimension.
so when i am querying for
f1.c1 , d.c1 , f2.c1 , its throwing me up with error
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: 14020] None of the fact tables are compatible with the query request
Can you please help me with this issue , am i doing the correct join ??, can we query two columns from two diff fact tables?
Thanks in advance.

Hi All,
Thanks for your responses , I have tried creating hierarchy dimension and assgned levels to the fact sources but i still see the error
and
Combining 2 facts will resolve the issue but its not the case here as each fact table has about 25 dimensions connected to it , but there are only 2 confirmed dimensions between both facts and the problem here is user wants to see both the fact tables in the same subject area
I have been trying but unable to get the solution.
Can you guys please suggested any other way of achiving this task
Thanks a lot

Filling of Dimension and Fact tables

Hello every one,
Basically from the training guide from net. I have come to know that when you make Dimenions or facts you put every column to the source as seperate level e.g 'emp_no' column from the source will be a level in OWB and will convert into 'id and emp_no'. Now the problem arises that how can i populate them both when data will come in emp_no from source, should i link a sequence with every level's IDs.
I am pretty much confuse and then at the time of making OLAP Cube, will i call the IDs of every level or what. Please guide me.
Thanks
Mustafa Ali Qizilbash
[email protected]

Dimension level can have more than one attribute (except ID), so if you have a customer dimension, and customer is at the lowest levelof your hierarchy, this level can have multiple attributes like first_name, last_name, address, age etc. On the next hierarchy level you can have, for example, customer_type, where you will have customer_type_id and again multiple level attributes (customer_type_name, income_bracket etc.).
For OLAP you indeed have to have a unique id across all the levels (you cannot have a customer_id that is identical with a customer_type_id). You can achieve this for example by loading each level id in a separate mapping ssequentially from the same sequence (this would not be particularly efficient, but can be acceptable in some cases) or by having one sequence per level. These sequences start with different numbers and you take care that the sequence numbers they generate will never overlap. For example you can have a cust_s sequence that populates the customer_id, and you know that you will probably never ever have more that 100 thousands customers. In this case, this sequence will start with 1. As for the customer_type_id, you can have the sequence cust_type_s that starts with 10 million and progresses from there (always take some slack in these cases). This way the values generated by cust_s and cust_type_s will (probably) never overlap.
Regards:
Igor

Denormalized dimension and different fact levels

Similar Messages

Maybe you are looking for