Oracle Retail Knowledge Base

18 Attribute Processing

11 min read

Mirror of Oracle documentation

Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.

18 Attribute Processing

This chapter addresses attribute preprocessing. It contains the following sections:

  • Attribute Preprocessing

  • Product Attribute Loading

Attribute Preprocessing

Attributes provide context about products and enhance the accuracy of DT and CDT models. Attributes are stored within AIF data warehouse and are derived from product descriptions and merchandise hierarchy.

AIF applications may or may not contain product attributes. Any attributes found in AIF applications may have been created for BI reporting or other purposes and may need mining or preprocessing to make them suitable for the application.

Some steps in attribute preprocessing require manipulating attribute data. Oracle Enterprise Product Data Quality is a licensed software package that facilitates some of the preprocessing data manipulation steps required to make attributes suitable for CDT and DT modeling.

Here is an example of product information for yogurt.

  • Product description: Brand A non-fat organic 6 oz.

  • Class description: Dairy product.

  • Sub-class description: Yogurt.

SKU/Store attributes determined by preprocessing:

  • Brand

  • Price

  • Size

Note that CDT modeling works optimally when there are five or fewer possible values for any given SKU-store attribute. For example, many price points are available for yogurt. For CDT, it is better to define between three and five price bins (that is, budget, regular, premium, and elite).

Process Overview

The basic steps for attribute preprocessing are as follows:

  • Populating AIF data warehouse with attribute data

  • Translating (optional)

  • Parsing

  • Cleansing and standardizing

  • Categorizing and labeling

  • Defining attributes

  • Binning and grouping

Populating AIF Data Warehouse with Attribute Data

A few steps are required to make attributes suitable for the application so that the applications can use this data.

The first requirement is to ensure that the attribute values are populated in the AIF data warehouse (W_RTL_ITEM_GRP1_D table). This is the source for the attribute data and must be loaded there in order to be available to the application.

Regarding raw attributes: In the data warehouse, an attribute can be defined in multiple ways. Some generic attributes are typically stored in a column of the W_PRODUCT_ATTR_D table. The data warehouse has a table W_RTL_METADATA_G that contains a list of defined attribute locations. Consult this list to see if there is already a defined place to store a particular attribute value.

AIF data warehouse also offers the ability to store Item Differentiators for products. These are essentially User Defined Attributes (UDAs), which consist of a lookup code for the attribute and the attribute value. These lookup codes are then defined in a standard translation table (W_DOMAIN_MEMBER_LKP_TL with domain codes of ITEM_UDA_HEAD and ITEM_UDA). The actual association of an item to one of the UDAs is performed in the W_RTL_ITEM_GRP 1_D table.

Once attributes are available in the data warehouse, it is necessary to define these attributes in the RSE_BUSINESS_OBJECT_ATTR_MD table. This table must be set up with appropriate metadata to define the source of the attributes from the data warehouse tables. The sample seed_data file for this table contains some standard attributes that can be defined in W_RTL_ITEM_GRP1_D, but the table must be adjusted to contain the complete list of attributes that should be available for the applications to use. This must include Flex Attributes as well as User Defined Attributes.Once attributes are defined in the

RSE_BUSINESS_OBJECT_ATTR_MD, the next step is to provide custom lists of attributes that should be used per product category. This can be done through the RSE_PROD_ATTR_GRP_VALUE_STG and RSE_PROD_ATTR_VALUE_XREF_STG interfaces. The first interface is used to define the output of the binning and grouping of attributes. For example, if Coffee needs a Brand Tier attribute, and it should have values of Premium, Value, and Mainstream, then this interface would define this Coffee Brand Tier attribute, along with the values of Premium, Value, and Mainstream, and it should specify what source attribute is to be used for this (the source is in RSE_BUSINESS_OBJECT_ATTR_MD). The second table of the interface (RSE_PROD_ATTR_VALUE_XREF_STG), enables the association of specific Brand attributes to the binned/grouped attribute values from the first interface (RSE_PROD_ATTR_GRP_VALUE_STG).One concept to consider for these attributes and attribute values, is that they must be unique across all product categories. This offers the ability to classify one Brand as Premium for one product category, while it could be Mainstream for another product category. Additionally, it enables a different selection of attribute values for each product category. For example, another product category might not have a Premium Brand Tier, and therefore the interface would not include this value in this interface for that product category.

