No query rewriting in a star schema

Gentlemen,
I am facing a problem with query rewriting in a simple data warehouse star schema. I want to take advantage of the built-in roll up along dimensions of a star schema. Therefore, I created several DIMENSIONs and made sure that all foreign key/primary key relationships between fact and dimension tables are set up correctly. In addition, as many table attributes as possible are assigned the NOT NULL constraint, especially the ones that are used by the CHILD Of and ATTRIBUTE relationships.
I defined materialized views on the fact table and a couple of dimension tables to report on aggregated data. All the MVIEWs are enabled for query rewriting and I have the initialization parameter set correctly (QUERY_REWRITE_INTEGRITY is set to TRUSTED).
From my tests I learned that a query is rewritten correctly only of the corresponding MVIEW contains the fact table and one dimension table. This is true for every dimension I created. However, as soon as the MVIEW joins more than one dimension table to the fact table the rewriting mechanism fails. It appears that the roll-up (aggregation along the hierarchy) is only possible for one of the dimensions. If the original query suggests rolling-up more than one dimension (e.g., "summarize the key figures by year and product category" but the underlying dimension is based on month and product), the MVIEW is no longer rewritten at all.
Do you know this effect from your work experience? Is this a bug or have I made a mistake or forgotten to switch on a special feature?
Here are some technical data of our data warehouse: we are running an Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 on a Windows Server 2003, the size of the database is about 10 GB (excluding indexes), the star schema contains ten dimension tables each one with a simple or parallel hierarchies (e.g. a product dimension). The fact table and the MVIEWS are partitioned by month.
Any help is very welcome.
Regards,
John

Hi,
you may ask with DBMS_MVIEW why your query does not get rewritten:
Maybe you have to create a util table first with
SQL> @?/rdbms/admin/utlxrw.sql
Then you ask:
SQL> begin
DBMS_MVIEW.EXPLAIN_REWRITE('<your query without ; at the end>');
end;
The reason why it is not rewritten:
SQL> select message from rewrite_table order by sequence;
Kind regards
Uwe

Similar Messages

Risky enable star transformations and trusted Query Rewrites?

Hi,
I need some advice/opinions from someone experienced with large scale
data warehousing.
I'm working on a fairly large data warehouse (around 3 TB), and we're
using Oracle 10.1.0.2.0.
So, I found out about MV's and Star Transformations, and that we're not
using them.
Naturally I decided to try them out in our test environment and I was
more than pleased (actually, I nearly wet my pants) with the potential
performance boost we could get for some of our more critical solutions.
However, I also noticed that the production environment has the
following settings:
star_transformation_enabled = false
query_rewrite_integrity = enforced
...which basically disables all the cool stuff. In the testing
environment I used the following:
star_transformation_enabled = true
query_rewrite_integrity = trusted (to make use of func. dep in
dimensions)
I would like to stand on somewhat solid grounds and increase my
understanding before aproaching our DBA's with the suggestion to change
system global settings :)
Basically, my question(s) are:
1. What are the impact of enabling Star Transformations on a system?
Is there any at all, if no previous solution has been built in a way
to
make use of star transformations?
Or could this change result in fine-tuned queries performing badly
since they
suddenly make use of star transformations?
2. Is "query_rewrite_integrity" used by Oracle for other things besides
Materialized Views?
I'm thinking, if the only thing it's used for is to resolve query
rewrites for MV's, then it's safe to change it, because there are no
such MV's.
Note that I'd like to set it to TRUSTED, in order to make real use
of the dependencies declared with CREATE DIMENSION...
I would be happy to know what you think about this.
Any thoughts, opinions are welcome since this is new grounds for me.
Best Regards
R.

Following parameters are deprecated in release 10.2.
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE
Check this in your parameter file.
As per Oracle Errors Documents.
Error : ORA-32004
Cause:     One or more obsolete and/or parameters were specified in the
     SPFILE or the PFILE on the server side.
Action:     See alert log for a list of parameters that are obsolete. or
     deprecated. Remove them from the SPFILE or the server side PFILE
Regards,
Sabdar Syed.

Query Rewrite ISSUE (ANSI JOINS do not work, traditional join works ) 11gR2

