Notation convention in schema documentation: Must the primary key be underlined in the relation schema, or is underlining merely a documentation convention rather than a requirement?

Introduction / Context:
During logical design, relation schemas are often shown in textbooks and design documents with the primary key attributes underlined. Students sometimes misinterpret this visual cue as an enforced rule in the DBMS. This question clarifies the difference between documentation notation and actual database constraints.

Given Data / Assumptions:

• We are discussing the appearance of relation schemas in documentation.
• We distinguish visual conventions from DBMS-enforced constraints.
• Primary keys in a DBMS are declared with constraints, not with underlining.

Concept / Approach:
Underlining a primary key attribute in a printed or written schema is a widely used notation to indicate key status at a glance. However, it is merely a convention for human readers. The DBMS recognizes primary keys because you define a PRIMARY KEY constraint in DDL. Nothing in SQL requires a particular visual notation, and documentation styles vary (boldface, asterisks, separate key lists, or crow’s-foot diagrams). Thus, the claim that the primary key “does not need to be underlined” is correct: underlining is optional as a documentation style, not a requirement for validity.

Step-by-Step Solution:

Verification / Alternative check:
Inspect any DBMS system catalog; primary key status is recorded in metadata tables, not inferred from a document’s typography.

Why Other Options Are Wrong:

• Mandatory underlining or dependence on BCNF, composite keys, or indexing has no basis in SQL standards.

Common Pitfalls:
Treating classroom notation as a DBMS rule; neglecting to define an actual PRIMARY KEY constraint in DDL because a diagram “shows” an underline.

Final Answer:
Correct (underlining is a convention, not a DBMS requirement)