No. We use contexts and aliases to resolve loops.
Shortcut joins are used to shorten join paths.
In a data warehouse star schema, you typically wouldn't use them. The times when you would use them is if the design has a snowflaked schema - this is where an extra layer of dimension table is added. For example, say you sell lots of products. Products can belong to a product group, which can belong to a product category, so a cricket ball would belong to the Cricket group, which would belong to the Sporting Goods category.
You may simply have a Product Dim table joined to your sales fact table:
PD -< SF
However, given that you have lots of products, you will be repating product category and product group description many times. What you could then do is create a product group table and a product category table to create a hierarchy of tables:
PC -< PG -< PD -< SF
You would use surrogate keys to join the tables together, where Sales Fact and Product Dim would contain all three surrogate keys, product group would contain the product group and product category keys and product category would have a product category key. Well done on getting this far, but where do the shortcut joins come in? Well, say you want to report on sales at a group or category level but didn't want to report on products in that report (you might have a report linked to a drilldown on products for exception reporting). What you'd do is join Product Group to Sales Fact on product group key and Product Category to Sales Fact on product category key. Both of these joins would be shortcut joins because you will use them to shorten the join path. What they actually do is avoid loops rather than resolve them.
So, if you just wanted to report on sales by product group, your query would utilise the shortcut join and avoid the product dimension table.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.