For some types of queries constructed with ANSI JOINS, materialized views are not being used.
This is currently increasing time on various reports since we cannot control the way the queries are generated(Tableau Application generates and runs queries against the STAR Schema).
Have tried to debug this behavior using DBMS_MVIEW.EXPLAIN_REWRITE and mv_capabilities function without any success.
The database is configured for query rewrite: REWRITE INTEGRITY, QUERY REWRITE ENABLED and other settings are in place.
Have successfully reproduced the issue using SH Sample schema:
Q1 and Q2 are logically identical the only difference between them being the type of join used:
Q1: ANSI JOIN
Q2: Traditional join
Below is an example that can be validated on SH sample schema.
Any help on this will be highly appreciated.
-- Q1: the query is generated by an app and needs to be rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
-- Q2: the query with traditional join is rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Tested both queries with the following materialized views:
CREATE MATERIALIZED VIEW MVIEW_TEST_1
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
CREATE MATERIALIZED VIEW MVIEW_TEST_2
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Explain Plans showing that Q1 does not use materialized view and Q2 uses materialized view
SET AUTOTRACE TRACEONLY
--Q1 does not use MVIEW_TEST_1
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4    5
511 rows selected.
Execution Plan
Plan hash value: 1218164197
| Id | Operation           | Name       | Rows | Bytes |TempSpc| Cost (%CPU)| Time       |
|   0 | SELECT STATEMENT      |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   1 | HASH GROUP BY           |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   2 |   VIEW                | VM_NWVW_1 | 55500 | 1571K|       |   916   (1)| 00:00:11 |
|   3 |    HASH GROUP BY      |        | 55500 | 1842K| 2408K|   916   (1)| 00:00:11 |
|* 4 |     HASH JOIN           |        | 55500 | 1842K|       |   409   (1)| 00:00:05 |
|   5 |      TABLE ACCESS FULL| COUNTRIES |    23 |   414 |       |     3   (0)| 00:00:01 |
|   6 |      TABLE ACCESS FULL| CUSTOMERS | 55500 |   867K|       |   405   (1)| 00:00:05 |
--Q2 uses MVIEW_TEST_2
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4
511 rows selected.
Execution Plan
Plan hash value: 2126022771
| Id | Operation               | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |              |     511 | 21973 |       3   (0)| 00:00:01 |
|   1 | MAT_VIEW REWRITE ACCESS FULL| MVIEW_TEST_2 |     511 | 21973 |       3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------Database version 11gR1 (Tested also on 11gR2)
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

Thanks for the formatting tips.
Just found an Oracle Bug which explains the above behavior.
Unfortunately the bug will be fixed only in 12.1 Release so as a workaround will try to use traditional joins.
For those who have metalink access see [Bug 10145667 : ERRORS TRYING TO REWRITE QUERY WITH EXACT TEXT MATCH TO MVIEW]

Usage of Query Rewrite in Materialized Views

Hi,
I have a star schema with fact table and and dimensions tables.
One of the dimension tables is time_dimension and I have created
a materialized view(time_sales_mv) on it and the fact table. I
have also created a dimension(time_dim) on the
table 'time_dimension' with hierarchies and attributes.
Following are the syntaxes -
--Dimension table
CREATE TABLE TIME_DIMENSION (
TIME_KEY NUMBER(9) NOT NULL,
DAY_OF_MONTH NUMBER(9),
WEEKDAY NUMBER(9),
WEEKEND NUMBER(9),
JULIAN_DAY NUMBER(9),
JULIAN_WEEK NUMBER(9),
JULIAN_YEAR NUMBER(9),
MONTH_NUMBER NUMBER(9),
MONTH_NAME VARCHAR2(15),
WEEK_OF_THE_YEAR NUMBER(9),
WEEKDAY_NAME VARCHAR2(10),
WEEK_DAY_NUMBER NUMBER(9),
THE_YEAR NUMBER(9),
DAY_OF_THE_YEAR NUMBER(9),
THE_DATE DATE,
THE_QUARTER NUMBER(9),
PRIMARY KEY ( TIME_KEY )) ;
--Fact table
CREATE TABLE SALES_FACT (
TIME_KEY NUMBER(9) NOT NULL,
PRODUCT_KEY NUMBER(9) NOT NULL,
PROMOTION_KEY NUMBER(9) NOT NULL,
CUSTOMER_KEY NUMBER(9) NOT NULL,
DOLLAR_SALES FLOAT,
UNIT_SALES NUMBER(9),
DOLLAR_COST FLOAT)
-- Dimension created
CREATE DIMENSION Time_dim
LEVEL THE_DATE IS TIME_DIMENSION.THE_DATE
LEVEL WEEK_OF_THE_YEAR IS time_dimension.WEEK_OF_THE_YEAR
LEVEL MONTH_NUMBER IS time_dimension.MONTH_NUMBER
LEVEL THE_QUARTER IS time_dimension.THE_QUARTER
LEVEL THE_YEAR IS time_dimension.THE_YEAR
HIERARCHY calendar_rollup (
     THE_DATE CHILD OF
     MONTH_NUMBER CHILD OF
     THE_QUARTER CHILD OF
     THE_YEAR )
