Tip: The Demantra Local Application replaces Collaborator Workbench. You may see both names in this text.
This chapter describes the Analytical Engine parameters that you can see in Business Modeler and lists their default values, if any.
This chapter covers the following topics:
For each parameter, this chapter indicates which engine variations that parameter can be used with. This chapter also indicates which parameters can be used with nodal tuning. Some of the Promotion Effectiveness (PE) parameters are useful only if your system also includes Promotion Optimization.
Oracle provides two different modes for the Analytical Engine:
In PE mode, the engine is suitable for use with Promotion Effectiveness.
In DP mode, the engine is suitable for use in demand planning applications.
As indicated, most parameters are visible to all users; a few are visible only if you log in as the owner of the component.
See also
"Theoretical Engine Models"
Parameter | Location | Default | Engine Mode* | Details | Tuning |
---|---|---|---|---|---|
A | |||||
add_zero_combos_to_mdp | Engine > Data Manipulation | yes | Both** | Visible only to owner. Specifies the Proport mechanism handles combinations whose historical data consists of zeros. Use one of the following values:
|
|
AllowableExceptions | Engine > Validation | 10 | PE only | Visible only to owner. Specifies the permissible amount of exceptional uplifts, as a percentage of total number of uplifts. The LowerUpliftBound parameter controls the threshold for exceptional uplifts. The engine discards a model (for a given forecast node) in either of two cases:
|
Global setting only |
AllowNegative | Engine > Adjustment | no | Both | This parameter is used by the fit and residuals module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
AnalyzeMdp | Engine > Shell | Full analyze | Both | Visible only to owner. Specifies how to analyze the mdp_matrix table after the Engine Manager divides the forecast tree into tasks. Use one of the following values:
Note: The branch_id field is for internal use only. |
Global setting only |
AverageHorizon | Engine > Data Manipulation | 12 for monthly 52 for weekly 7 for daily | PE only | Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the length of time to be used in calculating the average baseline forecast. This window of time starts at the date given by the StartAverage parameter. For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP" in the Oracle Demantra Implementation Guide. |
Global setting only |
B | |||||
BatchRunMode | Engine > Shell | estimation and forecast run | PE only | Specifies the kind of forecasting to do:
This parameter applies to both batch run and simulation run. |
Global setting only |
BottomCoefficientLevel | Engine > Data Manipulation | 1 | PE only | Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the lowest forecast tree level for which the Analytical Engine will calculate coefficients. Use any forecast tree level between the lowest promotional level and the InfluenceRangeLevel, inclusive. For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP" in the Oracle Demantra Implementation Guide. |
Global setting only |
BulkLoaderBlockSize | Engine > Shell | Both | Oracle only; visible only to owner. Specifies the minimum amount of number of rows that the Analytical Engine loads at one time, when writing to the database. The larger this is, the more quickly the data is loaded, but there is greater risk if the database connection is lost. Use a value between 100 and 100,000. | Global setting only | |
BulkLoaderEnableRecovery | Engine > Shell | Both | Specifies whether Oracle Bulk Loader should perform recovery after a lost database connection. Oracle Bulk Loader is used by the Analytical Engine. | Global setting only | |
C | |||||
CachePath | Null | Both | Specifies the path to the directory into which the Analytical Engine should write its caching files. This can be any of the following:
You should create the directory manually if it does not yet exist. |
Global setting only | |
CalcOptimizationInput | Engine > Data Manipulation | no | PE only | Applies only to Promotion Optimization; parameter is visible only to owner. Specifies whether the Analytical Engine should calculate inputs needed for Promotion Optimization. Use one of the following values:
|
Global setting only |
cannibalism | Engine > Data Manipulation | Both** | Specifies the default values for aggri_98 and aggri_99, which are combination-specific fields. If equal to 0 or 1, the defaults for both fields are 1. If equal to 2, the default for aggri_98 is 1, and the default for aggri_99 is 0. |
Global setting only | |
CannibalizationIgnore | Engine > Data Manipulation | PE only | Controls whether the Analytical Engine will calculate switching effects (cannibalization). You can use this parameter to easily switch off that calculation when needed, for example, when running specific simulations. | Global setting only | |
CollinearityMaxRatio | Engine> Data Manipulation | 5 | Both | Maximum ratio allowed between base or lift elements and total demand. Can be set to any integer greater than one. | Global setting only |
CollinearityTolerance | Engine> Data Manipulation | 1 | Both | Parameter controlling sensitivity of collinearity detection. Default value of 1 detects very strong cases where large values such as 1000 would detect weaker cases. Can be set between 1 and 100,000. | Global setting only |
CollinearityUseRidge | Engine> Data Manipulation | 1 | Both | This flag controls the use of Ridge regression or QR/SVD decomposition in cases of collinearity. Possible values are: • 0 - Ridge Service is not used • 1 - Use Ridge for cases of collinearity. • 2 - Use QR instead SVD for cases of collinearity and NonNegRegr. |
Global setting only |
COMPETITION_ITEM | Engine > Shell | PE only | Visible only to owner. Specifies the level (from the group_tables table) that defines the competitive item (CI) groups. Each node of this level represents a different item group. The CI should be consistent with the item groups (I). Specifically, two items within a given item group must also belong to the same competitive item group. The easiest way to follow this rule is to set the CI equal to an item level that is higher than I and that is within the same hierarchy. A similar rule applies for the locations. Note: You specify the item groups indirectly when you specify the IGL in the forecast tree. see "Configuring the Forecast Tree". |
Global setting only | |
COMPETITION_LOCATION | Engine > Shell | PE only | Visible only to owner. Specifies the level (from the group_tables table) that defines the competitive location (CL) groups. See the notes for COMPETITION_ITEM. |
Global setting only | |
CutTailZeros | Engine > Data Manipulation | yes | Both | Visible only to owner. Specifies how the preprocessing module (of the Analytical Engine) should handle series that start with zero values. Use one of the following values: | Can be tuned by node |
D | |||||
DampPeriod | Engine > General | 0 | Both | This parameter is used by the Bayesian blending module of the Analytical Engine. It specifies the length of periods in which the residuals will receive the same weights. The dampening of weights is done between each successive period. This parameter lets you put greater weight on models that perform better on most recent historical data, as opposed to models that show close fit to the remote history. |
Can be tuned by node |
DampStep | Engine > General | 0 | Both | This parameter is used by the Bayesian blending module of the Analytical Engine. It specifies the rate of weights decay. By setting this parameter to 0 (or 1), you set all weights to be equal to 1 (equal weights). | Can be tuned by node |
def_delta | Engine > Proport | 0.75 | Both** | Specifies the default value for the delta field in the mdp_matrix table. If delta equals null for a given combination, the system uses the value of this parameter instead. All new combinations created through data loading, member management, and/or chaining will have a null value in their delta column, thus indicating that they will also take the default delta value from this parameter. In turn, the delta field is used in the proport calculation as in the following example: P1 = glob_prop * delta + (monthly demand) * (1 - delta) |
Global setting only |
DeleteIsSelfRows | PE only | Specifies whether the Analytical Engine deletes unneeded promotion_data records. Use one of the following values:
A record is considered unneeded if all the following conditions are true: It is flagged as is_self = 0 All lifts (uplift, pre and post effect, and switching effects) equal 0 The condition specified by DeleteIsSelfCondition is true Also see "Is_Self". |
Global setting only | ||
DeleteIsSelfCondition | PE only | Specifies an additional true/false condition that must be met to delete unneeded records in promotion_data. Used only if DeleteIsSelfRows is 1. This parameter is used as an SQL extra where clause. The Analytical Engine uses it to restrict the deletion. |
Global setting only | ||
detect_cp | Engine > Outlier and Regchange | yes | Both | This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
detect_outlier | Engine > Outlier and Regchange | yes | Both | This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
Also see GrossRemove. To disable all outlier detection, both these parameters must be switched off. |
Can be tuned by node |
DetectModelOutliers | Both | Visible only to owner. Specifies whether to check for outlier models for each forecast node. Outlier models are models that do not fit well enough. The sensitivity of the test is controlled by the ModelValidationBound parameter. | Global setting only | ||
DeviationFactor | Engine > Validation | 5 | Both | Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, residuals are checked for presence of large deviations, as specified by DeviationFactor. This parameter specifies the maximum number of standard deviations that the residuals are allowed to attain. A model is rejected if it fails this test. | Can be tuned by node |
DownTrend | Engine > Adjustment | 0.2 | Both | This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via EnableAdjustment). It controls the forecast adjustment for downward trend. Specifically, it specifies the amount by which the forecast is rotated to align with recent trend in data. Use a value from 0 to 1, inclusive. Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models. |
Can be tuned by node |
dying_time | Engine > Proport | 0.5 season (1 season in media) | Both** | If no sales occurred during the length of time specified by this parameter, the combination is marked as dead. See prediction_status. Global setting, but may also be defined locally in a worksheet. | Global setting only |
E | |||||
EnableAdjustment | Engine > Adjustment | no | Both | This parameter controls the adjustment module of the Analytical Engine. Use one of the following values: | Can be tuned by node |
EnableFitValidation | Engine > Validation | yes | Both | Visible only to owner. This parameter controls the fit validation module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
EnableForecastValidation | Engine > Validation | yes | Both | Visible only to owner. This parameter is used by the forecast validation module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
EnableModifiedVariance | Engine > General | no | Both | Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
EnableSimGLFilter | Engine > General | yes | PE only | Visible only to owner. Specifies whether simulation should respect or ignore any general-level filtering applied to the worksheet. Use one of the following values:
|
Global setting only |
EngDimDef_ItemOrLoc | Engine > Tables | none | DM only | Determines which forecast tree dimension, item or location displays additional levels. The default is that no additional levels are shown. | Global Setting only |
EngineOutputThreshold | Engine > General | 0 | Both | see Fine Tuning and Scaling Demantra -- EngineOutputThreshold | Global Setting only |
EngineScaleInput | Engine>General | 0 | Both | Activates engine scaling of demand and causals as necessary when viewing weekly data by calendar month. If set to No (0-default) no scaling will be done. If set to Yes (1) demand periods and causals are scaled by the forecast engine. | Global Setting Only |
EngineScaleIntermInput | Engine>General | 0 | Both | Controls whether to scale data Intermittent nodes when scaling data. This parameter only applies when EngineScaleInput set to Yes. If set to No (0-default), no scaling will be done. If set to Yes (1), scaling will occur for intermittent forecast nodes and the Croston model is disabled. | |
EngKeyDef_Supersession | Engine > Proport | item_id, location_id | DM only | Key used to aggregate members belonging to the same supersession set. When set to the same value as EngKeyDefPK, the proport calculates proportions for each lowest-level member processed by the engine individually and no special handling of supersessions is done. If set above the level defined by EngKeyDefPK, then calculation of proportions is done at this aggregated level considered the supersession and all underlying combinations receive the same proportional values. | Global Setting only |
EngKeyDefPK | Engine > Tables | item_id, location_id | DM only | Defines the primary key of the combination and data tables selected for this Analytical Engine profile. | Global Setting only |
EngTabDef_HistoryForecast | Engine > Tables | SALES_DATA | DM only | Table that holds historical demand and into which the forecast to be written. | Global Setting only |
EngTabDef_Inputs | Engine > Tables | INPUTS | DM only | Table that contains time definitions for the chosen engine profile. This parameter should not be modified. | Global Setting only |
EngTabDef_Matrix | Engine > Tables | MDP_MATRIX | DM only | Table that holds the combinations available for the chosen engine profile. | Global Setting only |
EngTabDef_Parameters | Engine > Tables | PARAMETERS | DM only | Table that holds the analytical model parameters for engine profiles. | Global Setting only |
F | |||||
FillMethod | Engine > Data Manipulation | linear interpolation | Both | This parameter is used by the preprocessing module of the Analytical Engine (if FillParameter equals 1). The FillMethod parameter specifies how to fill any null (missing) values. Use one of the following values:
|
Can be tuned by node |
FillParameter | Engine > Data Manipulation | 0 | Both | This parameter is used by the preprocessing module of the Analytical Engine. It specifies how to handle null (missing) values. Use one of the following values:
|
Can be tuned by node |
ForecastGenerationHorizon | Engine > Time | 0 | Both | Specifies what historical fit data the engine will write to the database. If this parameter is 0, the engine writes the forecast only. If this parameter is a positive integer N, the engine writes the last N historical fit values. | Global setting only |
ForecastMeanRelativeDistance | Engine > Validation | 3.5 | Both | Visible only to owner. This parameter is used by the forecast module of the Analytical Engine. It specifies the sensitivity of forecast validation. The smaller the value, the stricter the test. | Can be tuned by node |
G | |||||
GLPropSuperSessionMethod | Engine > Proport | latest revision | DM only | Defines the method general level proportions use to allocate proportions during supersessions. When set to the default for each period, proportions are allocated completely to the member with the latest starting date. If set to All Active Revisions for each period, proportions are allocated equally among all active members. | Global setting only |
GrossRemove | Engine > Outlier and Regchange | No | Both | This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
|
Can be tuned by node |
H | |||||
HighestSquaring | Engine > Validation | 4 | Both | Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine. It specifies the number of residual standard deviations, beyond which the residuals participate in the sum of squares calculation in their absolute value, rather than squared. | Can be tuned by node |
hist_glob_prop | Engine > Proport | 1 season | Both** | Maximum number of base time buckets to use in calculating glob_prop, the running average demand for any given item-location combination. This parameter is used by the proport mechanism. Global setting, but may also be defined locally in a worksheet. | Global setting only |
HistoryLength | Engine > Time | 0 | Both | The number of base time buckets to consider for fit estimation and for the proport mechanism. Must be a non-negative integer. If equal to 0, the length of the history is set by the start_date parameter instead. | Can be tuned by node |
I | |||||
InfluenceGroupLevel | Engine > Shell | PE only | Read-only. Specifies which level (from the group_tables table) is used as the influence group level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. | Global setting only | |
InfluenceRangeLevel | Engine > Shell | PE only | Read-only. Specifies which level (from the group_tables table) is used as the influence range level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. | Global setting only | |
IntermitCriterion | Engine > General | 99 | Both | This parameter is used by the preprocessing and intermittent flow modules of the Analytical Engine. It specifies the minimum percentage of zero data points that a series must have to be considered intermittent. In this test, leading zeros may or may not be considered (depending on the setting of CutTailZeros). Trailing zeros are ignored in either case. In the extreme case where this parameter equals 0, all series are treated as intermittent. |
Can be tuned by node |
IntUpdate | Engine > Adjustment | 0.5 | Both | This parameter is used by the intermittent flow module of the Analytical Engine. It specifies the degree to which the Analytical Engine will update the fit after the last spike in history, in the case where there is decline in demand at the end of historical period. Use a number between 0 and 1, inclusive. The value 1 means that the change in fit is to be carried forward fully to the forecast. On the other extreme, the value 0 means that no change is to be applied. A value between 0 and 1 will be used as a weight for combining past and updated behavior. |
Can be tuned by node |
L | |||||
last_date | Engine > Time | 1/1/1900 | Both | Last date of actual sales, to be used by the Analytical Engine and the proport mechanism. No dates after this are used towards the forecast or the proport calculation. If this parameter equals 1/1/1900, the system instead uses last_date_backup. | Global setting only |
last_date_backup | Engine > Time | Both | Specifies a backup value to use for the last sales date, in case last_date is 1/1/1900. Sometimes, when you load sales data, you need to change this parameter so that you can ignore a recent subset of history. The proport mechanism makes sure that this parameter is never later than max_sales_date. See "max_sales_date". |
Global setting only | |
lead | Engine > Time | 12 for monthly data, 52 for yearly, 30 for daily | Both | The number of base time buckets to predict. The Analytical Engine generates a forecast for the base time buckets in the span from max_sales_date to max_sales_date + lead. See "max_sales_date". |
Global setting only |
LogCorrection | Engine > General | no | Both | This parameter is used by the fit and forecast modules of the Analytical Engine. The issue is that logarithmic models use log-transformed demand data, which can give inaccurate results if that transformed data is near to 1 in value. In such a case, you may want to use this parameter to make an internal adjustment. Use one of the following values: yes: Use correct form of the expectation of a lognormal variable. no: Do not perform the log correction. |
Can be tuned by node |
LogLevel | Controls the amount of detail that is written into the Analytical Engine log. Use one of the following values:
This setting applies to all log groups chosen through the Engine Administrator: |
Global setting only | |||
LowerUpliftBound | Engine > Validation | 3 | PE only | Visible only to owner.Specifies the limit beyond which an uplift value is considered "exceptional." This limit is specified as a proportion of baseline. For each model, the Analytical Engine compares the absolute value of the uplift, divided by baseline, to this parameter. The engine discards a model (for a given forecast node) in either of two cases:
|
Can be tuned by Node |
M | |||||
mature_age | Engine > Data Manipulation | 2 | Both** | Controls the mature_date of each combination, which is calculated backwards from the current date using the mature_age parameter. A combination is young (rather than active) if it does not have any non-zero sales data on or before the mature_date. See prediction_status. This is a global setting, but may also be defined locally in a worksheet. |
Global setting only |
max_accept_num | Maximum absolute value that is permitted for the forecast results. If the Analytical Engine generates a result larger than this in absolute value, it substitutes this maximum (or minimum, if applicable).
Tip: Make sure the forecast columns are large enough to accommodate a number of this size, and be sure to account for a possible negative sign. Errors occur if the Analytical Engine cannot write the forecast because the database columns are not large enough. |
Global setting only | |||
max_fore_level | Engine > Shell | Level just below the highest fictive level | Both | The maximum level on the forecast tree at which a forecast may be produced. Upon failure at this level, the NAIVE model will be used (if NaiveEnable is yes). In Promotion Effectiveness, this must be at or below the influence range level (IRL); see InfluenceRangeLevel. |
Global setting only |
MaxEngMemory | Engine > Proport | 100 | Both | Specifies the maximum amount of system memory usage (in megabytes) at the end of a task, before an engine is re-initiated. Use this parameter to prevent the Analytical Engine from failing or generating errors when processing large amounts of data. For machines that run multiple engines, ensure that each engine has access to the amount of memory specified. |
Global setting only |
MeanRelativeDistance | Engine > Validation | 0.5 | Both | Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. A model is rejected if its MAPE (Mean Absolute Percentage Value) is greater than this threshold. The smaller the value, the stricter is the validation. |
Can be tuned by node |
MetricsPeriods | Engine > Validation | 26 | Both | Number of recent periods used to calculate automated engine accuracy metrics. If set to 0 engine will not generate metrics. | Tuned by node |
min_fore_level | Engine > Shell | 1 | Both | Minimum forecast level that the engine will forecast. From that level down, the engine will split the forecast using the precalculated proportions in the mdp_matrix table. For PE, this must be at or above the lowest promotional level (LPL). |
Can be tuned by node |
MinLengthForDetect | Engine > Outlier and Regchange | 12 for monthly data, 52 for weekly, 14 for daily | Both | This parameter is used by the preprocessing module of the Analytical Engine. It specifies the minimum number of data points needed in order for the engine to try to detect outliers and regime changes. | Can be tuned by node |
ModelValidationBound | 0.2 | Both | Specifies the sensitivity of the test used to detect "outlier" models for a given node. Outlier models are models that do not fit well enough. This parameter is used only if model outlier detection is enabled (via the DetectModelOutliers parameter.) | Global setting only | |
N | |||||
NaiveEnable | Engine > General | yes | Both | Specifies what to do at the highest forecast level, upon failure of all models. Use one of the following values:
|
Can be tuned by node |
need_spread | Engine > Adjustment | produce continuous forecast | Both | This parameter is used by the intermittent flow module of the Analytical Engine, and it controls whether the final result should be given in the form of spikes. Use one of the following values: produce forecast with spikes produce continuous forecast This applies only to intermittent models. |
Can be tuned by node |
node_forecast_details | Engine > Shell | forecast is written to node_forecast_q | Both | Visible only to owner. Specifies whether the Analytical Engine should write forecast data for each node, before splitting to lower levels. Use one of the following values:
|
Global setting only |
NonNegRegrMaxTolMult | Specifies the maximal multiplier to be used in order to increase the tolerance value in nonnegative regression. When you disable negative coefficients (via UseNonNegRegr) and are unable to acquire a solution, it may be helpful to increase this tolerance. Recommended value range: 30 - 2000 Default value: 30 |
Global setting only | |||
NormalizationFactor | Engine > Data Manipulation | 0 | PE only | Parameter is visible only to owner. Specifies the degree of normalization to perform, if NormalizeResults is yes. Use a number from 0 to 1, inclusive. The ends of this range have the following meanings:
This normalization is applied only to historical data (where the baseline is known). |
Global setting only |
NormalizeResults | Engine > Data Manipulation | no | PE only | Parameter is visible only to owner. Specifies whether to normalize the historical engine results so that the observed baseline values are preserved. Use one of the following values:
|
Global setting only |
NumShapes | Engine > Validation | 8 | Both | Parameter is visible only to owner. Specifies the maximum number of allowed shape causal factors for the engine to use for a given node in the forecast tree. Use an integer from 0 to 8, inclusive. Applies to activity shape modeling (rather than to promotional shape modeling). | Global setting only |
O | |||||
oracle_optimization_mode | Engine > Shell | cost | Both | Oracle only; visible only to owner. Optimization mode of the database. | Global setting only |
OutliersPercent | Engine > Outlier and Regchange | 25 | Both | This parameter is used by the preprocessing module of the Analytical Engine. A set of points, suspicious as outlying, will be regarded as such only if its size does not exceed this given percentage of data. | Can be tuned by node |
OutlierStdError | Engine > Outlier and Regchange | 2.5 | Both | This parameter is used by the preprocessing module of the Analytical Engine, if gross outlier processing is enabled (via the GrossRemove parameter). The OutlierStdError parameter specifies the sensitivity of gross outlier detection. The greater this value, the less sensitive (more liberal) is detection of gross outliers. The value 0 is not allowed. |
Can be tuned by Node |
P | |||||
PartitionColumnItem | Both | Specifies the name of the column that partitions the data by item. This column must exist in sales_data, mdp_matrix, and (for Promotion Effectiveness) promotion_data. If this is null, data is not partitioned by item. See "Database Partitioning for the Engine". |
Global setting only | ||
PartitionColumnLoc | Both | Specifies the name of the column that partitions the data by location. This column must exist in sales_data, mdp_matrix, and (for Promotion Effectiveness) promotion_data. If this is null, data is not partitioned by location. See "Database Partitioning for the Engine". |
Global setting only | ||
PercentOfZeros | Engine > Adjustment | 0.2 | Both | This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via the EnableAdjustment parameter). It specifies the maximum fraction of zero values in data beyond which no forecast adjustment is performed. Use 0.2 for 20 percent, for example. Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models. |
Can be tuned by node |
PopulationExtraFilter | Engine> Shell | Null | Both | This parameter can be used to apply an extra filter on the combination population processed by the engine. This can help support incremental engine runs as well as ensure only desired combinations are forecasted. The default setting is null, applying no additional filter. An expected filter is on the MDP_MATRIX table with the synonym M. This filter will not require specifying the table for this table, and should only include the additional WHERE clause used by the filter. Example: WHERE PREDICTION_STATUS=1 Filters including other tables must specify those other tables and join then to MDP_MATRIX. The syntax for the additional tables must begin with a comma, followed by the table name. It is not recommended that tables with a time dimension be used, including SALES_DATA. Care should be taken when defining columns for the filter, as they may exist in multiple tables, causing SQL errors. It is strongly recommended that any column referenced in the filter be prefaced by the table from which it is being retrieved. Example: … ITEMS I WHERE I.ITEM_ID=M.ITEM_ID AND I.ITEM_ID < 100 Example: … T_EP_FRANCHISE T1, T_EP_RETAILER T2 WHERE T1.FRANCHISE_ID=M.FRANCHISE_ID AND T2.RETAILER_ID=M.RETAILER_ID AND T1.FRANCHISE_CODE < 100 AND T2.RETAILER_CLASS > 5 |
Global Setting Only |
PopulationFilter | Engine > Shell | Null | Both | Applies a filter to the set of item/location combinations included in a batch profile. The engine will completely ignore combinations that do not meet the filter criteria. The default is no filter. This filter supports columns on the MDP_MATRIX table. Example- CONSUMPTION_DEMAND=1. If the profile is on a General Level then columns from the General Level table can also be referenced. | Global setting only |
PROMO_AGGR_LEVEL | Engine > Shell | PE only | Read-only. Specifies which level is used as the lowest promotional level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. | Global setting only | |
PromotionStartDate | Engine > Time | PE only | Parameter is visible only to owner. Earliest date for which promotion data can be considered reliable. The Analytical Engine ignores any promotion data before this date. This parameter applies only to combinations that have promotions. | Global setting only | |
PromotionSeries | Engine > Proport | null | Globally Defined | see chapter Configuring the Analytical Engine, section Split Forecast by Series | Global Setting only |
proport_missingm | Engine > Proport | treated as zero observations | Both** | Specifies how missing dates are treated. Use one of the following values:
|
Global setting only |
proport_spread | Engine > Proport | receive 0 proportions/global proportions | Both** | Specifies how months that are missing from historical data are filled. Use one of the following values:
|
Global setting only |
proport_threshold | Engine > Proport | 0 | Both** | Specifies how many different months of the year must include data in order for Demantra to calculate proportions for the individual months (P1 - P12, PW1-PW6, etc.). Use any integer from 0 to 12, 24, inclusive. For each combination, the number of unique observable buckets is found (having 3 different observations of January counts as only one month). If not enough months have non-null values, Demantra checks the value of the proport_missing parameter and then does the following: If proport_missing equals 0, then missing months receive glob_prop*delta. If proport_missing equals 1, then missing months receive the rolling average (glob_prop). |
Global setting only |
ProportParallelJobs | Engine > Proport | 1.00 | Both** | The number of parallel jobs used when running Proport calculations. This parameter's value should not exceed the number of CPUs on the database server. | Global setting only |
ProportRunsInCycle | Engine > Proport | 1.00 | Both** | The number of groups that the Proport process is broken down into. | Global setting only |
ProportTableLabel | Engine > Proport | Both** | The name of the level by which the process is broken down. The total number of members in this level is divided into equally sized groups, and one group is processed each time Proport is run. | Global setting only | |
Q | |||||
Quantile | Engine > Outlier and Regchange | 2.5 | Both | Visible only to owner. This parameter is used by the validations module of the Analytical Engine, when checking the influence of outliers. It specifies a standard normal percentile for detecting outliers at a prescribed significance level. | Can be tuned by Node |
quantity_form | Engine > Data Manipulation | See details. | Both | Visible only to owner. Expression that the Analytical Engine uses to compose the historical demand from the sales_data table; the result of this expression is the data that the engine receives as input. This expression should return 0, null, or a numeric quantity for any date. A date with 0 is treated as if there were no sales. A date with null is treated as a missing date; in this case, the system can interpolate a value or just ignore the date. On Oracle, the default is as follows: nvl(pseudo_sale,actual_quantity)*(1 + nvl(demand_fact,0)) + nvl(demand_lift,0) |
Global setting only |
R | |||||
RegimeThreshold | Engine > Outlier and Regchange | 5 | Both | This parameter is used by the preprocessing module of the Analytical Engine. It specifies the sensitivity of regime change detection. The smaller the value, the more aggressively the engine will detect regime changes. This parameter is used only if regime change is enabled (via the detect_cp parameter). |
Can be tuned by node |
RemoveResidOutlier | 0 | Both | Specifies the percentage of residuals (by number) to remove before validating the fit. The residuals are sorted by size and the largest residuals are removed. | Can be tuned by node | |
ResetForeVals | Engine > Shell | yes | Both | Visible only to owner. Specifies whether the engine should clear out previous forecast data before generating the forecast. Use one of the following values:
|
Global setting only |
resetmat | Engine > Shell | yes | Both | Visible only to owner. Use one of the following values:
|
Global setting only |
RunInsertUnits | Both | Specifies the behavior of the INSERT_UNITS procedure, which Demantra calls at the start of an engine run. This procedure makes sure the engine has rows to write into when generating the forecast. This parameter also controls whether Demantra runs the active rolling data profiles when it runs this procedure. Use one of the following values:
|
Global setting only | ||
RUNMODE | Not applicable | Read-only; parameter is visible only to owner. Specifies which version of the Analytical Engine to use.
|
Global setting only | ||
RunPartialDivider | Engine> Shell | No - Assign new Branch to every combination participating in forecast | Both | This parameter is used to control whether all combinations are assigned a branch at the beginning of a new engine run. Setting of No (default) will assign a branch ID to all combinations taking part in the engine run. Setting of Yes will assign Branch ID only to nodes that currently do not have a branch ID. Note: Setting value to No can improve engine run performance but may result in unbalanced engine tasks over time. | Global Setting Only |
S | |||||
SdeAnalyzeSwitch | Engine > General | yes | Both | Specifies how the Analytical Engine should analyze the sales_data_engine table. Use one of the following values:
|
Global setting only |
SdeCreateJoin | Engine > General | no | Both | Specifies whether the Analytical Engine should join sales_data_engine (or its synonym) and mdp_matrix during its run. Use one of the following values:
See "Reconfiguring the sales_data_engine Table". |
Global setting only |
SdeCreateSwitch | Engine > General | internal logic | Both | Specifies whether to use external logic to create the sales_data_engine table. Use one of the following values:
|
Global setting only |
season | Engine > Time | season length | Both | Read-only. Season length (52 for weekly systems, 12 for monthly, 7 for daily). | Can be tuned by node |
set_rb | Engine > Shell | SET transaction use rollback segment RB1 | Both** | Oracle 8i only; visible only to owner. Set Rollback Segment command for the database. This is database dependent. See your database documentation. | Global setting only |
ShapeSign | Engine > Data Manipulation | Both | Specifies the signs for the shape causal factors when using them in non-negative regression. Use one of the following values:
This parameter is ignored if UseNonNegRegr is set to prevent negative coefficients. |
Can be tuned by node | |
ShiftBaseCausals | Engine > Shell | 0 | PE only | Parameter is visible only to owner. Specifies the number of base time buckets by which the baseline causal factors should be shifted; this applies to the causal factors in the causal_factors table. Specify an integer (can be negative). The default setting (0) is recommended. | Can be tuned by node |
ShiftDynPromoDate | PE only | SQL expression that returns the number of days to add to the sales date for any given promotion; typically this is a negative number. If the resulting dates are already in the Inputs table, the Analytical Engine inserts those dates into promotion_data with is_self equal to 0. If this expression is null, then the default promotion dates are used.
|
Global setting only | ||
ShiftPromoCausals | Engine > Shell | 0 | PE only | Parameter is visible only to owner. This parameter is a global setting that applies to all promotions. You may want to use ShiftDynPromoDate instead, because that gives a greater amount of control. This parameter specifies the number of base time buckets by which the promotional causal factors should be shifted; this applies to the causal factors in the m3_causal_factors table. Specify an integer that can be negative. For example, to make the promotional causal factors active one week after the promotions occur, specify 1 (in a weekly system). |
Can be tuned by node |
ShiftPromoMaxValue | PE only | Specifies the number of additional future time buckets to bring into history, when shifting promotions to the dates given by ShiftDynPromoDate. By default, the Analytical Engine considers only historical promotions and ignores any future promotions. If you shift promotion dates, that typically means you need to shift promotions that are planned for the very near future. This parameter specifies how many time buckets of the future the Analytical Engine should consider when it shifts the promotion dates. |
Global setting only | ||
start_date | Engine > Time | 1-1-1995 | Both | First sales date, the start date as it appears in the Inputs table. Can be changed according to the length of history needed for fit estimation and for the proport mechanism. It is strongly recommended this parameter be reset to beginning actual date where history begins. See also the HistoryLength parameter. | Global setting only |
start_new_run | Engine > Shell | Yes | Both | Specifies whether to start a new Analytical Engine run or to perform an engine recovery. Internally, the engine records information to indicate its current processing stage. As a result, if the previous engine run did not complete, you can run recovery, and the Analytical Engine will continue from where it was interrupted. Use one of the following values:
|
Global setting only |
StartAverage | Engine > Data Manipulation | -12 for monthly -52 for weekly -7 for daily | PE only | Promotion Optimization only; parameter is visible only to owner. Controls the starting date of the time span used to calculating the average baseline forecast. You specify this date relative to last_date. The length of this span of time is controlled by the AverageHorizon parameter. For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP" in the Oracle Demantra Implementation Guide. |
Global setting only |
StdRatio | Engine > Validation | 3 | Both | This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, the residuals are split into two parts (earlier and later) controlled by TestPeriod. The parameter StdRatio is the maximum allowed ratio of the standard deviation of the later part to the standard deviation of the earlier part. A model is rejected if it fails the test. | Can be tuned by node |
T | |||||
TargetTaskSize | Parameters > System Parameters > Engine > Proport | 0 | Both | Specifies how many MDP_MATRIX combinations the Analytical Engine attempts to assign to each forecasting task. Allocation will be affected by forecast tree branch size. When this parameter is set to 0 (the default value), the system automatically calculates a value for 'TargetTaskSize' depending on the number of engines. Otherwise, the value of 'TargetTaskSize' is used. (Oracle does not recommend changing the default value.) The engine divider uses the value of 'TargetTaskSize' as a system-preferred branch size to create branches that are more equal in size which improves engine performance. The engine divider will try to add as many tasks as possible to an existing branch, up to the limit of 'TargetTaskSize' level 1 combinations, before adding new branches. |
Global setting only |
test_samp_len | Engine > Validation | 6 for monthly data, 26 for weekly 7 for daily | Both | This parameter is used by the fit validation module of the Analytical Engine. It specifies the length of data for forecast validation. | Can be tuned by node |
TestPeriod | Engine > Validation | 6 for monthly data, 26 for weekly 7 for daily | Both | This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, the residuals are split into two parts (earlier and later) controlled by TestPeriod. The parameter StdRatio is the maximum allowed ratio of the standard deviation of the later part to the standard deviation of the earlier part. A model is rejected if it fails the test. | Can be tuned by node |
TooFew | Engine > General | 2 | Both | This parameter is used by the preprocessing module of the Analytical Engine. It specifies the minimum number of non-zero data points that a series must have in order for the Analytical Engine to consider it model-feasible. In this test, leading zeros may or may not be considered (depending on the setting of CutTailZeros). Trailing zeros are ignored in either case. Must be 1 or greater. If the series has too few data points, the forecast failure module is run. |
Can be tuned by node |
top_level | Engine > Shell | Both | Visible only to owner; read-only. Indicates the highest level of the forecast tree (the highest fictive level, HFL). This indicates the number of levels that the forecast tree contains. | Global setting only | |
TopCoefficientLevel | Engine > Data Manipulation | PE only | Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the highest forecast tree level for which the Analytical Engine will calculate coefficients. Use any forecast tree level between BottomCoefficientLevel and the InfluenceRangeLevel, inclusive. For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP" in the Oracle Demantra Implementation Guide. |
Global setting only | |
TrendDampPeriod | New | Used during trend detection, this parameter specifies a block of time (as a number of buckets) over which the dampening is applied. The time that contains trend is divided into blocks, as specified by this parameter. For the nth block, the Analytical Engine applies a dampening factor n times. The result is exponential dampening. | Can be tuned by Node | ||
TrendDampStep | New | Used during trend detection, this parameter specifies the dampening factor, which is applied n times to the nth block of time within the trend. The result is exponential dampening. Use a value between 0 and 1, inclusive; smaller values cause dampening to happen more quickly. | Can be tuned by Node | ||
TrendModelForShort | New | Used during trend detection, this parameter specifies which engine model to use in order to generate the trend causal factor.
|
Can be tuned by Node | ||
TrendOutlierRatio | New | Used during trend detection, this parameter specifies how to treat outliers during model fit. It specifies a numeric weight to apply to the outliers within the long segment. | Can be tuned by Node | ||
TrendPeriod | Engine > Adjustment | Both | This parameter is used in two parts of the Analytical Engine. The adjustment module uses it as follows:
This parameter is also used by trend detection as discussed in "The Forecasting Process.". If you have disabled negative regression (via UseNonNegRegr), then it is difficult for the Analytical Engine to detect downward trends. In such cases, you should enable trend detection. |
Can be tuned by node | |
TrendPreEstimation | New | Specifies whether to perform trend detection as described in "The Forecasting Process". | Can be tuned by Node | ||
TrendShortRatio | New | Used during trend detection, this parameter specifies how to treat outliers during model fit. It specifies a numeric weight to apply to the outliers within the short segment. | Can be tuned by Node | ||
U | |||||
UpliftThresholdMethod | Engine > Validation | 1 | PE only | Specifies how to determine the uplift threshold:
|
Global setting only |
UpliftThresholdValue | Engine > Validation | .5 | PE only | Uplift and cannibalization values lower than this threshold are automatically set to null. This number must be greater than 0. | Global setting only |
UpperUpliftBound | Engine > Validation | 20 | PE only | Visible only to owner, Specifies the upper allowed limit for uplifts, as a proportion of baseline. For each forecasting model, the Analytical Engine calculates the lift for each node of the forecast tree. For any given node and model, if the absolute value of the uplift is greater than this limit, then that model is not used for this node. The engine discards a model (for a given forecast node) in either of two cases:
|
Can be tuned by Node |
UpTime | Engine > Data Manipulation | nvl(sum(nvl(UP_TIME,1)),1) | Both | This parameter is used by the preprocessing module of the Analytical Engine. It is used to flag whether each date in sales_data should be considered a sales date or not. Use an SQL expression that returns one of the following values:
|
Global setting only |
UpTrend | Engine > Adjustment | 0.2 | Both | This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via EnableAdjustment). It controls forecast adjustment for upward trend. Specifically, it represents the amount the forecast is rotated to align with recent trend in data. Use a value from 0 to 1, inclusive. Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models. |
Can be tuned by node |
UseBusinessFilter | Engine > Data Manipulation | no | Both | Specifies whether the Analytical Engine distinguishes business and non-business days. Use one of the following values: | Global setting only |
UseEnvelope | |||||
UseExternalSDUpdate | Engine > Shell | no | Both | Visible only to owner. Specifies how to update the sales_data table with the current forecast. Use one of the following values: yes: Use an external procedure (create_process_temp_table. no: Use an internal dynamic procedure. The create_process_temp_table procedure is a template that creates the dynamic stored procedure that will be executed by the engine for the update. By default, this procedure creates the same SP that as the engine creates, but this can be overridden. The interface to this SP is as follows:
|
Global setting only |
usemodelspernode | Engine > Data Manipulation | Both | Specifies whether you can specify the forecasting models to use for specific nodes in the forecast tree, via the File > Analytics menu option in Promotion Effectiveness. | Global setting only | |
UseNonNegRegr | Engine > Validation | yes | Both | Visible only to owner. Specifies whether to use non negative constraint estimation for all regression-based engine models. Use one of the following values:
|
Can be tuned by node |
UseParamsPerNode | Engine > Data Manipulation | Both | Specifies whether you can specify the engine parameters to use for specific nodes in the forecast tree, via the File > Analytics menu option in Promotion Effectiveness. | Global setting only | |
UseWeightedRegression | 0 | Both | Specifies whether the Analytical Engine applies a weight to each observation when fitting each model.
|
Can be tuned by Node | |
W | |||||
WriteIntermediateResults | Engine > Shell | no | Both | Applies only to the desktop products; parameter is visible only to owner. Specifies whether to enable the advanced analytics function, which is available only on the desktop. Use one of the following values:
|
Can be tuned by node |
WriteMissingDatesUplift | Engine > Shell | no | PE only | Parameter is visible only to owner.Specifies whether to write uplifts for dates that are missing from sales_data. Use one of the following values:
|
Global setting only |
* PE only means PE mode only; Both means both PE and DP modes. ** This parameter is not used directly by the engine and thus is available for use with either engine mode. |
The following parameters provide more advanced controls of how Demantra executes specific engine processes and allow you to tune the engine based on your implementation's unique characteristics. These parameters can be set in the INIT_PARAMS_% tables.
Warning: Using these parameters to improve engine performance depends almost entirely upon the expertise of the implementer. System issues may result if they are not used correctly. Oracle does not recommend using these parameters unless you have been trained and have previous experience tuning the Analytical Engine