You can't. In practice, you can hire trustworthy people, do
background checks, pay them well, have multiple people checking up
on each other, and provide separation of duties (for example, 'root'
on the webserver might not also have 'root' on the database server).
You can't prevent 'root' from modifying database data, but you don't
have to make it easy by also giving him an administrative database
login as well. And if he creates one for himself, the DBA in charge
of the database might notice.

Separation of duties is a big deal even in non-computerized accounting
systems. For example, you have two people open deposit envelopes
and count the cash in deposits. The same person who credits deposits
isn't allowed to be the person who prepares customer statements (or
he could conveniently "lose" the deposit, but send the customer a
phony statement indicating it's there).

Then you can't use the data except when the key is provided. This
may be OK for user passwords, but for much other private information,
the only reason to have it on the system at all is that there's a
need for it when the user is NOT logged in. For example, the alert
topics list and the user's email address might be used by the system
to send an email when something of interest (as specified by the
user) is posted. Banks need to know customer account balances (e.g.
when checks clear, to see if the check should bounce). Both the
store and the user need the user's credit card number when he orders
something and the order is processed.

And never forget that more primitive methods, like yanking an ATM
machine out of the ground with a chain and blowing it open with
explosives, or bribing the employee with the keys, can get around
sophisticated encryption locks.