HIERARCHY weekly_rollup (
     THE_DATE CHILD OF
WEEK_OF_THE_YEAR )
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_MONTH
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.WEEKDAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.JULIAN_DAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_THE_YEAR
ATTRIBUTE MONTH_NUMBER DETERMINES
time_dimension_sagar.month_name
ATTRIBUTE THE_YEAR DETERMINES
time_dimension_sagar.JULIAN_YEAR;
-- Materialized View
CREATE MATERIALIZED VIEW time_sales_mv
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT t.month_number, SUM
(dollar_sales) AS sum_dollar_sales
FROM sales_fact s,time_dimension t
WHERE t.time_key =
s.time_key GROUP BY
t.month_number
Now if I use the same query as in the MV and see the explain
plan it shows the MV is being used instead of the underlying
tables which is as expected. But if I change 'month_number'
to 'month_name' in the above query, the explain plan does not
use the MV which is not as expected. Since 'month_name' is an
attribute of 'month_number'(defined in the dimension
definition), we can use it and query rewrite feature will join
the MV to the time_dimension table. But in the actual plan, it
uses the fact table 'sales_fact' instead of the MV. Even when I
use the rewrite hint on the query it does not use the MV. I want
know why this is happening??
Query-
SELECT t.month_number, SUM(dollar_sales) AS
sum_dollar_sales FROM
sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_number
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82 Bytes=2132)
TABLE ACCESS (FULL) OF TIME_SALES_MV (Cost=1 Card=82
Bytes=2132)
Query(using month_name instead of month_number)-
SELECT t.month_name, SUM(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)
Query (using rewrite hint in the above query) -
SELECT /*+ rewrite(time_sales_mv)*/
t.month_name, SUM
(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)

Hi,
I have a star schema with fact table and and dimensions tables.
One of the dimension tables is time_dimension and I have created
a materialized view(time_sales_mv) on it and the fact table. I
have also created a dimension(time_dim) on the
table 'time_dimension' with hierarchies and attributes.
Following are the syntaxes -
--Dimension table
CREATE TABLE TIME_DIMENSION (
TIME_KEY NUMBER(9) NOT NULL,
DAY_OF_MONTH NUMBER(9),
WEEKDAY NUMBER(9),
WEEKEND NUMBER(9),
JULIAN_DAY NUMBER(9),
JULIAN_WEEK NUMBER(9),
JULIAN_YEAR NUMBER(9),
MONTH_NUMBER NUMBER(9),
MONTH_NAME VARCHAR2(15),
WEEK_OF_THE_YEAR NUMBER(9),
WEEKDAY_NAME VARCHAR2(10),
WEEK_DAY_NUMBER NUMBER(9),
THE_YEAR NUMBER(9),
DAY_OF_THE_YEAR NUMBER(9),
THE_DATE DATE,
THE_QUARTER NUMBER(9),
PRIMARY KEY ( TIME_KEY )) ;
--Fact table
CREATE TABLE SALES_FACT (
TIME_KEY NUMBER(9) NOT NULL,
PRODUCT_KEY NUMBER(9) NOT NULL,
PROMOTION_KEY NUMBER(9) NOT NULL,
CUSTOMER_KEY NUMBER(9) NOT NULL,
DOLLAR_SALES FLOAT,
UNIT_SALES NUMBER(9),
DOLLAR_COST FLOAT)
-- Dimension created
CREATE DIMENSION Time_dim
LEVEL THE_DATE IS TIME_DIMENSION.THE_DATE
LEVEL WEEK_OF_THE_YEAR IS time_dimension.WEEK_OF_THE_YEAR
LEVEL MONTH_NUMBER IS time_dimension.MONTH_NUMBER
LEVEL THE_QUARTER IS time_dimension.THE_QUARTER
LEVEL THE_YEAR IS time_dimension.THE_YEAR
HIERARCHY calendar_rollup (
     THE_DATE CHILD OF
     MONTH_NUMBER CHILD OF
     THE_QUARTER CHILD OF
     THE_YEAR )
