I need to design a database that will contains information about personal disease of users.
What can be the approach in order to implement the columns of the DB's tables: encrypt the information, separate data within two differents DB, one for sensitive data and another for not sensitive data, or both or another approach?
You could encrypt the data with a key stored in your web application so that the data is written/read from db in its encrypted form. However anyone with access to the code would have access to the key and with the key the unencrypted data. This solves the requirement
the dba should not be able to view the information about disease of the user of the database.
As far as using to separate databases I don't think that is needed. You are storing the data encrypted and using database permissions by user, table (if that's even needed) will be more than enough. I think the extra DB adds a layer of complexity without much else. Unless its at a different location, then it might have a SMALL improvement from a single database system.
Ominus' answer addresses your first question. The answer to the second question may require more details about your application.
Another approach with even greater security if the patients must access the database could be to have a separate database for each user. In this approach you might use a framework that provides multi-tenant, multi-database functionality. The problem however is that if you have separate application users and separate database users, synchronizing these users will be incredibly difficult. I would guess that patients don't need to access your database though. If they do need to, it might be most secure to have a key per user.
In addition to legal or contractual requirements, some other reasons I can think of to have separate databases are: customer's perception of increased security making sales easier, worries about encryption being broken, and worries about (the) key(s) being compromised.
Regarding the part of Briddmus' answer where he states "that you need to encrypt more than just the medical information": this only holds if everyone in the database has a medical condition. (I would guess this is the case).
Note: parts of this answer would be better suited as comments but I don't yet have sufficient rep to post comments here.
For this type of application you need to think about who should be allowed to access the data. With medical information I think it sould be restricted to the user who entered it and anyone they gave permission to view it.
In order to prevent the DBA from viewing the data you will have to encrypt it using a code that the DBA does not have access to.
You also need to encrypt the information in a way that the application programmer can't access it either. There's no point in encrypting the information from the DBA if a programmer can log in as any user.
You also don't want to encrypt all the data with the same code. The software might have a bug that shows one user the information of another. So it would probably be best to encrypt each users data using a code specific to that user.
It is important to note that you need to encrypt more than just the medical information; as an end user I wouldn't want your DBA even knowing I have a medical condition, let alone what it is. So you'll need to also encrypt any personally identifying information about the user. This includes such things as:
