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!

Similar Messages

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.

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

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.

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

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 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.

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

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

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

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.

Merging Multiple fact tables and creating a BIA target

Hi Folks
We are using Dataservices with BIA.
We want to merge mutliple fact table and create a sinvglc cube on BIA.
when we tried to do that we get a error message that we cannot merge multiple fact tables.
any pointers ?
Poonam

You could have the cubes individually on the BIA and then have a multiprovider which you can use..?
or create separate universes on the cubes and then merge the universes in BO and then you could hit the BIA for the same..?

Best way to combine multiple fact tables in single mart

Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
However, I'm not quite sure how to proceed at the month level. My initial thought is:
a) create a new LTS for the fact table at the month level
b) in the new LTS, add the join to the time dimension
c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
Is this the proper way to do this?
Thanks in advance!
Scott

Hi Scott,
I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
DAILY_FACT (
DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
DAILY_VALUE NUMBER); -- FACT MEASURE
MONTHLY_FACT(
MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
DIM_DATE(
DATE_KEY NUMBER,
DATE_VALUE DATE,
DATE_MONTH VARCHAR2(20),
DATE_YEAR NUMBER(4));
DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
Step 1)
Make the following three joins in the physical layer:
a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
Step 2)
Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
Step 3)
Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
Step 4)
Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
Step 5)
Drag all required reporting columns to the Presentation layer.
Step 6)
Create your report using the two different measures from the different fact tables.
Step 7)
Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
Step 8)
You're done.
The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
Hope that helps!
-Joe
Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

Can anyone tell what are the fact tables and dimension tables available in banking domian

what are the fact and dimension tables available in banking domain.
maximum how many fact and dimension tables we can keep in the banking project

Hi Srikanth Korrapati,
Please have a look on this book
The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling By Ralph Kimball & Margy Ross.
Here is the below link completely about the Banking Case Study from DW Toolkit.
The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling - Banking Case Study
Hope this will help you out
Regards,
Akhileshkiran.

How to create solved fact table and corresponding cube

Hello,
I want to create cube with solved fact table. It means, i need to feed data for higher levels of dimension also from fact table instead of aggreting from base level.
I am using star schema and AWM 10g R2 for creating cube.
If anyone knows how to do this, i would be very benificial.
Thanks
Subash