Translating

This step is only needed when the product data is in a different language than the customer’s primary language.

Parsing

This step identifies and extracts target key words, such as “Brand A,” “small,” “blue,” and “nonfat.” from the source data (such as product description). It is done through semantic recognition, usually by software such as Oracle Enterprise Product Data Quality.

Cleansing and Standardization

This step edits the text and corrects spelling and grammar. For example, “Addr.” will be recognized and converted into “Address” and “St.” into “Street.” EPDQ can facilitate this step.

Categorizing and Labeling

This step classifies targeted key words into the pre-defined categories, such as “Brand A” for “Brand,” “small” for “Size” and “blue” for “Color.” The product record can thus be labeled by the category values. EPDQ can facilitate this step.

Defining Attributes

With the extracted categories from the product data, attributes are defined. They can be some or all of the categories identified, based on contextual business knowledge and how populated the categories are.

Binning and Grouping

Binning and grouping are used to consolidate and reduce the number of possible values for an attribute into a manageable number.

  • Binning divides numerical attributes, such as price, discounts, and mileage, into discrete sets of ranges, such as ⇐$10, $10~$25, and >$25.

  • Grouping combines textual attributes that are too granular into a smaller set of attribute values. For example, tea weight can have dozens of values; grouping merges the values into coarser ranges (like small or large) and reduces the number of possible attribute values.

Product Attribute Loading

This section provides an example of adding an attribute for use by the application into all the relevant tables. In this example, a new attribute is added to represent Flavor within the Coffee product category.

The process flow for this involves:

1. Identify the need to add a new product attribute for a product category.

2. Determine where the attribute data is found within the data warehouse.

3. Use the Manage System Configurations screen to add the attribute definition in the tables, if it not already present.

4. Use AIF Apps jobs in POM to run the batch process to load attribute data from the data warehouse.

5. Determine if the attribute data requires any special grouping or binning.

6. Populate the RSE_PROD_ATTR_GRP_VALUE_STG staging table with attribute definition and values.

7. Populate the RSE_PROD_ATTR_VALUE_XREF_STG staging table with data to associate raw RADM attribute values to the Attribute Groups defined above.

8. Use AIF Apps jobs in POM to run the batch process that processes the interface staging tables.

9. Use AIF Apps jobs in POM to update the CIS attribute data to reflect the new attribute (product attributes).

10. Use AIF Apps jobs in POM to update the CIS attribute data to reflect the new attributes (non-product attributes).

Introduce New Attribute

The first step in the process is the catalyst that triggers the remaining steps. The catalyst is the new attribute that has been introduced and must be made available within the application.

Determine the Attribute Source and Define in the Tables

The new attribute is loaded from the AIF data warehouse for each of the products that require this attribute. The data warehouse has multiple ways of loading attributes, so the approach used varies, depending on where and how the data is stored. The process involves defining the source table and then defining the column (or column filter values) used to identify the attribute. Once the source is determined, the appropriate values are loaded into RSE_BUSINESS_OBJECT_ATTR_MD and possibly RSE_BUSINESS_OBJECT_DB_SRC.

W_PRODUCT_D or W_PRODUCT_ATTR_D

The data Warehouse’s W_PRODUCT_D table and W_PRODUCT_ATTR_D table can provide attributes from any of the available columns in these tables. The W_PRODUCT_D table contains named columns with data of a specific logical value, while the

W_PRODUCT_ATTR_D table contains a more flexible set of Number, Text, and Date columns that can contain varying values, depending on the implementation. From an attribute point of view, these tables are effectively the same and require the same type of handling.

W_RTL_ITEM_GRP1_D

The W_RTL_ITEM_GRP1_D table in the data warehouse is different than the other product attribute sources, in that these tables can have attributes implemented as unique rows and specific columns. This table contains a PROD_GRP_TYPE column, which defines the type of data in the table. Values of ITEMUDA are used for User Defined Attributes. Rows in which the PROD_GRP_TYPE corresponds to the BRAND, COLOR, FLAVOR, SCENT, FABRIC, and STYLE columns (ex. BRAND_WID) are also possible.