HIERARCHY weekly_rollup (
     THE_DATE CHILD OF
WEEK_OF_THE_YEAR )
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_MONTH
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.WEEKDAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.JULIAN_DAY
ATTRIBUTE THE_DATE DETERMINES
time_dimension_sagar.DAY_OF_THE_YEAR
ATTRIBUTE MONTH_NUMBER DETERMINES
time_dimension_sagar.month_name
ATTRIBUTE THE_YEAR DETERMINES
time_dimension_sagar.JULIAN_YEAR;
-- Materialized View
CREATE MATERIALIZED VIEW time_sales_mv
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT t.month_number, SUM
(dollar_sales) AS sum_dollar_sales
FROM sales_fact s,time_dimension t
WHERE t.time_key =
s.time_key GROUP BY
t.month_number
Now if I use the same query as in the MV and see the explain
plan it shows the MV is being used instead of the underlying
tables which is as expected. But if I change 'month_number'
to 'month_name' in the above query, the explain plan does not
use the MV which is not as expected. Since 'month_name' is an
attribute of 'month_number'(defined in the dimension
definition), we can use it and query rewrite feature will join
the MV to the time_dimension table. But in the actual plan, it
uses the fact table 'sales_fact' instead of the MV. Even when I
use the rewrite hint on the query it does not use the MV. I want
know why this is happening??
Query-
SELECT t.month_number, SUM(dollar_sales) AS
sum_dollar_sales FROM
sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_number
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82 Bytes=2132)
TABLE ACCESS (FULL) OF TIME_SALES_MV (Cost=1 Card=82
Bytes=2132)
Query(using month_name instead of month_number)-
SELECT t.month_name, SUM(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)
Query (using rewrite hint in the above query) -
SELECT /*+ rewrite(time_sales_mv)*/
t.month_name, SUM
(dollar_sales)
FROM sales_fact s, time_dimension t
WHERE t.time_key = s.time_key
GROUP BY t.month_name
Explain Plan -
SELECT STATEMENT Optimizer=CHOOSE (Cost=151 Card=9053
Bytes=307802)
SORT (GROUP BY) (Cost=151 Card=9053 Bytes=307802)
HASH JOIN (Cost=16 Card=9053 Bytes=307802)
TABLE ACCESS (FULL) OF TIME_DIMENSION_SAGAR (Cost=1
Card=82 Bytes=1804)
TABLE ACCESS (FULL) OF SALES_FACT (Cost=10 Card=11040
Bytes=132480)

Star schema - History

Say I have a star-lite schema with just 2 dimension tables and 1 fact table. The classic many-to-many relationship with a resolver/intersection table.
For discussion purposes, let's take the standard student/test/score tables. Student and Test are the dimensions and Score is the fact. In addition to capturing the test score, the requirement is to capture a snapshot of student and test (dimension) attributes when the Score is recorded.
This would mean duplicating the Student and Test attributes in the Score fact table, right? Are there any other ways to model this requirement?
Thanks

VANJ wrote:
. In addition to capturing the test score, the requirement is to capture a snapshot of student and test (dimension) attributes when the Score is recorded.Seems like a faintly odd requirement but anyway.
This would mean duplicating the Student and Test attributes in the Score fact table, right? Denormalisation is a fairly common feature of data warehouses. We trade more space for speedier queries.
Are there any other ways to model this requirement? Are there any other ways to denormalise attributes without duplicating them? No. But there is more than one way of implementing the desired outcome. For instance, instead of storing additional attributes with the SCORE you could build a Materialized View which joins STUDENT, TEST and SCORE together. Then allow Query Rewrite to use the MView to satisfy pertinent queries rather than the underlying tables.
This clarification of the requirement was added after I posted:
The requirement is to record the current Student & Test attributes as of the time the Score is recorded.If the requirement is to maintain a history - and I suppose the clue really is in the question - then there is no alternative but to duplicate the STUDENT and TEST attributes in the SCORE table. In an OLTP environment I would suggest using a separate sub-system of journalling tables to track changes but that wouldn't make a lot of sense in a SWH context.
Cheers, APC
Edited by: APC on Apr 26, 2013 2:04 PM

Star Schema and MV's

Hi Guys,
I have designed a Star schema for one of my datamart and my client is after me suggesting that over that I should create a MV to provide a consolidated view. I am trying to convience my client not to do so with the points as below:
1.     As we have created a Star Schema in the database we should take advantages of the same and should avoid creating another layer of reporting which in future will increase the complexity of the queries while expanding the functionality of the mart.
2.     We have to create a complete refresh MV and during refresh data will not be available for reporting to users and the duration will increase over the period of time once the data increases
3.     As MV are a table on a disk using a MV in this case will consume the tablespace which will increase over the period of time.
Please can you experts suggest of any more points or additions. We are using SAP BO as a reporting tool in our organization wherein a Universe can be created easily for reporting.
Cheers,
Shaz

