Results for “ams_dm_categorical_bb”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AMS_DM_CATEGORICAL_BB is a table in the AMS (Marketing) schema of Oracle E-Business Suite, documented as VALID in both release 12.1.1 and 12.2.2. Its stated purpose is to hold bin boundary definitions for categorical columns in the data mining data source used by Oracle Marketing's data mining and predictive modeling functionality. In practical terms, the table stores the discretization metadata that tells the mining engine how to group or bucket the distinct values of a categorical column before model training or scoring.

From a heuristic Data Vault modeling perspective, the metadata classifies this object as standalone. That classification is a modeling suggestion rather than a binding rule: the table has no inbound foreign-key dependents identified in the mined relationship data, and its only documented outbound reference is to the FND security model. It therefore behaves like a reference or configuration satellite anchored to its own identity, not a transactional hub or an associative link. No relationship to a marketing campaign, list, or model entity is documented for this table, so it should be treated as a self-contained lookup of categorical binning rules.

Key Information Stored

The table is documented with 14 columns. The most significant are:

• CATEGORICAL_BB_ID — the surrogate primary key. It is the single column of primary key AMS_DM_CATEGORICAL_BB_PK and is also the business-key candidate exposed through unique index AMS_DM_CATEGORICAL_BB_U1.
• COLUMN_NAME — identifies the data mining source column to which the boundary definition applies. This is the principal business attribute and the natural driver of most queries.
• CATEGORY and CATEGORY_VALUE — together describe the categorical grouping and the individual value assigned to that grouping, forming the boundary content of each definition row.
• GROUP_ID and GROUP_NAME — carry the grouping identifier and its human-readable label, supporting display and filtering.
• IS_ATTRIBUTE — flags whether the referenced column is treated as an attribute in the mining context.
• SECURITY_GROUP_ID — the only documented foreign key, referencing FND_SECURITY_GROUPS, used for row-level security and multi-organization data restriction.
• Standard EBS audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN and OBJECT_VERSION_NUMBER for concurrent update control.

Common Use Cases and Queries

Typical usage is diagnostic and configuration-facing: verifying how a categorical source column was binned, reviewing which category values map to which group, and confirming security-group partitioning before running a mining build.

• Retrieving boundaries for a specific source column: SELECT category, category_value, group_id, group_name FROM ams.ams_dm_categorical_bb WHERE column_name = :col;
• Auditing recent configuration changes: SELECT categorical_bb_id, column_name, last_updated_by, last_update_date FROM ams.ams_dm_categorical_bb ORDER BY last_update_date DESC;
• Tracking which categories are not mining attributes: SELECT * FROM ams.ams_dm_categorical_bb WHERE NVL(is_attribute,'N') = 'N';
• Security review joins: SELECT b.column_name, s.security_group_name FROM ams.ams_dm_categorical_bb b, fnd_security_groups s WHERE b.security_group_id = s.security_group_id;

Related Objects

The documented relationship footprint is narrow, so the related-object list is correspondingly short:

• FND_SECURITY_GROUPS — referenced via AMS_DM_CATEGORICAL_BB.SECURITY_GROUP_ID, providing the security group name for each boundary row.
• AMS_DM_CATEGORICAL_BB_PK / AMS_DM_CATEGORICAL_BB_U1 — primary key and unique index on CATEGORICAL_BB_ID, the integrity anchors for the table.
• Other AMS_DM_* data mining data source tables in the AMS schema, which share the same mining metadata domain and are commonly queried alongside this table when reviewing mining setup.

Because the table is standalone, any additional referencing objects should be confirmed against the specific 12.1.1 or 12.2.2 instance rather than assumed from the mined FK structure.