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

Similar Messages

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

I'm trying to open a 900kb Word doc (240pages) in Pages but get this error message: Import Warning - A table was too big. Only the first 40 columns and 1,000 rows were imported.

I'm trying to open a 900kb Word doc (240pages) in Pages but get this error message: Import Warning - A table was too big. Only the first 40 columns and 1,000 rows were imported.

Julian,
Pages simply won't support a table with that many rows. If you need that many, you must use another application.
Perhaps the originator could use a tabbed list rather than a table. That's the only way you will be able to contain a list that long in Pages. You can do the conversion yourself if you open the Word document in LibreOffice, Copy the Table, Paste the Table into Numbers, Export the Numbers doc to CSV, and import to Pages. In Pages Find and Replace the Commas with Tabs.
There are probably other ways, but that's what comes to mind here.
Jerry

Cartesian product (sum function on 2 tables)

Dear all,
I have 2 tables with columns student_no (foreign key), date and amount in both tables.
now I want to select the sum of the amount for a student for specific date.
the following query is from stu_fee_payment table.
select sum(sfp.amount)
from stu_fee_payment sfp
where student_no =1
and sfp.pay_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
result: 200
the following query is from stu_fee_adjustment table.
select sum(sfa.adj_amount)
from stu_fee_adjustment sfa
where student_no =1
and sfa.adj_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
result: 400
now I have the following query
select sum(sfp.amount), sum(sfa.adj_amount)
from stu_fee_payment sfp, stu_fee_adjustment sfa
where sfp.student_no = sfa.student_no
and sfp.student_no =1
and sfp.pay_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
and sfa.adj_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
result: 400 400
its some kind of cartesian product because the two tables have no primary foreign key relationship.
how to solve the problem?
Regards:
MN
Edited by: Muhammad Nadeem on Aug 22, 2010 11:55 PM
Edited by: Muhammad Nadeem on Aug 23, 2010 12:58 AM

Hi Nadeem,
Try this one
SELECT sfp_sno,sfp_amount,sfa_amount
FROM
SELECT sfp.student_no sfp_sno, SUM(sfp.amount) sfp_amount
FROM stu_fee_payment sfp
WHERE sfp.pay_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
GROUP BY sfp.student_no
) x,
SELECT sfa.student_no sfa_sno, SUM(sfa.adj_amount) sfa_amount
FROM stu_fee_adjustment sfa
WHERE sfa.adj_date < TO_DATE('01-AUG-2010','DD-MON-YYYY')
GROUP BY sfa.student_no
)y
WHERE sfp_sno = sfp_no(+) Regards,
Sreekanth Munagala.

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.

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.

Reporting off of three main fact tables

Hello all, we're starting work on a new universe and have run into some headaches.
Here's some background : Our datawarehouse splits our charges, payments and adjustments into three separate tables. Previously we've used a materialized view to join these three for Universe and reporting needs.
We'd like to get away from using this mview, hence the new Universe.
The issues we're running into are incorrect details and data aggregation.
Have any of you successfully gotten around a similar issue without using a materialized view?
Thanks!

Hi Stratos, thanks for your suggestion but using derived tables isn't really an option for us as performance is critical and our BO Admins don't like the amount of proc time they use.
We think we've found another option, I'll post back if it works.
Thanks

RCD table getting too big

Hello,
Our rcd table is getting bigger (21 M records) and querying from that table takes up a lot of time.
What is the recommended way to keep the size of that table within control?
We can always create a materialized view to get a subset of that table so we can work with more recent records. However, this doesn't solve the problem of it getting bigger and bigger.
Do you get it purged or archived somehow?
Thanks
Khanh

Will do.
Thank you Martin.
Found this document on metalink:
https://support.oracle.com/CSP/ui/flash.html#tab=KBHome(page=KBHome&id=()),(page=KBNavigator&id=(bmDocType=HOWTO&bmDocDsrc=DOCUMENT&bmDocTitle=Question%20on%20Switching%20to%20Noarchivelog%20Before%20Running%20Recon%20Archival%20Utility%20in%20OIM?&from=BOOKMARK&bmDocID=759373.1&viewingMode=1143))
Question on Switching to Noarchivelog Before Running Recon Archival Utility in OIM? [ID 759373.1]
Khanh
Edited by: user12049102 on Dec 4, 2009 11:14 AM
Edited by: user12049102 on Dec 4, 2009 11:18 AM

Trinidad table/form too big in mobile page

I was trying to emulate the demo at [http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/ADFMobile/adfmobile.htm] using my own data. I can't seem to get trinidad tables/forms to fit as nicely as the demo does within a 240x320 screen at design time. I set the width to 100% with no success. What other property/template should I set?

Nevermind! Set the form font to be smaller and that helped.

Logical fact table with fragmented data sources with different dimensions

Hello.
I have a logical fact table with four logical table sources. Three of the LTS's share the same dimensions, but the fourth LTS has one dimension (called Dim_A) less. In the physical layer the dimension Dim_A is joined to the first three physical fact tables, but not to the fourth fact table (since it doesn't have that dimensionality). In the BMM layer the logical fact table is joines to the logical dimansion Dim_A.
When I run an analysis on this RPD the measures from the logical fact is aggregated correctly (union of all four table sources) as long as I doesn't include Dim_A, but as soon as I include dimension Dim_A I get the error message:
+State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14052] Internal Error: Logical column Dim_A.Column_X has no physical sources that can be joined to the physical fact table source [Logical table sources (Priority=0): Fact_B.Fact_Y]. (HY000)+
I would like a solution where the analysis returns correctly aggregated measures also for the LTS with the "missing" dimension, but with a dimension value NULL for this LTS. Or something like this.
Is there a way to set this up in the RPD.
Thanks,
Henning Eriksen

