mview in a Production transactional db

I have a developer that that would like to put a materialized view in a production db. The UI is built on a proprietary Java platform so the there is not very much code running from the DB. Performance is not the issue. It is more of a data integrity issue with using a particular table, that is built from several other tables, to reference a field in its current records in order to rebuild that set of records when changes are made:
- Table a is built from tables a,b,c
- New user access runs a proc that goes to table a, stores all values in project field, deletes those records and rebuilds the table
:: Developer is concerned about the data integrity of table a... if records are 'accidentally' (love how she believes they ACCIDENTALLY get deleted) deleted or corrupted. it will not rebuild with all of the info needed.

We are going to test with a normal view but would you necessarily tell the dev to just test the code well enough to assure no rec's are 'ACCIDENTALLY' deleted. I am concerned with the 'refreshes' on the mview in the production environment and managing the mview.

Any thoughts would be appreciated.

what about the refreshes, what concerns

although typically changes will not be made too often to the data, it will have to be refreshed with each change. That is why I would like to test with a regular View first.

so whats the problem? an MV doesnt affect the base tables