SELECT T1.d, T2.c
FROM T1, T2
WHERE T1.x = T2.x (+) and T2.y > 5;

and its ANSI equivalent

SELECT T1.d, T2.c
FROM T1 LEFT OUTER JOIN T2
ON (T1.x = T2.x)
WHERE T2.y > 5;

into this inner join query

SELECT T1.d, T2.c
FROM T1, T2
WHERE T1.x = T2.x and T2.y > 5;

That’s according to the Optimizer Development Group blog. They go on to explain:

Here the filter predicate on the outer-joined table T2 does not contain the outerjoin operator (+); thus it will be applied after the left outerjoin has taken place. This will result in the elimination of all null appended rows of T2. Hence, Oracle converts the outer join into an inner join.

And here is an interesting thing about ANSI full outer joins:

Before Oracle 11gR1 all ANSI full outerjoins were converted into a UNION ALL query with two branches, where one branch contained a left outerjoined lateral view and the other branch contained a NOT EXISTS subquery. A native support for hash full outerjoin was introduced in 11gR1 to overcome this problem. When the native full outerjoin cannot be used, Oracle reverts to the pre-11gR1 strategy.

Their latest blog post about Outerjoins in Oracle is a good read.

Related articles:

• Back to basics: outer joins
• Outer joins and “OR”
• Back to basics: self joins

• Inner joins
• Outer joins
• Cross joins
• Self joins
• Equi and non-equijoins
• Anti-joins and semi-joins

However, ANSI SQL join syntax does not always work in Oracle, at least up to version 10gR2.

Related articles:

• Back to basics: cross joins
• Back to basics: outer joins
• Back to basics: inner joins

If you are writing queries that select from many tables, like denormalizing data for warehousing, and the sum of the columns in those tables exceeds 1,050, you always get ORA-01445. This occurs from 9i through 10g2, and has happened often enough to me that I avoid my preference for ANSI syntax on Oracle databases, unless I’m just selecting from a few tables.

Well, it just happened to me. Below are two queries. They both select from standard Oracle E-Business Suite (11.5.10) tables. The two queries are identical except that the first uses the ANSI style syntax, and the second uses the Oracle syntax. As you can see below, the query that uses ANSI joins failed miserably with the error:

ORA-01445: cannot select ROWID from, or sample, a join view without a key-preserved table.

This looks like a bug to me. Interestingly, if you change the SELECT NULL to SELECT COUNT(*), the query executes successfully.

APPS@sigma> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.5.0 - Prod
PL/SQL Release 10.1.0.5.0 - Production
CORE    10.1.0.5.0      Production
TNS for Linux: Version 10.1.0.5.0 - Production
NLSRTL Version 10.1.0.5.0 - Production

APPS@sigma> SELECT NULL
  2    FROM oe_order_headers_all header INNER JOIN oe_order_lines_all line
  3         ON header.header_id = line.header_id
  4         INNER JOIN ra_customers cust ON header.sold_to_org_id = cust.customer_id
  5         INNER JOIN mtl_system_items_b item
  6         ON item.inventory_item_id = line.inventory_item_id
  7       AND item.organization_id = line.ship_from_org_id
  8         INNER JOIN org_organization_definitions org
  9         ON org.organization_id = line.ship_from_org_id
 10         LEFT OUTER JOIN ra_salesreps_all salesrep
 11         ON salesrep.salesrep_id = header.salesrep_id
 12       AND salesrep.org_id = header.org_id
 13         LEFT OUTER JOIN hr_locations_all sales_loc
 14         ON sales_loc.location_id = salesrep.attribute1
 15   WHERE header.orig_sys_document_ref = 'OE_ORDER_HEADERS_ALL74846'
 16     AND header.order_source_id = 0;

       LEFT OUTER JOIN hr_locations_all sales_loc
                       *
ERROR at line 13:
ORA-01445: cannot select ROWID from, or sample, a join view without a
key-preserved table

Now, using the good old Oracle SQL syntax:

