Details from fact table as dimension - solution review needed

Hi experts,
I found a convinient way to display details from fact table, as a dimension and need your opinion. Do you see any potential issues about this solution?
Context
- I use vertical federation in OBIEE 11.1.1.6
- all aggregated measures are in OLAP
- there is a need that user drill down to lowest level details (single fact row) -> this information is in relational database
- we decided to use dedicated presentation hierarchy column and let users drill to lowest level detail (just 2 hierarchy levels "All" -> "Detail")
- always add this column at the right side of report table and after all other dimension drills are in place (other table columns are also presentation hierarchy), user can drill to contract ID (the detail)
Solution (I tested it and it seems to works ok)
- create "dummy" relational table with just 1 row ("All" level in hierarchy), linked to fact table (to "dummy" ID column in fact table)
- create "dummy" dimension in Analytic Workspace
- in BMM create logical table with 2 data sources: OLAP for hierarchy level "All" (linked to dummy OLAP dimension) and relational for hierarchy level "Detail" (using relational fact table)
- so in BMM we have additional logical dimension with 2 levels - one "All" that read from OLAP, and does not impact performance, and second "Details" that is the only information at all that is obtained from relational database when user expand "All"
- Why created "dummy" dimension? -> because OBIEE won't let me create logical dimension from fact table columns, but can create a dummy dimension with just "All" level and add to it column from fact table
Any comments are welcome.

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.

Similar Messages

DM - "Export from Fact Table" works but "Export" does not work properly

Hi,
I'm using BPC7M.
I found it strange that Export cannot dump data to a flat file though I'm pretty sure my selection of dimension members contain data. The existing of data was further confirmed by running Export from Fact Table successfully, where I chose the same set of dimension members. Below are the log files.
Export log file FAIL
u603Bu6B65u9AA4 2
1. Dump Data:     Failed in 32 sec.
[u9009u62E9]
FILE=\Shenergy\WJ2\DataManager\DataFiles\WJ2_SunnyTest.txt
TRANSFORMATION=\SHENERGY\WJ2\DATAMANAGER\TRANSFORMATIONFILES\SYSTEM FILES\EXPORT.XLS
MEASURENAME=PERIODIC
(u6210u5458u9009u62E9)
Category:
Time:
WED_Entity:
B_Account:
DataSrc: INPUT
[u6D88u606F]
There is no data in the selected region; select a region that has data._2_True
Export from Fact Table log file   SUCCESS
u603Bu6B65u9AA4 2
1. Dump Data:          completed in 1 sec.
2. Convert Data:       completed in 0 sec.
[u9009u62E9]
FILE=\Shenergy\WJ2\DataManager\DataFiles\\WJ2SunnyTest.txt
TRANSFORMATION=\SHENERGY\WJ2\DATAMANAGER\TRANSFORMATIONFILES\SYSTEM FILES\EXPORT.XLS
(u6210u5458u9009u62E9)
Category:
Time:
WED_Entity:
B_Account:
DataSrc: INPUT
[u6D88u606F]
Record Count: 104
Accept Count: 104
Reject Count: 0
Skip Count   :0
I tried Export in another application and it worked properly. Maybe there is something wrong with the application but I don't know how I can fix this.
Thanks!
Sunny

Hi Sorin,
In order to make sure the sum is not equal to 0, I ran the "Clear" package and full optimize the application. Afterwards, I deliberately sent only 1 record. I ran the "Export from Fact Table" and I have the following contents in my output flat file.
B_ACCOUNT,TIME,WED_ENTITY,DATASRC,CATEGORY,SIGNEDDATA
KPI0001,2009.INP,DEP_INPUT,INPUT,ACTUAL,-500.0000000
This confirms that the sum is not 0. Then, I ran "Export" package. Yet again, I encountered the same error.
There is no data in the selected region; select a region that has data._2_True
Best Regards,
Sunny

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.

Join multiple fact tables and dimensions and use all tables in report issue

