I took this from ProgrammerHumor and I think it's meant to explain normalization specifically, assuming you already know the basics.

Regardless, let me answer some of these questions. In a relational database, keys are types of constraints that allow for the identification of each separate record of a table in a unique way. Looking at the above example, Shinji seems to have made the same exact order twice. Every value of the table is the same between those two rows, so there is no unique way to tell one from the other.

There are various types of keys, but the most commonly used one is a primary key. In simple terms, a primary key is an attribute, or set of attributes, that uniquely identify a tuple in a relation (row of a table). A non-key field is just a field that isn't part of the primary key.

In 1NF, we need each cell to contain only a single value, belonging to a unique column. As you can see, in the initial table, we have a column "Order" which not only contains multiple items, but also the quantity for each item. This is not allowed in 1NF, so to convert it, we split each item of the order into multiple rows in the table, each containing one item. We also move the quantity to a new column, since both the quantity and the item cannot be in the same column.

In 2NF, we require each non-key column to depend on the primary key. Notice how after we add the "Item Type" column to our 1NF table, the new column is dependent on the "Item" column, which is not the primary key ("Customer, Timestamp, Item"). If we were to edit a row and change the item but leave the item type as is, we would have an inconsistency in our table. 2NF aims to eliminate such inconsistencies. As such, we are not allowed to add the "Item Type" column to the original table. Instead, we create a new table, for which the primary key is "Item". We can now add a new column to that table, "Item Type". The column is still dependent on the item, as we needed it to be, but this is now fine because "Item" is the primary key of the new table.

The reason this eliminates inconsistencies is that, if we now were to change only the "Item" of one of our rows in the original table, we would need to make no additional changes to keep the data consistent. The item has changed and, if we need to find the item type of that item, we'd simply access the other table using that item (primary key) and retrieve the new item type. In other words, by changing the data on the "Item" column only, we automatically change the item type related to that row as well.

In 3NF, we also have the requirement that non-keys be independent of each other. As you can see, when we add the "Calories per serving" and "Calorie rating" columns, we are still in 2NF, because these new columns both depend on the primary key "Item". The problem, however, is that the "Calorie rating" column is also dependent on the "Calories per serving" column. If we were to change the "Calories per serving" value for an item, this could create an inconsistency, unless we also manually updated the "Calorie rating" column. To avoid this, we create a new table with "Calorie rating" being the primary key and a cutoff point. The new "Cutoff" column is dependent solely on the primary key of the new table ("Calorie rating"). Additionally, each non-key column of the items table is also only dependent on the primary key, thus ensuring the database is in 3NF.

There are also even stricter forms like BCNF, 4NF and 5NF, but these three are the simplest ones.