I have designed a Star schema for one of my datamart and my client is after me suggesting that over that I should create a MV to provide a consolidated view. I am trying to convience my client not to do so with the points as below:You are convincing them to NOT do one of the the things materialized views were originally introduced to provide?
I'm purposely going all the way back to 8i documentation here to emphasize the point.
http://docs.oracle.com/cd/A87860_01/doc/server.817/a76994/qr.htm#35520
" Overview of Query RewriteOne of the major benefits of creating and maintaining materialized views is the ability to take advantage of query rewrite, which transforms a SQL statement expressed in terms of tables or views into a statement accessing one or more materialized views that are defined on the detail tables. The transformation is transparent to the end user or application, requiring no intervention and no reference to the materialized view in the SQL statement. Because query rewrite is transparent, materialized views can be added or dropped just like indexes without invalidating the SQL in the application code. "
>
The theory behind query rewrite is this: have them build their queries based on your star schema (or you a build a traditional view that does that), then build a materialized view that mirrors the query/view. If the materialized view is refreshing or not up-to-date, their queries will run (more slowly) against the star schema. If it is up-to-date it will be used instead, providing faster results.
But before you go to that trouble: they are asking for a consolidated view (presumably something easier to query - common in data warehousing). You can create a view to provide this. If that view is not fast enough for their performance requirements, materialize it. Yes, the materialized view uses space, but that space is the price you pay for meeting the performance requirement.

Using two facts of two different star schemas and conformed dimensions

Hi,
I've been working as developer and database designer for years and I'm new to Business Objects. Some people says you can not use two facts of two different star schemas in the same query because of conformed dimensions and loop problems in BO.
For example I have a CUSTOMER_SALE_fACT table containing customer_id and date_id as FK, and some other business metrics about sales. And there is another fact table CUSTOMER_CAMPAIGN_FACT which also contains customer_id and date_id as FK, and some other business metrics about customer campaigns. SO I have two stars like below:
DIM_TIME -- SALE_FACT -- DIM_CUSTOMER
DIM_TIME -- CAMPAIGN_FACT -- DIM_CUSTOMER
Business metrics are loaded into fact tables and facts can be used together along conformed dimensions . This is one of the fundamentals of the dimensional modeling. Is it really impossible to use SALE_FACT and CAMPAIGN_FACT together? If the answer is No, what is the solution?
Saying "you cannot do that because of loops" is very interesting.
Thank you..

When you join two facts together with a common dimension you have created what is called a "chasm trap" which leads to invalid results because of the way SQL is processed. The query rows are first retrieved and then aggregated. Since sales fact and campaign fact have no direct relationship, the rows coming from either side can end up as a product join.
Suppose a customer has 3 sales fact rows and 2 campaign fact rows. The result set will have six rows before any aggregation is performed. That would mean that sales measures are doubled and campaign measures are tripled.
You can report on them together, using multiple SQL passes, but you can't query them together. Does that distinction make sense?

Star schema in OBIEE 11G

Hi Experts,
Please tell me the places in OBIEE 11G where i can design the start schema.is it only in Physical Layer or In BBM too?
Thanks-Bhaskar

Final point, for performance reasons you should also try to model data into star schema in the physical layer.
If the data is modelled as a true star then there are database features which optimise query performance. These features are set by a DBA when the Warehouse is configured (e.g. enable_star_transformations). The results with this parameter on/off can be staggering (query time reduced from minutes to seconds), showing the power of star schema.
When snowflakes occur, these performance features will not work as designed, and performance will be degraded. There are certain criteria that have to be met by the data e.g. bitmap indices on all of the foreign key columns in the fact.
Please mark if helpful / correct,
Andy
www.project.eu.com

Materialized Views with Query Rewrite is not getting re-written

I have tried everything that has been mentioned in all the forums here and on metalink to fix this issue, has any smart APEX user found a solution?
The issue is the MV with Query rewrite capability is not being re-written.
Things I have tried
1) give all Query Rewrite privileges to all 3 APEx schemas and parsing schema;
2) check trace files with tkprof;
3) dynamically printed explain plan from v$_SQL on the page while executing the query;
4) to test in a different environment i created an another DAD using the pl/sql webtool kit and tried the same thing and rewrite works like a charm...
whats the issue here...why are apex schemas not re-writing the queries????
appreciate any help...thanks

