Oracle SQL Revealed: Executing Business Logic in the Database Engine

Part IFeatures and Theory

Features and Theory

Chapters 1-10 are organized to follow the list below of Oracle SQL features:

1.

All joins can be implicitly specified in the query; however sometimes it makes sense to use subqueries, for example, for a more efficient way to implement an ANTI/EQUI join. Correlated scalar subqueries may be more efficient than outer joins because of scalar subquery caching.

2.

Query transformations make it possible for two queries with quite different text to have the same plan and performance. On the other hand, query transformations are not a universal panacea and sometimes manual query refactoring is required to achieve the best performance.

3.

Analytic functions are an invaluable feature that helps to implement tricky logic without joins. On the other hand, they almost always require a sort, which may be an issue on big data volumes.

4.

Aggregate functions allow us to group data and calculate aggregate values as well as implement some complex flattening or pivoting logic.

5.

Connect by is the best tool to traverse hierarchies or generate lists; however it should not be used to traverse graphs despite built-in capabilities to handle cycles if performance is critical.

6.

Recursive subquery factoring extends capabilities of traversing hierarchies in a way that you can refer values calculated on a previous level. When recursive subquery factoring is used for iterative transformations of a dataset you should take into account that a new recordset is generated on each iteration, which leads to intensive memory consumption. A functional advantage in comparison to a model clause is that you can calculate multiple measures on each step. In case of a model clause, the first measure is evaluated for all specified rows, then the second one, one and so on.

7.

Model is the most powerful SQL feature but it’s shining in quite specific cases. Model may require intensive CPU and memory consumption and does not scale well enough for millions of rows; however performance can be dramatically improved in case of parallel execution of partitioned models.

8.

Row pattern matching adds noticeable flexibility for analysis of recordsets. This feature is the only way to solve a wide range of tasks in pure SQL in a scalable and efficient manner, and in addition it demonstrates a bit better performance for those tasks that can also be solved using analytic functions.

9.

One query block may contain various clauses including joins, aggregate and analytic, or even mixes of advanced features like model clause and pattern matching. It’s important to understand how this will be executed from a logical point of view and what are the pros and cons of using inline views.

10.

It was proven that SQL is Turing complete language and for academic purposes it was shown how to implement arbitrary algorithms using an iterative model. SQL is a declarative language though and was designed to manipulate data and not for iterative computations.

Tom Kyte wrote many times over the years, You should do it in a single SQL statement if at all possible. I’d like to elaborate on this statement a little bit. Even if we remove from consideration advanced features like recursive subquery factoring, model clause, row pattern matching, and connect by, there are some tasks that can be solved more efficiently using PL/SQL. Various examples will be considered in Chapter 11 to provide more background.

© Alex Reprintsev 2018

Alex ReprintsevOracle SQL Revealedhttps://doi.org/10.1007/978-1-4842-3372-6_1

1. Joins

Alex Reprintsev¹ 

(1)

London, UK

Most real-life queries combine data from multiple tables instead of querying a single table. Logic may be encapsulated in a view to hide complexity from the end user, but the database accesses multiple tables anyway to get the result set. It’s not necessary that data from all tables in a query appear in the result; some tables may be used to filter out data from other tables, for example.

Data from two tables may be combined using join (a join keyword is not mandatory as it will be shown later), subquery (may be correlated or not), lateral view (starting with Oracle 12c), or set operators (union/union all/intersect/minus).

Any logic implemented using set operators or subqueries may be rewritten with joins, but this may not be always optimal from a performance point of view. Moreover, semantically equivalent queries may be rewritten into the same query after query transformations are applied (see details in Chapter 2, Query Transformations) or may have the same execution plan even if they have not been rewritten into the same query. Lateral views can be imitated using a table operator on older versions.

Looking forward, let me mention that some queries that use only one table may be not very easy to understand and may contain quite complex logic, but that is a rare case (a lot of such queries you can find in Part II).

This chapter covers joins (both ANSI and traditional Oracle outer joins syntax) along with some details about subqueries, lateral views, and join methods.

ANSI Joins

The following tables will be used for demonstration.

