You can resort to a MySQL database, to leverage its cryptography support.
Then you have two options (actually you can employ both):
1) Some data can be left in plaintext, but anonymized - i.e., there's no way of knowing who the data refer to.
2) Other data are encrypted, using a symmetric algorithm. The key to do so will be random, and encrypted using the user's password. This way, several users can access the same data
User Password CryptoKey
alice <hash1> <encrypt(pwd1, RANDOM)>
bob <hash2> <encrypt(pwd2, RANDOM)>
To authenticate, Alice sends along her password, which is checked with the stored hash. If it is valid, the RANDOM key is extracted and stored in the server's memory for the duration of the session.
Text and BLOB fields can be then encrypted (with or without salting). Short fields or fields with low cardinality are better salted, otherwise the contents can be easily guessed: for example a field that either contains 'Male' or 'Female', after unsalted encryption might contain 'e3290d6cd47a701168b962aa0c6b249e' or 'd87d344d4808900421c93de58dd7557a' - but that's still two values only, which is a potential vulnerability.
Changing Alice's password is no great deal; of course, if RANDOM gets exposed, that's a big problem. Communications with the front-end should go through SSL/TLS and contain RANDOM-decrypted (but SSL-encrypted) data, thereby protecting the security of RANDOM, which never leaves the server.
Needless to say, physical access to the server's memory will compromise everything, since it would be easy to perform a man-in-the-middle attack and trick a valid user into revealing his password, from which RANDOM can then be obtained and the data store decrypted.
Optionally, you can encrypt also the connection to the database, but that seems a bit like overkill (they'll probably be local anyway) and still won't protect you against the server being exploited.
The data can be synchronized between a local and a remote MySQL database without knowing the password, either by downloading a database dump (which is viable if the data size is small; remember that encrypted data is not compressible) or by keeping a registry of updates, which is much more difficult (think 'Alice on her laptop modifies a record while Bob on his desktop deletes that same record, and Charlie inserts a new record with a new primary key...').
Frankly, the best solution I've found in these cases is to place everything on a reputable server with an appropriate backup plan, and have the clients connect to the server. It is usually actually faster and cheaper to supply unconnected clients with Internet connectivity than to design the database for offline usage, syncing, and conflict resolution. Read only copies could be handed out, of course. The remote server can usually be configured to send e-mails and run cron jobs, and inform the clients of any events (e.g. "Janie has earned the A2 Award").
By only exposing a REST interface, you can exploit several application frameworks, and also have a simpler and more easily testable server-side application (entry points and workflow paths are few by design and can be enumerated), which appreciably reduces the risk of a server exploit.
Given that the master database lives on a central server, and a copy of the same lives locally, you can keep the application and the database on an external, encrypted USB key. The database itself has no encryption; you could use
SQLite locally. If using MySQL, you can run it via Portable Apps or something like it.
Then, the workflow would be: the user inserts the USB key, which requires a PIN or even a fingerprint . Once unlocked, he can run the application, which if necessary (i.e. MySQL, PostgreSQL,...) will activate the server and connect to it; or it will directly access the data (SQLite). When finished, the server (if any) is stopped, the key is ejected and the data on it is proof against any reasonable threat.
When back into connectivity range, the user again fires up the application and syncs it with the central server.
This solution has the advantage that security is a plug-in with a known cost. The users may decide not to pay that cost, but it is their decision, not yours.