All of the jargon and confusingly said theories in textbooks and online resources are quite useless when you’re trying to learn database theory for the first time. Below is a really layperson-focused (almost mechanical) set of rules for when you’re trying to determine the normal form of a database table.
Visually, a functional dependency could look like any of the following forms:
A -> B
A -> BC
BC -> D
BC-> DE
BCNF
The left side of every functional dependency has to be a key
3NF
The left side of every functional dependency has to be a key
OR
The right side of every functional dependency has to be an attribute that is part of the key
2NF
For every non-key on the right side, you must end up with a key on the left side – either directly or by way of transitivity.
1NF
Basically anything that’s in tabular form.
If you need more help:
Functional dependency: a relationship between two attributes (ex: A -> B) where for two rows in a table, if they have the same value for A, then they must have the same value for B.
Determinant: the left side of a functional dependency
Resultant: the right side of a functional dependency
Key: an attribute that (with the complete set of functional dependencies) functionally determines every other attribute.
Composite (aka Compound) Key: a key that consists of two or more attributes
Candidate Key: one of possibly many keys (composite or not)
Primary Key: a candidate key that’s chosen as the key based on performance, storage concerns.
Prime Attribute: an attribute that is a part of a composite key.
If you want some examples and exercises, I highly recommend chapter 3 of A First Course in Database Systems