The IntervalMatch prefix is used to create a table matching discrete numeric values to one or more numeric intervals, and optionally matching the values of one or several additional keys.
IntervalMatch (matchfield)(loadstatement | selectstatement )
IntervalMatch (matchfield,keyfield1 [ , keyfield2, ... keyfield5 ] ) (loadstatement | selectstatement )
The IntervalMatch prefix must be placed before a LOAD or a SELECT statement that loads the intervals. The field containing the discrete data points (Time in the example below) and additional keys must already have been loaded into QlikView before the statement with the IntervalMatch prefix. The prefix does not by itself read this field from the database table. The prefix transforms the loaded table of intervals and keys to a table that contains an additional column: the discrete numeric data points. It also expands the number of records so that the new table has one record per possible combination of discrete data point, interval and value of the key field(s).
The intervals may be overlapping and the discrete values will be linked to all matching intervals.
The extended IntervalMatch prefix is used to create a table matching discrete numeric values to one or more numeric intervals, while at the same time matching the values of one or several additional keys. This is a very powerful and flexible feature that can be used for linking transactions with dimensions that are changing over time: Slowly changing dimensions.
In order to avoid undefined interval limits being disregarded, it may be necessary to allow NULL values to map to other fields that constitute the lower or upper limits to the interval. This can be handled by the NullAsValue statement or by an explicit test that replaces NULL values with a numeric value well before or after any of the discrete numeric data points.
|matchfield||The field containing the discrete numeric values to be linked to intervals.|
|keyfield||Fields that contain the additional attributes that are to be matched in the transformation.|
|loadstatement or selectstatement||Must result in a table, where the first field contains the lower limit of each interval, the second field contains the upper limit of each interval, and in the case of using key matching, the third and any subsequent fields contain the keyfield(s) present in the IntervalMatch statement. The intervals are always closed, i.e. the end points are included in the interval. Non-numeric limits render the interval to be disregarded (undefined).|
In the two tables below, the first one defines the start and end times for the production of different orders. The second one lists a number of discrete events. By means of the IntervalMatch prefix it is possible to logically connect the two tables in order to find out e.g. which orders were affected by disturbances and which orders were processed by which shifts.
LOAD * Inline [
Time, Event, Comment
00:00, 0, Start of shift 1
01:18, 1, Line stop
02:23, 2, Line restart 50%
04:15, 3, Line speed 100%
08:00, 4, Start of shift 2
11:43, 5, End of production
LOAD * INLINE [
Start, End, Order
01:00, 03:35, A
02:30, 07:58, B
03:04, 10:27, C
07:23, 11:43, D
//Link the field Time to the time intervals defined by the fields Start and End.
Inner Join IntervalMatch ( Time )
LOAD Start, End
The table OrderLog contains now an additional column: Time. The number of records is also expanded.
Example 2: (using keyfield)
Same example than above, adding ProductionLine as a key field.
A table box could now be created as below:
|0||Start of shift 1||-||-||-|
|P2||01:00||0||Start of shift 1||-||-||-|
|P1||02:23||2||Line restart 50%||A||01:00||03:35|
|P1||04:15||3||Line speed 100%||B||02:30||07:58|
|P1||04:15||3||Line speed 100%||C||03:04||10:27|
|P1||08:00||4||Start of shift 2||C||03:04||10:27|
|P2||09:00||4||Start of shift 2||D||07:23||11:43|
|P1||11:43||5||End of production||-||-||-|
|P2||11:43||5||End of production||D||07:23||11:43|