See this post for my notes on SQL Server column-level encryption.
The Database Master Key is a symmetric key that is secured by the Service Master Key. A database can only have one DBMK. Objects can then be created within that database that are secured by the DBMK. The keys for the DBMK are kept in the database, and in the instance's master database (this behavior can be changed, to only be kept in the primary database, in case keeping it in master is a security issue).
The certificates are then created that are secured by the DBMK, and the Symmetric Keys are created that are secured by the certificates. Then the data is secured by the Symmetric Keys. See my post above for a whole set of scripts that run through it from start to finish.
Note: The SMK is secured by the Windows security API’s (DPAPI), utilizing the credentials of the SQL Server service account user. If that user is changed, special commands must be used to change the SMK to re-associate the key with the new user’s credentials.
In order for a user to use the symmetric keys, they have to be granted REFERENCES, like in the following:
GRANT REFERENCES ON SYMMETRIC KEY::SymmKey1 TO someusername
Where SymmKey1 is the name of the symmetric key and someusername is the username of a user (or role name, and just assign users to that role, which is better).
Be sure to back up all keys, the Service Master Key, the Database Master Key, and the certificates (which you can back up, as opposed to asymmetric keys, which you cannot), and keep the backups in a safe place, along with the passphrases used to make the backups. See my scripts in the above post for code on backing them up.
These would be needed if you need to move the database to another server, or recreate your server in a DR situation.
Note of caution: Practice the scripts on a development box before you do anything on a production system. Learn the different aspects and details of encryption before putting it into production.