Three-tier view of enterprise data access:\nJudge the statement:\n\n"In an enterprise-class database system, business users interact with database applications, which in turn talk to the DBMS, which directly accesses the stored database data."

Introduction / Context:
This statement summarizes the classic layered architecture used in most enterprise information systems: user interface layer → application/business logic → DBMS engine → physical data. Recognizing this separation of concerns is foundational to system design, performance tuning, and security.

Given Data / Assumptions:

• Business users work through applications (web, mobile, desktop, services).
• Applications connect to the DBMS via drivers/providers (JDBC/ODBC/native).
• The DBMS manages storage structures, transactions, and query processing against persistent data files.

Concept / Approach:
In both on-premises client/server and modern cloud deployments, applications rarely allow users to issue raw DBMS commands directly. Instead, application logic validates inputs, enforces business rules, and uses SQL or other APIs to interact with the DBMS, which then reads/writes to the underlying storage managed by the engine.

Step-by-Step Solution:

Verification / Alternative check:
Even in serverless/cloud databases, the pattern persists: clients call application services or managed endpoints; the engine still mediates all data access. Direct user-to-DB connections are reserved for administrators and specialized tools, not general business use.

Why Other Options Are Wrong:

• Incorrect and conditional variants: add unnecessary caveats; the layering applies widely (OLTP, OLAP, on-prem, and cloud).

Common Pitfalls:
Assuming users “hit the database” directly; skipping the app tier undermines validations, auditing, and security controls.

Final Answer:
Correct