Three-schema architecture and user perspective: To effectively use a DBMS for application development, which level must an application programmer primarily understand?

Introduction / Context:
The ANSI/SPARC three-schema architecture separates database descriptions into external (subschema), conceptual (logical model), and internal (physical storage) levels. This separation promotes independence between application programs and physical data organization.

Given Data / Assumptions:

• The question targets what an application developer needs to understand to build correct queries and updates.
• We assume a DBMS that supports user-specific views (subschemas).
• Physical storage details should not be required for typical application logic.

Concept / Approach:
Application programmers work with the external schema (their subschema), which presents tailored views and hides irrelevant structure. They do not need to master the physical schema (file layouts, indexes) to write business logic. Nor do they need to know all subschemas—only their own view.

Step-by-Step Solution:
Identify the user level closest to programs: the external schema (subschema).Note that only the relevant subschema matters for each application or user.Choose “one subschema” as the minimal necessary knowledge.

Verification / Alternative check:
Database textbooks explain external/conceptual/internal separation; application independence from physical details is a core benefit of DBMSs and logical data independence.

Why Other Options Are Wrong:

• The physical schema: Too low-level; typically unnecessary for app code.
• All subschemas: Impractical and irrelevant to a single application.
• Both (a) and (b): Combines two incorrect/extreme requirements.

Common Pitfalls:
Hard-coding assumptions about physical storage into applications reduces portability and maintainability. Always program against views and logical models exposed to the application.

Final Answer:
one subschema