Cross Join or Cartesian Product

Hi Expert,
I'm not sure if I'm posting in the right place, because this problem involve between BW/BEx, Universe and BO; but I think there's a possibility 'a wrong' in the universe.
Right now I want to create a report in Webi from BEx Query via Universe.
When I put 2 query item in Webi, let's say, PERNR and TRFST. The result looks like this (example) :
PERNR         TRFST
12345            S1
12345            S2
54321            S1
54321            S2
Ok, that's the appetizer. Here's the main course.
For some reason, I'm using function module in ABAB to create a data source table as transaction data in BW. I create a Fact Table that contain all field that I need to create dimension tables. This, in my opinion, for eliminate the possibility that the cross join appear because there's something wrong in the relationship between the dimension and the fact when creating the cube. This is a little example of my Cube result :
PERNR        TRFST        KEY FIGURE
12345            S1            XXX
54321            S2            ZZZ
As I explain above, I create Person dimension and TRFST (in my case I called 'Eselon') dimension and 1 Key Figure. So, from here, I assumed that there's no problem with the BW because the cube resulted the content as I'm expected.
Then I moved to BEx designer. I create a query from that cube, creating a pivot table that contain Person, Eselon, and the key figure. When I open the query in the BEx Analysis, the excel create a pivot table like this :
                       KEY FIGURE
12345    S1       XXX
Result               XXX
54321    S2      ZZZ
Result               ZZZ
From here, again I assumed, there's no problem in BEx, since there's no cross join between the dimension. Then I create the universe, then I tried to create the Webi report, and DANG!! a cross join appear.
Did you guys have any idea or solution about this? This is for the first time I created a universe using BEx, so maybe I miss something.
I will appreciate every helpful comment from you
Thank You
Rully

Well.. ummm.. actually I don't using 2 query nor 2 data provider for my report. It came from 1 query. But that's ok. It's just misunderstanding between us. Maybe because I'm using the '2 query item' word. I'm sorry.
Just for your information, finally I can solve it. Like I said in the first post, I'm just trying to use 2 characteristic (I think this is better word rather than query item), but I don't pull the key figures to the report. When I put at least 1 key figure to the report, pam pam pa ra pam... the cross join gone. I don't know why, but it happen.
Than, I examine this case by creating a simple report using eFashion universe. When I put 2 characteristic without key figure, there's no cross join. I don't know why, but it happen.
well, thank you for your comment, even mostly there are misunderstanding, but I really appreciate it. Thank you.
Rully

Similar Messages

What is the use of Cartesian Product or Cross join?

Dear friends...
I have done with inner join, self join and outer join. But I m getting confused with cross join. I know it used to produce Cartesian product of two table. But I wanted to know what is the use of Cartesian product in real life? In
which situation we can use Cartesian product or cross join? I wanted some real life examples on Cartesian product. Please help me.

Sometimes you get requirement stating that all combinations should be considered and in this scenario CROSS JOIN comes in play.
If you have Products and Stores table, by using CROSS JOIN you can get the combination of all stores and all products and then you can JOIN this result set to other tables.
Please refer: The power of the Cross Join
Cheers,
Vaibhav Chaudhari
[MCTS],
[MCP]

Joining DB VIEW and Command result in cartesian product

hello,
My SQL query is joining a DB view and a Command(=ad hoc query).
Nonetheless from the results it appears that CR didn't join the views correctly, it returns a cartesian product.
Any idea what the issue could be, I'm using very simple queries.
Thanks in advance

#1 make sure you are linking everything together properly in the "Links" tab of the Database Expert
#2 In my experience, it's just a bad idea to join SQL commands and other tables. I had poor performance issues in my case. (It prevents server side filtering and grouping) My suggestion is to write out the entire thing in the command. If you are pulling from multiple database, write a separate command for each database and link them.

Cartesian Product, JOIN

Good Morning Everyone,
We have limited knowledge in DB but we have to work according to needed.
Whenever we working on DB, we have challenges in Cartesian Product, JOIN, and more.
We created reports and looks good. We have to test for our data is accuracy and correct.
If you have experience using Toad, Query Builder, Report Builder, please share your experiences.
Thanks in advance,
NY