The SQL could look something like this.
SELECT dim_a.col_1, fact_a.measure_1
FROM db.dim_a
JOIN
db.fact_a
ON fact_a.col_2 = dim_a.col_2
WHERE fact_a.date = '28-nov-2012'
UNION ALL
SELECT dim_a.col_1, SUM (fact_b.measure_1)
FROM db.dim_a
JOIN
db.fact_b
ON fact_b.col_2 = dim_a.col_2
WHERE fact_b.date = '28-nov-2012'
UNION ALL
SELECT dim_a.col_1, SUM (fact_c.measure_1)
FROM db.dim_a
JOIN
db.fact_c
ON fact_c.col_2 = dim_a.col_2
WHERE fact_c.date = '28-nov-2012'
UNION ALL
SELECT NULL, SUM (fact_d.measure_1)
FROM db.fact_d
WHERE fact_d.date = '28-nov-2012'
I would appreciate if you could give me some hints for the RPD.
Thanks,
Henning

Is it ok? if we have 42 million records in a single fact table!!

Hello,
We have three outstanding fact tables, and we need to add one more fact type, and we were thinking whether we can do two different fact tables, or can we put the values in one of the same fact table which is similar, but the records are upto 42 million if we add ,so my question is having a single fact table with all records, or breaking it down, to two different ones!!!Thnx!!

I am not sure what is an "outstanding fact" or an "fact type". A 42m fact table doesn't necessarily indicate you are doing something wrong although it does sound as odd. I would expect most facts to be small as they should have aggregated measures to speed up report. In some cases you may want to drill down to the detailed transaction level in which case you may find these large facts. But care should be taken not to allow users to query on this fact without user the "transaction ID" which obviously should be indexed and should guarantee that queries will be quick.
Guessing from your post (as it is not clear not descriptive enough) it would seem to imply that you are adding a new dimension to your fact and that will cause the fact to increase it's row count to 42m. That probably means that you are changing the granularity of the fact. That may or may not be correct, depending on your model.

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

Map two fact table

hi,
I have develop one application, in which
1 fact table(cube) and 6 dimension table(dimension)
fact table : project billing detail
dimension table : customer, time, PM, company etc.
its working fine
because there are foreign key in project billing table
now i want to map one project_CR table which is child table of project billing table
i have create one cube for that and in repository i have crate foreign key in business diagram so project_CR table show as a dimesion table
in presentation when i am creating report in BI answer its giving with other dimension table,
its working with only fact table project billing.
how can i map project_CR table so it will work with combination report with other dimension.
please help me..
thanks in advance.
Edited by: user579853 on Mar 9, 2010 6:11 AM

Thanks for your reply.
to the source of dimension table means..?
Should i create new dimension for project_cr ?
one thing i did that i have created one dimension project_id and map both cube project and project_cr with that dimension
now its working fine in presentation layer for project,project_cr,project_id table
but project_cr table now working with other dimension like time,pm.
if i want report with combination of time,project,and project_cr then its showing null data in project_cr.
Please describe me in some detail so i can do it.
Thanks in advance.

Issue using one 2 Fact tables with one dimension Table.

Hi,
I have 1 Dimension table X and 2 Fact tables A and B
X is joined to Both A and B for Loan Amount ( with A) and for colleatral amount (with B) when I am selecting the X.Product_Name, A.Loan_Amt, B.Collateral Amount, it is giving an error message
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table EIP Collateral FACT) does not contain mapping for [EIP Reporting FACT.PD ID]. (HY000)
Any clues???
Is there a Inner or Outer join which needs to be created or set in the RPD to get the desired results???

Ok..
I have one table which is Porfolio Details which has Portfolio name, Product Category , Product Name, Product ID, Product sources code.- This is my Dimension table.
I have another 2 set of fact tables : EIP Reporting FACT and EIP Collateral FACT..
These two tables are joined to Portfolio Details table.
EIP Reprting FACT gives portfolio wise Loan Amount
and EIP Collateral FACT gives Portfolio wise Collateral Amount details for same set of customer..
Now, I am selecting Portfolio Name, Product Category, Product Name,SUM( EIP Reporting FACT.LOAN_AMOUNT), SUM(EIP Collaetral FACT.Collateral_Amt) in a report
Now, on selecting these columns I am getting that error message which is related to mapping.
If I take any column from Portfolio details table and any column from EIP Reporting FACT- It works.
If I take any column from Portfolio details table and any column from EIP Colletral FACT- It works.
But if I take any column from portfolio table and columns from both FACT tables it gives mapping error...
Hope I am able to explain the issue in a better way now..
Edited by: help-required on Mar 11, 2010 6:53 PM
Edited by: help-required on Mar 11, 2010 6:53 PM

Multiple Fact Tables and Dimension Tables

I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
Thank you in advance for anyones time. :)
Dimension Tables
WorkOrder_D
Operation_D
Resource_D
Organization_D
Fact Tables
WorkOrder_F
Operation_F
Resource_F
Joins
WorkOrder_D -> Operation_D
Operation_D -> Resource_D
WorkOrder_D -> WorkOrder_F
Operation_D -> Operation_F
Resource_D -> Resource_F
Organization_D -> WorkOrder_D
Organization_D -> Operation_D
Organization_D -> Resource_D

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.

Cartesian product of three dimensions - fact table is too big

Similar Messages

Maybe you are looking for