OBIEE Warning: Unused Physical Tables

If you’ve ever developed an OBIEE Repository (RPD) in which you’ve configured a multi-table Logical Table Source (LTS), you’ve likely been plagued by the following warning:

There are physical tables mapped in Logical Table Source “Logical Table Source Name” that are not used in any column mappings or expressions.

If you’re a Type-A OBIEE Developer like myself, such warnings are maddening. To me, nothing is more satisfying than a warning-free RPD.

Luckily, these unused physical table warnings are quite easy to resolve.

What does this warning mean?

Before revealing how to resolve this warning, let’s focus on what this warning means. In essence, the warning boils down to nothing more than OBIEE telling you that you have conveyed that you wanted to use a Physical Table, but don’t actually seem to be using it.

To provide further detail:

  • By pulling a Physical Table into a Logical Table Source, you are telling OBIEE you intend to use that table
  • If you do not later use that Physical Table in any of the column mappings — whether directly or in an expression — in the Logical Table related to your Logical Table Source, OBIEE infers that you haven’t used the table and throws the warning

What happens if I ignore it?

So what happens if you ignore this warning and leave your configuration as is? Absolutely nothing.

This warning is just that, a warning. Think of it as a friendly reminder that OBIEE has your back — it’s not going to let you set an intention and not follow through without making sure it gives you some grief about it. If you ignore it, your RPD will still save and function as you designed it with no ill-effects.

(But hey, warnings are messy and irritating, so don’t ignore them, resolve them!)

How can I resolve it?

Luckily, this warning can easily be resolved in one of two ways.

  1. Map a Logical Column in the Logical Table with the affected Logical Table Source to a Physical Column from your unused Physical Table
  2. Tell the OBIEE RPD you wish to allow unmapped tables

If you’ve truly forgotten to use your Physical Table, go for Option 1 and thank the Consistency Check Manager for its diligent review of your work.

More commonly in this situation is that your unused Physical Table has been mapped into your Logical Table Source to provide a join path between two or more tables. As OBIEE developers, we often do this to facilitate a direct logical relationship where a direct physical one does not exist.

Multi-Table Logical Table Source to provide join path to facilitate a direct logical relationship.

In this situation, either Option 1 or Option 2 can be used to resolve the warning.

Key from “Farthest Out” Table Mapped to Logical Column on Logical Table with affected Logical Table Source.

If going with Option 1 in this situation, you don’t have to map a column from all of your physical sources to resolve the warning; rather, if you map a column from the “farthest out” join, or the last table in your join path, your warning will magically disappear. When using this option, my favorite strategy is to pull the Key value from my “farthest out” join into my Table. Any column from your “farthest out” join will do, however, as you don’t actually want and/or need the column; the column is being included solely to resolve your warnings.

Option 2 resolves this warning by toggling a simple option within your affected Logical Table Source. Within the General tab of your Logical Table Source Properties, check the “Allow Unmapped Tables” option.

“Allow Unmapped Tables” option configured within Logical Table Source properties.

Voilà! The warning is gone.

Of the two options, I personally prefer and recommend Option 2. With Option 2, the warning can be resolved in a single step and the Logical Table remains uncluttered by unneeded columns. However, either option will work, so the Option 1 vs. Option 2 decision is up to you.

Most important to this whole process is that once you’ve chosen an option, you implement it as a standard and use the same option across your RPD. The only thing a Type-A OBIEE developer hates more than warnings is inconsistency.