New Yorker wrote:
Good Morning Everyone,
We have limited knowledge in DB but we have to work according to needed.
Whenever we working on DB, we have challenges in Cartesian Product, JOIN, and more.
We created reports and looks good. We have to test for our data is accuracy and correct.
If you have experience using Toad, Query Builder, Report Builder, please share your experiences.
I believe you should read the following and gather as much as knowledge possible for all above mentioned operators.
http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm
HTH
Aman....

Joins between two tables generating Cartesian product

Hi All,
I am facing an issue in my report in which, I am getting mismatch as the two subsets which I'm joining is resulting in a cartesian product of individual subset's results. I am doing left join to join those two subsets. Please help in resolving
this issue.
Thank you,
Anu.

Hi,
Can you please post your script to see what is causing the cartesian product?
This way it is difficult to help you.
Regards,
Reshma
Please Vote as Helpful if an answer is helpful and/or Please mark Proposed as Answer or Mark As Answer when question is answered

CARTESIAN/CROSS JOIN

HI,
i use OBIEE version 11.1.1.6.0. I created dummy fact table and column in physical layer. and join all dimensional table with this fact. but i dont know ow handle with it in business model. can anyone help me to create cross join?
Thanks
Edited by: 968086 on Oct 30, 2012 12:59 AM

Follow this link
http://www.rittmanmead.com/2009/08/oracle-bi-ee-10-1-3-4-1-reporting-on-non-transactional-dimension-values-equivalence-of-outer-joins/
Pls mark if helps

Cross Join in ABAP Open SQL

Hi guys!
I need to implement a CROSS JOIN (cartesian product) based on two tables. To my understanding there is no construct to implement a cross join in OPEN SQL. So the question is first is this correct? And secondly in which way would you then implement a cross join of two tables with the constructs at hand in ABAP?
I have come up with the following solution of cross joining two tables, but would like to know if there is a better (not so ugly way).
Example:
SELECT * FROM tab1 AS t1 JOIN tab2 AS t2 ON t1mandt = t2mandt INTO CORRESPONDING FIELDS OF itab.
Note that this only works if the tables tab1 and tab2 is client dependent.
Regards,
Christian

Christian,
There's no cross join construct in abap. Join statement results in a cartesin product rarely because of completely obsolete statistics missing selection or join conditions.
Try the following join to get result similar to cartesian product
select tab1location tab2matnr into itab
from tab1 join tab2 on tab1location ne tab2matnr.
if you really want to implement cross join, use native sql, try the following code,
beware of cartesian products, Basis folks doesn't like em....
data: begin of itab occurs 0,
loc like tab1-sloc
matnr like tab2-matnr,
end of itab.
exec sql performing append_itab.
select a.loc, b.matnr
    into :itab
    from tab1 a
    cross join tab2 b
endexec.
form append_itab.
append itab.
endform.
Regards
Sridhar.

CONNECT BY with CROSS JOIN and WHERE not executing as described in doc

