Results for “label_code”

10 results




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

Overview

IBC_LABELS_B is a base table in the IBC schema belonging to the Oracle E-Business Suite Content Manager module (product code IBC). It is the primary definition table for labels used throughout the Content Manager framework. Labels serve as reusable classification tags that can be attached to content item versions, enabling categorization, filtering, and metadata-driven retrieval of managed content within IBC.

The table follows the standard Oracle EBS multi-language architecture: IBC_LABELS_B stores language-independent label attributes while IBC_LABELS_TL holds the translatable text. This pattern is consistent with other _B/_TL table pairs in the EBS data model and allows a single label definition to carry multiple translated descriptions.

From a Data Vault modeling perspective, the metadata classifies this object heuristically as hub-leaning. This is a reasonable suggestion: LABEL_CODE acts as a stable business key around which descriptive attributes such as audit columns and security group are attached. Under a Data Vault design, one might model a label hub keyed on LABEL_CODE with a satellite carrying the audit and descriptive attributes, though the presence of edition tracking (see below) suggests additional historical handling may be warranted.

Key Information Stored

The table exposes nine documented columns. The most significant are:

  • LABEL_CODE — the business identifier for the label and the column referenced by every foreign key relationship involving this table. Applications resolve a label by its code rather than by a numeric surrogate, which is why the code itself is documented as both the primary key and a business-key candidate.
  • SECURITY_GROUP_ID — a foreign key to FND_SECURITY_GROUPS, implementing Oracle's application-level data security (row-level access) model. Each label definition is isolated to a security group.
  • OBJECT_VERSION_NUMBER — the optimistic-locking column used by the Oracle Application Framework (OAF) and forms-based UI to detect concurrent updates and raise a "record has been modified" condition.
  • ZD_EDITION_NAME — part of the editioning mechanism introduced for online patching in EBS 12.2. Its appearance in the IBC_LABELS_B_U1 unique index (LABEL_CODE, ZD_EDITION_NAME) reflects the 12.2 edition-based redefinition strategy and is absent from 12.1.1 implementations.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide the standard who-did-what-and-when audit trail populated by the standard EBS WHO columns.

Two unique indexes are relevant: IBC_LABELS_B_PK on LABEL_CODE (the primary key) and IBC_LABELS_B_U1 on LABEL_CODE, ZD_EDITION_NAME (the edition-aware uniqueness constraint). Note that LABEL_CODE is the business key candidate; there is no separate numeric surrogate identifier documented.

Common Use Cases and Queries

Typical scenarios involving this table include:

  • Enumerating available labels — retrieving all active label codes and joining to IBC_LABELS_TL for the display name in the current language:
SELECT b.label_code, t.description
FROM   ibc_labels_b  b,
       ibc_labels_tl t
WHERE  b.label_code = t.label_code
AND    t.language = USERENV('LANG')
  • Finding labels applied to content item versions — joining through the association table IBC_CITEM_VERSION_LABELS to inventory which labels tag which versions:
SELECT cvl.citem_version_id, cvl.label_code
FROM   ibc_citem_version_labels cvl,
       ibc_labels_b            b
WHERE  cvl.label_code = b.label_code
  • Audit and security review — listing labels created or modified within a date range, or filtered by SECURITY_GROUP_ID:
SELECT label_code, created_by, creation_date, security_group_id
FROM   ibc_labels_b
WHERE  creation_date >= :from_date

Reporting use cases include content governance dashboards (how many labels are defined and used), data migration validation (label coverage across versions), and security alignment checks. SECURITY_GROUP_ID should always be considered in queries executed under a restricted responsibility.

Related Objects

The table's documented relationships are:

  • IBC_LABELS_TL — the translation child table; joined on LABEL_CODE. This is the principal companion object for any label query requiring user-facing text.
  • IBC_CITEM_VERSION_LABELS — the association table linking content item versions to labels; joined on LABEL_CODE. This is the primary consumer of the label definitions and is central to content tagging.
  • FND_SECURITY_GROUPS — the referenced security group table, joined on SECURITY_GROUP_ID, governing row visibility.

These three relationships define the operational footprint of IBC_LABELS_B: it is a low-volume definition table referenced by the higher-volume version-label association table, with translations supplied by the _TL sibling. Any content reporting or integration touching IBC labels should traverse through IBC_CITEM_VERSION_LABELS and IBC_LABELS_TL rather than querying the base table in isolation.