TDE is a new feature in SQL Server 2008 Enterprise Edition; it provides real time encryption of data and log files. Data is encrypted before it is written to disk; data is decrypted when it is read from disk. The "transparent" aspect of TDE is that the encryption is performed by the database engine and SQL Server clients are completely unaware of it. There is absolutely no code that needs to be written to perform the encryption and decryption. There are a couple of steps to be performed to prepare the database for TDE, then the encryption is turned on at the database level via an ALTER DATBASE command.
We've probably all heard of incidents where backup tapes containing sensitive information have been lost or stolen. With TDE the backup files are also encrypted when using just the standard BACKUP command once encryption is turned on for the database. The data in the backup files (or on disk) is completely useless without also having access to the key that was used to encrypt the data.
Before we dive in to the steps to implement TDE, let's take a minute to discuss encryption at a very high level. The definition of encryption is "the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key". To encrypt some data, I choose an available algorithm, supply a key and I now have encrypted data. To decrypt the encrypted data, I choose the same algorithm and supply the key. The security provided by encryption is based on the strength of the algorithm and protection of the key. There are two types of keys - symmetric and asymmetric. With a symmetric key, the same value is used to encrypt and decrypt the data. An asymmetric key has two components - a private key and a public key. I use the private to encrypt data and someone else must use the public key to decrypt the data. To recap, the symmetric key or private key of the asymmetric key pair must be stored securely in order for encryption to be effective.  
                                                                                         How to implement TDE.
The following four steps to implement TDE on a particular database:

• Create a master key
• Create or obtain a certificate protected by the master key
• Create a database encryption key and protect it by the certificate
• Set the database to use encryption

Create a Master Key
A master key is a symmetric key that is used to create certificates and asymmetric keys. Execute the following script to create a master key:
Note that the password should be a strong one (i.e. use alpha, numeric, upper, lower, and special characters) and you have to backup (use BACKUP MASTER KEY) and store it in a secure location.
Create a Certificate
Certificates can be used to create symmetric keys for data encryption or to encrypt the data directly. Execute the following script to create a certificate:
Note that certificates also need to be backed up (use BACKUP CERTIFICATE) and stored in a secure location.
Create a Database Encryption Key
A database encryption key is required for TDE. Execute the following script to create a new database and a database encryption key for it:
In order to work with TDE the encryption key must be encrypted by a certificate (a password will not work) and the certificate must be located in the master database.
Enable TDE
The final step required to implement TDE is to execute the following script:
You can query the is_encrypted column in sys.databases to determine whether TDE is enabled for a particular database.

The following is a list of the terminology used with SQL Server Replication.

Replication : The capability to copy (i.e. replicate) data and changes to that data from one database to another.
Snapshot Agent : The Replication Snapshot Agent is an executable file that prepares snapshot files containing schema and data of published tables and database objects, stores the files in the snapshot folder, and records synchronization jobs in the distribution database.
Article : An article can be an entire table, select rows from a table, specified columns from a table or a stored procedures, Used defined functions, Views. An article is what is to be replicated.

Distribution Agent : The distribution agent is a process that moves transactions and snapshots held in the distribution database to subscribers.

Distribution Database :
- A distribution database tracks the changes (to publications) that need to be replicated (from publishers). A publisher can act as its own distributor, or a remote database server can be used to hold the distribution database.
-  For transactional replication, the distribution database tracks changes made to publications.
-  For merge replication it stores only synchronization history.

Distributor  : The server that contains the distribution database.

Merge Agent  : The merge agent is a process that merges changes between publication and subscription databases where merge replication is used.

Merge Replication : Type of replication that allows changes to the data to be made at any site. Changes to publications are then merged with the copies of that publication held at the other server(s). Merge replication cannot guarantee transactional consistency because the same or related records can be updated on different servers at the same time.

Publication : The data to be replicated is contained with a publication. A publication can contain a selection of tables and stored procedures. A table included in a publication is called an article. A publication therefore defines the set of data that is to be replicated. Each publication can be replicated as a snapshot publication (using snapshot replication), a transactional publication (using transactional replication) or a merge publication (using merge replication).

Publisher : A publisher is a server that makes data available for other servers, i.e. it is the server that makes data available for replication.

Pull Subscription : With pull subscription the subscriber asks the publisher for periodic updates. With pull subscription each subscriber can specify the best time for the update. Pull subscription is generally considered the better form of replication when a large number of subscribers are involved, or where the load on the LAN needs to be distributed.

Push Subscription : With push subscription the publisher pushes any changes made to the data out to the subscribers. Typically push subscription is used where changes need to be replicated to the subscribers shortly after the change occurs, i.e. where the the replication of changes is required in near real time.

Snapshot replication : Type of replication where a snapshot is taken of the current publication data. The subscriber's copy of the data is then replaced with the entire contents of that snapshot. Snapshot replication requires less processor overhead than either merge or transaction replication because it does not require continuous monitoring of data changes. Probably not suitable for replicating large volumes of data (i.e. large tables) because of the network traffic involved.

Subscriber : A subscriber is a server that receives updates to the data. Each subscriber is associated with a publisher.

Transactional Replication : Type of replication where the copies of the transactions are replicated to each subscriber. Transactional replication uses the transaction log to capture changes. These changes are then sent to subscribers and applied in the same order. This guarantees transactional consistency. Transactional replication is well suited where near real-time updates are required.