Hello all,
please see these two statements. They are the same, but the 1st uses t1 INNER JOIN t2 while the snd uses a CROSS JOIN with WHERE.
The 2nd statement shows one row more than the first, but the CROSS JOIN with WHERE is the same as the INNER JOIN.
The result would be OK if Oracle did:
JOIN -> CONNECT BY PRIOR -> WHERE
But according to the docs it does:
JOIN (and WHEREs for JOINS) -> CONNECT BY PRIOR -> Rest of WHERE
See http://docs.oracle.com/cd/E11882_01/server.112/e26088/queries003.htm#SQLRF52332 for details. There it says:
Oracle processes hierarchical queries as follows:
A join, if present, is evaluated first, whether the join is specified in the FROM clause or with WHERE clause predicates.
The CONNECT BY condition is evaluated.
Any remaining WHERE clause predicates are evaluated.
+.....+
Is this a bug? I'd say yes, because it differs from the docs and it also is not what people are used to ("a,b WHERE" is the same as "a INNER JOIN b").
Thanks,
Blama
--Statement 1:
WITH t1
AS
(SELECT 1 a, 2 b FROM DUAL UNION ALL
SELECT 2 a, 3 b FROM DUAL UNION ALL
SELECT 3 a, 4 b FROM DUAL UNION ALL
SELECT 4 a, 5 b FROM DUAL UNION ALL
SELECT 5 a, 6 b FROM DUAL),
t2 AS
(SELECT 1 c FROM DUAL UNION ALL
SELECT 2 c FROM DUAL UNION ALL
SELECT 3 c FROM DUAL UNION ALL
SELECT 5 c FROM DUAL)
SELECT DISTINCT t1.a, t2.c, t1.b, level, SYS_CONNECT_BY_PATH(t1.a, '/') Path
FROM t1 INNER JOIN t2
ON t1.a = t2.c
CONNECT BY t1.a = PRIOR t1.b
START WITH t1.a = 1
ORDER BY
1,2,3;
--Result:
--1     1     2     1     /1
--2     2     3     2     /1/2
--3     3     4     3     /1/2/3
--Statement 2:
WITH t1
AS
(SELECT 1 a, 2 b FROM DUAL UNION ALL
SELECT 2 a, 3 b FROM DUAL UNION ALL
SELECT 3 a, 4 b FROM DUAL UNION ALL
SELECT 4 a, 5 b FROM DUAL UNION ALL
SELECT 5 a, 6 b FROM DUAL),
t2 AS
(SELECT 1 c FROM DUAL UNION ALL
SELECT 2 c FROM DUAL UNION ALL
SELECT 3 c FROM DUAL UNION ALL
SELECT 5 c FROM DUAL)
SELECT DISTINCT t1.a, t2.c, t1.b, level, SYS_CONNECT_BY_PATH(t1.a, '/') Path
FROM t1 CROSS JOIN t2
WHERE t1.a = t2.c
CONNECT BY t1.a = PRIOR t1.b
START WITH t1.a = 1
ORDER BY
1,2,3;
--Result:
--1     1     2     1     /1
--2     2     3     2     /1/2
--3     3     4     3     /1/2/3
--5     5     6     5     /1/2/3/4/5My details:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE     11.2.0.2.0     Production
TNS for Solaris: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

blama wrote:
Hello Paul,
that means that "a,b" isn't the same as "a CROSS JOIN b".
I don't think that that is really the case.
Do you have docs on this one?No explicit docs just (my) logic - having said that, I suppose it is implied that if you are doing ANSI style joins, it's not the where clauses that
are specifying the join.
If you do t1,t2 where t1.a=t2.a then Oracle figures out the kind of join from the (relevant) where clauses and treats the other where clauses after the CONNECT BY.
If you do t1 cross join t2 where t1.a=t2.a then you are saying the join is completely specified by the CROSS JOIN - i.e it's Cartesian. Oracle doesn't look at the where clauses for this. Therefore
all where clauses are treated as 'other' and are evaluated after the CONNECT BY.
So, in my mind it's 10g that has the bug.

Inline query vs cross join

Hi all,
Two tables who have no relation with each other. For example an employees table and a systemparameter table with a startworktime.
We need a query with data from both tables:
Get all employees and the startworktime (which is the same for everybody)
Which is cheaper: an inline query or a cartesian product or crossjoin?
Inine :
select name, function
, (select startworktime from systemparameter)
from employees;
Cartesian product:
select name, function, startwoime
rktfrom employees
cross join systemparameter;
Your thoughts on this.

Hi,
To see which runs faster on your system, with your sub-query, there's no sibstitute for testing on your system, with your sub-query.
I predict you won't notice any difference. Scalar sub-queries (as in your first example) are cached (at least in recent versions of Oracle), so you can include a scalar sub-query in a result set of a million rows, and the sub-query can be executed once, not a million times.

MERGE INTO and CROSS JOIN

Hello Guys,
I have a bit of trouble understanding the MERGE I have written here.
All the code executes without errors. As far as I see,
the below MERGE SELECT is a Cartesian product/cross join and I remember that is not
good. The ON (join condition) seems to be only for the merge into table (T_CLAIMS_BB) and
the table that comes from the select (d).
merge into T_CLAIMS_BB t
using
SELECT sch_vt.SCH#,vert.CNO,vers.SubCNo,regv.ReturnNo,regv.SndReturnNo,sch_vt.MainProd,sch_vt.Prod
FROM mainschema.TCONTRACT vert, mainschema.TVERSCONTRACT vers, commonschema.VC_REGVEREINB regv, myschema.T_CLAIMS_VT sch_vt
) d
ON (
t.sch# = d.sch# AND
SUBSTR(UPPER(t.BOOKINGTEXT),1,2) = d.SndReturnNo AND d.SubCNo IS NULL
) -- Join
when matched then
update
set t.CNO = 'a',
t.ReturnNo = 'a',
t.MainProd = 'b',
t.Prod = 'c';
I wonder now, what is the advantage of using MERGE in my case - if there is one.
Finally I want to demonstrate how the whole thing would look without a MERGE:
SELECT vers.* FROM TVERSCONTRACT vers
LEFT OUTER JOIN myschema.T_CLAIMS_BB sch ON sch.SubCNo = vers.SubCNo
LEFT OUTER JOIN commonschema.VC_REGVEREINB regv ON sch.SCH# = regv.SCH# AND SUBSTR(UPPER(sch.BUCHTEXT),1,2) = regv.SndReturnNo AND sch.SubCNo IS NULL
LEFT OUTER JOIN myschema.T_CLAIMS_VT sch_vt ON sch.SCH# = sch_vt.SCH#

