Search Results pji_system_parameters_pk

Overview

PJI_SYSTEM_PARAMETERS is a configuration table owned by the PJI schema, the database account associated with Oracle Projects Intelligence, one of the analytical modules delivered with Oracle Projects. The table stores installation-level settings that govern how a Projects Intelligence implementation behaves at runtime, supplying the parameter values consumed by the intelligence engines, extraction programs, and user-facing reporting components. Its documented description in the ETRM repository is simply "Information about the configuration of an Oracle Projects Intelligence installation," which confirms its role as a lightweight, name-value configuration store rather than a transactional business entity.

The object carries a VALID status in the ETRM dictionary and is documented with only two physical columns, NAME and VALUE, making it one of the smallest tables in the PJI schema. The declared primary key is PJI_SYSTEM_PARAMETERS_PK, implemented on the NAME column, and a second unique index, PJI_SYSTEM_PARAMETERS_U1, is also defined on NAME. This redundancy is typical of seeded system parameter tables where a single business identifier column anchors every lookup. Under the ETRM heuristic Data Vault classification, the table is identified as standalone, indicating that it participates in no foreign-key relationships. From a modeling perspective, this suggests treating the table as an independent reference or configuration structure rather than a hub, link, or satellite within a Data Vault model, since it neither resolves business keys across entities nor records change history for a parent hub.

Key Information Stored

The documented physical schema for PJI_SYSTEM_PARAMETERS in ETRM 12.2.2 lists exactly two columns:

• NAME — The parameter identifier. This column is both the primary key component (PJI_SYSTEM_PARAMETERS_PK) and the documented business-key candidate through the unique index PJI_SYSTEM_PARAMETERS_U1. In practice, NAME holds the short code or token by which a configuration setting is addressed, such as a flag controlling an intelligence feature, a default processing option, or a reference to a seeded installation attribute.
• VALUE — The parameter value associated with the corresponding NAME. Because no datatype qualifiers are exposed in the metadata, VALUE is generally treated as a character string carrying the configured setting, which consuming programs interpret according to the semantics of the named parameter.

There is no separate surrogate key column: the business key and the primary key coincide on NAME, and the table is intentionally narrow to keep configuration lookups inexpensive. No descriptive, audit, or timestamp columns are documented, so change tracking for these settings, if required, must be derived externally from application behavior or archived comparisons rather than from the table itself.

Common Use Cases and Queries

The primary use of PJI_SYSTEM_PARAMETERS is diagnostic and administrative: implementers and support analysts query it to confirm how a Projects Intelligence installation has been configured, and to compare settings across environments during cloning, patching, or upgrade activities. Typical retrievals include selecting all parameters to obtain a full configuration snapshot, and selecting a single value by name for verification. Representative patterns include:

• SELECT name, value FROM pji.pji_system_parameters ORDER BY name; — full configuration inventory for an environment baseline.
• SELECT value FROM pji.pji_system_parameters WHERE name = :parameter_name; — targeted lookup of one setting.
• SELECT a.name, a.value AS source_value, b.value AS target_value FROM pji_system_parameters a JOIN j2.pji_system_parameters b ON a.name = b.name WHERE a.value <> b.value; — cross-environment comparison against a cloned or reference schema.

Reporting use cases are similarly modest: configuration audits, pre-upgrade readiness checks, and regression comparison after applying patches. Because the table is small and static between maintenance windows, its contents are also suitable for periodic snapshotting into a change-log table if configuration drift monitoring is desired.

Related Objects

The ETRM relationship data classifies PJI_SYSTEM_PARAMETERS as standalone, with no foreign keys outgoing to parent tables and no documented incoming references. Consequently, the following related objects are identified by module and naming convention rather than by explicit join columns:

• PJI_SYSTEM_PARAMETERS_PK — the primary key constraint on NAME; the authoritative access path for all lookups.
• PJI_SYSTEM_PARAMETERS_U1 — the unique index on NAME, which reiterates NAME as the business-key candidate.
• PJI application schema objects — other configuration and staging tables in the PJI schema that share the installation context, including parameter-driven extract and load structures.
• Oracle Projects Intelligence concurrent programs — the execution components that read parameter values at runtime to determine processing behavior.
• PA (Oracle Projects) base tables — the upstream project, expenditure, and resource data that Projects Intelligence consumes and whose processing is affected by these settings.

Because no join columns are documented, integration with other objects occurs indirectly, through the parameter values themselves rather than through referential constraints. Any dependency mapping for this table must therefore be established at the application layer.