Never forget that the primary purpose of database normalization is to:
1) Reduce duplicate entry of data.
2) Prevent insert anomalies. Insertion of data that would cause duplication of data.
2) Prevent update anomalies. Updating date that would leave data that conflicts with the new value.
2) Prevent delete anomalies. Deletion of a record for one entity loses data about another.

Remember the phrase: "The data depends on key [1NF], the whole key [2NF], and nothing but the key [3NF]."

2NF rules from the class lectures:

Tables have a single PK -or- if composite PK then all attributes depend on the full PK.

1) For the second normal form, the relation must first be in 1NF.
   The relation is automatically in 2NF if, and only if, the PK comprises a single attribute.
   If the relation has a composite PK, then each non-key attribute must be fully dependent on the entire PK and not on a subset of the PK (i.e., there must be no partial dependency or augmentation).

2) A relation is in 2NF if it is in 1NF and no non-prime attribute is dependent on any proper subset of any candidate key of the relation.
   A non-prime attribute of a relation is an attribute that is not a part of any candidate key of the relation.
   Put simply, a relation is in 2NF if it is in 1NF and every non-prime attribute of the relation is dependent on the whole of every candidate key.

3) As per the Second Normal Form there must not be any partial dependency of any column on primary key.
   It means that for a table that has concatenated primary key, each column in the table that is not part of the primary key must depend upon the entire concatenated key for its existence.
   If any column depends only on one part of the concatenated key, then the table fails 2NF.

4) A table is said to be in 2NF if both the following conditions hold:
     a) Table is in 1NF (First normal form)
     b) No non-prime attribute is dependent on the proper subset of any candidate key of table.

5) A relation is in second normal form (2NF) if all of its non-key attributes are dependent on all of the key.
   Another way to say this: A relation is in second normal form if it is free from partial-key dependencies
   Relations that have a single attribute for a key are automatically in 2NF.
   This is one reason why we often use artificial identifiers (non-composite keys) as keys.

6) A table is in 2NF when it is in 1NF and it includes no partial dependencies.
   However, a table in 2NF may still have transitive dependencies, i.e., dependencies based on attributes that are not part of the primary key.

EXAMPLE: data that is not related to the whole composite primary key.

Given a table:
     		 student(studentID*, studentName,    MajorCode*, MajorName)
And sample data: 34673656,   Avram Hinton,   NSA,        Network Systems Administration
                 34673656,   Avram Hinton,   CST,        Computer Support Technician
                 83681840,   Hayes Gibson,   CST,        Computer Support Technician
                 94086534,   Kristen Acosta, CP,         Computer Programmer
Is the table in 1NF?
The studentName is not atomic, it contains a first and last name. This is a 1NF violation.
So, first we will make the table 1NF compliant:
         student(studentID*, firstName, lastName,  MajorCode*, MajorName)
And sample data: 34673656,   Avram,     Hinton,    NSA,       Network Systems Administration
                 34673656,   Avram,     Hinton,    CST,        Computer Support Technician
                 83681840,   Hayes,     Gibson,    CST,       Computer Support Technician
                 94086534,   Kristen,   Acosta,    CP,        Computer Programmer
Now we can see if the table is 2NF.
You can see that the MajorName is not dependent on both the studentID and MajorCode, only on the MajorCode.
You can see that the firstName is not dependent on both the studentID and MajorCode, only on the studentID.
You can see that the lastName is not dependent on both the studentID and MajorCode, only on the studentID.
Solution: This can be fixed by moving the major data to a new table and adding a relationship table to relate the student to the major.
New table:
     student(studentID*, firstName, lastName)
Sample data: 34673656,   Avram,     Hinton
             83681840,   Hayes,     Gibson
             94086534,   Kristen,   Acosta
New table:
       major(MajorCode*, MajorName)
Sample data: NSA,        Network Systems Administration
             CST,        Computer Support Technician
             CP,         Computer Programmer
New table:
student_major(studentID*@, MajorCode*@)
Sample data:  34673656,    NSA
              34673656,    CST
              83681840,    CST
              94086534,    CP
Are the tables in 3NF?
Yes, since all non-key attributes depend on the primary key.
Note: The solution is to:
      Reduce the entity table to only hold data related to the first primary key.
      Create a new table or tables to store data that is not related to the entire primary key.
      The create a new table or tables table to relate the moved data back to the entity table.
      The phrase: "The data depends on key [1NF], the whole key [2NF], and nothing but the key [3NF]."
      Not only solves all 1NF and 2NF issues but most 3NF issues as well.
      Each non-primary field in a table must be functionally dependent on the entire primary key.