create table t1(id, name) as

select 1, 'A' from dual union all select 0, 'X' from dual;

create table t2(id, name) as

select 2, 'B' from dual union all select 0, 'X' from dual;

Listing 1-1

Tables for demonstration

Cross join (also called Cartesian product). It returns all possible combinations of two table’s rows.

select *

  from t1

  cross join t2;

        ID N         ID N

---------- - ---------- -

         1 A          2 B

         1 A          0 X

         0 X          2 B

         0 X          0 X

Listing 1-2

Cross join

Inner join – join type that returns those and only those rows from both joined tables satisfying a join predicate (i.e., predicate evaluates into TRUE).

select *

  from t1

  join t2

    on t1.id = t2.id;

        ID N         ID N

---------- - ---------- -

         0 X          0 X

Listing 1-3

Inner join

The table before the join keyword is called a left joined table, and the table after the join keyword is called a right joined table. For an inner join it does not matter which table is left and which one is right, as the result will always be the same for the same tables and join predicate.

A predicate may not always be an equality condition; it can be any expression that evaluates into TRUE, FALSE, or UNKNOWN. UNKNOWN acts almost like FALSE; if a join predicate evaluates into UNKNOWN for given rows from two tables, then they will not be part of the result set. However, if atomic predicates are combined using AND, OR, NOT conditions, then the result may be different if the subexpression evaluates to UNKNOWN and not to FALSE. For example, NOT FALSE evaluates to TRUE, but NOT UNKNOWN evaluates to UNKNOWN.

Speaking about joins, the terms condition, predicate, and criteria are interchangeable.

It’s not mandatory that columns from both tables should be used in the predicate. t1.id > 0 is also a valid join condition. All rows from table t2 satisfy this condition and only one row from table t1 does.

select *

  from t1

  join t2

    on t1.id > 0;

        ID N         ID N

---------- - ---------- -

         1 A          2 B

         1 A          0 X

Listing 1-4

Inner join with predicate containing only one table

If a join condition evaluates into true for some row from one table and multiple rows from another one, then that row will be repeated in the result multiple times. For example, join condition «t1.id <= t2.id» in the below example evaluates to true for row with id = 0 from the left join table and two rows from the right joined table so row with id = 0 appears in the result twice. The same reasoning is valid for row with id = 2 from the second table.

select *

  from t1

  join t2

    on t1.id <= t2.id;

  ID N   ID N

---- - ---- -

   0 X    0 X

   0 X    2 B

   1 A    2 B

Listing 1-5

Inner join with non-equality predicate

Outer join – type of join that returns the same rows as inner join (i.e., rows from both tables that match join condition and) and rows from left joined table (for left join) or right joined table (for right join) or both tables (full join), which do not match the join condition along with NULL values in place of other table’s columns.

select *

  from t1

  left join t2

    on t1.id = t2.id;

        ID N         ID N

---------- - ---------- -

         0 X          0 X

         1 A

Listing 1-6

Left outer join

select *

  from t1

  right join t2

    on t1.id = t2.id;

        ID N         ID N

---------- - ---------- -

         0 X          0 X

                      2 B

Listing 1-7

Right outer join

select *

  from t1

  full join t2

    on t1.id = t2.id;

        ID N         ID N

---------- - ---------- -

         0 X          0 X

                      2 B

         1 A

Listing 1-8

Full outer join

The unnecessary keyword outer was not used in Listings 1-6, 1-7, or 1-8 because keywords left/right/full indicate then that the join is outer. Similarly, if none of the keywords left/right/full are used in join, then it’s inner, so it does not make sense to specify this explicitly using an inner keyword.

As a rule, developers do not use right join in real-life tasks because it’s always possible to use left join instead, which makes the statement easier to understand and improves readability.

When multiple tables (data sets) are joined in a query, then Oracle joins the first two and after that joins the resulting data set with the third data set etc. In case of inner joins, there are no logical limitations on the order of joins and CBO (Cost Based Optimizer) can join tables in any order irrespective of how tables are listed in the query text. For ANSI outer joins, the order of joins in the query matters - see section Clearness and Readability for more details.

