I am working on a modular modelling architecture in Cognos Analytics using multiple data modules.

The structure is roughly as follows:

Data Warehouse
        │
        │
Fact modules 
Dimension modules 
        │
        │
Analysis modules (facts joined with dimensions)
        │
        │
Enterprise / Uber module
        │
        │
Dashboards

In the analysis modules I am able to create lookup references to the time dimension and use them to generate relative time measures (e.g. YTD, MTD, Today, Yesterday). This works as expected.

However, if I want to use the analysis module in an enterprise/uber module, I need to convert the dimensions to shortcuts, according to the reference in the bottom (to have a conformed dimension).

As a result, the relative time logic (lookup reference + generated measures) cannot be edited or extended in the analysis module.

So my questions are:

1. How do people typically handle relative time in a multi-module architecture like this?
2. Is there a recommended way to design an analysis module, that can later be used in an enterprise reporting module that supports relative time calculations and conformed dimensions?

For context, the goal of the enterprise module is simply to provide a unified model for report and dashboard authors while keeping modelling logic reusable in the lower layers.

Any guidance or best practices would be appreciated.

Ref enterprise-model:
Multi-modeler, multi-module techniques

Multi-modeler, multi-module techniques data modules complex modelling projects modularity

Hi Davy,

The description that you have given reflects the current support. At this time the support via shortcuts/aliases that reference a table with relative time in an underlying module isn't supported. The idea behind it was to keep things relatively flat. However keeping things flat eliminate the idea of the uber module. 
This would require an enhancement to the product.

Hi Henk,

Thank you for confirming and clarifying this. It helps a lot to understand that the behaviour I was seeing is indeed a current product limitation.

After some additional testing, it seems that a workable approach is to have two time dimensions: one used as a shortcut for conformity, and the other used as a reference to implement the relative time measures. In my tests, this allows the relative time measures to continue working while still enabling reuse of the analysis modules.

So while relative time through shortcuts to an underlying module is not supported directly, structuring the model this way appears to be a practical workaround.

Thanks again for the clarification!

Best regards,
Davy

Hi Davy,

You modular modeling architecture approach sounds interesting! Is the intent to create re-useable components that can be used in different Analysis Modules? We have a warehouse with 15+ stars and hundreds of conformed dimensions. We have modeled these in FM but the future is clearly data modules and -- if I'm interpreting what you are doing correctly -- the agility of this approach would be very appealing to use. I would love to learn more if you are willing to share? (Apologies if this is taking the post in a different direction).

I just read the referenced post from @IAN HENDERSON which provides the details I was looking for! I definitely need to give this a try. 

Cheers,

Mike

------------------------------
Mike A
------------------------------

Hi,

Yes, the main idea is exactly that - to create reusable components that can be combined into different analysis modules depending on the use case. The goal is to keep the lower layers modular and reusable, while still allowing us to build subject-specific analysis models on top of them.

Great to hear that the post from Ian Henderson was helpful. 

And of course - feel free to reach out anytime if you want to discuss this further. Whether it's about this topic or anything else related to Cognos or modeling, I'm always happy to chat. I think it's really important that we as a community help each other move forward and share ideas, so I'd definitely be open to an informal discussion.

Cheers,
Davy

I think the issue is that generated measures don't always behave like normal cube values in relative time logic.

Instead of referencing the generated measure directly, try using the base measure and apply the time shift there (like previous period). That usually works more reliably.

Also depends a bit on where you're doing this (PAW view vs MDX vs rule).