On snapshots, foreign keys and all other constraints should be defined as DEFERABLE. All deferable constraints will be defered during a snapshot refresh and validated upon commit.

You may place any indexes on a snapshot with the exception of a unique index (you may have a unique constraint on a snapshot but make it deferable. that'll use a non-unique index).

You would also need to create a snapshot group to logically collect together all tables related by declaritive integrity constraints into one group. This group of objects will be refreshed in an atomic fashion.

The reason this is so is because snapshots refresh a table at a time. If you have the EMP and DEPT table -- and you have deleted a departement and its employees and added a deptartment with new employees, the following events will occur:

1) emp is refreshed. you will now have rows in EMP that have no dept.
2) dept is refreshed. your EMP rows now have a dept
3) commit; the changes are permanent

step 1 shows why constraints must be deferable -- during the refresh process, the data is "not consistent". No one will see these inconsistencies and when we commit, everything is OK.

step 2 shows why we need a snapshot group. if we committed each snapshot individually, the emp refresh would never work (emps without a valid DEPT). Additionally, the refresh of DEPT would never work either (we need to delete a DEPT but there are employees assigned to it).