Hi,
metalray wrote:
Hello Guys,
I have a bit of trouble understanding the MERGE I have written here.
All the code executes without errors. As far as I see,
the below MERGE SELECT is a Cartesian product/cross join and I remember that is not
good.Cross joins are good for some purposes. In practice, they're useful in only 1 or 2 queries out of every 1000.
Using the old join notation, it was very easy to get a cross join by mistake. Given how rarely cross joins are needed, the vast majority of cross joins (using old notation) were not good, but that was the fault of the programmers and the notation, not an indication that cross join itself was bad.
The ON (join condition) seems to be only for the merge into table (T_CLAIMS_BB) and
the table that comes from the select (d).Exactly!
You can have separate ON conditions inside the USING sub-query, if you need them.
>
merge into T_CLAIMS_BB t
using
SELECT sch_vt.SCH#,vert.CNO,vers.SubCNo,regv.ReturnNo,regv.SndReturnNo,sch_vt.MainProd,sch_vt.Prod
FROM mainschema.TCONTRACT vert, mainschema.TVERSCONTRACT vers, commonschema.VC_REGVEREINB regv, myschema.T_CLAIMS_VT sch_vt
) d
ON (
t.sch# = d.sch# AND
SUBSTR(UPPER(t.BOOKINGTEXT),1,2) = d.SndReturnNo AND d.SubCNo IS NULL
) -- Join
when matched then
update
set t.CNO = 'a',
t.ReturnNo = 'a',
t.MainProd = 'b',
t.Prod = 'c';
I wonder now, what is the advantage of using MERGE in my case - if there is one.I don't see any advantage, but I suspect the statement, as written, is not doing what it's supposed to. If someone made the mistake of using MERGE when UPDATE would be better, that might be the least of the mistakes in this statement.
Finally I want to demonstrate how the whole thing would look without a MERGE:It looks like the MERGE statement above is equivalent to:
UPDATE     t_claims_bb
SET     cno          = 'a'
,     returnno     = 'a'
,     mainprod     = 'b'
,     prod          = 'c'
WHERE     UPPER (SUBSTR (bookingtext, 1, 2)) IN
          SELECT returnno
          FROM     commonschema.vc_regvereinb
AND     EXISTS
          SELECT 1
          FROM     mainschema.tverscontract
          WHERE     subcno     IS NULL
AND     EXISTS
          SELECT     1
          FROM     mainschema.tcontract
AND     EXISTS
          SELECT     1
          FROM     myschema.t_claims_vt
;Again, I suspect that the MERGE state,ment above is not doing what it was meant to do, or may coinncidentally be getting the right results on a small sample set. Many of the tables named in the USING clause of the MERGE statement do'nt seem to have much of a role in this problem.
SELECT vers.* FROM TVERSCONTRACT vers
LEFT OUTER JOIN myschema.T_CLAIMS_BB sch ON sch.SubCNo = vers.SubCNo
LEFT OUTER JOIN commonschema.VC_REGVEREINB regv ON sch.SCH# = regv.SCH# AND SUBSTR(UPPER(sch.BUCHTEXT),1,2) = regv.SndReturnNo AND sch.SubCNo IS NULL
LEFT OUTER JOIN myschema.T_CLAIMS_VT sch_vt ON sch.SCH# = sch_vt.SCH#What is this query? Perhaps you meant to have something like this in the USING clause of the MERGE.
I hope this answers your question.
If not, post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) for all the tables involved, and the results you want from that data.
The sample data should show what the tables are like before the MERGE (or UPDATE), and the results will be the contents of the changed table after the MERGE.
Explain, using specific examples, how you get those results from that data.
Always say what version of Oracle you're using.

Cross join

