>>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.

It may well be redundant indeed. But how can we be sure about that?

In my eyes, your second idea is not a prerequisite.