Time-Dependent Hierarchies

Use

In a hierarchy that is not time dependent, the characteristic values are always the same.

If you want to create views of a hierarchy that are valid for a specific time period, you need to create the entire hierarchy as time dependent.

If you want to model relationships that change time-dependently, you need to create the hierarchy structure time-dependently.

Functions

In InfoObject maintenance, you can set whether and in which ways a hierarchy is time dependent. You can choose from the following:

whether the hierarchy is not time dependent (Hierarchy Not Time-Dependent). This is set by default.

whether the entire hierarchy is time dependent (Entire Hierarchy Time-Dependent).

whether individual node relationships are time dependent (Hierarchy Structure Time-Dependent)

Whether a temporal hierarchy join is used with time-dependent hierarchy structures (Use Temporal Hierarchy Join)

Entire Hierarchy is Time-Dependent

You can either load time-dependent hierarchies (seeLoading Time-Dependent Hierarchies) or create them in the BW system (see Creating a Hierarchy). When you create a time-dependent hierarchy, you have to enter a validity interval (Valid To and Valid From fields).

If an entire hierarchy is time dependent, the system creates hierarchy versions that are valid for separate intervals. The system automatically uses the current valid version in this case. The hierarchy valid in each case can be uniquely identified by its technical name and the From-To Date.

In the InfoObject tree of the Data Warehousing Workbench, all time-dependent hierarchies under the associated InfoObject are displayed with the corresponding To Date, for example Time-Dependent Hierarchy 05/31/2000.

In reporting, the system returns the valid hierarchy when a query is executed using the query key date.

Tip

When restructuring the areas of your enterprise, you can create time-dependent versions of a hierarchy for the Main Area InfoObject. This allows you to compare the restructuring over different time periods in a query.

Time-dependent hierarchy 01/01/1999 - 05/31/1999	Time-dependent hierarchy 06/01/1999 - 12/31/1999
Main Area NORTH	Main Area NORTH
Area 1
Area 2	Area 2
Main Area SOUTH	Main Area SOUTH
	Area 1
Area 3	Area 3
Area 4	Area 4

Note

In Reporting, you can work in the individual columns of the report structure with fixed date values. You may want to do this to compare Main Area North in the Time-Dependent Hierarchy 05/31/2000 with Main Area North in the Time-Dependent Hierarchy 06/01/2000 (simulation).

Time-Dependent Hierarchy Structures

You can either load time-dependent hierarchies (seeLoading Time-Dependent Hierarchies) or create them in the BW system (see Creating a Hierarchy).

In hierarchy maintenance, you can determine a valid time interval for each hierarchy node (Valid To and Valid From fields).

In reporting, a hierarchy with time-dependent hierarchy structures is created either for the current key date or for the key date defined for the query. In addition, you can evaluate a hierarchy historically using the temporal hierarchy join.

Tip

You can assign an employee to different cost centers at different times within the context of a restructuring.

In the context menu of a hierarchy, choose Display Hierarchy to access the hierarchy display: Each node and leaf has been given a date symbol.Hierarchy nodes that are assigned to different places in the hierarchy structure, depending on the time, are displayed more than once. By double clicking on a hierarchy node, you can display the associated validity period for the node relation.

Tip

In the following example, you can double click on the Jones leaf to see that the worker Jones was assigned to region USA between 01/01/1999 and 05/31/1999 and Puerto Rico from 06/01/1999 to 12/31/1999.

In order to use a hierarchy with a time-dependent hierarchy structure in reporting, you require the following settings in the BEx Query Designer:

If you want to evaluate a hierarchy with a time-dependent hierarchy structure for a fixed key date, enter the key date in query definition.
If you want to evaluate a hierarchy with a time-dependent hierarchy structure historically, for a key date that is to be derived from the data, choose the temporal hierarchy join option and specify the derivation type for the key date.

For a more detailed description of the functions and differences between the two evaluation views, seeTime-Dependent Hierarchy Structures in the Query.

In maintenance of the key date derivation type (RSTHJTMAINT) determine the rule you want to use to determine the key date from the data. In this way you determine the time characteristic and way in which the key date is to be derived.

First determine the time characteristic.
If you choose a Basic Time Characteristic as a time characteristic (for example, 0CALDAY, 0CALMONTH, 0FISCPER), you can use a key date derivation type of this kind for all InfoProviders that contain exactly one time characteristic which references the selected basic time characteristic. If there are several time characteristics in an InfoProvider that reference the basic time characteristic, you have to either determine the time characteristic more specifically or select a particular time characteristic from a particular InfoSet (Time Characteristic from InfoSet).
Determine how you want the key date to be derived from the time characteristic.
The following derivation types are available:
- First day of the period
- Last day of the period
- Delay by number of days (you specify this in the Delay by Days field). In this case, the key date is calculated from the first day in the period plus the number of days specified minus 1. If the key date does not fall within the period, the last day of the period is used.
  Tip
  Key date derivation type with (basic characteristic = 0CALMONTH, derivation type = "first day of period"):
  - For January 2005 the key date is calculated as 1/1/2005.
  - For February 2005 the key date is calculated as 2/1/2005.
  Key date derivation with (basic characteristic = 0FISCPER, derivation type = "delay by number of days" and "delay " = 29):
  - For K4/01.2005 the key date is calculated as 1/29/2005.
  - For K4/02.2005 the key date is calculated as 2/28/2005.
  - For K4/03.2005 the key date is calculated as 3/29/2005.
    Caution
    Note that the way in which you determine the key date derivation type affects performance. The number of data records that the OLAP processor reads corresponds to the level of detail on which the time characteristic and the leaf level lie. For this reason, choose the time characteristic as approximately as possible in order to keep the hierarchy small.
    
    Tip
    A small hierarchy has 100 leaves. For a period of 12 months, the OLAP Processor reads 1200 data records at month level. At day level, it reads 36500 data records.