Other Types of Joins

Equi joins . If all join conditions contain equality operators, then join is called equi join; otherwise join is called non-equi (Theta) join. Listing 1-3, Listing 1-6, Listing 1-7, and Listing 1-8 are examples for equi join. Listing 1-4 and Listing 1-5 are non-equi joins.

A special case of an equi join is a natural join. A Natural join uses an implicit join condition, which are equality predicates on common columns from both tables (i.e., columns with the same names). This introduces potential danger because if table structure changes, then the join condition may change as well.

select * from t1 natural join t2;

        ID N

---------- -

         0 X

Listing 1-9

Natural join

It’s possible to specify whether a natural join is inner or outer.

create table t(id, name, dummy) as select 1, 'A', 'dummy' from dual;

select * from t1 natural left join t;

        ID N DUMMY

---------- - -----

         1 A dummy

         0 X

Listing 1-10

Outer natural join

If there are no common columns in both tables, then natural join will be effectively cross join.

Another form of equi join on the same columns is named columns join. It allows us to list all columns for join conditions and preserve join conditions even if table structure changes.

select * from t1 join t2 using (id);

        ID N N

---------- - -

         0 X X

Listing 1-11

Named columns join

When using this syntax, a common column only from one table appears in the result. The same happens in case of a natural join in Listing 1-9 and Listing 1-10.

Semi joins . This type of join happens in case of using conditions like in (subquery) or exists (correlated subquery). Result contains column only from one table and only one row is returned from that table even if multiple rows from the subquery satisfy the condition.

create table t0(id, name) as

select 0, 'X' from dual union all select 0, 'X' from dual;

select t1.* from t1 where t1.id in (select id from t0);

        ID N

---------- -

         0 X

select t1.* from t1 where exists (select id from t0 where t1.id = t0.id);

        ID N

---------- -

         0 X

select t1.* from t1 join t0 on t1.id = t0.id;

        ID N

---------- -

         0 X

         0 X

Listing 1-12

Semi join

Anti joins . Work similarly to semi joins but return rows with no matches from the second table. Anti join appears when using predicates not in (subquery) or not exists (correlated subquery). The result will have no rows when using not in and the subquery contains NULL values. If the condition evaluates to UNKWNOWN for some rows and the not exists condition, then those rows will not be part of results; but result is not necessarily empty if the table in the subquery has NULL values for joining columns. This logical difference can be seen in the query plan operation name – HASH JOIN ANTI NA.

select t1.* from t1 where t1.id not in (select id from t0);

select * from table(dbms_xplan.display_cursor(format => 'basic'));

select t1.* from t1 where not exists (select id from t0 where t1.id = t0.id);

select * from table(dbms_xplan.display_cursor(format => 'basic'));

-----------------------------------

| Id  | Operation          | Name |

-----------------------------------

|   0 | SELECT STATEMENT   |      |

|   1 |  HASH JOIN ANTI NA |      |

|   2 |   TABLE ACCESS FULL| T1   |

|   3 |   TABLE ACCESS FULL| T0   |

-----------------------------------

-----------------------------------

| Id  | Operation          | Name |

-----------------------------------

|   0 | SELECT STATEMENT   |      |

|   1 |  HASH JOIN ANTI    |      |

|   2 |   TABLE ACCESS FULL| T1   |

|   3 |   TABLE ACCESS FULL| T0   |

-----------------------------------

Listing 1-13

Anti join

Here and in many following examples, output from SQL*PLUS may be trimmed for readability and formatting purposes.

Some SQL engines allow us to explicitly specify SEMI/ANTI. For example, Cloudera Impala has keywords left/right semi join, left/right anti join.

> select * from t1 left anti join t2 on t1.id = t2.id;

+----+

| id |

+----+

| 1  |

+----+

Fetched 1 row(s)

> select * from t1 right anti join t2 on t1.id = t2.id;

+----+

| id |

+----+

| 2  |

+----+

Fetched 1 row(s)

Listing 1-14

Cloudera Impala ANTI join syntax

Oracle-Specific Syntax

