Results for “feature_type”

50+ results




Overview
Explore in AI Chat

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

Overview

CZ_DES_CHART_FEATURES is a Configurator (CZ) module table in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented description is "Controlling features in each Design Chart." The table records the association between a configurable model's design chart, the controlling features it exposes, and the rules that govern those features. In the Oracle Configurator runtime and modeling environment, a design chart defines how a model's structure is presented and validated; this table captures which features act as drivers within that structure and under which rule and model-reference-explanation context they apply.

Because the table sits between rules, feature nodes, and model reference explanations, the ETRM relationship metadata classifies it heuristically as a link entity in a Data Vault model. This is a modeling suggestion only: the physical table functions as a many-to-many resolution table that connects three independent parent entities through foreign keys.

Key Information Stored

The table has 16 documented columns. The most significant are the following.

  • RULE_ID — Foreign key to CZ_RULES; identifies the configuration rule that controls the feature's behavior within the chart.
  • FEATURE_ID — Foreign key to CZ_PS_NODES; identifies the feature (a configurator node) being controlled.
  • MODEL_REF_EXPL_ID — Foreign key to CZ_MODEL_REF_EXPLS; identifies the model reference explanation that ties the feature and rule to a specific model context.
  • FEATURE_TYPE — Classifies the feature (for example, its role or category within the design chart).
  • FEATURE_SEQ_NBR — Sequence number governing display or evaluation order of the feature in the chart.
  • DELETED_FLAG — Soft-delete indicator; rows are typically retained for audit while logically removed.
  • EFF_FROM, EFF_TO, EFF_MASK — Effective dating columns controlling the date range during which the feature-to-chart association is valid.
  • SECURITY_MASK — Controls visibility or access restrictions on the feature association.
  • CHECKOUT_USER — Indicates the user who has the record checked out during model development, supporting concurrent editing.
  • Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide standard who/when tracking.

The primary key is CZ_DES_CHART_FEATURES_PK, defined on the composite of RULE_ID, FEATURE_ID, and MODEL_REF_EXPL_ID. All three columns are also foreign keys, so no separate surrogate key exists; the composite is both the primary key and the business-key candidate that enforces uniqueness of a rule-feature-model-reference combination.

Common Use Cases and Queries

Typical uses include tracing which features a given rule controls, listing all controlling features for a model reference explanation, and diagnosing why a feature is hidden, sequenced, or excluded during a configuration session.

A representative query joins the three parents:

  • Filter by RULE_ID to enumerate every feature controlled by a rule: SELECT FEATURE_ID, FEATURE_TYPE, FEATURE_SEQ_NBR FROM CZ_DES_CHART_FEATURES WHERE RULE_ID = :p_rule_id AND DELETED_FLAG = 'N';
  • Resolve feature names by joining FEATURE_ID to CZ_PS_NODES, and rule details by joining RULE_ID to CZ_RULES.
  • Apply effective dating with SYSDATE BETWEEN EFF_FROM AND EFF_TO to return only active associations.
  • Reporting on effective versus soft-deleted rows by including DELETED_FLAG and EFF_MASK in the filter.
  • Monitoring CHECKOUT_USER to detect models currently locked for editing.

Related Objects

The FK metadata identifies three direct parents, all joined through the composite primary key columns.

  • CZ_RULES — joined on CZ_DES_CHART_FEATURES.RULE_ID = CZ_RULES.RULE_ID; supplies rule definitions.
  • CZ_PS_NODES — joined on CZ_DES_CHART_FEATURES.FEATURE_ID = CZ_PS_NODES.FEATURE_ID; supplies feature/node attributes.
  • CZ_MODEL_REF_EXPLS — joined on CZ_DES_CHART_FEATURES.MODEL_REF_EXPL_ID = CZ_MODEL_REF_EXPLS.MODEL_REF_EXPL_ID; supplies the model reference explanation context.

These three relationships define the table's role as a link among rules, feature nodes, and model references. Reporting and validation should always respect the composite key and effective-dating columns to avoid double-counting features across model contexts.