Configuring Analytic Type Records

To configure analytic type records, in the analytic type definition, select the Record tab, and then select Insert, and then Record.

This example illustrates the fields and controls on the Analytic Type Record Property dialog box. You can find definitions for the fields and controls later on this page.

Note:

You can access the properties of an existing analytic type record by right-clicking the record and selecting the Analytic Type Record Properties option.

Field or Control	Description
Record Name	Select the record to use in the analytic type definition. Note: If you select a derived/work record, remember that its scope in optimization PeopleCode is different from that in other PeopleCode. When you use the CreateOptEngine or CreateAnalyticInstance function, each derived/work record is instantiated at level zero of the analytic instance rowset. The record persists, and you can continuously modify its data across multiple transactions, until you shut down the optimization engine using the ShutDown method.
Synchronization Order	Indicates the order in which the optimization engine reads the optimization application records. If a record has dependencies on another record, the dependent record should be read later. For example, the QE_RSM_EXERTGT record (synchronization order number is 4) depends on data in the QE_RO_MACH_CALS record (synchronization order number is 1). This order is determined by the application logic.
Read Once	Select to have the record read only once during the initial load of the analytic instance into the optimization engine. You cannot select the Writeable check box if the Read Once check box is selected. The optimization engine reads these records only once during the initial data load. The assumption is that the data in these records does not change (or the user doesn't care if it changes) from the initial load of the optimization engine until shutdown. For the exercise machine problem, you might create a record that contains the name of an exercise machine and the number of calories one can burn on it. This information needs to be read only once by the optimization engine. Furthermore, the information will not change, so a VERSION field is not required.
Readable	Select to have the record checked for updates by the optimization engine with every optimization transaction. Readable records, besides being loaded during the initial load, are checked for updates by the optimization engine at the beginning of every optimization transaction. For every readable optimization application record, you must also create a corresponding optimization delete record and associate the readable record with the delete record. This process is explained later in this topic. Note: Oracle recommends that you keep the analytic type records in sync with the optimization delete records. For the exercise machine example, an appropriate readable record contains the name of a person who exercises, the start time and duration of the exercise, and the number of calories that the person wants to burn. This record is readable and scenario-managed. It has a VERSION field and a PROBINST field that contain the name of the person. Because this is pure source data, this data is not writable.
Writable	Select to enable the optimization engine to modify rows for this record. A record can be both readable and writable. Records more likely to be readable and writable than just writable. A writable record contains result data from the optimization engine. For the exercise machine example, the system calculates this data every time you request an exercise summary. For this reason, it is purely writable.
Scenario Managed	Select to indicate that the record will contain data pertaining to multiple analytic instances. Note: Scenario-managed records must have a PROBINST key field. See Scenario Management.
Callback	Select to enable the optimization engine to update its working data whenever this record changes. Your analytic type definition might include a record that you expect to change during the course of the optimization. If you want those changes to be taken into account by the optimization, you can define it as a callback record, so you can use provided PeopleCode callback methods to dynamically propagate those changes to the derived data structures of the optimization. A callback record must be readable and writable. Warning! If you select this check box for a record, you must ensure that you override all of the abstract callback placeholder methods that are defined in the extended PT_OPT_BASE:OptBase application class, even if it contains only a Return statement. Otherwise your Optimization PeopleCode plug-in will fail. See OptBase Application Class.
Record Fields	In the Record Fields list, select the fields in this record that need to be read into the optimization engine. These are the fields that the OPI can access. Key fields and the VERSION field (if it exists) are always selected automatically. To conserve memory used by the optimization engine, select only the necessary fields. When the analytic type definition is saved, if there are fields that have not been selected but are being mapped to a cube or dimension, an error message is displayed, and you must go back and correct the error before you can save the analytic type definition. If there is a record in the analytic type definition that has none of its fields mapped to any cube or dimension, a warning message is displayed when you try to save the analytic type definition. You can continue to save the analytic type definition after you have acknowledged the warning message; you do not have to change anything in the definition.