The ANSI join syntax was introduced in Oracle 9i thus before that in order to join tables all of them should be specified in the from clause and join conditions in the where clause. Oracle-specific syntax (also called Oracle native syntax) for outer joins was available much earlier, including versions such as Oracle 5.

Listing 1-3 with inner join can be rewritten in the following way, as shown in Listing 1-15.

select * from t1, t2 where t1.id = t2.id;

Listing 1-15

Another form of inner join

Even though this statement does not have the keyword join, it fully complies with the ANSI standard.

Before ANSI support, the only way to specify that join was left or right was to use Oracle-specific syntax. The construction (+) near column name indicates that join is outer. Left and right outer joins from Listing 1-6 and Listing 1-7 can be expressed in the following way, as shown in Listing 1-16.

select * from t1, t2 where t1.id = t2.id(+);

select * from t1, t2 where t1.id(+) = t2.id;

Listing 1-16

Oracle native syntax for left and right outer join

In the first case table t1 is an inner table and table t2 is a left outer table; in the second case table t1 is a right outer table and table t2 is an inner table.

A full outer join cannot be expressed using native syntax in a way so that each table is used only once. As a rule, developers imitated it using two queries combined using union all.

select *

  from t1, t2

 where t1.id = t2.id(+)

union all

select *

  from t1, t2

 where t1.id(+) = t2.id

   and t1.id is null;

Listing 1-17

Imitation of full join using Oracle native syntax

Speaking about outer joins, it’s very important to understand concepts of pre-join and post-join predicates (Metalink Doc ID 14736.1). As it was mentioned earlier, in the ANSI outer join description, if there is no matching row in the outer table, then columns in the result set are populated with NULL values. The difference between pre-join and post-join predicates is that pre-join predicates are evaluated before NULL augmentation while post-join predicates are logically evaluated after it. In other words, pre-join can be considered as join predicates and post-join as filer predicates.

select *

  from t1, t2

 where t1.id = t2.id(+)

   and t2.id is null;

        ID N         ID N

---------- - ---------- -

         1 A

Listing 1-18

Pre-join and post-join predicates in Oracle native syntax

Expression t1.id = t2.id(+) in Listing 1-18 is a pre-join predicate and t2.id is null is a post-join predicate. Row with id = 1 from table t1 does not have a matching row from table t2 for the join condition t1.id = t2.id(+) so NULL values are populated for columns from t2 and after that filter by t2.id is null is applied.

It’s important to mention that a filter predicate by an inner table may be (will be) applied before joining but this does not violate the definitions of pre-join and post-join predicates. This is part of optimization and you can find additional details at the end of Chapter 2, Query Transformations where the selection operation is mentioned.

Please analyze which predicates are pre-join and post-join in Listing 1-19 (answer will be given right after the code snippet).

create table t3 as

select rownum - 1 id, mod(rownum, 2) sign from dual connect by level <= 3;

1)

select *

  from t3

  left join t1

    on t1.id = t3.id

 order by t3.id;

        ID       SIGN         ID N

---------- ---------- ---------- -

         0          1          0 X

         1          0          1 A

         2          1

2)

select *

  from t3

  left join t1

    on t1.id = t3.id

   and t1.id = 1

 order by t3.id;

        ID       SIGN         ID N

---------- ---------- ---------- -

         0          1

         1          0          1 A

         2          1

3)

select *

  from t3

  left join t1

    on t1.id = t3.id

 where t1.id = 1

 order by t3.id;

        ID       SIGN         ID N

---------- ---------- ---------- -

         1          0          1 A

4)

select *

  from t3, t1

 where t1.id(+) = t3.id

   and t1.id(+) = 1

 order by t3.id;

        ID       SIGN         ID N

---------- ---------- ---------- -

         0          1

         1          0          1 A

         2          1

5)

select *

  from t3, t1

 where t1.id(+) = t3.id

   and t1.id = 1

 order by t3.id;

        ID       SIGN         ID N

---------- ---------- ---------- -

         1          0          1 A

Listing 1-19

Pre-join and post-join predicates

The first query simply demonstrates the left outer equi join. Predicate t1.id = 1 in the third and fifth queries is post-join while a