Okay, let's call it the employee-ID.

You make here the assumption that all IDs will have to be changed if the category changes. But is this assumption correct? If the company would say "yes", then you'd have a decisive argument to call it a stupid decision. But again, is it possible that the company would say "no"?

The behind-the-scenes, meaningless ID is not a prerequisite according to the normalization theory. There is also a real disadvantage to it. Have you ever tried to merge two databases of, for example, two groups of employees, let's say of two departments? This is not an easy job, but it is even harder if abstract IDs identify the employees, rather than an employee-ID.

>I don't think you've explained things well. The stored employee number should be the exact employee number. If it is stored with the category, then I would assume that is the way the company set it up and that's the actual employee number. Now that's kind of dumb because the category may change and you then have one of two bad situations: The employee number has to change (and that is most likely to have serious ramifications) or it has to remain the same (in which case the category is meaningless going forward).
>
>But if the company sets up something stupid like this, then I guess you have to store it exactly that way. I'd create a separate PK and use that as the "internal, behind-the-scenes" employee number, then I'd also create the category number field. So it would be:
>
>

>ID   Employeenumber    Category
>1    1-12345           1
>2    2-42535           2
>3    1-34545           1
>4    1-34534           1
>

>
>Redundant, yes, but only because the company made a dumb decision on how to set up their employee numbers. If this is the way the programmer designed it, then I'd say that's a bad decision, too, and does break normalization.