Jes, per your request
--create materialized view
CREATE MATERIALIZED VIEW "RPLANSWEB"."MV_FCG_ALL_SUMMARY_TAB"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "RPLANSWEB"
BUILD IMMEDIATE
USING INDEX
REFRESH FORCE ON DEMAND
USING DEFAULT LOCAL ROLLBACK SEGMENT
ENABLE QUERY REWRITE
AS SELECT fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable allow_drillable,
MAX(category_code_um1) category_code_um1,
SUM(perm_asset) perm_asset,
SUM(temp_asset) temp_asset,
SUM(semi_asset) semi_asset,
SUM(lease_asset) lease_asset,
SUM(planned_constr) planned_constr,
SUM(all_perm_asset) all_perm_asset,
SUM(total_asset) total_asset,
SUM(allow) allow, SUM(rqmt) rqmt,
SUM(perm_planned_constr) perm_planned_constr,
SUM(perm_planned_constr_rqmt_delta) perm_planned_constr_rqmt_delta,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(all_perm_asset)/SUM(rqmt)*100)) perm_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(all_perm_asset)/SUM(allow)*100)) perm_allw_pctsat,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(total_asset)/SUM(rqmt)*100)) total_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(total_asset)/SUM(allow)*100)) total_allw_pctsat,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(rqmt)/SUM(all_perm_asset)*100)) perm_rqmt_pctutl,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(allow)/SUM(all_perm_asset)*100)) perm_allw_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(rqmt)/SUM(total_asset)*100)) total_rqmt_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(allow)/SUM(total_asset)*100)) total_allw_pctutl,
SUM(coarse_screen_asset) coarse_screen_asset,
SUM(total_excess) total_excess,
SUM(total_deficit) total_deficit,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
GROUP BY fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable;
sql plus> log in as parsing schema user (not APEX_PUBLIC_USER)
sql plus> SELECT fcg, year, fcg_desc,
SUM(perm_asset) perm_asset,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
where year=2007
GROUP BY fcg, year, fcg_desc;
--execution plan
SELECT STATEMENT     ALL_ROWS     12     291     17460
HASH(GROUP BY)          12     291     17460
MAT_VIEW REWRITE ACCESS(FULL) RPLANSWEB.MV_FCG_ALL_SUMMARY_TAB     ANALYZED     11     291     17460                         "MV_FCG_ALL_SUMMARY_TAB"."YEAR"=2007
--execution plan from sql workshop (application express)
SELECT STATEMENT 42,341 55 3,882 1,990,027
HASH GROUP BY 42,341 55 3,882 1,990,027
TABLE ACCESS FULL SUMMARY_TAB_DD 109,158 47 3,329 5,130,426 "YEAR" = 2007
--execution plan from an APEX page (displayed from v$sql and V$SQL_PLAN)
OPERATION: SELECT STATEMENT OPTIONS: OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: ALL_ROWS SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: BYTES: CPU_COST: IO_COST: ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION:
OPERATION: HASH OPTIONS: GROUP BY OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: 109158 BYTES: 8732640 CPU_COST: 549150132 IO_COST: 4569 ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION: "FCG"[VARCHAR2,6], "FCG_DESC"[VARCHAR2,15], SUM("PERM_DEFICIT")[22], SUM("PERM_EXCESS")[22], SUM("SATISFY_RQMT")[22], SUM("TEMP_EXCESS")[22], SUM("ALL_PERM_EXCESS")[22], SUM("ALL_PERM_DEFICIT")[22], SUM("PERM_ASSET")[22]
OPERATION: TABLE ACCESS OPTIONS: FULL OBJECT_NAME: SUMMARY_TAB_DD OBJECT_ALIAS: SUMMARY_TAB_DD@SEL$1 OBJECT_TYPE: TABLE OPTIMIZER: SEARCH_COLUMNS: 0 COST: 3329
as you can see while executing the script in sql developer the optimizer is finding the relevant materialized view, not in the case of APEX's SQL Workshop or Page.
appreciate your time

11g OLAP cube MV's with Query Rewrite option

