Examples - Custom Dimension Connections

This page provides some examples on how the Custom Dimension Connections functionality can be used.

Contents

• Example 1
• Example 2
• Example 3

Example 1

This example just shows the basic steps how to create a dimension connection to a Fact (Information Source).

Assume that we want to connect the customer dimension DIM_CUSTOMER to GL Balances, FACT_GL_BALANCE. The assumption is that code part H is by the customer used to represent customers in most of the used companies.

First the header is created a saved.

Next the Fact connection is defined in the connections section.

The Fact (Information Source) identity is defined and also the order it should be displayed in the Information Source navigator. The Exact Join checkbox is not selected since the code part H might not have a value for all GL balances. Then the connection info is saved.

The RMB Suggest Join Info is used to get a suggested join in the join section.

Use LoV to get the possible Fact Item IDs.

Next the connection row is approved.

And finally the complete definition for DIM_CUSTOMER is Approved and Published on the header level.

If the Publish action is successful, a message will be prompted to the user.

Looking in the Information Source navigator it is now possible to see that FACT_GL_BALANCE has been customized and that there is a customized dimension.

Example 2

In the following example the idea is to do the following:

• The connection of dimension DIM_SUPPLIER to Information Source FACT_CUSTOMER_ORDER_LINE should be modified
• An new inherited dimension named DIM_SUPPLIER2, inherited from DIM_SUPPLIER, is to be created and connected to FACT_CUSTOMER_ORDER_LINE

The dimension DIM_SUPPLIER is already connected to FACT_CUSTOMER_ORDER_LINE.

The connection part has two rows, both for FACT_CUSTOMER_ORDER_LINE:

• On the first row the checkbox Replace Existing Dimension Connection has been selected, since we want to modify the dimension-fact join.
• The second row defines that a new inherited dimension should be created from DIM_SUPPLIER. It is necessary to supply the new identity in New Inherited Dimension ID, a display name for the new dimension and an alias that is used when building a SQL statement that joins the new dimension and FACT_CUSTOMER_ORDER_LINE.

The connection lines then have to be approved and then Approve and Publish is performed on the header level.

Publish will modify how DIM_SUPPLIER is connected to FACT_CUSTOMER_ORDER_LINE and there will also be a new inherited dimension with identity DIM_SUPPLIER2 created and connected to FACT_CUSTOMER_ORDER_LINE.

Looking in the Information Source navigator it is now possible to see that FACT_CUSTOMER_ORDER_LINE has been customized and that dimensions DIM_SUPPLIER and SIM_SUPPLIER2 are connected and marked as customized.

Example 3

In the following example the purpose is to use the general time dimension DIM_BI_TIME to create one new inherited time dimension and then to connect the inherited dimension to two different Facts (Information Sources).

A new record is created and the general time dimension DIM_BI_TIME is specified and then save is performed.

We want to add a new time dimension named DIM_MVT_DATE to the Facts (Information Sources) FACT_CUSTOMER_ORDER_DELIV and FACT_CUSTOMER_ORDER_LINE. In the connections section two rows are created.

• Exact Join is selected since the target date in the Fact has a value for all transactions.
• In column New Inherited Dimension ID the name DIM_MVT_DATE is defined, the Display Name of Inherited Dimension is set to "Incremental MVT Date" and the Dimension Alias is set to MVT_DATE.
• The column Display Order for Dimension has not been defined, meaning that the dimensions will end up at the top of the Information Source navigator in e.g. in IFS Business Reporter.

Join section

• A join has to be defined for each connection
• The join is for both Facts done by connecting a Fact attribute named <Fact>.MVT_YEAR with the dimension item DIM_BI_TIME.YEAR.
  • The time dimension has the date as the key but in this case the non key attribute YEAR has been used in the connection. Not using the natural keys is possible but should normally be avoided unless there is a special purpose with the connection join.
  • The two Facts (Information Sources) have a timestamp attribute <.Fact>.MVT_CREATED_DT that refers to a column where the incremental timestamp is defined. There is no year attribute in the Facts related to MVT_CREATED_DT. This can however be handled by adding a custom attribute to the two Facts that extracts the year part from MVT_CREATED_DT. So this means that new custom attributes have to created first.
    
    An expression has been used when defining the relation needed to add the year attribute.
    
    The attribute MVT_DATE added as a custom attribute to FACT_CUSTOMER_ORDER_LINE (and of course also to FACT_CUSTOMER_ORDER_DELIV).

The connection lines then have to be approved and then Approve and Publish is performed on the header level.

Publish will create a new inherited time dimension named DIM_MVT_DATE, based on the dimension DIM_BI_TIME, and then connect it to the Facts (Information Sources) FACT_CUSTOMER_ORDER_DELIV and FACT_CUSTOMER_ORDER_LINE.

Looking in the Information Source navigator it is now possible to see that FACT_CUSTOMER_ORDER_DELIV and FACT_CUSTOMER_ORDER_LINE have been customized and that dimension DIM_MVT_DATE has been connected and the dimension is marked as customized.