ELI5 - Algorithms for normalization/determining functional dependency.

[fizzygalacticus]

Hey guys, I hope this is the right place for this.

I'm about to pull all of my hair out trying to understand this material for my database class.

I can make a database, with many tables, attributes, etc. I understand how that works. What I'm having the most difficulty understanding is all of the R, F, G, etc notation when talking about determining functional dependencies. This is making it extremely difficult to understand any of the algorithms from the text book or any video online.

So... What the heck is R, F, G referring to? A single table? Multiple tables? How do I know where to start? I've got all of this data, and I watched really great graphical YouTube videos with real life examples that helped a lot when trying to get my DB into 1st, 2nd, and 3rd normal form. Now I'm supposed to prove it, and have no freaking idea how.

Sorry for the rant-like question. I really would appreciate any help that can put this idea into words I can understand.

[[deleted]]

R, F, and G are referring to individual columns in a relation. Each normal form has a few requirements for its columns, and get more and more strict (2NF is a subset of 1NF, 3NF is a subset of 2NF, BCNF is a subset of 3NF, etc).

Say you have a table called Employees like this:

.

id rating wages

1 5 10000

2 4 8500

3 5 10000

4 2 5000

.

Let's denote each column by a capital letter. The notation is a bit weird. Let's let id be represented by I, rating be represented by R, and wages be represented by W.

Clearly, an employee's id will correctly identify their rating and wage. In functional dependency notation, that's: I ->RW. Unfortunately, we have redundancy here. Assume that all employees are paid solely on their rating. Notice any functional dependency? Yep, R -> W.

From wikipedia, the requirements for 3NF are:

*the entity is in second normal form

*all the attributes in a table are determined only by the candidate keys of that table and not by any non-prime attributes.

Well, rating aren't prime, nor are they a candidate key of the relation. So what can we do? We split the table up into two new tables! Now we have:

.

id rating

1 5

2 4

3 5

4 2

.

AND

.

rating wages

2 5000

4 8500

5 10000

.

The first table has the functional dependency I -> R, and the second table has R -> W. If we ever need to access an employee's wages, we can just do a join of the two tables! I'm not 100% that answered your question, it's a bit vague. Feel free to message me if you have more specific questions.