| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
 Previous |
 Next |
| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
Previous |
Next |
Data model irregularities are not unusual in complex systems, since performance, flexibility, and functionality are constant requirements that force many compromises. The same metadata that allows the application's access to the RMS data model also exposes the irregularities of that same data model, unlike any existing RMS interface. This would be true in general for any system monitored by Active Retail Intelligence via metadata, and is not in itself problematic. In fact, the metadata as designed has in some cases been used to build in compensation for these irregularities. Without regard for the benefits or reason for the RMS data model being constructed as it is, following are brief discussions of some of the specific areas of the RMS data model that impact Active Retail Intelligence administration.
Even though locations are unique, the location tables are split by location type (store and warehouse). Thus, to monitor certain kinds of location related exceptions, similar but distinct exceptions may need to be defined on more than one table. These exceptions may be the best example (see the Examples chapter) of multiple exceptions driving the same event, which could be done only if the event could get its additional information from the common tables and precisely because the key identifiers are unique across the tables.
To define conditions against a unique set of metadata requires that information can only be gathered from tables that are somehow the parents of whatever table is being monitored. You can only navigate "up" the foreign key chain. To navigate downward, to check whether a SKU exists on an order, or to compute a total, or otherwise check an attribute of detail information that can be treated as a single row of data, requires functions to return calculated fields. Details on setting up these functions are discussed elsewhere in this section and in the Examples section.
Active Retail Intelligence installation loads metadata appropriate to the release of RMS with which it is released. However, use of external data systems or custom modifications that add new tables or change existing ones requires metadata maintenance.
Internal metadata, describing Active Retail Intelligence, the RMS, or some other integrated Oracle systems sharing the same DDL and owner as these products, is generally best defined before the systems are put into production.
Suppose that, through custom modifications, you add a new table to the RMS or modify an existing table. Before putting the system into production or creating Active Retail Intelligence exceptions and events, you should always make the metadata accurate. This includes deleting parameters representing removed columns, adding parameters representing new columns, and modifying those representing changed columns. Depending on the change, the modification may simply be a change to a parameter type. Consider these examples:
For example, you add new columns to the RMS ITEM tables to categorize items in terms of shelf life and, where applicable, record the duration of that shelf life. Using the auto-discovery feature of the Parameter dialog, you could start at the ITEM table and auto-discovery would successively pre-populate data about these new columns. You would likely create a new parameter type for the shelf-life category, and use an existing parameter type such as number of days parameter type to describe the shelf-life duration.
Building on this example, if you added a code to the code_head and code_detail table to describe the various shelf-life categories, you might add a code type to the shelf-life category parameter as well. A code type such as SHLF could contain the codes FOOD and PHARM for food items and pharmaceuticals. If, instead, the number of categorizes were to be dynamically created by the buyers as needed, the categories might be stored on a new shelf-life category table with a code and description column. In this case you would first describe the new table and then use its description column as a decode column for the parameter representing the shelf-life category on the ITEM tables.
As another example, consider if you needed all ITEM numbers to be able to have a length of 10 instead of only 8 as is currently the practice in the RMS. After making the changes in the RMS to tables and code, the only change that would be needed for Active Retail Intelligence would be a modification to the ITEM parameter type. Because all parameters that contain ITEMs should already have a parameter type of ITEM and it is the parameter type that contains the data length and type information, not the parameter itself, a single modification to the type modifies the whole system.
The difficulty in the parameter type example is that after the parameter types are in use (to describe parameters), they cannot be modified. Instead, a new parameter type (ITEM -10, for example) must be created and then all of the ITEMs must be assigned to it so that, no longer part of the definition of ITEM parameters, the parameter type (ITEM-8) can be deleted. Such a mass update is likely easier done in SQL*PLUS by a system administrator, but these illustrations are intended to show you both when and how to use the tools provided and when to use another method.
As these examples show, there are inherent difficulties with changing the table structures of the RMS after it has been put into production. Data dependencies make certain changes difficult to make once the RMS system is in use, and so it is with Active Retail Intelligence. As shown in the last example, some of these dependency difficulties exist in ARI as well. Thus, you should know that pre-production metadata synchronization is critical. Post-production changes, except possibly in the form of new tables, are more difficult (though still possible).
Active Retail Intelligence does not come with any external realms pre-defined. This is because the external feeds that are available depend on the reports an individual retailer is interested in monitoring.
It might be helpful to describe the Active Retail Intelligence realm table as internal metadata and define an exception against it notifying the Active Retail Intelligence Administrator every time the active indicator is set to NO on a realm that has an active or future exception defined against it. This would prompt the Active Retail Intelligence Administrator to define a new realm and create a new version of the exception to monitor this new realm.
Defining a realm for a new headline version is just like defining a realm for the first version of a headline. The process of creating a new exception version when the realm changes is discussed in a later example.
