Search Results bic_relationship_types




Overview
Explore in AI Chat

Overview

BIC.BIC_RELATIONSHIP_TYPES is a reference (lookup) table belonging to the BIC — Customer Intelligence product family, which Oracle has designated obsolete in current EBS releases. It stores the master list of relationship type codes that classify how one party (customer, contact, or organization) relates to another within the Customer Intelligence model — for example, relationships such as "spouse," "employee of," or "subsidiary of," depending on how the implementation seeded the table. Rather than holding transactional relationship instances, BIC_RELATIONSHIP_TYPES provides the permitted, display-enabled set of types that drive classification of actual party relationships elsewhere in the schema.

The ETRM metadata classifies this object, using a heuristic derived from its foreign-key structure, as a standalone Data Vault element. In Data Vault terms this is best treated as a hub-like reference dimension: it is not a link (it does not resolve many-to-many relationships between other hubs) and it is not a satellite of a single parent. Designers modeling this table as a raw vault object can treat PARTY_RELATIONSHIP_TYPE as the natural business key of the hub. Because the parent product is obsolete, the object is most commonly encountered today during legacy data migrations, discovery/impact analysis of the BIC schema, and archival reporting.

Key Information Stored

The table has eight documented columns. The most important include:

No separate surrogate primary-key column is documented; the sole unique index is the business-key candidate on PARTY_RELATIONSHIP_TYPE.

Common Use Cases and Queries

Typical usage centres on decoding relationship-type codes for reporting and validating that only display-enabled types are seeded:

  • LOV population — retrieve the types available for selection, filtered by display flag and security group:
    SELECT party_relationship_type FROM bic_relationship_types WHERE display_flag = 'Y' AND security_group_id = :g;
  • Code decode for joins — join a relationship fact table back to this lookup on the business key to render descriptions.
  • Seed/migration validation — confirm all expected relationship types exist, especially before and after BIC-to-successor-product migration, since BIC is obsolete.
  • Audit reporting — identify when types were created or last modified using the WHO columns, useful during evidence gathering for a data-governance or impact-assessment exercise.

Because the older BIC tables often duplicate security-group filtering, queries should always constrain SECURITY_GROUP_ID to avoid cross-tenant leakage.

Related Objects

  • FND_SECURITY_GROUPS — joined via BIC_RELATIONSHIP_TYPES.SECURITY_GROUP_ID → FND_SECURITY_GROUPS.SECURITY_GROUP_ID. The only documented foreign key of this table.
  • BIC_RELATIONSHIP_TYPES_U1 — the unique index enforcing the business key on PARTY_RELATIONSHIP_TYPE.
  • Party relationship tables within the BIC schema (e.g., relationship-instance tables) — logically depend on this lookup through PARTY_RELATIONSHIP_TYPE for classification and validation, even though no explicit FK is documented.
  • BIC customer/organization objects — the parties referenced by relationships ultimately resolve to these entities.
  • FND_APPLICATION — indirectly relevant for identifying the BIC product registration when tracing the obsolete module.

Given BIC's obsolete status, related-object discovery is best performed through the EBS data dictionary (FND tables and AD_ZD or DBA_ views) rather than relying on runtime dependency documentation.