Link fact tables?

hi all,
I have two fact tables – charges and payments and both these fact tables are in the cube (as measure groups). On the relational side, these two fact tables are “linked” by a column called trans_no. Linking these two tables could be little tricky because
a single charge can have multiple payments.
 for example, let’s say there was a charge of 100$ but the payment was done in two installments so there is one row in the charge fact table, but 2 rows in the payment fact table – both rows have the same transaction number but different date.
It is also possible to have two charges in the charge fact table with the same transaction number but one payment in the payment fact table. So I think this is a many-to-many relationship.
How can I link these tables in SSAS? I would to be able to show payments and charges side by side down to the transaction level. Please advise and thanks for the help.

thank you Ken, so i am going to have  dimensions then? -
1. off of payments
2. off of charges
3. "Transaction" dimension
The reason i am saying i need #1 and #2 is because i need some other attributes such as "transaction type"(void etc) from both the fact tables. does this sound correct? i feel like i am cluttering the cube :(

Similar Messages

  • 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

  • How to link a fact table to one dimension many times

    I have fact table which contains four date fields and I want to connect all of them to the Time dimension. I think I probably must split this fact table to multiple tables and then link them to dimensions. What is the right way to solve this kind of problem?
    Example: Fact table: TimeIn, TimOut, TimeStart, TimeStop, InPlace, OutPlace, StartPlace, StopPlace, Speed, Weight, Width, Height .....
    Thank you

    Hello Kostis,
    thank you for your answer. I don't fully understand you. Can you show me short example, please? I create alias table for time dimension on Physical Layer - original table is TimeDayDim and I create aliases TimeDayDim1, TimeDayDim2, TimeDayDim3, TimeDayDim4. Then I create foreign key Fact.Time1 -> TimeDayDim1, Fact.Time2 -> TimeDayDim2, Fact.Time3 -> TimeDayDim3, Fact.Time4 -> TimeDayDim4. And what now? Must I create these table api Bussines Model and create new time dimensions at bussiness model????
    I need in Answers ONE Time dimension. I think I must split my fact table to four tables ... (time1, place1 ...) (time2, place2 ...) (time3 place3...) (time4 place4...) then link those tables to Time dimension (but I dont know where I can split those tables - on Physical Layer or on Bussines Layer).
    I suppose that I will have in Answers one time dimension and four facts tables and I will be able to query them. (for example: Time.Days, Fact1.Place1, Fact3.Speed, Fact4.Count Criteria: Time.Year = 2008)
    Best Regards Vlada

  • SSAS 2008 Linking two cubes on the foreign key between two fact tables

    Hi, all -- 
    I have two cubes:
    Cube 1 has Fact1 (F1, "Events") and 3 dimensions (D1, D2, D3)
    Cube 2 has Fact2 (F2, "Sales") and 3 dimensions (D4, D1, D6)
    As you can see, two cubes reuse D1 as their common dimension.  In addition, F2 foreign keys into F1, e.g. F1 is "Events", and F2 is "Sales".  Every "sale" is an "event", but not every "event" is
    a "sale".
    The question is, how to I link the two cubes and their two respective fact tables on the foreign key?
    Thanks, Austin.

    Hi Austin,
    According to your description, you want to retrieve data from two different cubes, right? In Analysis Services, to query multiple cubes from a single MDX statement you can use the LOOKUPCUBE function (you can't specify multiple cubes in your FROM statement).
    The LOOKUPCUBE function will only work on cubes that utilize the same source database as the cube on which the MDX statement is running. For the detail information about it, please refer to the link below to see the blog.
    Retrieving Data From Multiple Cubes in an MDX Query Using the Lookupcube Function
    If I have anything misunderstood, please point it out.
    Regards,
    Charlie Liao
    TechNet Community Support

  • OBIEE-can we link two dimension tables belonging to different fact tables?

    Hi ,
    I have just started with OBIEE concepts....need your views on this issue:
    Fact 1 -> Dim 1, Dim2,Dim3 and so on..
    Fact 2 -> Dim a, Dim b,Dimc and so on...
    If I link Dim1 and Dim a with a valid key ,would that distort the star schemas to slowflake in BMM layer?
    Thanks in advance!
    Neha

    I don't see this that would make it snowflake more like what I think as conforming dimensions. You need to make sure the grain of the measures is at what level , the they are same grain then you should be good however if they are different then you would start seeing null values.
    Fact Measures use the same, conformed dimensions like Dim1 and Dim a if you trying to generate from multiple facts, the BI server was able to automatically stitch them together into a single result set. If they came from the same fact table that's easy as its only one single table, but if you are pulling from different fact tables, the conformed dimensions would allow them to be stitched into the same report
    Conformance means that these sources can be mapped to a common structure – the same levels – and also the same data members.
    Mark if helps.
    Thanks,
    SVS

  • How to link two fact table in OBIEE

    i experts
    1. I have one fact table EXCHANGE_FACT(Contains the exchange rate for each curruncy on each day) .
    2. I Have anothe fact Table ACCOUNT_FACT(Contains Amount for each currency on each day).
    Now i have to link these two table on bace of currency_key and time_key in OBIEE. so i have can i achieve it in OBIEE.
    Regards
    Frnds

    Hi Frnds,
    You should create two common dimensions (currency en time) and join each fact table seperately to these dimension. Create a demnsion (hierarchy) for each dimension.
    Good Luck,
    Daan Bakboord
    Scamander Solutions

  • Multiple Date Fields (Fact Table) - Linking with Time Dimension

    I have a fact table that has multiple date columns.
    I can make a time dimension, but it has to be joined to a particular date column. This becomes difficult because of the limit in having multiple date fields reference one time dimension. I can see possibly
    creating a date table which contains all dates, link to fact as well as time dimension table. I am trying to better visualize the table layout on this one. Or are there possibily better ways of looking at this senerio
    Any idea's

    Figured this one out; going to use one time dimension - what looking too much into the details in regard to this scenerio

  • Content tab for a fact table

    Hi
    Please , help me in knowing the use of content tab for a fact table in the repository in OBIEE.
    Thanks.

    if you have multiple LTS then you should set the content level approprately otherwise you can get errors during consistency checks.not able to find any link which talks only about content level.see these links and let us know if you have any doubts
    http://kr.forums.oracle.com/forums/thread.jspa?threadID=604637
    Content tab is also handy when you are using aggregate tables.
    Regards,
    Sandeep

  • Error VLD-0917 (unknown error)  while deploying FACT table

    Hi,
    I keep getting this error while trying to deploy a FACT table:
    VLD-0917: An unknown error occured while generating <fact table name>.
    An unknown error occurred while generating <fact table name>. Error details: java.lang.NullPointerException.
    Do yo know what can it be? This fact table was linked to a Dimension that I modified (added one more level to its hierarchy). Since I did this change, the fact table cannot be validated.
    This happens to all fact tables that use this dimension. I created a new cube with the new definition of the dimension and had no trouble at all. I disassociate the dimension from existing cubes and they validate OK. What could be happening?
    I would appreciate any help you could provide.
    Regards,
    --oswaldo.
    [osantos]

    Hi,
    I realized that I'm getting this error for all fact tables. I cannot deploy any of them. What could be happening? I have a dimension that is linked to all facts which I changed recently: had to redefine its default hierarchy as a value-based one. I don't know if this affected my cubes.
    Any idea what might be happening here?
    Best Regards,
    --oswaldo.
    [osantos]

  • Regarding  Dimension Table and Fact table

    Hello,
    I am having basic doubts regarding the star schema.
    Let me explain first regarding  star schema.
    Fact table containes Key fiigures and Dim IDs,Ok,
    These DIm ids will be connected to my dimension tables.The Dimension table contains Characterstics and these Dim ids ,Ok.
      Then My basic doubt
    1.How does DIm id will be linked to SID tables
    2.If I have not maintained any master data or text or Heirachies then SID tables will it be generated or not?
    3.If it is generated I think there is use of This SID now..as we have not  maintained Master data.
    4.I am haing 18 characterstic which are no way related to each other in that scnerio how does Dimensions have to identified.?or we need to inclued whole chracterstics in one dimensions or we need to create seprate dimesnions for each of them..?(max is 13 dimensions)
    5.If Dimension table contains dim ids and characterstics then where does the  values for characterstics will be stored...?
    ( for ex..sales rep is characterstics for this we will be giving values some names where does these values will be stored..)

    hi Vasu,
    e.g we have infocube with 
    - dimension 'location' -> characteristic 'sales rep', 'country' 
    - dimension 'partner'.
    fact table
    dim-id('sales person') dim-id('partner') revenue
    1001                   9001              500
    1002                   9002              300
    1003                   9004              200
    dimenstion table 'location'
    dim-id  sid-id(sales rep) sid-id(country)
    1001    3001              5001
    1002    3004              5004
    1003    3005              5001
    'sales rep' sid table
    sid   sales rep
    3001  abc
    3004  pqr
    3005  xyz
    'country' sid table
    5001      country1
    5004      country2
    so from the link dim-id and sid, we get
    "sales rep report"
    sales-rep   revenue
    abc        500
    pqr        300
    xyz        200
    "country report"
    country    revenue
    country1   700
    country2   300
    hope it's clear.

  • Fact Table and Dimension Tables

    Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
    Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
    Please help me with this on how I should address this.

    hi,
    The exact data will be hard to give however you can reach at a round figure in your case.
    You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
    For example, let us say we want to combine data for sales order and deliveries in a DSO.
    Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
    regards,
    Arvind.

  • Multiple fact tables

    Hi All,
    I am using OBIEE 11g. In my requirement, I have 1 Fact table and 3 Materialized Views of fact table. Now, these 3 MV have same columns as actual fact table 1 barring a couple of additional columns in each of them. Imported these 3 MVs and 1 Fact table in Admin tool. In Physical Layer I joinedmy dimensions to each of the Fact (table and MVs). In BMM I created one Fact table with 4 LTS coming from these fact table and MV. Now, all the dimensions are conformed. Still when bring in a column from each of these facts I am getting incorrect results. e.g. when I find sales from years, the data is correct. As soon as I add another fact column from a different MV/fact table the values from first sales column gets changed.
    I have check LTSs and Content levels and do not see any problems.
    Does anyone have some similar experience?
    Thanks,
    D

    Hi Dcole,
    It should not be a problem,you are going in right direction but i want you to check the joins established in the physical layer once again.
    But you mentioned a point above saying all the columns are same as actual fact with MV's.I suppose it is assuming as 1 column only.Can you change the column names..
    Go through these links for more info
    http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
    http://www.obinotes.com/2010/08/joins-within-logical-table-sources-in.html
    hope helps you.
    Cheers,
    KK

  • Fact table with 2 time keys, measures showing together in the same report

    Hello,
    I am using OBI EE and I have the following scenario: a fact table hold information about enquiries. An enquiry may or may not generate an appointment. So in my fact table I have two date columns: enquiry date and appointment booked date (not the date of the appointment itself, but when it was actually booked).
    This raises a couple of questions. First question is: I can only have one logical FK to the Times table, how to create two LFKs for those 2 dates? Should I create a logical copy of the Times table in the BMM, along with another time dimension?
    Second question is how to display both pieces of data in the same report. For instance, in a summary report per month I want to see the number of enquiries made and appointments booked in each month. Most likely they will be different numbers and refer to different rows in the database. What is the best way to model this in the BMM?
    For instance, in October there were 10 enquiries, 8 of them were converted into appointments along with 3 enquires made in September. So, the report should show for October: number of enquires: 10, number of appointments: 11 (8 from October + 3 from September)
    Sorry if this is a basic question but I couldn't find around any examples of this scenario.
    Thanks,
    Luis

    Genius, that works perfectly, thanks!
    Just one issue that I noticed... I have other dimensions on that fact table, one of them is "channel". Channel is linked to a column in the original fact table, as is Number of Enquiries.
    If I include Channel in a report that shows Number of Enquiries and Number of Appointments, the Number of Appointments column only shows zeros, while the Number of Enquiries column still shows the correct numbers:
    Month    Channel   Enquiries   Appointments
    Jan 09   Email      100           0
             Phone      120           0
    Feb 09   Email       87           0
    ...Then I figured out that I needed to add a PFK for all dimensions to the aliased fact table, not only for the times dimension.
    Thanks again
    Luis

  • Reg: Fact table and Dimension table in Data Warehousing -

    Hi Experts,
    I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
    This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
    Fact table contains data that can be aggregate.
    Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
    Dimension contains data that is use to generate groups and filters.
    This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
    Any help is much appreciated.
    Pardon me if this's not the correct place for this question. My first question in the new forum.
    Thanks and Regards,
    Ranit Biswas

    ranitB wrote:
    But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
    Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
    Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
    Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
    Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
    Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
    And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

  • Join fact table with higher dimension level

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

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

Maybe you are looking for