Hi All,
I am trying to test the 11g OLAP cube MV's with the Query Rewrite option.
I had created a cube on the schema OLAPTRAIN problem by oracle. I an selected necessary options in 'Materialized Views' tab of the Cube definition in AWM. here is the screenshot
!http://i40.tinypic.com/9jzpte.png!
and then I try to run the SQL query
select SUM(S.QUANTITY) AS QUAN,
SUM(S.SALES) AS SALES,
T.CALENDAR_YEAR_NAME,
P.DEPARTMENT_NAME,
C.COUNTRY_NAME
FROM
TIMES T,CUSTOMERS C,PRODUCTS P, SALES_FACT S
WHERE
C.CUSTOMER_KEY = S.CUSTOMER AND
T.DAY_KEY = S.DAY_KEY AND
P.ITEM_KEY = S.PRODUCT
group by T.CALENDAR_YEAR_NAME, P.DEPARTMENT_NAME, C.COUNTRY_NAME;
and observed the Explain plan, it is not using OLAP cube built, instead it is using the relational tables given in the above sql query.
Also, i have observed that , though enabling or disabling of the Query Rewrite option doesn't make any change in the Explain query for the above query.
alter materialized view olaptrain.cb$sales_cube enable query rewrite;
alter materialized view OLAPTRAIN.cb$sales_cube disable query rewrite;
No idea why is this Query Rewrite feature is not working on my Database instance of 11g R2 . Do am I missing any steps that has be taken care of , to make this working. Any inputs would be appreciated.
Thanks
S

Hi there,
You should check out Note 577293.1 on Metalink - 'Oracle OLAP 11g: How to ensure use of Cube Materialized Views/Query Rewrite'
Thanks,
Stuart Bunby
OLAP Blog: http://oracleOLAP.blogspot.com
OLAP Wiki: http://wiki.oracle.com/page/Oracle+OLAP+Option
OLAP on OTN: http://www.oracle.com/technology/products/bi/olap/index.html
DW on OTN : http://www.oracle.com/technology/products/bi/db/11g/index.html

Star schema question

Hi,
I have a question about the realization of the star schema. I have familiarized me with the basic concepts of dimensions and fact tables. But what I don’t get is how I “combine” the dimensions with the fact table. I know that the fact table includes the dimension-IDs and measures. But do I use the joiner-operator in the OWB to join the dimension-ID (IDs of the dims are the criteria for the joiner condition) to create the fact table?
So my understanding is when I have for example 3 dimensions (product dimension, sales dimension, time dimension) and one fact table.
The realization looks like this:
product dim ->
sales dim -> joiner operator = fact table with the IDs of the dims and measure
time dim ->
Please correct me if I am wrong.
If there is something that I can read to this subject of matter it would be very nice if someone could post it.
Thx

Hi,
first you load the dimensions. Every entry has an id (surrogate key) and some business key (coming from the data source).
When you load the fact, you use the business key from the data source to join (using a joiner or lookup operator) the dimension and get the id (surrogate key) from it. You only load the id and the measures into the fact table.
Make sure to handle the case that the business key is null or no entry in the dimension can be found.
If you query the fact table you must always join the dimensions.
Regards,
Carsten.

Star schema versus snowflake schema

I have a question regarding dimensional data modeling. My question here is, when star schema model would be useful and when snowflake schema model would be useful.
In star schema, we have only fact and it is connected with dimensions. But in snowflake schema, we are normalizing dimension into one more level. Let us say, we have dimension product. Product can be normalized into another table called supplier. Let us take another example, customer dimension. Customer dimension can be normalized into country…
Advantage of star schema is, easy to write the query since we have only less tables. You do not need to join multiple tables when we write the query. It would improve the performance some time.
Advantage of snowflake schema is, it is little complex to write the query, since we have to join multiple tables. Performance might improve some time when we join smaller tables…
My question is, at what circumstances, we can use star and snowflake schema? I am not able to define the word sometime_
Any help is highly appreciated…

Hi,
There is a trade off on the availability and the Complex analytics.
A star schema is good if you have the functional requirements really simple. Like the dimension is not SCD Type2 (slowly changing dimension) and you don't need to do "AS IS" vs "AS WAS" reporting.
In modern Analytics in any domain dimensions are SCD Type 2 as business keep on evolving. In a star schema structure this will cause explosion of data if there are frequent changes at the higher levels of the dimensional hierarchy. That anyway will hit the performance.
As far as my experience goes, at the data model level it is better to have snow flaked dimensions. and while managing the metadata (in a BI reporting tool) you can consolidate the snowflaked dimensions in star schema structures. That will make ah hoc analytics much simple for the business users.
A lot of performance measure can be taken to improve the end user experience.
In short the trend in BI analytics demands to have a snowflaked structure rather than a simple star schema structure.
Hope this helps.

Converting 3 tables to a star schema ??