Can some one plz explain in wat scenarios cross join is useful?

It's not easy to come up with a generic scenario / use case.
I assume you know what it is / what the effects are so there's no point showing that.
The cases where I have used it are a) rare and b) very specific - i.e. not good for showing why you might want to use it.
Chances are you might never need to use it.
CROSS JOIN syntax is good when you clearly want a cartesian product and by using this syntax you effectively document that this behaviour is intentional.

Cartesian Product from in-line queries

I have the following query:
SELECT AUDIT_MONTH, AUDITS, DEFECTS
FROM
select distinct(to_char(AUDIT_DATE,'MM/YY')) as AUDIT_MONTH
from v_safety_audit_records
select count(distinct(AUDIT_ID)) AUDITS
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
select count(KEY_ID) DEFECTS
from v_safety_audit_records
where SUBAREA_ID NOT LIKE '_98'
and SUBAREA_ID NOT LIKE '_99'
group by to_char(AUDIT_DATE,'MM/YY')
but it keeps giving me a cartesian product. Is there a way to re-write this so that I only get the month, the number of audits, and number of defects on a line rather than number of months x number of months worth of lines? I can't seem to get the join conditions worked out... I can re-write this all using views, but as it is for a single report, I'd rather not bother with more views if I can avoid it.
Thanks in advance.

The problem is that the query doesn't return a single row and isn't meant to. I tried:
SELECT
select distinct(to_char(AUDIT_DATE,'MM/YY'))
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
) AUDIT_MONTH,
select count(distinct(AUDIT_ID))
from v_safety_audit_records
group by to_char(AUDIT_DATE,'MM/YY')
) AUDITS,
select count(KEY_ID)
from v_safety_audit_records
where SUBAREA_ID NOT LIKE '_98'
and SUBAREA_ID NOT LIKE '_99'
group by to_char(AUDIT_DATE,'MM/YY')
) DEFECTS
FROM DUAL;
and got "ORA-01427: single-row subquery returns more than one row". It would be a good idea if I only needed it for one month, however.

Cartesian Product in Select

    Hi all!
I need help.
I have this function that launches a Select. My Oracle Grid tells me, when I tune the Select of this function, that there is a Cartesian Product. I understand what a Cartesian Product is, but I fail to find it. Can you help me by pointing out WHERE is the misteke? Thank you!!
P.s. Oracle EE 10.2.0.4 on windows Server 2003 R2 SP2 64Bit
[code]
create or replace
FUNCTION          "ANA_GETVERBALE"
v_VerbaleId      IN NUMBER DEFAULT NULL,
v_Sezione        IN VARCHAR2 DEFAULT NULL,
v_NumeroVerbale IN VARCHAR2 DEFAULT NULL,
v_DataVerbale    IN DATE DEFAULT NULL,
v_TargaVeicolo   IN VARCHAR2 DEFAULT NULL,
v_Serie          IN VARCHAR2 DEFAULT NULL,
v_LoggedUser IN VARCHAR2 DEFAULT NULL
RETURN SYS_REFCURSOR
AS
   cv_1 SYS_REFCURSOR;
BEGIN
OPEN cv_1 FOR
    SELECT
      ANA_M.VerbaleId,
      ANA_M.Sezione,
      ANA_M.NumeroVerbale,
      ANA_M.DataVerbale,
      ANA_M.TargaVeicolo,
      ANA_M.Serie,
      SCH_C.StatoCartellinoId,
      LOV_StatoCartellino.ListOfValueName StatoCartellino,
      sch_c.cartellinoid
    FROM ANA_Materia_Verbale ANA_M
    INNER JOIN SCH_Cartellini SCH_C ON SCH_C.SoggettoId=ana_m.verbaleid AND SCH_C.TipoSoggettoId = SIS_CONSTANTS_PKG.VB
    INNER JOIN SIC_PROFILO_STATO SIC_PSC ON SIC_PSC.STATOID=SCH_C.STATOCARTELLINOID
    INNER JOIN SIC_PROFILI_USERS SIC_PUC ON SIC_PUC.PROFILOID=SIC_PSC.PROFILOID AND SIC_PUC.PERSONALID=v_LoggedUser
    LEFT JOIN TYP_ListOfValues LOV_StatoCartellino ON LOV_StatoCartellino.ListOfValueId = SCH_C.StatoCartellinoId
    WHERE ( v_VerbaleId = SIS_CONSTANTS_PKG.AnyBigint OR ANA_M.VerbaleId = v_VerbaleId )
      AND ( v_Sezione = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.Sezione, '^' || v_Sezione || '$', 'i') )
      AND ( v_serie = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.Serie, '^' || v_Serie || '$', 'i') )
      AND ( v_NumeroVerbale = SIS_CONSTANTS_PKG.AnyString OR ANA_M.NumeroVerbale = v_NumeroVerbale )
      AND ( v_DataVerbale = SIS_CONSTANTS_PKG.AnyDateTime OR ANA_M.DataVerbale = v_DataVerbale )
      AND ( v_TargaVeicolo = SIS_CONSTANTS_PKG.AnyString OR REGEXP_LIKE(ANA_M.TargaVeicolo,'^' || v_TargaVeicolo || '$', 'i') );