Hi,
I have a report requirements and need to use multiple fact tables and unconformed dimensions as described below
Fact table: F1,F2,F3
Dimensions tables: D1.....D9
F1:(joined to) D1,D2,D3,D4
F2::(joined to)D1,D2,D5,D6
F3::(joined to)D1,D2,D7,D8
D7::(joined to)D9,D8 (dimension D7 joined to two other dimensions D9 and D8
I'm trying to use columns from almost all the fact and dimension tables but getting "Unable to navigate requested expression. Please fix the metadata consistency warnings."
Repository is consistent and no errors and warnings.
How can I configure the repository to develop reports using all fact tables and dimensions?
Appreciate for your help.
Thanks
Jay.
Edited by: Jay on Feb 9, 2012 4:14 PM

So you want me to convert snowflake schema to star. does it solve my problem? individual star queries are working find but when I query multiple stars together getting inconsistency errors. I removed content tables dim level totals for unconformed dimensions in logical fact LTS and set level for measures at total level for unconformed dimensions. it is still in progress and need to test.
Thanks
Jay.

To find the size of the fact table and dimension table

Hi experts,
Can anyone plz tell me if i want to find size of the fact table and size of the dimension table to find cardinality and line item do we first build statistics then find size by transaction DB02 or any other method we have?
Thanks in advance

Hi ,
Please go to Tcode DB02 >Space>Table and Indexes.Give your table name or pattern (like /BIC/F* for gettinf all the Fact tables)
.This will give you sizes of all the table.
Also if you want to get list like TOP 30 Fact tables and Dimension Table.Please use TCode ST14, this will give a desired output with all the required details.
-Vikram

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.

Fact table and dimension table

what is the difference b/w fact table and dimension table

A fact table contains numeric values and also contain composite key(i.e collection of foreign key) e.g.. sales and profit. Typically has two types of columns: those that contain facts and those that are foreign keys to dimension tables.
Dimension tables, also known as lookup or reference tables, contain the relatively static data in the warehouse. It contains character values E.g Customer_name,Customer_city.
Dimension tables store the information you normally use to contain queries. Dimension tables are usually textual and descriptive and you can use them as the row headers of the result set.
Rachna

Sizeof fact table and dimension table

Hi Experts ,
Can you tell me how to measure the size of dimension table and fact tables and how to find the ratio of size of dimension table to the size of fact table.
Thanks in advance,
Thanks and Regards
Ram Kommineni

Hi,
The ratio of size of fact table to dimension table is ideally should be 10:1. That means the size of the dimension tables should be 10% of the size of the fact table. This serves better in terms of performance.
Whenever you load any cube, you can easily find out the number of records in fact table (E and F table) and the dimension tables. Based on that statistics you can determine the ratio of size in fact and dimension tables.
Hope this info helps you.
Regards,
Yogesh.

Where can we see Fact Table And Dimension Table in DataWarehouse Workbench?

Hai Experts
where can we see Fact Table And Dimension Table in DataWarehouse Workbench?
Best Regards
nvnkmr12

Hi
Refer the link below and you will get a comprehensive explanation of how data is stored and modeled in BI. If explains fact table, dimension table, SID table, P and Q , X and Y tables.
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/6ce7b0a4-0b01-0010-52ac-a6e813c35a84
Cheers
Umesh

#datasync error - could that come from merging on fields from fact tables instead of dimensions tables?

I'm reporting out of two universes published by Epic
1. Warehouse - Patient
2. Warehouse - Transactions
I wanted to join two queries based on the primary key for a hospital encounter. Following the tutorial seemed pretty straightforward until I got to displaying data from a merged query.
The table displayed results from Query1, but adding fields from Query2 wiped out all the data in the table, leaving only #datasync in each field.
My workaround to get fields from both queries displayed (see screenshot)
1. Merge queries on *two* fields - primary key of hospital encounter and primary key of patient
2. Create new variable
3. Make variable type Detail
4. Associate variable with hospital encounter key from Query1
5. Set formula equal to a field from Query2
I'm not sure why this workaround works or if what I'm experiencing is a symptom of something larger. Could this workaround be needed because I am merging on fields from a fact table instead of fields from a dimension table?
Thanks in advance

You have defined merged dimension on 'company code-Key' which is common in both the Bex-queries.
You are able to bring the merged dimension and other objects from Query_ One to report block without any issue but when adding objects from Query_Two you are getting the error #DATASYNC.
In this case objects from Query_One are got sync with the merged dimension object without any issue because they got added first to it.
Similarly when you add merged dimension and objects from Query_Two you find no issue, because objects from Query_Two go sync first.
Once objects from a query(Query_One/Query_Two) got added to a merged dimension, when we try adding objects from other query we get #DATASYNC error. This is because data in the other query is not able to sync with the initial result set, this is a know behavior.
There are two workarounds:
1) Merging all common dimension/characteristic objects: Only merged dimensions data will sync with the initial query, un-merged dimensions/characteristic objects will still give #DATASYNC error.
2) Create detail objects/attribute objects at report level for all uncommon characteristic/dimension objects from query_two referring to merged dimension. Then add these newly created detail/attribute objects to the table block that is having initial query objects with merged dimension, with this you see result set of query_two in the table block not #DATASYNC error.
~ Manoj

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.

