Your question can be paraphrased as:
How do you stop someone with access to change data from changing data?
The first step is to ensure that only the people expected to have access do have access. This is about good password management practices and account auditing (for those who are expected at some point to have access) while to prevent people who are never intended to have access, regular patching, code inspections and pen testing.
But you can't prevent your sysadmin from going crazy (apart from good salaries and working conditions etc) and you can never prove your system is completely secure. But there are still things you can do to prevent or contain such activity.
The classic 3-tier web app has a service account on the application tier which connects to the database. I've frequently seen (and in the past written) apps where this account has read/write access to all the tables containing the data to be manipulated. Restricting the read and write operations to specific records by using stored procedures provides some mitigation.
A complementary approach is to make the authentication from the application tier to the database dependent on the credentials supplied by the end user rather than simply treating the validation of the user credentials as a gateway test. At its simplest - the end users would be created as database users and the application would store their credentials each time it needs to connect. However this does approach has scalability issues - notably with Oracle which has a rather chatty authentication process resulting in most apps on Oracle re-using persistent connections. In the absence of additional controls it also means that the end user passwords are being stored in clear text rather than just the service password in cleartext (but there are solutions to this).
The other important piece of the puzzle, after you've done all you can to prevent an incident, is detection: Capturing identifiers of the client (IP address) when important data is changed: capturing the queries and DML being sent to that database and auditing it : deploying honeypot/canary data