As I said in an earlier message, this is an area where my experience is limited. You can choose to distinguish historical and current data either by the historical data in a separate table (which complicates the introduction of a new value - the old one has to be moved) or by not recording the end date at all because it is redundant - the previous value's reign ends when the next value begins (but then you have to be wary of performance - watch out for "triangular joins") or by using a special value (or NULL, but that's usually not a good idea) for the end date to distinguish current data (that may be the best option - but don't use a date anywhere in the feasible lifetime of your database as that special value). Look at Esteban Zimányi's 2006 paper "Temporal Aggregates and Temporal Universal Quanti?cation in Standard SQL" (available on pages 16 to 25 of this pdf doc, or get hold of the book "Temporal Data and the Relational Model" by Date, Darwen and Lorentzos if you are heavily into data warehousing with history requirements. For a brief discussion the normal form level of some table types that may be useful there is this but be warned it's aimed at showing that their chosen table forms are all in 6NF, rather than showing how to do anything useful with them; but if you like it, or the tables it describes, you may want to read up on anchor modelling more generally.