In most database design books and articles, a department table (e.g.) that has columns named employee1, employee2, employee3, etc., is said to not be in 1NF.

However, if you read statements of what 1NF is (e.g., Wikipedia article, Chris Date's paper titled "What First Normal Form Really Means," Codd's articles), you will find that 1NF is concerned ONLY with a single column. Some formulations also say that one must not repeat an attribute, but that's impossible in the relational model and in all of the RDBMSes I'm familiar with.

In fact, Chris Date goes so far as to say that no relational database can have a relation that violates 1NF. It is like the sign on an elevator that says: "Out of order. Do not use."

I have come up with an alternative rule that specifically addresses the employee1, employee2, etc., problem. (What it says isn't relevant to this post.)

My question is this: Is my rule, assuming I've put it together well, an alternative to 1NF as the latter is usually expressed? In order to answer this question, I would need to know what problem 1NF was intended to solve. However, in reading the literature extensively, I have never seen this explained, except that in the Date paper I mentioned above he says that the problem it is intended to solve is the system not being relational. That's not what I was looking for.

I would think that if Codd, Date, etc., were concerned about the employee1, employee2, etc., problem, they would have said so. I suspect they were not, because such a table, however awkward, causes no consistency problems at all, and therefore probably is perfectly OK as far as relational database theory is concerned. (Its flaws are that the table definition needs to be altered whenever another employee is needed, and that the SQL becomes horrendous. I doubt that theoreticians would care about either of those very practical concerns.)

Comments? What problem is 1NF as formulated by the database gurus intended to solve?