APPS@sigma> SELECT NULL
  2    FROM oe_order_headers_all header,
  3         oe_order_lines_all line,
  4         ra_customers cust,
  5         mtl_system_items_b item,
  6         org_organization_definitions org,
  7         ra_salesreps_all salesrep,
  8         hr_locations_all sales_loc
  9   WHERE header.header_id = line.header_id
 10     AND header.sold_to_org_id = cust.customer_id
 11     AND item.inventory_item_id = line.inventory_item_id
 12     AND item.organization_id = line.ship_from_org_id
 13     AND org.organization_id = line.ship_from_org_id
 14     AND salesrep.salesrep_id(+) = header.salesrep_id
 15     AND salesrep.org_id(+) = header.org_id
 16     AND sales_loc.location_id(+) = salesrep.attribute1
 17     AND header.orig_sys_document_ref = 'OE_ORDER_HEADERS_ALL74846'
 18     AND header.order_source_id = 0;

N
-


2 rows selected.

Another interesting observation is that I could not find any reference to the ORA-01445 error in the Oracle Database Error Messages document for versions 10.1 and 10.2. I did however find the following references:

• Andrew Channels Dexter Pinion: ORA-01445
• Oracle-l: limit on number of tables in join
• OraFAQ Forum: Urgent-ORA-01445
• Outer join – same query, different results
• Oracle bug no. 5967612 on Metalink

Related articles:

• Back to basics: inner joins
• Back to basics: anti-joins and semi-joins
• Back to basics: outer joins

Anti-joins:
Anti-joins are written using the NOT EXISTS or NOT IN constructs. An anti-join between two tables returns rows from the first table for which there are no corresponding rows in the second table. In other words, it returns rows that fail to match the sub-query on the right side.

Suppose you want a list of departments with no employees. You could write a query like this:

SELECT   d.department_name
    FROM departments d
MINUS
SELECT   d.department_name
    FROM departments d, employees e
   WHERE d.department_id = e.department_id
ORDER BY department_name;

The above query will give the desired results, but it might be clearer to write the query using an anti-join:

SELECT   d.department_name
    FROM departments d
   WHERE NOT EXISTS (SELECT NULL
                       FROM employees e
                      WHERE e.department_id = d.department_id)
ORDER BY d.department_name;

Semi-joins:
Semi-joins are written using the EXISTS or IN constructs. A semi-join between two tables returns rows from the first table where one or more matches are found in the second table. The difference between a semi-join and a conventional join is that rows in the first table will be returned at most once.

Suppose you want a list of departments with at least one employee. You could write the query like this:

SELECT   d.department_name
    FROM departments d, employees e
   WHERE d.department_id = e.department_id
ORDER BY department_name;

The department name in the query result will appear as many times as the number of employees in it. So, for example if a department has 30 employees then that department will appear in the query output 30 times.

To eliminate the duplicate rows, you could use the DISTINCT or GROUP BY keywords. A more elegant solution is to use a semi-join between the departments and employees tables instead of a conventional join:

SELECT   d.department_name
    FROM departments d
   WHERE EXISTS (SELECT NULL
                   FROM employees e
                  WHERE e.department_id = d.department_id)
ORDER BY d.department_name;

The above query will list the departments that have at least one employee. The department will appear only once in the query output no matter how many employees it has.

Sources and Resources:

• Speeding Up Queries with Semi-Joins and Anti-Joins
• Documentation

Related articles:

• Back to basics: cross joins
• Back to basics: self joins
• Back to basics: outer joins

But, what does this have to do with databases. Well, it turns out that the SQL language has politics embedded in it. For example, consider the following two simple queries:

Query 1:

SELECT emp.last_name,
       dept.department_name
  FROM departments dept LEFT OUTER JOIN employees emp
       ON dept.department_id = emp.department_id

Query 2:

SELECT emp.last_name,
       dept.department_name
  FROM employees emp RIGHT OUTER JOIN departments dept
       ON dept.department_id = emp.department_id

Both queries return the same result set. The difference between the two is that one uses “LEFT” and the other uses “RIGHT”.

Which one do you prefer using? In other words, which type of outer join do you usually use in your queries, the left or the right?

Now, if you select query 1, the one that uses the “LEFT” join, you most probably lean towards the left. You are a liberal. As a result, you are more likely to vote Democrat this Tuesday.

But, if you select query 2, the one that uses the “RIGHT” join, you most probably lean towards the right. You are a conservative. As a result, you are more likely to vote Republican this Tuesday.

There you go. A simple test, for all of you SQL developers out there, to know your political affiliation.

Some have called for a boycott of all right joins and only use left joins on Tuesday. Others have called for the abolition of both the left and the right.

Personally, I do not use right joins. But again, I cannot vote because I’m not a US citizen.

Related articles:

• Back to basics: outer joins
• Back to basics: inner joins
• Outer joins and “OR”

To get information about an employee and her manager, you have to join the employee table to itself, thereby treating employees as if it were two separate tables. The following example query uses a self join to return the name of each employee along with the name of the employee’s manager:

SELECT e.last_name employee, m.last_name manager
  FROM employees e INNER JOIN employees m
       ON e.manager_id = m.employee_id;


         EMPLOYEE                  MANAGER          
------------------------- ------------------------- 
Kochhar                   King                      
De Haan                   King                      
Hunold                    De Haan                   
Ernst                     Hunold                    
Austin                    Hunold                    
Pataballa                 Hunold                    

...                   

106 row(s) retrieved

But

SELECT COUNT (*)
  FROM employees;

               COUNT(*)                
-------------------------------------- 
                                   107 

Even though the employees table has 107 rows, the previous query returned only 106 rows. This is because there is an employee without a manager_id. Oracle excludes that employee’s row from the result set while performing the self inner join. To include that employee without a manager, you need an outer join:

SELECT e.last_name employee, m.last_name manager
  FROM employees e LEFT OUTER JOIN employees m
       ON e.manager_id = m.employee_id;


         EMPLOYEE                  MANAGER          
------------------------- ------------------------- 
King                     
Kochhar                   King                      
De Haan                   King                      
Hunold                    De Haan                   
Ernst                     Hunold                    
Austin                    Hunold                    
Pataballa                 Hunold                    

...                   

107 row(s) retrieved

The previous examples showed self equijoins. However, there are situations when you need to perform self non-equijoins. For example, let’s assume that you are in charge of organizing an interdepartmental soccer competition for the following departments:

SELECT department_name
  FROM departments
 WHERE department_id IN (10, 20, 30, 40);

        DEPARTMENT_NAME        
------------------------------ 
Administration                 
Marketing                      
Purchasing                     
Human Resources                

4 row(s) retrieved

You decide that each department plays against the other three departments only once, which means that the output of the query you are going to write cannot contain one combination Administration, Marketing and another Marketing, Administration because that means that each department plays against the others twice. The solution is to use a self non-equijoin query like this:

SELECT d1.department_name dept1, d2.department_name dept2
  FROM departments d1 INNER JOIN departments d2
       ON d1.department_id < d2.department_id
 WHERE d1.department_id IN (10, 20, 30, 40)
   AND d2.department_id IN (10, 20, 30, 40);

             DEPT1                          DEPT2             
------------------------------ ------------------------------ 
Administration                 Marketing                      
Administration                 Purchasing                     
Administration                 Human Resources                
Marketing                      Purchasing                     
Marketing                      Human Resources                
Purchasing                     Human Resources                

6 row(s) retrieved

That’s it for self joins

Sources:

• Oracle Documentation
• Mastering Oracle SQL

Related articles:

• Back to basics: anti-joins and semi-joins
• Back to basics: cross joins
• Back to basics: outer joins

Equijoins are the most commonly used. An example of an equijoin:

SELECT e.first_name, d.department_name
  FROM employees e INNER JOIN departments d
       ON e.department_id = d.department_id
/
       
     FIRST_NAME              DEPARTMENT_NAME        
-------------------- ------------------------------ 
Steven               Executive                      
Neena                Executive                      
Lex                  Executive                      
Alexander            IT                             
Bruce                IT                             

Non-equijoins are less frequently used. An example of a non-equijoin:

SELECT zip_codes.zip_code, zones.ID AS zip_zone,
       zones.low_zip, zones.high_zip
  FROM zones INNER JOIN zip_codes
       ON zip_codes.zip_code BETWEEN zones.low_zip
                                 AND zones.high_zip
/

ZIP_CODE ZIP_ZONE LOW_ZIP HIGH_ZIP
-------- -------- ------- --------
57000    1        57000   57999 
84006    2        84000   84999 

Can you think of another non-equijoin example?

Related articles:

• Back to basics: self joins
• Back to basics: inner joins
• Back to basics: outer joins

The ANSI SQL syntax of an outer join is:

FROM t1 { LEFT | RIGHT | FULL } [OUTER] JOIN t2

OUTER is optional. If you use LEFT, RIGHT, or FULL, the assumption is that it is an outer join.

LEFT OUTER JOIN

LEFT specifies that the results be generated using all rows from t1. For those rows in t1 that don’t have corresponding rows in t2, NULLs are returned in the result set for the t2 columns.

For example, to list all departments even if they have no employees, you can perform a LEFT OUTER JOIN between the dept and the emp tables:

SELECT dept.dept_name, emp.emp_name
FROM dept LEFT OUTER JOIN emp 
ON dept.dept_id = emp.dept_id

DEPT_NAME  EMP_NAME
---------- ---------
HR         
IT         Eddie                                          

2 rows selected

A corresponding query using the old join syntax is:

SELECT dept.dept_name, emp.emp_name
FROM dept, emp
WHERE dept.dept_id = emp.dept_id(+)

The (+) operator following emp.dept_id means that you want to display a row from the dept table, even though there exists no corresponding row in the emp table.

RIGHT OUTER JOIN

RIGHT specifies that the results be generated using all rows from t2. For those rows in t2 that don’t have corresponding rows in t1, NULLs are returned in the result set for the t1 columns.

For example, to list all the employees even if they are not related to any particular department, you can perform a RIGHT OUTER JOIN between the emp and the dept tables:

SELECT dept.dept_name, emp.emp_name
FROM dept RIGHT OUTER JOIN emp 
ON dept.dept_id = emp.dept_id

DEPT_NAME  EMP_NAME  
---------- ---------
           King
IT         Eddie

2 rows selected

A corresponding query using the old join syntax is:

SELECT dept.dept_name, emp.emp_name
FROM dept, emp 
WHERE dept.dept_id(+) = emp.dept_id

The (+) operator following dept.dept_id means that you want to display a row from the emp table, even though there exists no corresponding row in the dept table.

LEFT or RIGHT?

The LEFT and RIGHT keywords in an outer join query are relative to the position of the tables in the FROM clause. Here is a way to decide which to use, LEFT or RIGHT: look at t1 and t2 in the FROM clause, if t1 is to your left and you want to return all rows from t1, use LEFT JOIN. If t1 is to your right and you want to return all rows from t1, use RIGHT JOIN.

FULL OUTER JOIN

FULL specifies that the results be generated using all rows from t1 and all rows from t2. For those rows in t1 that don’t have corresponding rows in t2, NULLs are returned in the result set for the t2 columns. Additionally, for those rows in t2 that don’t have corresponding rows in t1, NULLs are returned in the result set for the t1 columns.

For example, to list all the departments (with or without employees), as well as all the employees (with or without a department), use a FULL OUTER JOIN:

SELECT dept.dept_name, emp.emp_name
FROM dept FULL OUTER JOIN emp 
ON dept.dept_id = emp.dept_id


DEPT_NAME  EMP_NAME  
---------- ---------
HR         
IT         Eddie
           King

3 rows selected

A corresponding query using the old join syntax is:

SELECT dept.dept_name, emp.emp_name
FROM dept, emp 
WHERE dept.dept_id(+) = emp.dept_id(+)

OOPS! if you execute the above query you get this error:

ORA-01468: a predicate may reference only one outer-joined table

The fact is that FULL OUTER JOIN is not supported in the old syntax. The outer join operator (+) can appear on only one side of an expression in the join condition, not on both (a workaround is to use a UNION of two SELECT statements).

One other advantage to using ANSI SQL is to overcome the restriction that a condition containing the (+) operator may not use the IN operator and may not be combined with another condition using the OR operator. For example:

SELECT dept.dept_name, emp.emp_name
FROM dept, emp 
WHERE dept.dept_id(+) = emp.dept_id
OR emp.emp_name = 'King'

Will give you this error:

ORA-01719: outer join operator (+) not allowed in operand of OR or IN

Here is how you would write the query using the ANSI SQL join and without getting the ORA-01719 error:

SELECT dept.dept_name, emp.emp_name
FROM dept RIGHT OUTER JOIN emp 
ON (dept.dept_id = emp.dept_id
    OR emp.emp_name = 'King')

DEPT_NAME  EMP_NAME  
---------- ---------
HR         King
IT         King
IT         Eddie

3 rows selected

That concludes my overview of outer joins. Later, I will review the rest of the join types…

Related articles:

• Back to basics: inner joins
• Back to basics: cross joins
• Back to basics: self joins

For example:

create table dept (
    dept_id number primary key, 
    dept_name varchar2(100))
/
create table emp (
    emp_id number primary key, 
    emp_name varchar2(100), 
    dept_id number,
    foreign key (dept_id) 
    references dept(dept_id)
)
/
insert into dept values (1, 'HR')
/
insert into dept values (2, 'IT')
/
insert into emp values (1, 'King', null)
/
insert into emp values (2, 'Eddie', 2)
/

To join the two tables using the old syntax:

select emp.emp_name, dept.dept_name
from emp, dept
where emp.dept_id = dept.dept_id

Using the new syntax:

select emp.emp_name, dept.dept_name
from emp INNER JOIN dept
ON emp.dept_id = dept.dept_id

The JOIN keyword is by default INNER, so the INNER keyword in optional in the example above.

Since the join column is named identically in both emp and dept tables, you can use the USING keyword:

select emp.emp_name, dept.dept_name
from emp INNER JOIN dept
USING (dept_id)

But be careful, if you want to return the join column in the select list, make sure not to qualify it. The following:

select dept.dept_id, emp.emp_name, dept.dept_name
from emp INNER JOIN dept
USING (dept_id)

Returns this error:

ORA-25154: column part of USING clause cannot have qualifier

There is one additional join option called “natural join”, using the NATURAL JOIN clause. With natural joins, you don’t specify a join condition. A natural join joins on columns with the same names from each table. For example, because the column dept_id is named the same in both emp and dept tables, the following is a legal SQL that implicitly joins emp and dept on dept_id:

select emp.emp_name, dept.dept_name
from emp NATURAL JOIN dept

Similar to USING, if you want to return the join column in the select list, make sure not to qualify it. The following is legal:

select dept_id, emp.emp_name, dept.dept_name
from emp NATURAL JOIN dept

But, if you use dept.dept_id instead of just dept_id, you get this error:

ORA-25155: column used in NATURAL join cannot have qualifier

Finally, my preference is to use INNER JOIN…ON instead of USING or NATURAL JOIN. INNER JOIN…ON is very clear in showing on what columns you are joining.

Outer joins next…

Related articles:

• Back to basics: outer joins
• Back to basics: anti-joins and semi-joins
• Back to basics: cross joins

Starting with Oracle database version 9i, you can use the SQL join syntax that is compliant with the ANSI/ISO SQL92 standard. You also have the option to continue using the “old” syntax – that I have been using for years and that I am so used to. But to me, one of the main advantages of using the “new” join syntax is that join conditions are separated from the other filter conditions in the WHERE clause, making the query self explanatory as far as join conditions are concerned.

I have decided to break my habit and start using the “new” syntax in all my queries (except when I’m working against Oracle 8i). To that end, I will be writing a series of posts about the different types of joins along with code examples both in the “old” and the corresponding “new” syntax. Nothing revolutionary, just simple, “back to basics” stuff.

Here are the different types of joins that I’m planning to review:

• Cross joins
• Inner joins
• Outer joins
• Equi-joins and non equi-joins
• Self joins
• Anti-joins
• Semi-joins

I will start with cross joins, a.k.a. Cartesian products. A Cartesian product is returned when you don’t specify a join condition when joining two tables. Oracle combines each row from the first table with each row from the second table. The number of rows in a Cartesian product is equal to the number of rows in the first table multiplied by the number of rows in the second table.

Using the old syntax:

select e.first_name, d.department_name
from employees e, departments d

Using the new syntax:

select e.first_name, d.department_name
from employees e cross join departments d

Result set:

FIRST_NAME           DEPARTMENT_NAME                
-------------------- ------------------------------ 
Ellen                Administration                 
Sundar               Administration                 
Mozhe                Administration                 
...
...
Matthew              Payroll                        
Jennifer             Payroll                        
Eleni                Payroll                        

2889 rows selected

2889 = 107 employees * 27 departments.

Cross joins are usually useless and should be avoided.

Using the old syntax, it is easier to forget to include a join condition resulting in an unintentional Cartesian product.

Always include a join condition unless you specifically need a Cartesian product. Join conditions are included in all the other join types.

In my next post, I will review inner joins.

Related articles:

• Back to basics: inner joins
• Back to basics: outer joins
• Back to basics: anti-joins and semi-joins