Dimension Facts

Please advise on this.
There are 2 dimension tables with each joined to individual fact tables separately. For example, Dim1 joins to Fact1 and Dim2 joins to Fact2.
Assumption: Dim1 and Dim2 have 1000 records each. Fact 1 has 10 and Fact 2 has 100 records within it.
Is it possible to generate a report by merely selecting columns from Dim1 and Dim2 only? If yes, then I am wondering what will be the output in terms of number of records. I imagine there will be a backend query fired in some way to retrieve the data set from both the corresponding dimension tables.

Hi
The only way you can do it is to do an "union" of the dim1 members with the dim2 members.
Exemple :
Dim1 : has 1000 records representing Customers
Dim2 : has 1000 records representing Employees
You can do a report that will display 2000 "people" name.
First, do you report by displaying the 1000 customers. Do not use any measure, because fact are here useless.
Then, use the button "combine with similar request" and use the dim2 employee name.
If, in each fact table, you have a specific measure, you can add them in your combined report.
Exemple :
- Fact1 has measure "NB of purchases"
- Fact2 has measure "NB of sales"
So, your first report will display "customer name + nb of purchase"
And will be combined with "employee name + nb of sales"
It will do a combined report "people name + nb of... something"
But you won't be able to do a report that will cross the 2 dimensions "dim1 + dim2" because there is no relation between them.

