One of the biggest challenges with outer joins (other than potential performance issues) is explaining to a user why their query results changed because they added a condition to their query. Remember that users don’t (typically) look at the SQL, so they won’t know that I have created an outer join. It can be confusing. Fortunately I have options as to how my outer joins are executed, so once I determine their usage requirements I can change the way my universe behaves.

Defining the Problem

For this post I will am going to use a very simple universe with only three tables, shown here.

This universe joins a customer to an order, and an order to order lines. In my database I have one customer that does not yet have any orders. If I run a query against the current universe structure, this new customer will not show up. My requirement is to show all customers, whether they have orders or not. This must be true even if I put a condition on the order table. That’s where it gets tricky.

ANSI_92 Parameter Setting

In order to make this work, I have to make sure that my universe parameter setting for ANSI_92 is set properly. From the File menu I will select Parameters, and on the tabbed dialog box that appears I will click on the Parameters tab. I need to set the ANSI_92 parameter to “Yes” in order for this technique to work. Without this setting, my joins will be created using Oracle-specific syntax and that isn’t what I want here.

Once I have verified this setting I can close the parameter screen. Next I need to define my outer join.

Defining an Outer Join

The outer join definition is done the same way with all databases, but it’s not always done in the same direction. In some databases I have to check the primary table and in others I need to check the secondary or optional table. Rather than trying to remember which database does what, I will pick a side and check to make sure that the tiny “o” appears on the expected side of my join. For example, I want to reconfigure my existing inner join between customers and orders and make it an outer join as shown here.

The structure window looks a bit different now.

As mentioned earlier, the tiny “o” on the right side of the join denotes the optional side. If the “o” is on the wrong side, I will open the join properties window and select the other checkbox.

That’s how I create an outer join in my universe. Let me show how it works first, then I will show how I can break it.

Outer Join Queries

I have exported my outer join universe and created a very simple query. I have included the customer ID, name, and their order total. There is one customer (appropriately named “New Customer”) that has no orders and their order amount shows up blank because of the outer join setting.

So far everything is working as I expected.

Breaking an Outer Join

An outer join is designed to allow rows that don’t completely match to still show up on my report. What happens if I apply a condition to the outer relationship? For example, I might want to add a condition to limit orders to a particular date range.

Here are the results after running this query.

What went wrong? (Answered on next page…)

I am going to try to clear up a couple of those questions now. First here is a summary of everything I need to know about shortcuts:

• Shortcut joins do not provide an alternate path.
• Shortcut joins do provide a shorter path.

By the end of this post I hope that the reader will understand the difference between those two statements. There are two rules for how and when a shortcut will be applied:

• A shortcut join will only be used if it eliminates tables from the query.
• A shortcut join is applied after the SQL has been generated (meaning after a context selection has been made, if required).

I will talk about these two items as well. But first, how do I create a shortcut join in my universe?

Creating a Shortcut Join

Creating a shortcut join is quite simple. All I have to do is double-click the particular join and mark the shortcut attribute.

A shortcut join will appear in my universe structure as a dotted rather than a solid line, as shown here.

The process used to create a shortcut join is quite simple. But was it appropriate to convert the join as shown above into a shortcut? Will it be used?

Shortcut Path

The sample shown above is from the Prestige Motors database. There is a direct relationship from the Country table to the Region table, and also from the Region table to the Client table. However there is also a direct relationship from the Country table to the Client table, as the COUNTRY_ID column has been denormalized into the Client record. (If you have never seen this database, a client is a customer.) The question at this point becomes, “Is this a shorter path or an alternate path?”

How do I tell the difference?

I believe the answer is simple. If I get the same result from both join paths then it’s a shortcut. If I get a different answer then it’s an alternate path.

Alternate Path

In the Prestige Motors database the COUNTRY_ID exists in the Showroom table as well as the Client and Region tables. I could create joins like this:

In this case I have a join from Country to Client. I also have a join from Country to Showroom. Because of the relationship with the Sales table I now have a loop in my structure. By changing one of the two Country joins to a shortcut I can avoid the loop, like this:

What has happened here? I have eliminated the loop from my structure and solved that problem, right? Perhaps, but it is the wrong solution. In this case, the shortcut is an alternate path rather than a shorter path. I can tell because (as I mentioned earlier) I will not get the same results from the two queries.

Suppose I want to combine Country, Showroom, and Sales. The longer path looks like this:

When I execute a query using this set of joins, I will get a list of showrooms that have had sales to customers, and I will get the country where the customer is located. Next I will run a query against this shorter path:

When I execute a query using this path, I will get a completely different result set. I will get a list of showrooms, their sales, and the country where they are located. The customer tables never come into play, so I get a completely different result set. This is my indication that I do not have a proper shortcut join definition.

And interestingly enough, Web Intelligence will never use the shortcut for the query outlined above! It is smart enough to realize that the shortcut is not properly defined as it does not truly present a shorter path. It is an alternate path, and that’s not a valid application of a shortcut.

As a brief aside: How should this particular loop be resolved? Obviously a shortcut is not the answer.