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]."

1NF rules from the class lectures:

1) In the first normal form, only single values are permitted at the intersection of each row and column; hence, there are no repeating groups.

2) A relation is in first normal form if and only if the domain of each attribute contains only atomic (indivisible) values, and the value of each attribute contains only a single value from that domain.
   First normal form enforces these criteria:
     a) Eliminate repeating groups in individual tables.
     b) Create a separate table for each set of related data.
     c) Identify each set of related data with a primary key.

3) A database is in first normal form if it satisfies the following conditions:
     a) Contains only atomic values.
     b) There are no repeating groups.

4) The First normal form (1NF) sets basic rules for an organized database −
     a) Define the data items required, because they become the columns in a table.
     b) Place the related data items in a table.
     c) Ensure that there are no repeating groups of data.
     d) Ensure that there is a primary key.

5) A table is in 1NF when all the key attributes are defined (no repeating groups in the table) and when all remaining attributes are dependent on the primary key. However, a table in 1NF still may contain partial dependencies, i.e.,dependencies based on only part of the primary key.

6) A relation is in first normal form if it meets the definition of a relation:
     a) Each attribute (column) value must be a single value only.
     b) All values for a given attribute (column ) must be of the same type.
     c) Each attribute (column) name must be unique.
     d) The order of attributes (columns) is insignificant
     e) No two tuples (rows) in a relation can be identical.
     f) The order of the tuples (rows) is insignificant.

7) 1NF includes not only multiple atomic values but the use of repeating fields or repeating tables. All of these must be avoided.

EXAMPLE 1; multiple atomic values:
Given a table:
employee(        EmployeeNo*, HomeMobilePhone)
And sample data: 1001,        103-391-7811;676-683-6301
                 1002,        447-149-5334;156-953-7528
You can see that multiple atomic values are stored in the HomeMobilePhone field.
This violates 1NF. This can be fixed by moving the phone numbers to another table with a one-many relationship with the employee table.
Solution: Create new tables to store the employee phone numbers.
New table:
     employee(EmployeeNo*)
Sample data:  1001
              1002
New table:
employeephone(EmployeeNo*@, Phone*,       Type)
Sample data:  1001,         103-391-7811, home
              1001,         676-683-6301, mobile
              1002,         447-149-5334, home
              1002,         156-953-7528, mobile

EXAMPLE 2; repeating fields:
Given a table:
        employee(EmployeeNo*, HomePhone,    MobilePhone)
And sample data: 1001,        103-391-7811, 676-683-6301
                 1002,        447-149-5334, 156-953-7528
You can see that there are multiple fields that store the employee phone numbers.
While this is not strictly a violation of 1NF, the use of multiple fields is really a 'cheat' to get around 1NF rules. It also restricts the database (In this case to only two phone numbers per employee).
Solution: This can be fixed by moving the phone numbers to another table with a one-many relationship with the employee table.
New table:
     employee(EmployeeNo*)
Sample data:  1001
              1002
New table:
employeephone(EmployeeNo*@, Phone*,       Type)
Sample data:  1001,         103-391-7811, home
              1001,         676-683-6301, mobile
              1002,         447-149-5334, home
              1002,         156-953-7528, mobile

EXAMPLE 3; repeating tables:
Given the tables:
        employee(EmployeeNo*)
And sample data: 1001
                 1002
       homephone(EmployeeNo*@, Phone*)
And sample data: 1001,          103-391-7811
                 1002,          447-149-5334
     mobilephone(EmployeeNo*@, Phone*)
And sample data: 1001,         676-683-6301
                 1002,         156-953-7528
You can see that there are multiple tables that store the employee phone numbers.
While this is not strictly a violation of 1NF, the use of multiple tables is really a 'cheat' to get around 1NF rules. It also restricts the database (In this case to only two phone numbers per employee).
Solution: This can be fixed by moving the phone numbers to another table with a one-many relationship with the employee table.
New table:
     employee(EmployeeNo*)
Sample data:  1001
              1002
New table:
employeephone(EmployeeNo*@, Phone*,       Type)
Sample data:  1001,         103-391-7811, home
              1001,         676-683-6301, mobile
              1002,         447-149-5334, home
              1002,         156-953-7528, mobile

Note: All of the examples above really have the same solution:
      One table to hold the entity data.
      Another table with a 1-to-many relationship with that table that holds the repeating data.
      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.

EXCEPTIONS:
If repeating fields are used to compute another value then they can be in the table.
FirstName, MiddleName, and LastName can be combined to create a FullName.

Dates and times are not considered repeating fields.
StartDate, StopDate, BeginningTime, and EndTime are OK.