Populate RSE_PROD_ATTR_GRP_VALUE_STG Interface

Once the attribute data has been reviewed and groups have been defined, it is necessary to define the attribute groups and process them into the database. The output of the prior step must be loaded into the staging table for Attribute Value Groups

(RSE_PROD_ATTR_GRP_VALUE_STG). This interface defines two sets of data and is used to load two different tables.

Table 18-1 RSE_PROD_ATTR_GRP_VALUE_STG

ColumnExampleDescription
PROD_HIER_TYPE_NAMEProduct HierarchyMust match the NAME from
RSE_HIER_TYPE that has the ID equal to
the RSE_CONFIG for CMGRP_HIER_TYPE.
PROD_EXT_KEYCLS100010000The external key used to identify the product
category (for example, Coffee Class). This
value is the same as in RADM’s
INTEGRATION_ID of the
W_PROD_CAT_DH, and also the
PROD_EXT_KEY of the
RSE_PROD_SRC_XREF table.
ATTR_SHORT_DB_NAMEFLAVORThis must match the SHORT_DB_NAME of
the RSE_BUSINESS_OBJECT_ATTR_MD
table for the newly added attribute.
PROD_ATTR_GRP_EXT_K
EY		CLS100010000flavor_y
n
CLS100010000flavor_t
ype		This must be a unique value to describe the
attribute to be used by the applications.
Since the source Flavor attribute is being
defined as two different attributes, two
example values are shown here.
PROD_ATTR_GRP_NAMEFlavorYN
FlavorType		A name to be displayed in the UI for the new
attribute. Two example values are shown
here.
PROD_ATTR_GRP_DESCRFlavor Y/N Indentifier
Flavor Type		An optional/additional descriptive value that
can be displayed in the UI for the new
attribute.
PROD_ATTR_VALUE_KEY(See additional table
below)		A unique/external identifier for the new
attribute values.
PROD_ATTR_VALUE_NAM
E		(See additional table
below)		A name displayed in the UI for the attribute
value.
PROD_ATTR_VALUE_DES
CR		(See additional table
below)		An optional/additional descriptive value that
could be shown in the UI for the new attribute
value.
FUNC_ATTR_FLGNThis is a Y/N flag to indicate whether this
attribute is considered to be an attribute
associated with a specific function or role (Y)
or not (N).
For example, a customer cannot choose a
product with a different value for the auto
wiper blade size because each car model
has a specific size requirements.

Here is a table showing the different values for adding the example Flavor Attribute Values.

Table 18-2 Flavor Attribute Values

PROD_ATTR_PROD_ATTR_VALUE_KEYPROD_ATTR_VALUPROD_ATTR_VALUE
GRP_NAMEE_NAME_DESCR
FlavorYNCLS100010000flavor_ynyYYes
FlavorYNCLS100010000flavor_ynnNNo
FlavorTypeCLS100010000flavor_typenonNon FlavoredNon Flavored

Table 18-2 (Cont.) Flavor Attribute Values

PROD_ATTR_
GRP_NAME		PROD_ATTR_VALUE_KEYPROD_ATTR_VALU
E_NAME		PROD_ATTR_VALUE
_DESCR
FlavorTypeCLS100010000flavor_typefruitFruit FlavoredFruit Flavored
FlavorTypeCLS100010000flavor_typemildMild FlavoredMild Flavored
FlavorTypeCLS100010000flavor_typespec
ial		SpecialtySpecialty

Populate RSE_PROD_ATTR_VALUE_XREF_STG Interface

Once the RSE_PROD_ATTR_GRP_VALUE_STG interface has been loaded, it is possible to load the RSE_PROD_ATTR_VALUE_XREF_STG interface with a mapping of actual product attribute values (otherwise known as base attributes) to the attribute groups that were loaded via RSE_PROD_ATTR_GRP_VALUE_STG. The format of data to be loaded here depends on the format of the base attributes. Only one set of attribute value columns should be populated for this interface. These sets are MIN_ATTR_NUM_VALUE and MAX_ATTR_NUM_VALUE (for numeric attributes), ATTR_STRING_VALUE (for text attributes), MIN_ATTR_DATE_VALUE and MAX_ATTR_DATE_VALUE (for date attributes), ATTR_VALUE_EXT_CODE (for dimension-based attributes). The sets are mutually exclusive of each other for this interface.

