Change Authorisation

Hello,
I have to implement a mechanism into an existing human resources asp.net application to allow users to change their data but not display it anywhere until someone from the management authorizes the changes.

An example that shows the requirements is contacts:
we have a table person, personcontact and contact in sqlserver, with foreign key constraints set up. Users should be able to add, delete and change contacts, and there should be a way to reasonably show the changed data to the managers (i.e. displaying them a bunch of guids is not an option).

Some .Net-related informations:
We use an OO Model where we have entity classes that inherit from DataRow and collection classes that inherit from DataTable. We use a single Dataset for each Table, so we do net setup constraints in our Datasets.

Can anyone share ideas on how one could solve this?
Are there design patterns for this?

Of course we would prefer solutions that minimize changes to the database and ones that are most elegant from an OO-design point of view.

Let me clarify a few things: The decision to use a single DataSet per table was made before I joined the team. Yes we are aware that we loose the constraint functionality of datasets (Changeing the tables is nice and fast though, and we are in the uncomfortable situation that we regularly get new requirements). We implemented additional logic in the derived entity and collection classes to simplify access to related tables etc., so our entity classes are not dumb tablewrappers.
Anyway, all this is largely irrelevant as we cannot change the whole DAL to use a single dataset etc. now.

What I would like to hear about is how exactly you go about change authorization in your applications. We came up with two approaches that could work:

1) When you call save on your dataset, do not save the data to the table itself, but write to a changetable the table, column, old value, new value, order of the change. Then when authorizing it is difficult to display the manager with the changed data, but generally it would work (of course, foreign key constraints etc have to be taken care of).

2) Implement a state column in the database. This is easy for add and delete, but would require to copy the entire row (with a new primary key) every time the row changes and remember which 2 changed rows (old and new state) belong to each other until the change has been authorized. It would also require us to outsource several fields like e.g. lastname to a seperate table as we cannot loose the primary key of the person, it's used in several other parts of the program.

1 has the advantage of little data redesign, but is compicated to track with all constraints and hard to display (a relation table with 2 guids is difficult to read, even for a programmer). 2 implies serious change in the underlying data model but is easier to display and implement.

Are there any solutions we miss?
What are additional pros/cons you can think of?

I hope I made myself clear, please tell me if something is still a little foggy.

Many thanks for your opinions.
regards, Peter Kullnigg