Hi i was trying to prepare a very small demo for an OLAP system. Anyways I have a simple transaction database for a supposed Book Store anyways the database has the following 3 tables :
Table No:1
Table Name:Main Table
This Table contains the following columns:
Customer Name (PK) | Book Purchase ID (PK) | PRICE
Table No:2
Table Name:Customer Table
This Table contains the following columns:
Customer Name | CELL | ADDRESS
Table No:3
Table Name:BOOKS Table
This Table contains the following columns:
BOOK Name | Book Purchase ID | GENRE
so the above is my transactional database.. LEt me know if i am missing any other detail. Anyways now i want to convert the above to start schema ?? How would i acccomplish that .. I tried to read a couple of tutorials but i was a bit confused... so if you guys could assist me on this i would be really thnakfull.

David_Aldridge wrote:
thinking in general about this, it sounds like what you need is a set of four tables:
Dim_Cust -- stores customer details as a dimension
Dim_Book -- stores book details as a dimension
Dim_Date -- stores dates for transactions
Fct_Book_Sales -- stores the transactions themselves as the purchase of a book for a certain price by a customer on a date.
Use synthetic keys for all but the Dim_Date.Okay i kind of got lost on the way here is wht i know so far regarding the star schema
"A star schema consists of fact tables and dimension tables. Fact tables contain the quantitative or factual data about a business--the information being queried. This information is often numerical, additive measurements and can consist of many columns and millions or billions of rows. Dimension tables are usually smaller and hold descriptive data that reflects the dimensions, or attributes, of a business. SQL queries then use joins between fact and dimension tables and constraints on the data to return selected information."
so from your explaination there are going to be 3 dimension tables
Dim_Cust (Details about the customers) (Customer_ID,Cell No,Address)
Dim_Book(Details about the Books) (Book Name ,ID,Genre)
Dates (I am confused about the dates part)
Fct_Book_Sales (Confused about this part also)
and one last thing What would the fact table look like ??

Creation of star schema from snowflake schem in BMM layer

hi,
This is my situation.I have "Fact-table" which has Dim 1 .now Dim 1 is joined to Dim2,Dim3
Fact
|
Dim 1
|
| |
Dim 2 Dim 3
Now in Bmm Layer how can i make this snowfalke schema to star schema.I heard about making changes in the Logical Table source.And what will be the look of the presentation layer.
Any help is appricaited Guys.

In physical layer, you have a join between Dim 1 and Dim 2, Dim1 and DIm3, Fact and Dim1. In BMM for Dim1, in the sources, add Dim2 and Dim3. You may add both these dimensions in one single LTS if the data is not duplicate in the tables. In case the data is duplicated add them as seperate LTS in the sources for Dim1. Refer this post for reference -- Logical Table source source query
In BMM you need a join between Dim1 and Fact. Basically your Dim1 is sourced from three different tables which are your dimensions. This would transform your snowflake into star. In your presentation layer you will have all the columns from your dimensions (except for the duplicates, lets say you have column A in both dim1 and dim2, you should map this column in column mapping tab so as to enable BI server to pick the most economical source) and facts.
Hope this clears your question.

Normalized (3NF) VS Denormalized(Star Schema) Data warehouse :

what are the benefits of normalized data warehouse (3NF) over the denormalized (Star schema)?
if DW is in the 3NF then is need to create the seprate physical database which contains several data marts( star schema)with physical tables, which feeds to cube or create the views(SSAS data source view) on top of 3NF warehouse of star schema which feeds to
cube?
please explin the pros and cons of 3NF and denormalized DW.
thanks in advance.
Zaim Raza.

Hi Zaim,
Take a look to this diagram:
1) Normally, 3NF schema is typical for ODS layer, which is simply used to fetch data from sources, generalize, prepare, cleanse data for upcoming load to data warehouse.
2) When it comes to DW layer (Data Warehouse), data modelers general challenge is to build historical data silo.
Star schema with slow changing facts and slow changing dimensions are partially suitable.
The DataVault and other similar specialized methods provides, in my opinion, wider possibility and flexibility.
3) Star schema is perfectly suitable for datamarts. SQL Server 2008 and higher contains numerous query analyzer improvements to handle such workload efficiently. SQL Server 2012 introduced column stored indexes, that makes possibility to
create robust star model datamarts with SQL Query performance comparable to MS OLAP.
So, your choice is:
1) Create solid, consistent DW solution
2) Create separate datamarts on top of DW for specific business needs.
3) Create necessary indexes, PK, FK key and statistics (of FK in fact tables) to help sql optimizer as much as possible.
4) Forget about approach of defining SSAS datasource view on top of 3NF (or any other DWH modeling method), since this is the way to performance and maintenance issues in the future.

No query rewriting in a star schema

Similar Messages

Maybe you are looking for