INDEX_ORDER
Applies to: CELONIS 4.6 CELONIS 4.7
Description
INDEX_ORDER
returns a column with INTEGER indices, starting from 1
. The indices indicate the order of the rows, if the input table values had been sorted.
The INDEX_ORDER
function creates an INTEGER index column. The index column contains a unique INTEGER value for every row of a required reference input column. The values of the indices are based on the order of the values in the input column.
INDEX_ORDER
can be applied to INT, FLOAT, DATE or STRING columns. The result is a column of type INTEGER .
Syntax
INDEX_ORDER returns integer indices based on the given sorting and partition. In this preferred syntax, ORDER BY and PARTITION BY can be used to define the sorting and partitioning that should be used (Since: CELONIS 4.7):
INDEX_ORDER ( column [, ORDER BY ( sort_column [sorting], ... )] [, PARTITION BY ( partition_column, ... )] )
column: The source column on which the index column will be based.
sort_column: Optional sorting column to specify an
sorting: Each of these columns can have an optional tag specifying the ordering of the column. Default is ascending:
ASC: Ascending order
DESC: Descending order
partition_column: Optional partition column to specify groups in which INDEX_ORDER should operate.
Ordering
One or more columns can be given to specify an ordering. This tells the INDEX_ORDER function what the preceding element actually is. Optionally every column can be tagged as ascending or descending. Equal input values are always given distinct output indices. The indices for a given range of equal input values are incremented starting from the topmost value of this range of the input column:
Partitioning
The partition columns specify groups. The INDEX_ORDER function operates independently within every group. This means when an ordering is given it is applied within every group.
Null handling
Null values are ignored, meaning that the null value rows stay null in the result column and will count as an index order value.
Deprecated Behavior
As an alternative to the recommended syntax, the INDEX_ORDER function can be called as follows: [ DEPRECATED SINCE 4.7 ].
INDEX_ORDER ( <column> [, <sorting> ] [, GROUP( <group_column>, ... ) ] )
column: The source column on which the index column will be based.
sorting: An optional sorting of the indices, which defaults to ascending.
ASC: Ascending index order values.
DESC: Descending index order values.
grouping: Optional grouping columns. Independent index order ranges will be created for each group, all starting from 1.
The values of the indices are based on the order of the values in the input column, meaning that the input column is automatically sorted.
[3] Create an index order for an integer input column. |
[4] Create an index order for a date input column. |
[5] Create an index order for an input column in ascending order. |
[6] Create an index order with a joined case table.
|
[7] Create an index order on an aggregation function.
|
[8] Create an index order for a date input column with equal values. |
[9] Create an index order for a string input column with a function. |
[10] Create an descending index order for an integer input column that includes NULL values. |
[11] Create an index order for each partition.
|
[12] Create an index order for each group, as given by more columns.
|
Advanced Example: Case Coverage
The INDEX_ORDER
function allows to calculate KPIs, that require sorting. One example is calculating how many cases are covered by the N most common process variants.
[13] Given two cities, we want to find out how many cases are covered by the two most common variants for each city. Let us first look at the process variants.
|
[14] In this step we add:
|
[15] Finally we want to report the fraction of cases which are covered by the two most common process variants, per city. To calculate the fraction, we use the PU_COUNT function to count cases per city:
|