* You can create foreign keys that reference a view which has primary
key constraint. But the PK
constraint on the view must be in "disable, novalidate" state.
Consequently, the FK will also need to be created in "disable,
novalidate" state. Here is an examle:



SQL> create or replace view t1_vw(c1,  constraint c1_pk primary key
(c1) disable novalidate) as select * from t1;

View created.

SQL> create table t2 (c1, constraint c1_fk foreign key (c1) references
t1_vw(c1));
create table t2 (c1, constraint c1_fk foreign key (c1) references
t1_vw(c1))
*
ERROR at line 1:
ORA-02270: no matching unique or primary key for this column-list

SQL> create table t2 (c1, constraint c1_fk foreign key (c1) references
t1_vw(c1) disable novalidate)
;

Table created.

Since both PK and FK are disable, you can not really use them for data
validation. Any attempt to enable the PK on the view will result in
errors:

SQL> alter view t1_vw enable constraint c1_pk;
alter view t1_vw enable constraint c1_pk
                 *
ERROR at line 1:
ORA-00922: missing or invalid option

SQL> alter view t1_vw modify constraint c1_pk rely;

View altered.

SQL> 

If one can not use these PK, FK for data validation, why would one
create them? Well, it populates the data dictionary and gives you a
picture of how the entities are realted to one another. It also has
implications on "query rewrite".  This is most useful in a data
warehouse environment.