Home/ Questions/Q 394551
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T16:22:00+00:00

Should dates for a temporal database stored in one or 2 tables ? If

  • 0

Should dates for a temporal database stored in one or 2 tables ? If one doesn’t this violate normalisation ?

PERSON1 DATE11 DATE21 INFO11 INFO21 DEPRECATED
PERSON2 DATE21 DATE22 INFO21 INFO22 CURRENT
PERSON1 DATE31 DATE32 INFO31 INFO32 CURRENT

DATE1 and DATE2 Columns indicate that INFO1 and INFO2 are true for the period between DATE1 and DATE2. If DATE < TODAY, the facts are deprecated and shouldn’t show any more in the user interface but they shouldn’t be deleted for historical purpose. For example INFO11 and INFO21 are now deprecated.

Should I split this table ? Should I store the state (deprecated or current) in the table ?

To clarify the question further more, Deprecated is the term used by the Business, if you prefer “not current”, the problem is not semantic, it’s not about sql queries either, I just want to know which design violates or best suits Normalisation rules (I know normalisation is not always the way to go, that is not my question either).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “I want to know which design violates Normalisation rules”

    Depends on which set of normalization rules you want to go by.

    The first and most likely violation of normal forms, and in Date’s book it is a violation of first NF, is your end-dates in the rows that hold “current” information (making abstraction of the possibility of future-dated information): you violate 1NF if you make that attribute nullable.

    Violations of BCNF may obviously occur as a consequence of your choice of keys (as it is the case in nontemporal database designs too – the temporal aspect makes no difference here). Wrt “choice of keys”: if you use separate start- and end-dates (and SQL kind of leaves you no other choice), then most likely you should declare TWO keys: one that includes the start date, and one that includes the end-date.

    Another design issue is the multiple data columns. This issue is discussed quite at large in “Temporal Data and the Relational Model” : if INFO1 and INFO2 can change independently of one another, it might be better to decompose your tables to hold just one attribute, in order to avoid an “explosion of rows count” that might otherwise occur if you have to create a new complete row every time one single attribute in the row changes. In that case, your design as you gave it constitutes a violation of SIXTH normal form, as (that normal form is) defined in “Temporal Data and the Relational Model”.

    • 0