drop view v5;
drop view v4;
drop view v3;
drop view v2;
drop view v1;
drop table t2;
drop table t1;

---------------------------------------------------------------------------------------

create table t1 (c1 integer);
insert into t1 values (1);
insert into t1 values (1);
insert into t1 values (1);
insert into t1 values (1);
commit;
select* from t1;
create view v1 as select * from t1;
update v1 set c1 = 2;

4 rows updated.

There is no PRIMARY KEY defined here, yet the view has no difficulty deciding what rows to update.

---------------------------------------------------------------------------------------

create table t2 (c1 integer, c2 integer);
insert into t2 values (2,1);
insert into t2 values (2,1);
insert into t2 values (2,1);
insert into t2 values (2,1);
commit;
select * from t2;
create view v2
as
select t1.c1,t2.c2
from t1,t2
where t2.c1 = t1.c1
/
update v2 set c1 = c1;

update v2 set c1 = c1
              *
ERROR at line 1:
ORA-01779: cannot modify a column which maps to a non key-preserved table

OK so technically this error is a lie since the first example was also of a non key-preserved table but it was still updateable.

Seems adding a join causes a problem.  But this may be due to the goofy data model shown, let us correct that.

---------------------------------------------------------------------------------------

update t1 set c1 = rownum;
update t2 set c1 = rownum;

select * from t1;
select * from t2;

commit;

alter table t1 add primary key (c1);
alter table t2 add primary key (c1);

update v2 set c1 = c1+100;

4 rows updated.

Seems after we make the data right and define primary keys on the tables, we can update the join view no problem.
After the update the data will no longer be retrievable since the keys between tables will no longer match but the view is still updateable.

01:03:12 SQL> select* from t1;

        C1
----------
       101
       102
       103
       104

4 rows selected.

Elapsed: 00:00:00.03
01:03:16 SQL> select* from t2;

        C1         C2
---------- ----------
         1          1
         2          1
         3          1
         4          1

4 rows selected.

Elapsed: 00:00:00.04

---------------------------------------------------------------------------------------

but the above example is actually also not realistic.
Let us define the missing foreign key as well and redo the update.

rollback;

alter table t2 add foreign key (c1) references t1;

update v2 set c1 = c1+100;

update v2 set c1 = c1+100
*
ERROR at line 1:
ORA-02291: integrity constraint (KEVIN.SYS_C0010352) violated - parent key not found

This tells us that the join view is updateable, but that since we are updating the primary key, and our FK is not deferred, this update will not work.

---------------------------------------------------------------------------------------

create or replace view v3
as
select c1,count(*) rowcount
from t2
group by c1
/

update v3 set c1 = c1+100;

update v3 set c1 = c1+100
       *
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view

A different error.  Seems this group view is not updateable.
In this case this makes sense since there is no identifiable row to update.
Being true aggregate rows, no row in this view maps to any table used in the view.

---------------------------------------------------------------------------------------

create or replace view v4
as
select t1.c1,count(*) rowcount
from t1,t2
where t1.c1 = t2.c1
group by t1.c1
/

update v4 set c1 = c1+100;

update v4 set c1 = c1+100
       *
ERROR at line 1:
ORA-01732: data manipulation operation not legal on this view

Hmm... this however does not make sense.
There is no problem knowing what row to update since the primary key of the view and the primary key of the rows to be updated by the view match.
Oracle should have been able to figure this out but it cannot which tells us it is relying on a simplified implementation of the definition.
Maybe using ROWID is the basis for an Oracle database (I am guessing).

---------------------------------------------------------------------------------------

create or replace view v5
as
select t1.c1,(select count(*) from t2 where t2.c1 = t1.c1) rowcount
from t1
/

update v5 set c1 = c1+100;

update v5 set c1 = c1+100
*
ERROR at line 1:
ORA-02292: integrity constraint (KEVIN.SYS_C0010352) violated - child record found

But this variation of the view works.  Same result (ignoring the possible issue of nulls anyway) but here it updates fine.
This seems to be because the identity of the row is something the database can figure out.
The error tells us the view is updateable but also that doing the update violates other constraints.
But again, the view is updateable.

create or replace view v6
as
select t2.c2
from t1,t2
where t1.c1 = t2.c1
/

update v6 set c2 = 9;

4 rows updated.

Understand why this works?
There are no primary keys preserved by this view (none are presented in the view result row anyway).
So this is not technically a primary key preserving view is it?
Yet the database has no problem updating table T2.
So once again it appear Oracle is no relying strictly on the old definition of "primary key preserved view" in order to determine updatability of the view.
Just saying.
Not how similar this is to view V2 yet in that case the table updated was T1.
Neat how Oracle can figure out what to update eh.

select constraint_name from dba_constraints where table_name = 'T2' and constraint_type = 'R';

CONSTRAINT_NAME
----------------------------------------------------------------------------------------------------------------------
SYS_C0010352

1 row selected.

alter table t2 drop constraint SYS_C0010352;

update v2 set c1 = c1+100,c2 = c2+100;

update v2 set c1 = c1+100,c2 = c2+100
                          *
ERROR at line 1:
ORA-01776: cannot modify more than one base table through a join view

this and the other examples help you to start thinking about how oracle is translating your update against a view into updates against the underlying tables of the view.