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

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

  • 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!

  • 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

  • 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

  • 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

  • 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

  • Best way to combine multiple fact tables in single mart

    Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
    I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
    For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
    I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
    However, I'm not quite sure how to proceed at the month level. My initial thought is:
    a) create a new LTS for the fact table at the month level
    b) in the new LTS, add the join to the time dimension
    c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
    Is this the proper way to do this?
    Thanks in advance!
    Scott

    Hi Scott,
    I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
    DAILY_FACT (
    DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
    START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
    END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
    DAILY_VALUE NUMBER); -- FACT MEASURE
    MONTHLY_FACT(
    MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
    MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
    MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
    DIM_DATE(
    DATE_KEY NUMBER,
    DATE_VALUE DATE,
    DATE_MONTH VARCHAR2(20),
    DATE_YEAR NUMBER(4));
    DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
    Step 1)
    Make the following three joins in the physical layer:
    a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
    b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
    C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
    Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
    Step 2)
    Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
    Step 3)
    Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
    Step 4)
    Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
    Step 5)
    Drag all required reporting columns to the Presentation layer.
    Step 6)
    Create your report using the two different measures from the different fact tables.
    Step 7)
    Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
    Step 8)
    You're done.
    The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
    Hope that helps!
    -Joe
    Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

  • Children not appearing in drop down of dimension in multiple hierachy

    Hello,
    In 4.2 we had parenth1 and parenth2 and one dimension table (at least I think).  If parenth2 had multiple layers of children (children that were parents) you saw them in the drop down lists of the dimension for the second hierarchy.  In 5.1 it appears the architecture changed with dimensions and multiplie heirarchies.  I do not see children of children in my alternate hierarchies as before.  In looking in the dim"dimensionName"_H2 table I see the correct information.  The data seems to be in the tables but drop down lists for the dimension are not showing children of children if this makes sense.
    Ex.in 5.1  I'm expecting to see in  Hierarchy2 09 -> Child 099 ->Grandchild 0991
          but I'm only seeing Hierachy2 09 -> Child 099
    The Grandchild 0991does not appear. (Grandchild if you will of Hierarchy2)
    In Hierachy1 of the same dimension (or what use to be Parenth1 in 4.2) you see all parents and their children and children of their children etc.   Note:  this dimension is built using a dimension build ssis pkg.
    I know my explanation is probably wordy and confusing but hopefully someone can make sense out of it.  Any feedback, would be greatly appreciated!
    Vikki

    Hi Vikki,
    The way the memberselector shows the hierarchies to end-users is not changed from V4 to V5, so I think there might be something wrong in your dimension.
    Please try to copy the contents of the mbr<dimname> table to you membersheet to see more clearly what is going wrong, also try to process it from there (it will give you more hints compared to using a ssis package to import a dimension.
    Another idea is to look to Apshell, some dimension have multiple hierarchies, you could compare them to your own to see what is wrong.
    Alwin

  • Multiple facts

    Hi All,
         I have one doubt, I have F1 fact connect  D1&D2 dimensions.And F2 fact connect with D3 dimensions.In report we need F1 D1 F2 & D3 tables only.How can we do .Give reply anybody..........

    Based on given info best option is using UNION !!
    ie. Combine both reports
    If helps mark
    ~ http://cool-bi.com

  • Conformed dimension and query multiple fact tables

    Hello,
    Please if someone can guide me on this requirement.
    Requirement - I have a conformed dimension D1 and two fact tables F1 and F2. Both fact tables have many columns so I cannot merge
    the two fact tables into one logical table. Currently both these fact tables have logical tables F1 and F2 respectively.
    As per design the conformed dimension is a simple logical table in the rpd and not a dimension.
    Can someone guide me how should i proceed so that i'll be able to fetch information from both the fact tables?
    Edited by: 930542 on Apr 26, 2012 12:28 PM

    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.

Maybe you are looking for