From a relational integrity perspective, how should a primary key be declared to ensure every row is uniquely and reliably identifiable?

Introduction / Context:
The primary key is the cornerstone of relational design. It uniquely identifies each row and serves as the target for foreign keys. If a primary key could be NULL, it would fail to identify the row and break referential integrity assumptions.

Given Data / Assumptions:

• Every table (except pure intersection tables using composite keys) should have a primary key.
• The DBMS enforces uniqueness and non-nullness for primary keys.
• NULL represents “unknown/absent,” which is incompatible with identity.

Concept / Approach:
A PRIMARY KEY constraint implicitly enforces NOT NULL and UNIQUE. If you define a composite primary key, every component is NOT NULL. This guarantees that each row has a fully populated identifier, enabling reliable joins and references.

Step-by-Step Solution:

Verification / Alternative check:
Attempting to insert a row with a NULL primary-key column should fail with a constraint violation, confirming enforcement.

Why Other Options Are Wrong:

• NULL: Cannot uniquely identify a row; multiple NULLs would be ambiguous.
• Either of the above: Not acceptable; PK must be NOT NULL.
• None of the above: Incorrect because NOT NULL is required.
• DEFERRABLE: Relates to timing of constraint checking; PK non-nullness is not deferrable in standard practice.

Common Pitfalls:
Selecting mutable attributes as PKs can cause cascading updates. Prefer stable natural keys or surrogates.

Final Answer:
NOT NULL.