Multiple fact tables and dimensions

I have two fact tables actual sales and planned sales and 8 dimension tables, using a star schema. I want to query on the two fact tables with two dimensions, product and time. When I create the report in discoverer i bring in the sales from actuals and then the product_desc and month_desc. Then I bring in the measure from the second fact table and a join window pops up asking which join to use. If I choose the join to the time dimension then I get no data for the second fact table and correct data for the first fact table. If I choose the product dimension then I get correct data for the first fact table and grossly incorrect data for the second fact table.
How can I stop this from happening?
Nick

Nick,
I hope you solved your reporting issue and can share the solution with me. I am encountering the same problem. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and have 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then week-ending from my time dimension, everything looks good at the stage. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost from the second fact table (advertsing costs)...... any help would be appreciated
monalisa

How to combine multiple fact tables and dimensions in one worksheet?

Hello Forum,
I am encountering a reporting problem when trying to create a worksheet that uses more than one cube/fact table and common dimensions. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then day from my time dimension, everything looks good at the stage, we're just trying to get a sum of all sales for that store on that day. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost measure from the second fact table (advertsing costs)...... any help would be appreciated

You have encountered one of the key limitations of Discoverer... which I complained about to the Discoverer product manager at OpenWorld in 2001....
Anyhow, to get around this, you are going to have to deal with it either in the database, (views, materialized views, tables), or within the admin tool by creating a custom folder.
Discoverer also calls this the "fan trap", but never really had a solution to the problem. [The solution only worked is you joined to one and only one dimension!]
What you want (using Sales_Fact and Inventory_Fact as an example) is to join Sales to Time, Store, and Product, and save that result. Then join Inventory to Time, Store, and Product, save that result, then do a double outer join between the two intermediate temporary tables in order to calculate something useful like inventory turns by store and product line.
This is also known a "multipass SQL", and is supported by some (but not many) other tools.
So, to accomplish this with Discoverer, you'll either need to create a view, or table, or materialized view that has already put Sales and Inventory into a single (virtual?) fact table. Alternatively you can write the SQL for how to do this linkage (don't forget to handle missing data), and use the Discoverer admin tool to create a custom folder that uses your SQL.
Hope this helps!

How to resolve many fact tables and Dimensions tables

Hi,
The scenario is we have many facts and dimension tables. Based on some conditions one measure from one fact will be divided by another fact measure. I have encoutered with many errors like " Unable to navigate .... " ? How to resolve these errors and reduce many to few ? ( I assume creating logical tables, but is there any other alternatives ? )
thanks
Suresh

Suresh,
I assume that you know how to create a single logical fact from n-physical facts, ie only if the fact tables are related. Then join all the conformed dimensions to this single Logical table using a join in the Business Model layer. Remember to set the mappings in the LTS. All if you have any hierarchies please set the aggregation level for those.
- Red

Including column from fact table reduces number of rows returned

Hello
I am facing this issue where in a report I select 5 columns from a fact table. Out of these five columns one of the column is "Amount" for which the aggregation rule is defined as Sum in RPD.
When I include these five column and filter results based on some criterion , I get all the rows (three rows) that satisfy the criterion. No I add a sixth column to my report and suddenly I only see one row returned by my report. Addition of this sixth column does not affect the criterion as the criterion is not based on this column. But this sixth column is a calculated column.
I tried different things but because the report was just getting columns from one table (fact) and suddenly inclusion of one column leads to reduction in number of rows , I was unable to find any reason why would that happen.
So I thought that some one in community may know that in what scenario this happens.
Thanks

Are there any repeated values? I'm wondering if what you're seeing is actually suppression of repetition in the results. Edit the analysis, go to the criteria tab, click column properties, go to the Column Format tab, and change the setting for value suppression from 'Suppress" to "Repeat". Repeat for each of your 6 columns and check the outcome.
Otherwise, I would try testing with other calculations and also bring in some columns from dimension tables to see how this affects the result. You should be able to come up with a case-by-case scenario to work out exactly what causes the rows to be suppressed which will get us one step to closer to working out why the rows get suppressed.
Thanks,
George

Details from fact table as dimension - solution review needed

Similar Messages

Maybe you are looking for