In relational database design, when the values in one or more attributes used as a foreign key must already exist as matching values in a candidate key of another table, what have we enforced?

Introduction / Context:
Foreign keys connect related tables. A core rule ensures that any foreign key value in a child table corresponds to an existing key value in the parent table. This rule prevents orphan records and maintains consistency across relations.

Given Data / Assumptions:

• A foreign key is defined in one table to reference a candidate key (often the primary key) in another table.
• The question asks which concept requires that referenced values exist before they can be used.
• We are working in a standard relational database context (SQL systems such as PostgreSQL, SQL Server, MySQL, Oracle).

Concept / Approach:
Referential integrity is the constraint that enforces valid references between related tables. It ensures every foreign key value either matches a candidate key value in the referenced table or is null (if allowed), thereby protecting data consistency.

Step-by-Step Solution:

Verification / Alternative check:
Consider a DELETE of a parent row. Without referential integrity, child rows referencing it would become orphans. With referential integrity, the DBMS blocks the delete, cascades the change, or sets nulls according to the defined action.

Why Other Options Are Wrong:

• Transitive dependency: a normalization concept about attribute dependencies, not cross-table references.
• Insertion anomaly: a symptom of poor design, not a constraint.
• Normal form: a classification of schema quality; it does not directly enforce cross-table references.

Common Pitfalls:
Assuming primary keys alone guarantee cross-table consistency. They do not; you must define foreign keys with referential actions.

Final Answer:
referential integrity constraint