Resolving Loop Traps

Style Studio alerts you to loop traps by highlighting the implicated joins in bright red. There are various approaches to resolving loop traps, described below.

Weak join designates a relationship to be used only when no other join route is available. Right-click on a relation line and select 'Weak Join' from the menu to mark a join as such. Weak joins appear as dotted lines.

Manually aliasing a table is another tool in resolving traps. Select a table and right-click to select the 'Create Alias' option. Once the alias is created, it can be used as a totally independent copy of the original table.

Auto aliasing provides a new level of flexibility. Creating alias tables manually is very simple and straightforward when the aliased table stands alone. However if a table has outgoing relationship links, aliasing the table may mandate further aliasing of other tables. The auto-aliasing feature significantly simplifies this process.

Example: Aliasing a Table  >>

Consider a simple example in which a table called 'PRODUCTS' needs to be aliased in order to resolve a cycle. Follow the steps below:

1. Create a new physical view, as shown below.

 

The joins highlighted in red indicate the presence of a cycle. You can resolve the cycle by auto-aliasing the 'PRODUCTS' table, as the following steps illustrate.

2. Right-click on the title of the 'PRODUCTS' table and select 'Auto-alias' from the context menu. This opens the 'Auto-alias' dialog box.

3. In the 'Auto-alias' dialog box, check the 'Enable Auto Aliasing' box. The dialog box lists all of the joins from the adjacent tables in the diagram.

4. In the 'Incoming Joins' panel, select the boxes next to the 'ORDER_DETAILS' and 'CUSTOMERS' tables.

This designates the 'ORDER_DETAILS' and 'CUSTOMERS tables as providing the “incoming” joins to the 'PRODUCTS' table. When the 'PRODUCTS' table is auto-aliased, two copies of the table will be created. One copy corresponds to the incoming join from the 'ORDER_DETAILS' table, and the other copy corre­sponds to the incoming join from the 'CUSTOMERS'. By splitting the 'PRODUCTS' table into two aliases, the join cycle is elimi­nated. (Note, however, that if only the 'PRODUCTS' table is aliased, the cycle will simply reappear on the 'CATEGORIES' table. This is why in the succeeding steps, you will specify the 'Keep Outgoing Links' option.)

5. In the 'Table Alias' field for the 'ORDER_DETAILS' table, enter “Order Products”.

6. Select 'Keep Outgoing Links' for the 'ORDER_DETAILS' table, and enter “Order” as the 'Table Prefix'. This will cause the downstream 'CATEGORIES' table to be aliased for the 'ORDER_DETAILS' join path as well.

7. In the 'Table Alias' field for the 'CUSTOMERS' table, enter “Customer Products”.

8. Select 'Keep Outgoing Links' for the 'CUSTOMERS' table, and enter “Customer” as the 'Table Prefix'. This will cause the downstream 'CATEGORIES' table to be aliased for the 'CUSTOMERS' join path as well.

 

Note: In the diagram, an italicized table name indicates that the table is aliased. To view the full effect of aliasing, however, you must preview the physical view (below).

9. Click 'OK' to complete the auto-alias procedure. Note the italics on the 'PRODUCTS' table, indicating aliasing.

 

10. Click the 'Preview' button in the Style Studio toolbar. This presents the structure of the physical view as it will actually be used for generating queries.

 

Observe that both the 'PRODUCTS' table and the 'CATEGO­RIES' table have been aliased, and that this has entirely eliminated the cycle.

The new tables that appear in the preview (Customer Products, Order Products, Customer_SA.CATEGORIES, Order_SA.CATEGORIES) have been introduced into the physical view by aliasing. They will appear among the tables available for constructing the Logical Model.

With the elimination of the cycle, there is no remaining ambiguity in the join structure; any set of fields that one selects from the various tables has a single unique join path. However, when you design the logical model, you must still be careful when selecting fields to expose as model attributes. For example, 'Customer Produsts.PRODUCT_NAME' will in general return different results than 'Order Produsts.PRODUCT_NAME' when these fields are used in a data model. (This is because, even though these two tables are identical aliases, they are joined to the other tables in different ways, which results in different data selection.)

 

See Also

Identifying Query Traps, for information about loop traps and other traps.

<< Overriding Automatic Cardinality Detection © 1996-2013 InetSoft Technology Corporation (v11.4) 4.3.2 Navigating a Physical View >>