Friday, March 27, 2026

Oracle SQL Views: CREATE, Types and DML Rules — 1Z0-071 Exam Guide

1Z0-071 Exam Prep Chapter 14 Volume 3

Views are one of the more nuanced topics on the 1Z0-071 exam. The questions are not just about CREATE VIEW syntax — they test whether you know when DML through a view is allowed, what WITH CHECK OPTION and WITH READ ONLY actually do, and how simple views differ from complex views in terms of what operations are permitted.

Get these rules clear and view questions become straightforward. Get them fuzzy and you will lose marks on questions that look simple on the surface.

01 — What a view is — and what it is not

A view is a stored SELECT statement. It has a name, it appears in the data dictionary, and you query it like a table. But it does not store data. Every time you query a view, Oracle runs the underlying SELECT against the base tables at that moment.

-- The view stores this definition
CREATE VIEW emp_dept50
AS
SELECT employee_id, last_name, salary, department_id
FROM   employees
WHERE  department_id = 50;

-- Querying the view runs the stored SELECT against EMPLOYEES
SELECT * FROM emp_dept50;
-- Equivalent to running the full SELECT directly
-- Data comes from EMPLOYEES — not stored in the view itself
No data storage: A view is just a query with a name. The base tables hold the data. If the base table data changes, a subsequent query on the view reflects those changes automatically. This is different from a materialized view, which does store data — but materialized views are not on the 1Z0-071 exam syllabus.

02 — CREATE VIEW syntax

The basic syntax is straightforward. Column aliases in the view can be defined either inside the SELECT or in a column list after the view name.

-- Basic view
CREATE VIEW emp_dept50
AS
SELECT employee_id, last_name, salary
FROM   employees
WHERE  department_id = 50;

-- Column aliases defined in the view name header
CREATE VIEW emp_summary (id, name, annual_sal)
AS
SELECT employee_id, last_name, salary * 12
FROM   employees;
-- Column aliases required in the header when the SELECT uses expressions
-- because expressions have no default column name

-- OR define aliases inline in the SELECT
CREATE VIEW emp_summary
AS
SELECT employee_id AS id,
       last_name    AS name,
       salary * 12  AS annual_sal
FROM   employees;

-- CREATE OR REPLACE — modify the view definition without dropping first
CREATE OR REPLACE VIEW emp_dept50
AS
SELECT employee_id, last_name, salary, job_id
FROM   employees
WHERE  department_id = 50;
Expressions need aliases: If the SELECT list contains any expression (such as salary * 12 or a function call), that column has no default name. The view creation will fail unless you provide an alias — either in the column list after the view name or inline in the SELECT with AS.

03 — Simple views vs complex views

The exam distinguishes between simple and complex views based on what the underlying SELECT contains. This classification matters because it determines whether DML through the view is possible.

Feature in the SELECTSimple viewComplex view
Number of base tablesOneTwo or more (JOIN)
GROUP BY / HAVINGNot presentPresent
DISTINCT keywordNot presentPresent
Group functions (SUM, AVG etc.)Not presentPresent
DML operations allowed?Generally yesGenerally no
-- Simple view — one table, no aggregates, no DISTINCT
CREATE VIEW simple_emp
AS
SELECT employee_id, last_name, salary, department_id
FROM   employees
WHERE  department_id = 50;

-- Complex view — JOIN across two tables
CREATE VIEW emp_with_dept
AS
SELECT e.employee_id, e.last_name, d.department_name
FROM   employees e
JOIN   departments d ON e.department_id = d.department_id;

-- Complex view — aggregate function
CREATE VIEW dept_summary
AS
SELECT   department_id, COUNT(*) headcount, AVG(salary) avg_sal
FROM     employees
GROUP BY department_id;

04 — DML through a view — when it is allowed

You can run INSERT, UPDATE, and DELETE through a view in some cases. The rules depend on what the view's SELECT contains. This is one of the most tested areas in the entire views topic.

View containsINSERTUPDATEDELETE
Simple single-table viewYesYesYes
JOIN (multiple tables)NoSometimes — only the key-preserved tableNo
GROUP BY / aggregate functionsNoNoNo
DISTINCTNoNoNo
Expressions (e.g. salary * 12)No — on that columnNo — on that columnYes
Pseudocolumn (ROWNUM)NoNoNo
-- Simple view — DML is allowed
UPDATE simple_emp
SET    salary = 6000
WHERE  employee_id = 120;
-- This updates the EMPLOYEES base table directly

-- View with expression — cannot UPDATE the expression column
CREATE VIEW emp_annual
AS
SELECT employee_id, last_name, salary * 12 AS annual_sal
FROM   employees;

UPDATE emp_annual SET annual_sal = 72000 WHERE employee_id = 100;
-- Error: virtual column not allowed here
-- DELETE through this view is still allowed though
Key-preserved table in JOINs: In a view based on a JOIN, UPDATE and DELETE are allowed only against the key-preserved table — the table whose primary key is still unique in the view's result set. INSERT is never allowed through a JOIN view. This is an advanced rule the exam occasionally tests.

05 — WITH CHECK OPTION

