Results for “css_def_defect_links”

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

Overview

CSS_DEF_DEFECT_LINKS is a Support module table in Oracle E-Business Suite that models a many-to-many association between defect records. Per the ETRM metadata, its documented purpose is to "identify a link from one Defect to another," meaning each row represents a directed relationship originating at one defect and terminating at another. The table belongs to the CSS - Support product, which the metadata flags as obsolete, and the implementation note explicitly states that the object is "Not implemented in this database." Readers should therefore treat CSS_DEF_DEFECT_LINKS as a legacy or historical artifact of the CSS data model rather than an active repository in typical 12.1.1 or 12.2.2 installations.

The heuristic Data Vault classification derived from the foreign-key structure is link. In Data Vault modeling terms, this is a natural fit: the table exists solely to resolve an association between two instances of the same parent entity, and it carries no descriptive attributes of its own beyond the surrogate identifier. A modeler reconstructing this schema would place CSS_DEF_DEFECTS_B as the hub and CSS_DEF_DEFECT_LINKS as the link joining one hub row to another via the FROM_ID and TO_ID columns.

Key Information Stored

The metadata documents a compact column set. The essential elements are:

• LINK_ID — the surrogate primary key of the table, enforced by the constraint CSS_DEF_DEFECT_LINKS_PK. This is the column the user's search term "css_def_defect_links_pk" maps to. It is a system-generated identifier with no business meaning.
• FROM_ID — foreign key referencing CSS_DEF_DEFECTS_B. Identifies the source defect in the relationship.
• TO_ID — foreign key referencing CSS_DEF_DEFECTS_B. Identifies the target defect in the relationship.

Both FROM_ID and TO_ID resolve to the same parent table, CSS_DEF_DEFECTS_B, which is characteristic of a self-referencing link structure. The metadata documents no unique index or alternate business key beyond the primary key, so no natural key candidate is evidenced; uniqueness of the defect pairing, if enforced at all, would most plausibly be expressed as a composite constraint over FROM_ID and TO_ID, but this is not documented. The absence of audit columns, type codes, or timestamps in the metadata suggests either that the table is minimal by design or that additional columns were never captured.

Common Use Cases and Queries

The principal analytical value of this table is relationship traversal between defects — for example, determining which defects are linked as duplicates, parents, or dependencies. Because it is documented as not implemented, queries against it in a live 12.1.1 or 12.2.2 instance will typically fail with an ORA-00942 unless the object exists as a legacy remnant. Where the structure is available, a representative pattern to enumerate links with both endpoints resolved is:

• SELECT l.link_id, f.defect_number AS from_defect, t.defect_number AS to_defect FROM css_def_defect_links l JOIN css_def_defects_b f ON f.defect_id = l.from_id JOIN css_def_defects_b t ON t.defect_id = l.to_id;
• Count outbound links per defect by grouping on FROM_ID to identify the most frequently referenced defects.
• Detect reciprocal or cyclic links by self-joining the table on reversed FROM_ID and TO_ID pairs.
• Feed defect dependency graphs into reporting tools for impact analysis during patch or upgrade planning.

Migration and archival projects frequently encounter such obsolete tables; extracting CSS_DEF_DEFECT_LINKS alongside CSS_DEF_DEFECTS_B preserves the historical relationship graph before the schema is retired.

Related Objects

The documented referential footprint is narrow, with both foreign keys pointing to a single parent:

• CSS_DEF_DEFECTS_B — referenced by CSS_DEF_DEFECT_LINKS.FROM_ID; the source defect.
• CSS_DEF_DEFECTS_B — referenced by CSS_DEF_DEFECT_LINKS.TO_ID; the target defect.
• CSS_DEF_DEFECT_LINKS_PK — the primary key constraint over LINK_ID that identifies each link row uniquely.

No views, APIs, or dependent child tables are enumerated in the supplied metadata. Practically, CSS_DEF_DEFECTS_B and its translated or _TL counterparts constitute the only significant join partners, and any downstream reporting object that consumes defect relationships would transitively depend on this link table.