Using views to expose calculations:\nEvaluate the statement:\n\n"Views can be used to show the results of computed (derived) columns."

Introduction / Context:
Views are virtual tables defined by queries. A common use case is to present derived or computed results—such as totals, formatted values, or conditional labels—without asking application code to repeat the same expressions everywhere. This question checks whether views can legitimately expose computed values to consumers.

Given Data / Assumptions:

• A view is defined with a SELECT that includes expressions (e.g., price * qty AS line_total).
• No requirement is stated that the values be physically stored.
• Standard relational DBMS semantics apply.

Concept / Approach:
Because a view definition is a SELECT statement, any expression allowed in SELECT—arithmetic, string functions, CASE, date math, aggregates with GROUP BY (subject to updatability differences), and window functions—can be projected as a column in the view. Consumers query the view and receive the computed results as if they were columns, improving consistency and encapsulation.

Step-by-Step Solution:

Verification / Alternative check:
Many systems also support materialized views that persist results; both standard (virtual) and materialized views can include computed expressions, though refresh strategies differ.

Why Other Options Are Wrong:

• Incorrect: Contradicts what a SELECT can project.
• Only for materialized views: Virtual views handle expressions just fine.
• Only with window functions: Ordinary expressions are sufficient.
• Only in warehouses: Views are used across OLTP and OLAP systems.

Common Pitfalls:
Confusing display of computed values (supported) with updating them (often not supported). Assuming views must store results—virtual views compute on demand.

Final Answer:
Correct