1) Premessa generale: ho l'impressione (bada bene, solo un'impressione personale, non vuole essere un giudizio nè tantomeno un'accusa) che tu stia dedicando molta (troppa ?) attenzione ad aspetti "teorici e formali" (la terza forma regolare, MVC, etc) che sono certamente importanti ed anzi, per molti versi "basilari" ma che rischiano forse a volte di farti perdere di vista aspetti implementativi secondo me altrettanto importanti: il famoso utilizzo degli ID univoci come chiavi primarie ed esterne, le iniziali idee sulle procedure per gestire la storicizzazione dei soci (che avrebbero portato a replicare inutilmente molte informazioni), etc
Come ho detto più volte non conosco Java e quindi mi risulta ben difficile valutare quali possano essere i pro ed i contro di alcune scelte che coinvolgano specificamente Java ed i suoi aspetti (nei miei post ho sempre cercato di dare consigli "generici" applicabili a qualunque linguaggio e qualunque database); a maggior ragione mi risulta difficile valutare un pacchetto esterno, quale Hibernate, che, a quanto vedo dal suo sito, sembra essere molto potente e mirato anche all'utilizzo proprio con i database ("...query service...", "...its own portable SQL extension...")

Nella mia esperienza (conosco bene MS SQL Server) ho sempre cercato di sfruttarne a fondo le funzionalità e le potenzialità, in particolare proprio l'utilizzo di funzioni, stored procedures, viste; tutti oggetti creati nel database e semplicemente richiamabili dall'applicativo in modo da riderre il carico elaborativo su quest'ultimo ed utizzare invece le funzionalità di ottmizzazione offerte dal motore del db stesso (e ridurre quando possibile la necessità di andare ad effettuare modifiche all'applicativo una volta rilasciato, magari per sistemare una piccola cosa...)
Non conosco a fondo gli aspetti MVC per poter dire con certezza "chi faccia cosa" e se questo rispetti le suddivisioni formali indicate da questo o quel modello; io (consiglio personale) cercherei di sfruttare a fondo le potenzialità del database


2) Temo che si rischi di entrare in un circolo vizioso senza uscita, e senza risposte certe. Un amministratore del database (non di rete, del database, ed ancor più un amministratore dell'intero database server) può per definizione fare quello che vuole nel database stesso, incluso quindi andare a cancellare i dati da qualche tabella e magari anche ripulire le tabelle di log.
Temo ci si possa fare ben poco... Lo stesso amministratore potrebbe anche cancellare l'intero database o modificare password e permessi all'utente utilizzato per il collegamento dalla tua applicazione...
Anche immaginando di togliere all'amministratore i permessi di cancellare la tabella di log, nessuno gli vieterebbe (se amministratore del server) di creare un nuovo utente, assegnargli tali permessi, ed effettuare operazioni "dolose" con le nuove credenziali...
Non so come funzioni PostgreSQL, in SQL Server esiste anche il log delle transizioni (un file separato in cui resta traccia di tutte le operaziono, utilizzato per eventuali "ricostruzioni" del database), ma, anche in questo caso, un amministratore potrebbe comunque modificare alcune proprietà del database, effettuare alcune operazioni e far sparire anche queste informazioni.
Ho l'impressione che non se ne esca: motivo in più per non dare a nessuno la password di amministratore e per non usare mai tale utente per collegarsi al database a meno che non sia assolutamente necessario, in modo da evitare anche il rischio di cancellazioni involontarie.
Se vuoi provare a cercare maggiori dettagli o suggerimenti sul modo migliore di effettuare questa "gestione dei logo delle operazioni" ti posso banalmente suggerire (forse lo sapevi già) i termini con cui vengono generalmente indicate tali operazioni "audit trail"
Google ti può dare una mano...