>Hi all,
>
>Here is the introduction to a thought I had that is hopefully interesting for you too.
>
>Database normalisation is based on certain assumptions (this list is not exhaustive):
>
>1) Each table must have a primary key: One, two or eventually even more fields that uniquely identify a record. The smaller the number of such fields, the better.
>
>2) Atomiticy: Each field decribes one and only one entity.
>
>3) The order of the records is not important.
>
>4) Entities must not be stored redundant.
>
>One consequence is that we want to avoid two or more entities to be described by one field only. And we reserve a field for each of those entities. Example:
>
>

>Employeenumber    Category
>12345             1
>42535             2
>34545             1
>34534             1
>

>
>Now consider the following case:
>
>

>Employeenumber
>1-12345
>2-42535
>1-34545
>1-34534
>

>
>We would critize the datamodel if we would encounter the above structure and were told that the employeenumber also incorporates the category. We would say that the atomiticy rule is broken.
>
>In the next case the employeenumber also incorporates the category. But moreover, the category is also stores separately. In this case, we might argue that this is a clear case of redundancy. But is this really, always, the case?
>
>

>Employeenumber    Category
>1-12345           1
>2-42535           2
>1-34545           1
>1-34534           1
>

>
>Yesterday I would, today I no longer have that opinion. How about you?

It seems to be a redundancy, and btw primary key should be meaningless.