DBMS · Module 5 — SQL
Views
A view is a named saved query that stores no rows — it hides columns and complexity, always reflects the current data, and only a materialized view actually stores results.
The exam office needs to see grades. They must not see fee balances — that's in the same Student table.
You could write them a careful query and hope they never edit it. Or you could hand them a window that only shows what they're allowed to see.
Why & what
You already met the idea in 1.3 without the name: the external level, where each user sees only their own slice of the database. A view is how you actually build that slice.
A view is a saved query with a name. It stores no rows of its own — every time you read it, its query runs again on the real tables underneath.
How it works
- Write the query you want people to have. Join Student and Enrollment, select name, course, grade — and simply don't include fees_due.
- Save it with a name.
CREATE VIEW student_grades AS
SELECT s.name, e.course, e.grade
FROM Student s
JOIN Enrollment e ON s.roll_no = e.roll_no;
- Use it like a table. SELECT * FROM student_grades WHERE grade = 'A' works exactly as if it were one. That's the whole appeal — the join is hidden inside.
- Notice what's not there. fees_due is unreachable through this view. Give the office access to the view instead of the table, and the money column is invisible to them.
- Watch it stay current. Update a grade in Enrollment and the view shows the new value immediately — because it holds no copy. It re-runs its query each time you read it.

Notice: a view stores no rows — it re-runs its query every time you read it.
Common confusion
The big one: people think a view stores data. It doesn't. It's a saved query, so it costs storage of essentially nothing and costs query time every read.
The exception worth naming: a materialized view does store the result physically. It's fast to read but goes stale until it's refreshed. Normal view = always fresh, re-computed. Materialized view = fast, possibly stale.
Second: can you update through a view? Sometimes. A simple view over one table usually accepts updates. A view with joins, GROUP BY, or DISTINCT usually doesn't — because the database can't work out which underlying row you meant to change.
Interview angle
- "What is a view and why use one?" — A saved query used like a table. Reasons: hide sensitive columns, hide complex joins, and give different users different slices.
- "Does a view store data?" — No, it re-runs its query each time. A materialized view does store results, trading freshness for speed.
- "Can you INSERT or UPDATE through a view?" — Simple single-table views, usually yes. Views with joins or aggregates, usually no, because the target row is ambiguous.
Quiz: skipped — reinforced above.
Recap
A view is a named saved query that stores no rows — it hides columns and complexity, always reflects the current data, and only a materialized view actually stores results.