I have generated parent child script using cwm2_olap_pc_transform.create_script. After running this generated script, it has created 3 table/view.
My Base Parent Child table is like this:-
drop table PARENT_CHILD;
create table PARENT_CHILD (PARENT varchar2(30), CHILD varchar2(30));
insert into PARENT_CHILD values ('Eligible', 'Compliant');
insert into PARENT_CHILD values ('Eligible', 'Non-Compliant');
insert into PARENT_CHILD values ('All', 'Eligible');
insert into PARENT_CHILD values ('All', 'Ineligible');
insert into PARENT_CHILD values (null, 'All');
After running generated script thru cwm2_olap_pc_transform.create_script, it has created :-
Table - PARENT_CHILD_SOLVED
View - PARENT_CHILD_SOLVED_view , PARENT_CHILD_view
This script also inserted data in above table/view. (5 rec in each). Table/View structure is like this:-
SQL> desc PARENT_CHILD_view
Name Null? Type
GID NUMBER
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 All Eligible Compliant
0 All Eligible Non-Compliant
1 All Eligible
1 All Ineligible
3 All
SQL> desc PARENT_CHILD_SOLVED
Name Null? Type
GID NUMBER
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 All Eligible Compliant
0 All Eligible Non-Compliant
1 All Eligible
1 All Ineligible
3 All
SQL> desc PARENT_CHILD_SOLVED_view
Name Null? Type
GID NUMBER
SHORT_DESCRIPTION VARCHAR2(30)
LONG_DESCRIPTION VARCHAR2(30)
CHILD1 VARCHAR2(30)
CHILD2 VARCHAR2(30)
CHILD3 VARCHAR2(30)
Data:-
0 Compliant Compliant All Eligible Compliant
0 Non-Compliant Non-Compliant All Eligible Non-Compliant
1 Eligible Eligible All Eligible
1 Ineligible Ineligible All Ineligible
3 All All All
I tried to create dim and cube based on this. I am not sure whether its correct or not! Though validate_dimension API call shows that it is valid.
Script for Dim:-
DECLARE
-- variable to hold error message
errtxt varchar(60);
BEGIN
-- To be on safer side just drop dimension before creating new one and catch exceptions
BEGIN
cwm2_olap_dimension.drop_dimension('APPS', 'HCP_DIM_PC');
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Dimension HCP_DIM_PC not dropped');
END;
cwm2_olap_dimension.create_dimension(
'APPS',
'HCP_DIM_PC',
'Parent Child',
NULL,
'Parent Child',
'Parent Child',
NULL);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Short Description',
'Short Description',
'Short Description',
'Short Description',
TRUE);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Long Description',
'Long Description',
'Long Description',
'Long Description',
TRUE);
cwm2_olap_dimension_attribute.create_dimension_attribute(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'Grouping ID',
'Grouping ID',
'Grouping ID',
TRUE);
cwm2_olap_hierarchy.create_hierarchy(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'Standard',
'Standard',
'Standard Parent Child Hierarchy',
'SOLVED LEVEL-BASED');
cwm2_olap_dimension.SET_DEFAULT_DISPLAY_HIERARCHY ('APPS', 'HCP_DIM_PC', 'HCP_DIM_PC_HIER');
cwm2_olap_level.create_level(
'APPS',
'HCP_DIM_PC',
'ALL_PARENT_LVL',
'All Parent Child',
'All Parent Child',
'All Parent Child',
'All Parent Child Level');
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Short Description',
'ALL_PARENT_LVL',
'Short Description',
'Short Description',
'Short Description',
'Short Description',
TRUE);
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Long Description',
'ALL_PARENT_LVL',
'Long Description',
'Long Description',
'Long Description',
'Long Description',
TRUE);
cwm2_olap_level_attribute.create_level_attribute(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'ALL_PARENT_LVL',
'Grouping ID',
'Grouping ID',
'Grouping ID',
'HTB Grouping ID',
TRUE);
-- Add all levels one by one to dimension hierarchy. For top most level last parameter is null.
cwm2_olap_level.add_level_to_hierarchy(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
NULL);
BEGIN
cwm2_olap_table_map.removemap_dimtbl_hierlevel(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Short Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Short Description');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Long Description', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Long Description');
cwm2_olap_table_map.removemap_DimTbl_HierLevelAttr(
'APPS', 'HCP_DIM_PC', 'Grouping ID', 'HCP_DIM_PC_HIER', 'ALL_PARENT_LVL', 'Grouping ID');
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Level map for ALL_PARENT_LVL not removed');
END;
-- Map ALL_PARENT_LVL level to dimension table. Last parameter is null since it is top most level
cwm2_olap_table_map.map_dimtbl_hierlevel(
'APPS',
'HCP_DIM_PC',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'GID',
NULL);
-- one by one map all the level attributes to respective columns in the dimension table.
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Short Description',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Short Description',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'SHORT_DESCRIPTION');
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Long Description',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Long Description',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'LONG_DESCRIPTION');
cwm2_olap_table_map.Map_DimTbl_HierLevelAttr(
'APPS',
'HCP_DIM_PC',
'Grouping ID',
'HCP_DIM_PC_HIER',
'ALL_PARENT_LVL',
'Grouping ID',
'APPS',
'PARENT_CHILD_SOLVED_VIEW',
'GID');
-- Use cwm2_olap_validate.validate_dimension to validate the dimension
cwm2_olap_validate.validate_dimension('APPS', 'HCP_DIM_PC');
cwm2_olap_metadata_refresh.mr_refresh;
-- Rollback if any exception occurs during processing this script
EXCEPTION
WHEN OTHERS THEN
cwm_utility.dump_error;
errtxt := cwm_utility.get_last_error_description;
dbms_output.put_line('ERROR: ' || errtxt);
ROLLBACK;
RAISE;
END;
Script for Cube:-
declare
HCP_time_dim number;
errtxt varchar(60);
begin
cwm_utility.collect_garbage;
begin
cwm2_olap_cube.drop_cube('APPS', 'HCP_PC_CUBE');
exception
when others then
dbms_output.put_line('No HCP_PC_CUBE to drop');
end;
begin
cwm2_olap_catalog.drop_catalog('HCP_PC_CAT');
exception
when others then
dbms_output.put_line('No HCP_PC_CAT to drop');
end;
CWM2_OLAP_CUBE.Create_Cube('APPS', 'HCP_PC_CUBE', 'Parent Child Cube', 'Parent Child Cube','Parent Child Cube');
cwm2_olap_cube.add_dimension_to_cube('APPS', 'HCP_PC_CUBE','APPS', 'HCP_DIM_PC');
cwm2_olap_measure.create_measure('APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE', 'PC Measure','PC Measure', 'PC Measure Fact');
cwm2_olap_table_map.map_facttbl_levelkey('APPS','HCP_PC_CUBE','APPS','HCP_PC_FACT','ET', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:ALL_PARENT_LVL/COL:CHILD3;');
cwm2_olap_table_map.Map_FactTbl_Measure('APPS', 'HCP_PC_CUBE','HCP_PC_MEASURE', 'APPS', 'HCP_PC_FACT', 'MEASURE_COL', 'DIM:APPS.HCP_DIM_PC/HIER:HCP_DIM_PC_HIER/GID:GID/LVL:CHILD3/COL:SHORT_DESCRIPTION;');
cwm2_olap_catalog.create_catalog('HCP_PC_CAT', 'Parent Child Catalog');
cwm2_olap_catalog.add_catalog_entity('HCP_PC_CAT', 'APPS', 'HCP_PC_CUBE', 'HCP_PC_MEASURE');
cwm2_olap_validate.validate_cube('APPS', 'HCP_PC_CUBE','DEFAULT','YES');
cwm2_olap_metadata_refresh.mr_refresh;
exception
when others then
cwm_utility.dump_error;
errtxt := cwm_utility.get_last_error_description;
dbms_output.put_line('ERROR: ' || errtxt);
rollback;
raise;
END;
My Fact Table is :-
DROP TABLE HCP_PC_FACT CASCADE CONSTRAINT;
CREATE TABLE HCP_PC_FACT (
SHORT_DESCRIPTION VARCHAR2(30) NOT NULL,
GID NUMBER NOT NULL,
CHILD1 VARCHAR2(30) NOT NULL,
CHILD2 VARCHAR2(30) ,
CHILD3 VARCHAR2(30) ,
MEASURE_COL NUMBER NOT NULL);
Data in Fact Table:-
insert into HCP_PC_FACT values('Compliant',0,'All','Eligible','Compliant', 100);
insert into HCP_PC_FACT values('Non-Compliant',0,'All','Eligible','Non-Compliant', 200);
insert into HCP_PC_FACT values('Eligible',1,'All','Eligible',null, 300);
insert into HCP_PC_FACT values('Ineligible',1,'All','Ineligible',null, 400);
insert into HCP_PC_FACT values('All',3,'All',null,null, 500);
I am not sure how to create level, level attr, dim attr for such dim.
All CWM2 validation API shows that my all dims, cubes are valid but when I try to create presentation thru JDev it hangs after selecting Parent-Child Measure.
Any complete working exapmle will be helpful.
P.S. One more query I have can we have one solved and one un-solved dim in the same cube/measure?
regds
Prakash

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

Similar Messages

Maybe you are looking for