In legacy navigational or file-based systems, what do embedded pointers primarily provide with respect to accessing records?

Introduction / Context:
Before relational databases became dominant, many systems used navigational access. Records were linked with pointers embedded within the data, enabling applications to traverse related records efficiently. Understanding the role of these pointers clarifies the difference between navigational and set-based access models.

Given Data / Assumptions:

• We consider schemes where records contain pointers to other records.
• The goal is faster traversal along predefined relationships.
• We are not creating separate index structures.

Concept / Approach:
Embedded pointers act as in-record links that create an additional, alternative route to reach related records—effectively a secondary access path. They do not themselves constitute a physical record key (that is an identifier for the record) and they are not equivalent to an inverted index, which is a separate structure mapping values to record locations.

Step-by-Step Solution:

Verification / Alternative check:
Descriptions of CODASYL/network databases emphasize set membership pointers as navigation channels distinct from key-based indexing.

Why Other Options Are Wrong:

• Physical record key: identifies a record, not a path to others.
• Inverted index: a separate index file or structure, not embedded pointers.
• All or None: conflate distinct concepts or deny the valid one.

Common Pitfalls:
Assuming pointers and indexes are interchangeable; confusing record identifiers with navigation links; overusing embedded pointers leading to rigid application logic.

Final Answer:
a secondary access path