WITH CHECK OPTION prevents DML through the view from creating or modifying rows that would no longer be visible through that view. It enforces that any row inserted or updated must still satisfy the view's WHERE clause.

CREATE VIEW emp_dept50
AS
SELECT employee_id, last_name, salary, department_id
FROM   employees
WHERE  department_id = 50
WITH CHECK OPTION CONSTRAINT emp_d50_ck;

-- This UPDATE is rejected — it would move the row out of dept 50
-- meaning the row would no longer be visible through the view
UPDATE emp_dept50
SET    department_id = 80
WHERE  employee_id = 120;
-- Error: new row does not satisfy the view's WHERE clause

-- This UPDATE is allowed — salary change keeps the row in dept 50
UPDATE emp_dept50
SET    salary = 7000
WHERE  employee_id = 120;
-- Allowed: row still visible through the view after the change
What WITH CHECK OPTION does not do: It does not prevent DML on columns outside the view's SELECT list. It also does not affect queries — only INSERT and UPDATE operations. DELETE is not affected because deleting a row cannot change whether the row satisfies the WHERE clause.

06 — WITH READ ONLY

WITH READ ONLY prevents all DML through the view — INSERT, UPDATE, and DELETE are all blocked. The view can still be queried. This is the strongest form of view protection.

CREATE VIEW emp_readonly
AS
SELECT employee_id, last_name, salary
FROM   employees
WITH READ ONLY;

-- Any DML raises ORA-42399
UPDATE emp_readonly SET salary = 5000 WHERE employee_id = 100;
-- Error: ORA-42399: cannot perform a DML operation on a read-only view

-- Queries work fine
SELECT * FROM emp_readonly;  -- allowed
WITH CHECK OPTIONWITH READ ONLY
Blocks INSERT?Only if new row fails WHERE clauseAlways
Blocks UPDATE?Only if updated row fails WHERE clauseAlways
Blocks DELETE?NoAlways
Blocks SELECT?NoNo
Error raisedORA-01402ORA-42399

07 — Modifying and dropping views

Views can be replaced without dropping them first using CREATE OR REPLACE VIEW. Dropping a view removes its definition from the data dictionary but does not affect the underlying base tables or their data.

-- Replace an existing view definition
CREATE OR REPLACE VIEW emp_dept50
AS
SELECT employee_id, last_name, salary, job_id, department_id
FROM   employees
WHERE  department_id = 50;
-- Overwrites the existing definition in place
-- If the view did not exist, it is created fresh

-- Drop a view
DROP VIEW emp_dept50;
-- Removes the view definition only
-- The EMPLOYEES base table and its data are not affected
DROP VIEW vs DROP TABLE: Dropping a view never removes any data. Dropping the base table, however, invalidates any views built on it. Oracle marks those views as invalid — they remain in the data dictionary but raise an error when queried until the base table is recreated.

08 — Inline views vs stored views

An inline view is a subquery in the FROM clause — it behaves like a view for the duration of one query but is not stored anywhere. A stored view has a name, lives in the data dictionary, and persists across sessions.

-- Inline view — exists only for this query
SELECT dept_avg.department_id, dept_avg.avg_sal
FROM  (SELECT   department_id, AVG(salary) AS avg_sal
       FROM     employees
       GROUP BY department_id) dept_avg
WHERE dept_avg.avg_sal > 7000;

-- Stored view — persists in the data dictionary
CREATE VIEW dept_avg_view
AS
SELECT   department_id, AVG(salary) AS avg_sal
FROM     employees
GROUP BY department_id;

SELECT * FROM dept_avg_view WHERE avg_sal > 7000;

09 — Quick reference

RuleDetail
Views store no dataData lives in base tables — view is a stored SELECT only
Expressions need aliasesCREATE VIEW fails if a SELECT expression has no column name
CREATE OR REPLACEReplaces existing view without dropping — preserves grants
Simple view — DML allowedSingle table, no GROUP BY, no DISTINCT, no aggregates
Complex view — DML blockedJOIN, GROUP BY, DISTINCT, or aggregate functions present
Expression column — no INSERT/UPDATECannot write to a derived column — DELETE still allowed
WITH CHECK OPTIONBlocks INSERT/UPDATE that would hide the row from the view
WITH READ ONLYBlocks all DML — SELECT still works
DROP VIEWRemoves definition only — base table data untouched
Base table droppedDependent views become invalid — not automatically dropped

10 — Practice questions

Q1 — A view is created with this definition:

CREATE VIEW dept50_emp AS SELECT employee_id, last_name, department_id FROM employees WHERE department_id = 50 WITH CHECK OPTION;

A user runs: UPDATE dept50_emp SET department_id = 80 WHERE employee_id = 121;

What happens?
Q2 — Which of these views would allow INSERT, UPDATE and DELETE operations?
Q3 — A developer drops the EMPLOYEES base table. What happens to views built on that table?
Oracle SQL 1Z0-071 Exam Prep Guide — Complete 4-Volume Set
19 chapters  ·  1,480 practice questions  ·  1,249 SQL examples
Chapter 14 covers every view scenario on the exam — simple vs complex, WITH CHECK OPTION, WITH READ ONLY, DML rules, and view management. Instant PDF download.
Get the full guide — $25 →

No comments:

Post a Comment