Although others have replied to you, I'll take your comment as constructive criticism. Though the tone could be better.

That's exactly what it does. When talking about each normal form, it gives an example and what to change.

> it gives an example and what to change

It gives an example of something wrong. Not once does it give an example of something right. It says "change this" but doesn't show what to change it to.

First normal form:

> Then the “areas” column has values that aren’t atomic. ... So this table is not in first normal form. ... To be in first normal form you should store a single value per field

Second normal form:

> In this design employee name can be directly inferred from employee_id because the idea is that the name of an employee is uniquely defined by it’s id. ... So we have two examples of columns where the columns can be inferred from only part of the primary key.

Don't include those fields. It's not explicitly said, but I think the author assumes that if you're told don't include data that can be inferred otherwise, these fields can be inferred otherwise, so they cause a problem, the solution is to remove those fields. You aren't losing data, it's already been covered that it can be inferred.

Third normal form:

> For a table to be in third normal form then it must be in second normal form and there should not be a non prime attribute* that depends transitively from the primary key. ... In this table the department_number can be inferred from the employee_id, but the department_name can be inferred from the department_number!

Same as second normal form. These fields cause problems, you already have the data elsewhere, get rid of them.

Perhaps you expected an article that said which commands to run to alter the tables. It's pretty obvious that wasn't the goal of this article. That said, it had everything you asked for, as long as you read it all and payed attention.

> To be in first normal form you should store a single value per field

Where? How? How instead should you store groups of things? Blog doesn't say.

> Don't include those fields. You aren't losing data, it's already been covered that it can be inferred.

If you just remove fields, then you absolutely are losing data. Your software can't magically infer it unless you put the values and the relationship somewhere else. So where should the data go instead? What should that look like? Blog doesn't say. Blog doesn't even actually say that you should remove those fields. That's just one possible course of action and you've now put words in blog's mouth.

> These fields cause problems, you already have the data elsewhere, get rid of them.

Again, just deleting fields is 100% losing data unless you put those values somewhere else. How should you handle that? Where should they go? Blog doesn't say.

> Where? How? How instead should you store groups of things? Blog doesn't say.

By normalizing. This is obviously a guide for to do and not to do, not a 101 level course on database design and normalization. You first step should be to google database normalized forms, and even specifically second normal form or third normal form. I know from experience that Wikipedia has articles covering these. I've read portions of them.

> If you just remove fields, then you absolutely are losing data. _YOU_ might be able to infer it, but your software sure as hell can't unless you put the data somewhere else. So where should the data go instead? What should that look like? Blog doesn't say. Blog doesn't even actually say that you should remove those fields. That's just one possible course of action.

> Again, just deleting fields is 100% losing data unless you put those values somewhere else. Where should they go? Blog doesn't say

The point is that if you're working towards normalizing that data, then you have the data in a different location.

The blog entry also doesn't explain what SQL is, or what a primary key or foreign key is. When you encounter terms that are not defined, you should make sure you understand them. If you don't, then the information is likely not aimed at you. If you don't understand normalization, you aren't going to understand what's being recommended. This obviously isn't a guide on how to normalize perfectly, it's a recommendation to do certain things, some of them to do with normalization, and a justification for why.

Consider it the equivalent to telling someone that they should eat a balanced diet for their health and notes some problems too much of certain types of food can cause. It's still valid advice even if it doesn't come with an explanation of exactly what to eat, and references medical phenomena without explaining what they are. That doesn't make it a bad article, it just makes it not terribly useful for people that it isn't aimed at.

A good ER database textbook illustrates normal forms much better than a blog post.

I find that textbooks focus way too much on the strict CS definition of the various normal forms as opposed to practical examples.

That's a sweeping over-generalization. I said find a good textbook.

The poster said "I find that...", which is equivalent to "In my experience...". How is someone posting their experience the same as making a "sweeping over-generalization"? They never flat-out said "ALL textbooks".

Also, surely if it were not accurate you could easily drop the name of a good textbook without any trouble, since you apparently have enough experience with them to make the distinction.