The first topic that I covered in my “Tales From a Universe Ninja” presentation at the 2007 Insight Americas conference was Index Awareness. I have to admit, this would probably not have been my first choice for a topic. I covered it on request from a member of the Universe Designer product team. As I went through this feature I found that much of what I remembered was still true even in XI R2. But I also found that in the right environment this feature could really help.

If you have downloaded a copy of my presentation then I am going to cover slides 10 through 16 in this blog post. Future blog posts will cover the rest of the material from the presentation. I believe that this feature was introduced in version 6.5 which means you must be at least at that version to be able to consider using it.

This feature is defined in the Universe Designer help file as follows:

Object keys allow Universe Designer to generate more efficient SQL by filtering on primary key values and eliminating unnecessary joins.

That’s great, but what does it mean?

Setting Up Index Awareness

When a designer builds an object there is a new tab available on the object properties screen called Keys as shown here:

This tab is where you can define the primary and foreign keys for the table in question. In this case, I am showing keys for the Country table from the Island Resorts Marketing universe. The table is referenced via an alias in order to break up a loop, and the keys are identified here:

If a table has foreign keys in more than one place that is not a problem. The designer can include as many key values as are appropriate. Here is another example from the Island Resorts universe, showing the Service table being related to two “fact” tables; one is for reservations and the other is for invoices.

Once the keys are defined, what does it do?

Index Awareness In Action

One of the main drawbacks to this feature is that it does not always work. There are certain things that have to be done in order to reap the benefits. The easiest way to start is to say that in order to get the key benefits the report user has to pick from a list of values. If the user enters a value manually, it does not work. If the user respond to a prompt, it does not work. (More on the prompt thing in a later post.)

So here is a screen shot showing a user selecting the Resort name (which has been defined as Index Aware) on a query panel:

And here is the SQL code generated by the query shown above:

SELECT
max( RESORT.resort ),
sum(INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE)
FROM RESORT, INVOICE_LINE, SERVICE, SERVICE_LINE
WHERE ( RESORT.RESORT_ID=SERVICE_LINE.RESORT_ID )
AND ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )
AND ( SERVICE.SERVICE_ID=INVOICE_LINE.SERVICE_ID )
AND RESORT.RESORT_ID = 2
GROUP BY
RESORT.RESORT_ID

The important line is this one:

AND RESORT.RESORT_ID = 2

Without the index keys the condition would have been based off of the resort name instead of the resort key. And it gets even better.

If the Resort result object is removed from the query then the query panel would look like this:

And here is what the SQL code looks like:

SELECT
sum(INVOICE_LINE.DAYS * INVOICE_LINE.NB_GUESTS * SERVICE.PRICE)
FROM INVOICE_LINE, SERVICE, SERVICE_LINE
WHERE ( SERVICE_LINE.SL_ID=SERVICE.SL_ID )
AND ( SERVICE.SERVICE_ID=INVOICE_LINE.SERVICE_ID )
AND SERVICE_LINE.RESORT_ID = 2

What has changed? Two very important things. First, the RESORT table has been removed from the query altogether. Second, the condition has switched to the foreign key defined in the SERVICE_LINE table instead. The query is much more efficient.

When I first read about this feature one of the touted features was a “Fact Only” query. That is certainly possible. I created a query that uses three conditions, all of them with Index Awareness defined, and the following SQL was generated:

SELECT
sum(SHOP_FACTS.Amount_sold)
FROM
SHOP_FACTS
WHERE
(SHOP_FACTS.WEEK_KEY = 233
AND
SHOP_FACTS.ARTICLE_CODE = 177264
AND
SHOP_FACTS.SHOP_CODE = 203)

This is really efficient SQL! However, the results are not very interesting. Without the key values as results the fact table is the only table referenced in the SQL code. But without those key values as output, the resulting report is not very interesting. (Please see slide 16 for more details, if you are interested.)

Summary

In this post I defined what Index Awareness was, showed how to set it up, and showed how it can help create more efficient SQL. The next post will start to talk about some of the challenges that you might encounter when using this feature.

Technical Notes

The universes used in my presentation were based on Island Resorts Marketing and eFashion. Both databases were converted to Oracle 10g in order to use some of the more advanced features that do not work with Microsoft Access. These universes and databases are not available for download at this time but I plan to make them available at some point in the future.