Similar Messages

  • Different Data sources for dimensions & Facts

    Hi
    Here is my scenario. For our POC purpose, we are just trying to access dimensions, & Facts from 2 different data sources.
    Dimensions come from db2 and Fact table comes from a different source.
    My question here is did any one faced issues like this ? I am wondering whether i need to join these tables physically in the phyical layer or should i have to take care of them in the BMM Layer.
    Thanks in advance for any of ur ideas

    As mentioned you will need to join across data bases. One thing you will see when you do this is that OBIEE will do a bulk select across those databases then join and filter logically in its own memory process. If you MUST join across databases at least propagate the common dimensions across both databases; that way at least OBIEE can do a semi-filtered grab of the data from each database before it joins the resultsets in memory.

  • Examples of using OLAP Worksheet to define dimensions & facts

    Hi - Does anybody have examples of how to use the olap worksheet to define dimensions & facts and then load them from database tables and views? The manuals are OK, but I feel like I'm feeling my way blindly and not sure if I'm doing it right. A good set of examples would do wonders to make me more confident that I can do what I want to do.
    Using AWM is out of the question, unfortunately. It simply doesn't do what I want it to do for semi-additive measures (i.e. count distinct).
    Thanks!

    Two minutes make no difference.
    We may say that we gave the response together.
    This forum is not a race area
    Yvan KOENIG (from FRANCE vendredi 15 mai 2009 11:00:18)

  • Import individual dimensions/fact tables or use views!

    Hi,
    Just a quick question to establish if there is a difference between importing a view that has been created based on our dimensional model or should we import the individual tables i.e. dimensions & fact table
    Many thanks,
    Rhys

    Thank you both for your responses.
    I am fairly new to dimensional modelling & DW and was just curious.
    My instinct is to use the dimension & fact tables as opposed to views but I was just wondering what sort of circumstance would benefit by using one approach or the other??
    In our first steps we have modelled a fairly simple process, imported the model and displayed the data on our dashboards and this worked just fine.
    Regards,
    Rhys

  • Snapshot Dimension & Fact tables

    We are currently designing a logical multidimensional model from an OLTP tables.Dimension tables have monthly snapshot because some of or all the attributes might change on monthly basis.The same situation for the fact table has monthly snapshot.
    I know that according to Kimball's modeling, the attributes for dimensions should be implemented using mini-dimensions and put combination key as a foreign key in the fact table but this step needs an ETL job to handle mini-dimension and other fact table.However, in our situation and according to scope limitation,there is no time to design separate ETL to handle mini-dimension.
    An example for our records:
    Customer:
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr20
    Installments
    Installment_ID
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr5
    Measure1
    Measure2
    Measure3
    Measure4
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?

    Xerox wrote:
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?You already give the answer yourself: you should create an Installment dimension and a Installment fact table, using the same physical table as logical table source. The logical dimension should only contain the attributes, the logical fact should only contain measures.

  • Cartesian product of three dimensions - fact table is too big

    Hi, I need some advice with OLAP design. I have tables with orders, customers and product types. My problem is that I want to know amount of orders for every combination of customer - date since customer was created - product type. I also need to filter
    days when no order was made and the opposite (by dimension). Also customer have some interval of time when he is considered as a new customer and I need to filter this customers too (again by dimension).
    Now I have got fact table filled with every combination of customer/product type/date and the number of orders with the bit flag - was a new customer. Problem is that I have aprox 100k customers, so this table has bilions of rows. Is there any other possible
    solution? For browsing cube is used Excel where I cannot easily filter by measure/calculation.

    It seems like every customer is a new customer at some point in time. So, you should probably store first order date in the customer table. Depending on the Date (Period) selected , a customer will become new, active or inactive. Also, create measures for
    new customer sales, old customer sales. i.e. First order date + 30 days of the customer is less than last date in the period selected, it is new customer sales.  I would assume that it would be difficult to do it in cube. Did you
    try to solve the problem using SQL queries?
    Good luck. 
    Customer
    First Ord Date
    New customer till
    Cust A
    3/1/2014
    4/1/2014
    New Cust Sales
    Old Cust Sales
    Total Sales (New + old) 
    2014-01
    2014-02
    2014-03
    10
    10
    2014-04
    20
    20
    2014-05

  • Join Between Dimension & Fact Table

    Hi all,
    Here is my scenerio:
    There are two tables, one dimension table and one fact table.
    Normally, they will be joined with a key, says Date_ID.
    However, these two tables do not have the same key.
    Question comes, can I create derived columns in both tables to pretend as key (the value of key assumes the same) and join them together? If yes, which layer (physical or business logic) to do the join? Will data be shown in Answer correctly?
    Thanks.

    Thanks for reply.
    I know that if two tables have the same key, says primary key and foreign key, they can be joined directly.
    However, the tables do not have the same key/column for join.
    Actually, I've tried to create dummy columns in both tables to join together in physical layer. Then use those dummy columns in business model layer to get the value from other columns. Complex join is carried out later in business moel layer. But it seems that it does work.

  • Alternatives to Dimension facts for row counts

    Hi,
    I currently have a data warehouse with 3 fact tables, they are all at an order line granularity.  I want to start looking to add some facts that perform a distinct count of related dimensions (like how many orders, how many customers, etc).
    The method i have used is to create a measure group from the dimension in question (lets say customers) which allows me to use a count measure. 
    While this approach works, i dont like the fact that there will be many measure groups presented in the user application.  What I would like to do is have 1 measure group that contains all the "counts" for the dimensions i want.
    Is that possible?  If so, could somebody point me in the right direction?
    Many thanks in advance,
    Dominic

    My 2 cents:
    Whenever you create a distinct count measure, it creates addiitional measure group with same number of partitions as present in original measure group.
    Here is an article on distinct measure group for tabular and the multidimenional model. This article explains how you can create
    distinct measure group with single partition.
    If this post answers your query, please click "Mark As Answer" or "Vote as Helpful".

  • Dimension fact aggregation question

    Hi,
    I am new to Oracle OLAP and I noticed something in this tool. It doesn't aggregate the right way.
    For example, if there is a customer A in the Customer dimension and customer A has 5 records in the fact with amounts 10,20,30,40,50. When I build the cube, the cube doesn't aggregate the amounts for customer A. It picks one of the amounts. I have to actually aggregate in the view and pass it to the cube.
    Is this how it is in Oracle OLAP? or am i missing somehting? Help me on this basic fact/dimension design.
    Thanks in advance.

    Oracle OLAP assumes that you're loading in source data at the same dimensionality as what the cube is designed at. In your case below, that isn't true. Your cube is dimensioned only by customer, while means each customer should have one and only one record.
    Two ways to resolve this - either add another dimension to the cube that lets you break out the 5 records (maybe a time dimension?), or create a view on the fact table that summarizes the data to the lowest level of your cube.
    Hope this helps,
    Scott

  • I do not 'get' the basic snowflake / dimension / fact thing....

    Hello,
    sorry for total newB question, but if I have a table that is the most detailed level of data, do I have to create a datawarehouse copy of this that summarises it, or can OBIEE do that for me???
    I have read the documents / by example stuff but I am struggling with this most basic thing, even though the more complex areas seem easy.
    So what I am asking is, if I have a table, say 'user_trans' - do I have to write something in OWB or similar to turn this into a number of heavily summarised tables, say - user_trans_by_state, user_trans_by_period OR is there a way with the tool itself that I can take the basic table, import into the physical layer in the inventory and get OBIEE to do these summarisations for me - by generating dimensions??
    So to illlustrate, say user_trans has =>
    amount, user name, period, state
    Do I have to write something in a DW to generate
    sum(amount), user name - for user_trans
    sum(amount), state - for trans_by_state etc
    Or is there a way in the repository to do this, if so can someone please talk me through it in basic terms???
    Thanx

    Try the links detailed on an earlier answer....
    Tutorials of OBIEE?, Oracle By Example OBIEE?
    And on basic principles you are looking at a 1 => Many join in a star structure, the 1 being the centre or base of your star.
    In terms of the rest, install yourself a test area and work through the Oracle By Example stuff - if you do not get the concept maybe it will sink in with the practise....
    hope this helps - and good luck!
    R.

  • 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

  • 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

  • OBIEE: REPORT FROM 2 FACTS WITH ONE SHARED AND ONE UNSHARED DIM; POSSIBLE??

    Hi All,
    We have a typical scenario to build a report from 2 subject areas(ideally from 2 facts)
    Here is the Scenario: Creating a report which based on two facts(2 Subject Area's) and one common dimension and one unshared dimension.
    Example
    ======
    Dimension Date is common between Fact Transaction and Fact Credits.
    Dimension Credit Type is applicable only for Fact Credit.
    We have to build a report with the below mentioned attributes/metrics
    Dim Date. Attribute (*Common Dimension*)
    Fact.Transaction.Metric
    Fact. Credit .Metric
    Dim.Credit Type. Attribute (*Unshared Dimension*)
    Is this is possible in OBIEE..?
    Thanks,
    Govardhana

    Yes, you must use measure levels. Set the column level of each measure from the Transaction Fact to Total for the Credit Type dim.

  • Fact table enriched with hierachy information

    Hi Guys,
    I have a fact table design question.
    The fact data table (oracle10g) on bottom level RelationshipManager (RM) contains the data columns
    for the RM dimension:
    FACT TABLE
    ID¦RM¦DEPARTMENT¦AGENCY¦REGION¦SALES
    1---23--Bronx------------NY---------US-------23232
    2---24 ---------------------NY---------US-------87878
    3---25-----------------------------------US------ 9999999
    This means the fact has been enriched with hierachy information, this is not whats usually done.
    Why have I done it? Because the RM is not necessarily always part of a department BUT can also
    be directly placed under an agency or a region (agency or region leads).
    Have I made the right choice by chosing to enrich the fact table? I could have also build a snow flake
    schema by storing hierachy information in a seperate table.
    Thanks.

    with your problem, it might be best to split the dimension into multiple dimensions or multiple attribute dimensions with default values where you do not have a value for example set up RM with a N0_RM and when you don't have data load it there. If I'm looking at this correctly, the problem it appears you have is you have an inconsistent hierarchy. where the rollups can change. having them in the same dimesion would be problematic. If therewere consistancy then you could add members into a single hierarchy something like
    US
    --No_State
    --NY
    -----Bronx
    ------RM23
    ------No_RM
    but from your example I don't see it. If they are seperate dimensions(not attribute dimensions) then you could load based on date. If they are attribute dimensions, then look at varying attributes

  • Processing error when doing a drillthrough agianst a Rolap dimension, working with MOLAP

    Hi,
    I'm having a drillthrough dimension (fact) that i'm using for drillthrough scripts. One thing that I have come a cross is that I get processing errors when I run queries agianst a ROLAP dimension where as it works agianst the same dimension set
    as MOLAP. This is kind of confusing me.
    The error message i get is like this one:
    Errors in the OLAP storage engine: The process operation ended because the number of errors encountered during processing reached the defined
    limit of allowable errors for the operation.
    Errors in the OLAP storage engine: An error occurred while the 'Journal NO' attribute of the 'GLFact' dimension from the 'XXX' database was being processed.
    I found a article about this
    http://sqlblog.com/blogs/marco_russo/archive/2009/01/17/issues-executing-a-drillthrough-with-a-rolap-dimension.aspx
    But I have set KeyDuplicate, Keynotfound, Nullkeyconvertedtounknown and NullKeynotallowed to ignoreerror and still it doesn't work.
    So my questions are 2:
    1. Do anyone have a solution for me? Or having any thoughts about this?
    2. When switching over to MOLAP the processingtime takes about 30 min. How can i decrease this to a minimum?
    This is all implemented in SSAS 2005.

    I'm getting the exact same error when attempting to drill down on a rolap dimension associated to the cube.  the cube is molap, but the dimension is rolap to reduce processing time (processing dimension using molap spike my 4 core processing to 100%
    for 4 minutes due to all the select DISTINCT on the attributes (about 10)). 
    I too have seen the article about KeyDuplicate but I think this is a different issue.  Anyone figure out the problem?
    Version: SSAS 2012 SP2
    Example of error:
    Server: The current operation was cancelled because another operation in the transaction failed. Errors in the OLAP storage engine: An error occurred while the 'City' attribute of the 'NameAddress'
    dimension from the 'MyDatabase' database was being processed. Errors in the OLAP storage engine: The process operation ended because the number of errors encountered during processing reached the defined limit of allowable errors for the operation.

Maybe you are looking for