If the parent entity is required by a foreign key constraint, can a new child row always be inserted unconditionally, or must a matching parent row already exist (or be created in the same transaction)?

Introduction / Context:
Foreign key constraints enforce that each child row's foreign key matches an existing parent key, unless the foreign key is NULL (when allowed). This question tests whether a child can be inserted “always” when a parent is required.

Given Data / Assumptions:

• The foreign key is NOT NULL (parent required).
• Referential integrity is enforced by the DBMS.
• Constraints may be immediate or deferrable (DBMS feature-dependent).

Concept / Approach:
When the parent is required, a child row can be inserted only if the corresponding parent row already exists or will exist by the time constraints are checked (e.g., within the same transaction for deferrable constraints). The blanket statement that a child can “always” be inserted is incorrect. Without a parent, the insert will fail with a referential integrity violation.

Step-by-Step Solution:

Verification / Alternative check:
Run a simple test: create parent and child tables with immediate constraints; try inserting child first — expect error; insert parent then child — succeeds.

Why Other Options Are Wrong:

• “Correct” contradicts referential integrity rules.
• “Only when the foreign key is deferrable” is too narrow; even then, parent must exist by commit.
• “Only if the parent has a surrogate key” is irrelevant; key type doesn’t relax integrity.
• “ON INSERT CASCADE” is not a standard referential action.

Common Pitfalls:
Confusing immediate vs. deferred constraint checking; relying on application order instead of transactional grouping; misinterpreting NULLable foreign keys as “parent required.”

Final Answer:
Incorrect