Keys and nullability: May a primary key attribute (or any component of a composite primary key) be null in a properly designed relational table?

Introduction / Context:
Primary keys uniquely identify rows in a table. This unique identification fails if the key can be null, because null represents “unknown or inapplicable” and does not compare equal to anything, including itself. Hence, nulls are incompatible with strict uniqueness semantics for primary keys.

Given Data / Assumptions:

• A primary key must uniquely identify every row and must be stable and minimal.
• Database systems enforce NOT NULL on primary key columns by design or by best practice.
• Composite keys inherit the same rule: no component may be null.

Concept / Approach:
If a primary key contained null, two issues arise: (1) you could not guarantee uniqueness (because null is not equal to any value); (2) referential integrity could break, as foreign keys referencing null would be ambiguous or invalid for identification. Therefore, primary keys must be defined as NOT NULL.

Step-by-Step Solution:
Define a primary key column (or set of columns).Apply NOT NULL constraints to all key components.Create unique indexes as needed to enforce uniqueness.Use surrogate keys (IDENTITY, SERIAL, UUID) if natural keys can be missing or unstable.Validate incoming data to prevent nulls in key columns.

Verification / Alternative check:
Attempt to insert a row with null in a primary key column in a standards-compliant database; the operation will be rejected due to NOT NULL enforced by the primary key constraint.

Why Other Options Are Wrong:
Correct: contradicts relational rules for primary keys.Allowed only if surrogate: surrogate keys are also primary keys; null still disallowed.Allowed once per table: not true; PK columns can never be null.

Common Pitfalls:
Confusing “unique but nullable” candidates with primary keys; some DBMSs allow multiple nulls in unique columns, but not in primary key columns.

Final Answer:
Incorrect