FACT TO FACT relation

Hi ,
I have 2 fact tables fact1 and fact 2. Fact 1 table consists of some measures where as fact 2 consists of measures and lot more non-fact columns. but i would like to create a dimensional hierarchy for fact2 table so that i can drilled down all the non-fact columns but the problem is i couldn't able to create a dimension hierarchy for fact2 table. Is there any way i can create dimensional hierarchy on fact tables?? But i found a solution not sure is it best approach or not first i created an alias for fact2 table and joined the alias and fact2 table then with alias i created a dimension. Please let me know if this is the right approach or any other solution for this.
Thanks in Advance,
chakri

Chakri,
No need to go for alias in phyical layer. In logical layer (BMM), create 2 logical table - diff names with same single physical table and just drag the non-measure columns to 1st logical table and measure cols to second logical table from physical source. Now create a simple logical join from 1st Logical Table to 2nd Logical table (1:N), in this way first will behave as Logical Dimension(will turn to white color) and second as Logical Fact(will turn to yellow color). Now go ahead and create hierarchy using cols from 1st Logical Table. This is pretty straight forward.
Hope this clears your doubt and good to start with.

Similar Messages

  • Incorrectly defined logical table source (for fact table Facts) does not

    Hi,
    I have two Dimensions A and B. A is joined to B by a foreign Key.
    The report works if I pull B. Column1, A.Column2.
    The report is throwing an error if i try to change the order of the columns like this. A.Column2, B. Column1.
    error : Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    File: odbcstatementimpl.cpp, Line: 186
    State: S1000. Code: 10058. [NQODBC] [SQL_STATE: S1000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table Facts) does not contain mapping for B.Column1
    I am not sure where it is going wrong.
    Thanks
    jagadeesh
    Edited by: Jagadeesh Kasu on Jun 16, 2009 4:22 PM

    did you make joins in LTS or on the physical table.
    try to make join in LTS if they are not there.

  • Can we Join Fact to Fact obiee11g

    Can we Join Fact to Fact obiee11g?
    Regards
    kumar

    - From a physical data model point of view, yes.
    - From a logical data model point of view, not.
    To resume, you can but one of the fact must be in the business model layer of the repository designed as a dimension of the other fact table.
    Cheers
    Nico

  • Can we join fact to fact?

    i am new to obiee i found this question in some bi sites.
    ” If you have 3 facts and 4 dimension and you need to join would you recommend joining fact with fact? If no than what is the option? Why you won’t join fact to fact?
    i found the answer like this
    o In the BMM layer, create one logical table (fact) and add the 3 fact table as logical table source.
    but i didn't find the anser for Why you won’t join fact to fact?
    Pleae guys help me.......................
    Thans in advance.
    Rani

    You can join any two table which has some relationship but ideally you don't join Fact to Fact because its not a good practice and degrades performance..
    Get some guidance from here http://siebel.ittoolbox.com/documents/how-to-join-two-fact-tables-14090

  • IMPLICIT FACT & FACTLESS FACT

    Hello Gurus
    Can anybody please explain what is implicit fact and for what is it used for .
    And also
    Can anybody please explain Fact Less Fact and for what it is used for .

    follow this,
    1. open administration tool
    2. go to help
    3. click on Search tab
    4. type Implicit Fact
    5. only one topic you'll findin the results.. plz read it and let me know your doubts on that..
    coming to your next question...
    Factless Factohhh, got these links after googling..
    http://www.geekinterview.com/question_details/31538
    http://dylanwan.wordpress.com/bi-and-olap-glossary/factless-fact-table/
    http://www.allinterview.com/showanswers/36017.html

  • Use dimension from detail fact to find related records in summary fact

    I have a cube with 2 facts and 2 dimensions. 
    What I want to accomplish is if I filter by a "Line Item Date" that it shows me the related total cost without having to show the invoice date.
    How should I design my dimensions or cube to get this to work? (dim example below)
    Dim_DateLineItem
    lineItemDate
    Fact_LineItems
    lineItemDate
    InvoiceDate
    price
    Dim_DateInvoices
    InvoiceDate
    Fact_invoices
    invoiceDate
    TotalCost

    Try to insert a record in dim table with row_wid=0 this record 0 for number type and Unspecified for string type columns
    in rpd use ifnull(col,0)
    ~ http://cool-bi.com

  • Fact to Fact Relationship urgent!!!!!!!

    Let us suppose there are 2 dimensions and 2 facts and every dimension is joined with every fact and there is no relation between two facts while selecting columns from both the facts with any dimension column its involving only one fact, we found one solution which is combined sql (union).
    can we have any other solution?
    Thanks in advance

    I hope I got your question.
    If you have 2 unrelated facts joined to a common dimension, and if you drag the dimension value and the measures from your fact tables, the data should show up as expected.
    For e.g. we have an orders received and an orders fulfilled fact tables that are unrelated, that we can see by day (the common dimension) in a single query without any union. Of course, your measures will need to be aggregated for your fact tables to return a single row for each dimension value, otherwise it would make no sense.
    HTH,
    Nilanshu.

  • Fact to Fact join in Obiee

    Hi
    I am new in OBIEE, I have an scenario where in we need to join two fact tables and the condition is F1.date is between F2.valid from date & F2.valid To date
    I have tried using confirm dimension. Is it possible to map such scenario in OBIEE 11g
    Thanks
    Sameer

    Hi Venkat,
    I am coming from the basics of a star schema here, so hope it helps
    What is a fact?
    A fact is something that has all measures which can be aggregated (Units, Dollars, # of Orders) etc with keys to different dimensions.
    What is a dimension?
    It is the context with which we understand/record/retrieve the measures in the fact. We understand "# of Orders" for a product/By a customer etc.
    So joining a dimension and a fact helps to answer the Who/What/When kind of business questions. Ex : Who bought these products? What was the product type? When these products were sold kind of...
    Now just imagine tying up fact to another fact. With this kind of model, you can never answer any business question.
    I have never tried joining a fact with another fact in OBI (But do not think it will allow it though :) )
    Hope I am clear.
    Thank you,
    Dhar

  • How do I Join Fact to Fact in the BMM

    I have a star schema in the BMM layer. Another star schema is also modelled. Now the fact table of star schema 1 has to get data from the dimension table in star schema 2.
    How do I join the fact tables of star schema 1 and star schema 2.
    They do not share a common dimension.
    Thanks for inputs.

    Just click inside the Shape and either type or paste.
    or
    select a Textbox and Shape by clicking on each with the command key held down > Menu > Arrange > Group
    Peter

  • Fact to Fact linkage thru a map table

    Hi,
    I have a situation where in two fact tables are linked thru an intermediate map table. The purpose of doing so was to facilitatie an n:n relationship between f1 and f2. So this map table essentially has 3 columns viz pk, f1 key, f2 key. f1 and f2 has it's own sets of dimension tables attached to it. Of these some dimension tables are linked to the fact tables thru corresponding map tables to facilitate n:n relationships. So there are two types of map tables >> between two facts and between a fact and a dim. The reporting requirement is like this: attributes of f1,dimensions attched to f1, attributes of f2s attached to f1, dimensions attached to f2.
    The design is tricky and was done a long time ago and solutions are currently running on it. So a design change is not possible. Can somebody suggest an approach to tackle this kind of a relationship?
    Many thanks

    Hi,
    Many thanks for the suggestion.
    I'd declared the map tables that connected fact to dimension as bridge tables. When I do the same for a map table between two fact tables, the conistency check fails. I get "Internal error: Missing functional dependancy assosiation for column : Control Legal Entity.d_checker_date" Control legal entity is a dim table which is connected to the fact table thru a map table and d_checker_date is the first column in that table. If i delete this column the same error repeats for the next column.
    Any thoughts on this?

  • Fact to fact join

    HI,
    I have join like this
    fact1 and fact2 >>>ledger>>RPT
    so ledger will be confirmed dimension
    now my report look like this
    column from RPT and column from fact1 filterd by fact2 column
    i bought both fact column in one logical table, and went to fact1 LTS and added ledger table as inner and RPT table as left outer
    ledger+fact1 =inner
    ledger+fact2=innner
    ledger+rpt=left outer
    still i am not getting result right
    when i use column from only one fact still its joing with other fact
    can i know how to do join?
    Edited by: 944346 on Oct 3, 2012 11:37 PM
    Edited by: 944346 on Oct 3, 2012 11:37 PM

    Hi,
    Kindly refer the below link
    http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
    Hope this help's
    Thanks,
    Satya

  • Fact join Fact in DAX

    hi All,
    I have a question about DAX for join itself, the scenario is:
    1. get last quarter customer with "A" status from Fact table
    2. based on the customer list get from #1 to join this quarter customer with "AB"status  from the same fact table
    3. distinct count #2 customer 
    ===================
    sample T-SQL query as below,
    ===================
    select count(distinct a.CUSTOMER_ID)
    FROM [Fact Table] a
    inner join ( 
    SELECT distinct [CUSTOMER_ID] as [CUSTOMER_ID]
    FROM [Fact Table]
    where Date between '2014-01-01' and '2014-03-01'
    and [Status]='A'
      ) b on a.CUSTOMER_ID=b.CUSTOMER_ID
     where Date between '2014-04-01' and '2014-06-01'
     and [Status]='AB'
    kindly advise if any solutions, thanks in advanced.
    Jackie

    Look at the "Transition Matrix" in Tabular model in "The Many-to-Many Revolution" whitepaper:
    http://www.sqlbi.com/articles/many2many/
    Marco Russo (Blog,
    Twitter,
    LinkedIn) - sqlbi.com:
    Articles, Videos,
    Tools, Consultancy,
    Training
    Format with DAX Formatter and design with
    DAX Patterns. Learn
    Power Pivot and SSAS Tabular.

  • Combining relation facts with dimensions from an Essbase cube

    Hi!
    I am having trouble combining relational measures (from EBS) with dimensions from an Essbase cube. The dimensions that we want to use for reporting (drilling etc) are in an Essbase cube and the facts are in EBS.
    I have managed to import both the EBS tables and the cube into OBIEE (11.1.15) and I have created a business model on the cube. For the cube I converted the accounts dimension to a value based dimension, other than that it was basically just drag and drop.
    In this business model I created a new logical table with an LTS consisting of three tables from the relational database.
    The relational data has an account key that conforms to the member key of the accounts dimension in the Essbase cube. So in the accounts dimension (in the BMM layer) I mapped the relational column to correct column (that is already mapped to the cube) - this column now has two sources; the relational table and the cube. This account key is also available in the LTS of my fact table.
    The content levels for the LTS in the fact table have all been set to detail level for the accounts dimension.
    So far I am able to report on the data from the fact table (only relational data) and I can combine this report with account key from the account dimension (because this column is mapped to the relational source as well as the cube). But if expand the report with a column (from the accounts dimension) that is mapped only to the cube (the alias column that contains the description of the accounts key), I get an error (NQSError 14025 - see below).
    Seeing as how I have modeled that the facts are connected to the dimension through the common accounts key, I cannot understand why OBIEE doesn't seem to understand which other columns - from the same dimension - to fetch.
    If this had been in a relational database I could have done this very easily with SQL; something along the lines of select * from relational_fact, dim_accounts where relational_fact.account_key=dim_accounts.account_key.
    Error message:
    [nQSError: 14025] No fact table exists at the requested level of detail
    Edit:
    Regards
    Mogens
    Edited by: user13050224 on Jun 19, 2012 6:40 AM

    Avneet gave you the beginnings of one way, but left out that a couple of things. First, you would want to do the export of level zero only. Second, the export needs to be in column format and third, you need to make sure the load rule you use is set to be additive otherwise the last row will overwrite the previouse values.
    A couple of other wats I can think of doing this
    Create a replicated partition that maps the 3 non used dimensiosn to null (Pick the member at the top of the dimension in your mapping area)
    Create a report script to extract the data putting the three dimensions in the page so they don't show up.
    Use the custom defined function jexport in a calc script to get what you want

  • 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

  • Report from 2 Facts and 1 Semi-Related Dimension

    Hello,
    I have a metadata structure as follows that is working properly:
    - Sales Fact
    - Targets Fact
    - Time Dimension
    - Sales Team Dimension
    The initial requirement was to build a dashboard report that returns actual sales results by sales team and compares them to their targets.
    Now the requirements have changed slightly and we need to filter the Sales Fact table based on a line of business. I was able to add the Line Of Business Dimension to the metadata and join it to the Sales Fact. This is where the problem arises. Sales results are now accurately returned with the filter, but since there is no relationship between the Targets Fact and Line of Business Dimension, those results now come back empty.
    Is there a way to tweak the metadata or report to fix this behaviour?
    Any recommendations are appreciated.
    Thanks

    There is no relationship between the Line of Business dimension and the Target Fact so they cannot be joined. I want to be able to query the Sales Fact with any dimension related to it and combine the results in a single table with the results from the Target Fact.

Maybe you are looking for