1. Eliminate duplicative columns from the same table.
2.Eliminates functional dependencies on a partial key by putting the fields in a separate table from those that are dependent on the whole key.
3.Eliminated Functional dependencies on non-key fields by putting them in a separate table. At this level, all non-key fields are dependent on the primary key.
In creating a database, normalization is the process of organizing it into tables in such a way that the results of using the database are always unambiguous and as intended. Normalization may have the effect of duplicating data within the database and often results in the creation of additional tables. (While normalization tends to increase the duplication of data, it does not introduce redundancy, which is unnecessary duplication.) Normalization is typically a refinement process after the initial exercise of identifying the data objects that should be in the database, identifying their relationships, and defining the tables required and the columns within each table.
A simple example of normalizing data might consist of a table showing: Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
If this table is used for the purpose of keeping track of the price of items and you want to delete one of the customers, you will also delete a price. Normalizing the data would mean understanding this and solving the problem by dividing this table into two tables, one with information about each customer and a product they bought and the second about each product and its price. Making additions or deletions to either table would not affect the other.
Normalization degrees of relational database tables have been defined and include:
First normal form (1NF). This is the "basic" level of normalization and generally corresponds to the
definition of any database, namely:
It contains two-dimensional tables with rows and columns.
Each column corresponds to a sub-object or an attribute of the object represented by the entire
table.
Each row represents a unique instance of that sub-object or attribute and must be different in
some way from any other row (that is, no duplicate rows are possible).
All entries in any column must be of the same kind. For example, in the column labeled
"Customer," only customer names or numbers are permitted.
An entity is in First Normal Form (1NF) when all tables are two-dimensional with no repeating
groups.
A row is in first normal form (1NF) if all underlying domains contain atomic values only. 1NF
eliminates repeating groups by putting each into a separate table and connecting them with a one-
to-many relationship. Make a separate table for each set of related attributes and uniquely identify
each record with a primary key.
Eliminate duplicative columns from the same table.
Create separate tables for each group of related data and identify each row with a unique column
or set of columns (the primary key).
Second normal form (2NF). At this level of normalization, each column in a table that is not a
determiner of the contents of another column must itself be a function of the other columns in the
table. For example, in a table with three columns containing customer ID, product sold, and price
of the product when sold, the price would be a function of the customer ID (entitled to a discount)
and the specific product.
An entity is in Second Normal Form (2NF) when it meets the requirement of being in First Normal
Form (1NF) and additionally:
Does not have a composite primary key. Meaning that the primary key can not be subdivided into
separate logical entities.
All the non-key columns are functionally dependent on the entire primary key.
A row is in second normal form if, and only if, it is in first normal form and every non-key attribute
is fully dependent on the key.
2NF eliminates functional dependencies on a partial key by putting the fields in a separate table
from those that are dependent on the whole key. An example is resolving many:many
relationships using an intersecting entity
Third normal form (3NF). At the second normal form, modifications are still possible because a change to one row in a table may affect data that refers to this information from another table. For example, using the customer table just cited, removing a row describing a customer purchase (because of a return perhaps) will also remove the fact that the product has a certain price. In the third normal form, these tables would be divided into two tables so that product pricing would be tracked separately. An entity is in Third Normal Form (3NF) when it meets the requirement of being in Second Normal Form (2NF) and additionally:
Functional dependencies on non-key fields are eliminated by putting them in a separate table. At this level, all non-key fields are dependent on the primary key. A row is in third normal form if and only if it is in second normal form and if attributes that do not contribute to a description of the primary key are move into a separate table. An example is creating look-up tables.
Domain/key normal form (DKNF). A key uniquely identifies each row in a table. A domain is the set of permissible values for an attribute. By enforcing key and domain restrictions, the database is assured of being freed from modification anomalies. DKNF is the normalization level that most designers aim to achieve.
References: KRUTZ, Ronald L. & VINES, Russel D., The CISSP Prep Guide: Mastering the Ten Domains of Computer Security, 2001, John Wiley & Sons, Page 47. and http://psoug.org/reference/normalization.html and Tech Target SearcSQLServer at: http://searchsqlserver.techtarget.com/definition/normalization?vgnextfmt=print

The other answers are distracters.

The differential backup method only copies files that have changed since the last full backup was performed. It is additive in the fact that it does not reset the archive bit so all changed or added files are backed up in every differential backup until the next full backup. The "additive backup method" is not a common backup method.
Source: KRUTZ, Ronald L. & VINES, Russel D., The CISSP Prep Guide: Mastering the
Ten Domains of Computer Security, John Wiley & Sons, 2001, Chapter 3:
Telecommunications and Network Security (page 69).

The main task here is the authentic distribution of the new root CA certificate as new trust anchor to all the PKI participants (e.g. the users).
In some of the rollover-scenarios there is no automatic way, often explicit assignment of trust from each user is needed, which could be very costly.
Other methods make use of the old root CA certificate for automatic trust establishment
(see PKIX-reference), but these solutions works only well for scenarios with currently valid root CA certificates (and not for emergency cases e.g. compromise of the current root CA certificate).
The rollover of the root CA certificate is a specific and delicate problem and therefore are often ignored during PKI deployment.
Reference: Camphausen, I.; Petersen, H.; Stark, C.: Konzepte zum Root CA
Zertifikatswechsel, conference Enterprise Security 2002, March 26-27, 2002, Paderborn;
RFC 2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile.