Cognos Analytics

Working with aliases and shortcuts in multiple linked modules

Using aliases or shortcuts in a destination module rather than references can make your modules more modular, with a cleaner, clearer presentation as only the aliases or shortcuts need to be in the destination module.

You can convert your existing references to aliases or shortcuts and, because the aliases or shortcuts point back to their targets in the target module, you do not need to include the baggage of all tables used in views used as references in the destination module.

Aliases and shortcuts point to their target object and automatically pick up changes made to them.  They also can be extended with new calculations, data groups, and selectable (i.e. optional) query subject filters. Aliases can also be augmented with embedded filters.

More details about aliases and shortcuts are available here:
Aliases and shortcuts (ibm.com)
https://community.ibm.com/community/user/businessanalytics/blogs/ian-henderson1/2022/09/04/aliases-and-shortcuts

References versus aliases

When you come to decide whether to convert references to aliases there are several things to consider.

References cannot be modelled in the destination module, as references are read-only.  Changes must be done in the target module. Those changes continue to be picked up in the destination module. References can come with their baggage of source tables which also need to be present in the destination module.

Converting a reference to alias means you can model the alias in the destination module as well as pick up changes from the target module. It also means that the destination module is more modular; it does not need the baggage which references need and thus is cleaner, clearer, and simpler.

Multiple module application use case examples

For a very long time if you needed to model multiple modules you needed to work with references. Now, aliases and shortcuts give you more flexibility in how you go about this.

One existing problem with working with multiple modules using references is that if you needed to use a view from another module you needed to include all the query subjects used in that view as well.

Here is an illustration of a module which is linked to several other modules.  In this example, the source modules each consist of a dimension and its source tables.  There is also a module which contains the fact tables. Multiple modellers could work on the project, each modelling a dimension, which would then be incorporated into a module which would serve as the basis for what is exposed to report and dashboard users. The relationships between the dimensions and their associated facts would be modelled in this module.

If it was modelled with references it would look like this.  You will note the presence of the source objects for the dimension.

Here is an example where references need their baggage.  You will note the validation errors and the error in the data grid.

Here is that reference after I converted it to an alias.  Once it was converted everything works.

If converted those references to aliases, it would look like this.  You would only need the dimension and fact aliases in the module.

  
Another stumbling block would be if you needed to make changes in the source module.  It can be difficult to carry those changes to the destination module. Changes to query subjects themselves would seamlessly synchronize, which is good, but additions to the module, such as new query subjects or new relationships, would be difficult to bring into the destination module.

For example, assume that you added a query subject to a source module and you created a relationship between it and a query subject which already existed in the source module and, as a reference, in the destination module. Dragging the new query subject into the destination module would be accomplished but the new relationship would not be added. 

One workaround would be to drag the entire source module into the destination module again.  This is not an unimpeachably elegant method.

With the introduction of shortcuts and aliases there are other methods.  One would be the conversion of the referenced objects into shortcuts. If you need to create relationships between those objects and other objects in the referencing module you should convert the objects into aliases.  By being converted to a shortcut or alias the object now will point back to the object in the referenced module and will pick up the relationship there, removing the need for the presence of the relationship in the referencing module.

Here is an example of this situation. 

This module has been simplified for illustrative purposes.

This source module originally has a dimension and a fact, with a relationship between them. It looks like this:

It is brought into another module, and it looks like this:

A new query subject is created in the source module and a relationship is created between it and the fact.

In the referencing module the query subject is added.  The relationship does not get added.

An existing technique to deal with this case would be to drag the entire source module into the referencing module, which as I mentioned is not elegant.

If you converted the references to shortcuts they would point to the query subjects in the source module and automatically pick up the relationships between them.

Working with multiple modules

The general pattern for working with referenced modules, regardless whether the referenced objects are references, aliases, or shortcuts, should be that complex interactions between objects in multiple modules should be avoided. 

Modular modelling, such as modelling one dimension in each module and bringing aliases to the dimensions into the common, referencing module has been proven to work.  Relationships between the dimensions and facts should be created in the referencing module. If you need multiple objects from a source module, model them as aliases so that they will be able to resolve to their targets.

With that technique, you are only exposing the objects which need to have interactions with objects from other modules.

Bringing multiple objects from a source module and modelling things such as relationships between them in the destination module is probably an anti-pattern.

As a result, aliases and shortcuts make multi-module applications more manageable and more modular.

 Aliases versus shortcuts

If the object is going to have relationships to other objects then it probably ought to be an alias rather than a shortcut.