Table 18-3 RSE_PROD_ATTR_VALUE_XREF_STG

ColumnExampleDescription
PROD_ATTR_VALUE_KE
Y		CLS100010000~flavor_yn
~y		Must match a PROD_ATTR_VALUE_KEY that
was loaded via the
RSE_PROD_ATTR_GRP_VALUE_STG
interface.
MIN_ATTR_NUM_VALUE0Minimum numeric value to associate with this
attribute group value. Only applicable if this
attribute uses the ATTR_NUM_VALUE column
to store the base attribute value.
MAX_ATTR_NUM_VALU
E		7The maximum numeric value to associate with
this range. Only applicable in conjunction with
MIN_ATTR_NUM_VALUE.
ATTR_STRING_VALUEYA string value to associate with this attribute
group value. Only applicable if this attribute
uses the ATTR_STRING_VALUE column to
store the base attribute value.
MIN_ATTR_DATE_VALU
E		2010-01-01The minimum date value to associate with this
attribute group value. Default date format for
provided control file is YYYY-MM-DD. Only
applicable if this attribute uses the
ATTR_DATE_VALUE column to store the base
attribute value.
MAX_ATTR_DATE_VALU
E		2010-01-31The maximum date value to associate with
this attribute group value. Default date format
for provided control file is YYYY-MM-DD. Only
applicable in conjunction with
MIN_ATTR_DATE_VALUE.

Table 18-3 (Cont.) RSE_PROD_ATTR_VALUE_XREF_STG

Column
Example		Description
ATTR_VALUE_EXT_COD
32		For base attributes that are sourced from
EW_RTL_ITEM_GRP1_D, this column can be
used to specify the key from the appropriate
source column. This is applicable if this
attribute uses ATTR_VALUE_EXT_CODE to
store the attribute value.

Here is a table containing some examples for adding a new flavor attribute, using string-based attributes.

Table 18-4 Adding a New Flavor Attribute

PROD_ATTR_VALUE_KEYATTR_STRING_VALUE
CLS100010000flavor_ynyBLUEBERRY
CLS100010000flavor_ynyRASPBERRY
CLS100010000flavor_ynyVANILLA
S100010000flavor_ynyCARAMEL
CLS100010000flavor_ynyCINNAMON
CLS100010000flavor_ynyHAZELNUT
CLS100010000flavor_ynnPLAIN
CLS100010000flavor_typenonPLAIN
CLS100010000flavor_typefruitBLUEBERRY
CLS100010000flavor_typefruitRASPBERRY
CLS100010000flavor_typemildHAZELNUT
CLS100010000flavor_typemildVANILLA
CLS100010000flavor_typespecialCINNAMON
CLS100010000flavor_typespecialCARAMEL

In this guide

  • 24 FAQs — AI Foundation Implementation Guide · shares ATTR_STRING_VALUE, ATTR_VALUE_EXT_CODE, MAX_ATTR_DATE_VALUE, MAX_ATTR_NUM_VALUE
  • 23 Targeted Items Recommendation — AI Foundation Implementation Guide · shares ATTR_VALUE_EXT_CODE, FUNC_ATTR_FLG, RSE_BUSINESS_OBJECT_ATTR_MD, RSE_BUSINESS_OBJECT_DB_SRC
  • 2 Setup and Configuration — Retail Insights Cloud Service Implementation Guide · shares INTEGRATION_ID, W_PRODUCT_ATTR_D, W_RTL_ITEM_GRP1_D
  • 6 Data Validation Framework — AI Foundation Operations Guide · shares W_DOMAIN_MEMBER_LKP_TL, W_PRODUCT_ATTR_D, W_PRODUCT_D
  • 3 AI Foundation Data Batch Architecture — AI Foundation Operations Guide · shares W_PRODUCT_D, W_RTL_ITEM_GRP1_D

Graph View

Backlinks