Oops the last one contain some errors, sorry.


Jim,

>I don't know what you mean by "history problem". I often use vertical partitioning to keep historical data away form teh current data, but that has nothing to do with normalization. It is an implementationd eati. Ther is still only one logical entity, I just store the data in two files. And the surrogate PK goes with the record when they are moved from the current tabel to the history table.

By the history problem I mean that if you must be able to track canges trough time, how this affects normalisation.

A popular method of tracking changes is 'stacking' which means that the attributes are copied into another record and marked with a time stamp.

example a persons table:

Personid, firstname, lastname, adress, postalcode, city, dayofbirth, function, department, etc.

when you want to track changes you would probabply add a date identifyier to mark from which data this data becomes current:

(SomePk,) Date, Personid, firstname, lastname, adress, postalcode, city, dayofbirth, function, department, etc.

If this person changes departments the attributes are copied into a new record with a new datestamp. Though the department has changed, it still contains the same values for the other attributes. Is this redundant data ? if so, how would you solve this ?

Walter,