Just because a system administrator have access to the database doesn't necessarily mean that the administrator need to have access to all the data. You can encrypt the data to prevent the system administrator from having access to the data. If the encryption happens at the client side and only the users have access to the encryption keys, then you can design it so the system administrator would not be able to decrypt the data. Using public key cryptography, you can allow data entered by one user to be read by a different user, without the first user having to share their own encryption key to the second user.
Of course most real applications need the server to do some work with parts of the data, usually to allow searching the database, you'll need to rethink these aspects of the application. Perhaps, you can store a second hashed_name field so you can search based on the user's name without disclosing the actual name. Perhaps you can store a general location of addresses in plain text and have the full address encrypted.
You'll also need to consider if there are any data that can be correlated with other data to leak information even after encryption/hashing. For example, you may hash a disease's name so you can use the field for searching patients with that disease, but by correlating the frequency of occurrence of the hashed names can be correlated with publicly available data about prevalence of diseases to reduce the number of possibilities that each hashed names can be. You may want to consider whether such advanced attack scenarios would be in scope or to accept tree risk and limit the pseudonymization only to opportunistic attackers.
You can also enforce physical partitioning so that system A and B are managed independently by separate teams, running on separate hardware and resources (share nothing). This way, you ensure that no single system holds all the data and data leak will require at least two person from different teams to collude.