RETURN cv_1;
END;
[/code]

....ouch... well that explains a LOT!! The real problem was the Oracle Grid SQL_TUNING that warned me that the SELECT contained a CARTESIAN PRODUCT:
Ristruttura SQL
An expensive cartesian product operation was found at line ID 4 of the execution plan.
Consider removing the disconnected table or view from this statement or add a join condition which refers to it.
A cartesian product should be avoided whenever possible because it is an expensive operation and might produce a large amount of data.
with this EXECUTION PLAN:
Operazione
ID riga
Oggetto
Object type
Ordine
Righe
Dimensione (KB)
Costo
Tempo (sec)
Costo CPU
Costo I/O
SELECT STATEMENT
0
13
1
0,091
460
6
116.852.560
452
NESTED LOOPS OUTER
1
12
1
0,091
460
6
116.852.560
452
NESTED LOOPS
2
9
1
0,079
459
6
116.843.328
451
NESTED LOOPS
3
7
2
0,141
457
6
116.826.984
449
MERGE JOIN CARTESIAN
4
4
2
0,102
451
6
116.781.136
443
INDEX FAST FULL SCAN
5
DOCARK.PK_SIC_PROFILI_USERS
INDEX (UNIQUE)
1
1
0,010
2
1
81.903
2
BUFFER SORT
6
3
2
0,082
449
6
116.699.232
441
TABLE ACCESS FULL
7
DOCARK.ANA_MATERIA_VERBALE
TABLE
2
2
0,082
449
6
116.699.232
441
TABLE ACCESS BY INDEX ROWID
8
DOCARK.SCH_CARTELLINI
TABLE
6
1
0,020
3
1
22.924
3
INDEX RANGE SCAN
9
DOCARK.IDX_SCH_CARTELLINI_SOG_TIPO
INDEX
5
1
2
1
15.493
2
INDEX RANGE SCAN
10
DOCARK.PK_SIC_PROFILO_STATO
INDEX (UNIQUE)
8
1
0,009
1
1
8.171
1
TABLE ACCESS BY INDEX ROWID
11
DOCARK.TYP_LISTOFVALUES
TABLE
11
1
0,012
1
1
9.231
1
INDEX UNIQUE SCAN
12
DOCARK.PK_TYP_LISTOFVALUES
INDEX (UNIQUE)
10
1
0
1
1.900
0
So I started trying to REMOVE the Cartesian Product. But first I had to find it! So apparently I shouldn't worry too much...
The real problem is that I have to work with funtions and DBs created by others, so I am not sure what to expect from most of the Functions. Apparently this execution is correct no matter what that the Tunig Advisor says!
Thanks!

Ora 00918 normalizing problem using cartesian product

I am using a cartesian product to normalise a table. Is there a better way of doing this to avoid the 00918 error?
Thanks in advance ...
select
/* select clause */
from
z_dvo_proj_milestone_summary t1,
z_dvo_proj_milestone_summary t2
where
/* where clause */
create or replace view z_dvo_proj_milestone_summary as
select
query1.projid
,query1.projname
,query1.projtype
,query1.projcode
,query1.report_month
,query1.report_year
,query1.SubProjID
,query1.DVONUM
,query1.measure_type
,query1.MEASURE
,hier.level0_vosa_prj_type
from
(select
score.project as projid
,srm.name as projname
,hier.level0_vosa_prj_type as projtype
,score.code as projcode
,score.report_month as report_month
,score.report_year as report_year
,CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End as SubProjID
,dvonumtab.dvonum as DVONUM
,typetab.measure_type as measure_Type
,CASE
WHEN (subprojtab.subprojid = 1) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_planned
End
End
WHEN (subprojtab.subprojid = 2) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_planned
End
End
End as MEASURE
from
ODF_CA_PROJSCORE score
left outer join
srm_projects srm on (srm.id = score.project)
left outer join
Z_PROJECT_HIERARCHY hier on (srm.id = hier.level0)
Join
(select 1 as subprojid from dual
union
select 2 as subprojid from dual) subprojtab on (1=1)
/* There will be 11 measures here eventually */
Join
(select 'baseline' as measure_type from dual
union
select 'planned' as measure_type from dual) typetab on (1=1)
Join
(select 1 as dvonum from dual
union
select 2 as dvonum from dual) dvonumtab on (1=1)
WHERE
(CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End) IS NOT NULL) query1
left outer join Z_PROJECT_HIERARCHY hier
on (query1.SubProjID = hier.level0)

I am using a cartesian product to normalise a table. Is there a better way of doing this to avoid the 00918 error?
Thanks in advance ...
select
/* select clause */
from
z_dvo_proj_milestone_summary t1,
z_dvo_proj_milestone_summary t2
where
/* where clause */
create or replace view z_dvo_proj_milestone_summary as
select
query1.projid
,query1.projname
,query1.projtype
,query1.projcode
,query1.report_month
,query1.report_year
,query1.SubProjID
,query1.DVONUM
,query1.measure_type
,query1.MEASURE
,hier.level0_vosa_prj_type
from
(select
score.project as projid
,srm.name as projname
,hier.level0_vosa_prj_type as projtype
,score.code as projcode
,score.report_month as report_month
,score.report_year as report_year
,CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End as SubProjID
,dvonumtab.dvonum as DVONUM
,typetab.measure_type as measure_Type
,CASE
WHEN (subprojtab.subprojid = 1) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj1_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj1_dvo2_planned
End
End
WHEN (subprojtab.subprojid = 2) then
CASE
when typetab.measure_type = 'baseline' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_baseline
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_baseline
End
when typetab.measure_type = 'planned' then
CASE
when (dvonumtab.dvonum = 1) then score.proj2_dvo1_planned
when (dvonumtab.dvonum = 2) then score.proj2_dvo2_planned
End
End
End as MEASURE
from
ODF_CA_PROJSCORE score
left outer join
srm_projects srm on (srm.id = score.project)
left outer join
Z_PROJECT_HIERARCHY hier on (srm.id = hier.level0)
Join
(select 1 as subprojid from dual
union
select 2 as subprojid from dual) subprojtab on (1=1)
/* There will be 11 measures here eventually */
Join
(select 'baseline' as measure_type from dual
union
select 'planned' as measure_type from dual) typetab on (1=1)
Join
(select 1 as dvonum from dual
union
select 2 as dvonum from dual) dvonumtab on (1=1)
WHERE
(CASE
when (subprojtab.subprojid = 1) then score.sub_project_1
when (subprojtab.subprojid = 2) then score.sub_project_2
End) IS NOT NULL) query1
left outer join Z_PROJECT_HIERARCHY hier
on (query1.SubProjID = hier.level0)

How to avoid duplicates in CROSS JOIN Query

Hi,
I am using CROSS JOIN to get all the subset of a table col values as shown below:
PRODUCT (Col Header)
Bag
Plate
Biscuit
While doing cross join we will get as
Bag Bag
Bag Plate
Bag Biscuit
Plate Bag
Plate Plate
Plate Biscuit ..... like this
By placing where condition prod1 <> prod2 to avoid Bag Bag and Plate Plate values. So the output will be like below
Bag Plate
Bag Biscuit
Plate Bag
Plate Biscuit
Now "Bag Plate" and "Plage Bag" are same combination how to avoid these records. My expected result is
Bag Biscuit
Plate Biscuit
How to derive this ?
Sridhar

Hi,
This is the the solution that I found as fit to the OP question, but
Visakh16 already posted the same idea (assuming the names are unique) from the start and I don't think that anyone notice it!
Sridhar.DPM did
you check Visakh16's response
(the second response received)?!?
I will mark his response as an answer. If this is not what you need pls clarify and you can unmark it :-)
[Personal Site] [Blog] [Facebook]

Cross Join or Cartesian Product

Similar Messages

Maybe you are looking for