modélisation et normalisation de bases de données temporelles

Question

Les dates d'une base de données temporelle doivent-elles être stockées dans un ou deux tableaux? Si cela ne viole pas la normalisation?

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

Colonnes date1 et date2 indiquent que INFO1 et INFO2 sont valables pour la période entre DATE1 et DATE2. Si DATE < AUJOURD'HUI, les faits sont obsolètes et ne devraient plus apparaître dans l'interface utilisateur, mais ils ne devraient pas être supprimés à des fins historiques. Par exemple, INFO11 et INFO21 sont maintenant obsolètes.

Dois-je découper cette table? Dois-je stocker l'état (obsolète ou actuel) dans la table? Pour clarifier la question plus loin, Deprecated est le terme utilisé par le Business, si vous préférez "pas courant", le problème n'est pas sémantique, il ne concerne pas non plus les requêtes sql, je veux juste savoir quel design viole ou convient le mieux aux règles de normalisation (je sais que la normalisation n'est pas toujours la solution, ce n'est pas non plus ma question).

Answer 1

« Je veux savoir ce qui est contraire aux règles de conception Normalization »

dépend du jeu de normalisation règles que vous voulez passer.La première et la plus probable violation des formes normales, et dans le livre de Date, il est une violation de la première NF, est vos dates de fin dans les lignes qui contiennent des informations "actuelles" (faire abstraction de la possibilité de futur-daté information): vous violez 1NF si vous rendez cet attribut nullable.

Des violations de BCNF peuvent évidemment se produire en conséquence de votre choix de clés (comme c'est le cas dans des conceptions de bases de données non temporelles aussi - l'aspect temporel ne fait aucune différence ici). Wrt "choice of keys": si vous utilisez des dates de début et de fin séparées (et que SQL ne vous laisse aucun autre choix), alors vous devriez probablement déclarer DEUX clés: une qui inclut la date de début, et une qui inclut le date de fin.

Un autre problème de conception concerne les colonnes de données multiples. Ce problème est discuté en détail dans «Données temporelles et modèle relationnel»: si INFO1 et INFO2 peuvent changer indépendamment les uns des autres, il peut être préférable de décomposer vos tables pour ne conserver qu'un seul attribut, afin d'éviter une «explosion de rows count "qui pourrait se produire si vous devez créer une nouvelle ligne complète chaque fois qu'un seul attribut de la ligne change. Dans ce cas, votre conception comme vous l'avez donnée constitue une violation de SIXIÈME forme normale, car (cette forme normale est) définie dans "Données temporelles et le modèle relationnel".

Answer 2

La normalisation est un concept de base de données relationnelle - il ne s'applique pas aussi bien aux bases de données temporelles. Cela ne veut pas dire que vous ne pouvez pas stocker des données temporelles dans une base de données relationnelle. Vous pouvez certainement. Mais si vous allez avec la conception de base de données temporelle, alors les concepts de normalisation temporelle s'appliquent plutôt que la normalisation relationnelle.

Answer 3

Vous n'avez pas indiqué la signification des dates. Font-ils référence à (a) la période où le fait déclaré était vrai dans la vie réelle, ou (b) à la période où le fait déclaré était considéré comme vrai par le détenteur de la base de données? Si (b), alors je ne le ferais jamais de cette façon. Déplacez la ligne mise à jour vers une table/journal d'archivage immédiatement lorsque la mise à jour est terminée. Si (a), l'instruction suivante est sujette à caution:

« les faits sont déconseillés et ne doivent pas montrer plus dans l'interface utilisateur »

Si un fait n'a pas « besoin de se présenter dans la interface utilisateur "plus, il n'a plus besoin d'être dans la base de données non plus. Garder ces faits là ne réalise qu'une chose: détériorer la performance générale pour tout le reste. Si vous avez vraiment besoin de ces énoncés historiques pour répondre à vos besoins, il est probable que vos «faits obsolètes» soient toujours très pertinents pour l'entreprise et ne soient donc pas du tout «déconseillés». En supposant que pour cette raison, il y a très peu de faits «vraiment obsolètes» dans votre base de données, votre design est bon. Gardez simplement le nombre de «faits véritablement obsolètes» en les retirant périodiquement de la base de données opérationnelle.

(PS) Dire que votre conception est bonne ne signifie pas que vous ne rencontrerez aucun problème. SQL est extrêmement mal adapté pour gérer ce type d'information avec élégance. "Les données temporelles et le modèle relationnel" est un excellent traitement du sujet. Un autre livre, celui de Snodgrass, est souvent loué, mais pas par moi. Celui-ci est un peu un livre de recettes avec des recettes pour traiter ces problèmes en SQL, comme prouvé par la conversation suivante sur SO à propos de ce livre:

(Q) "Pourquoi lirais-je cela?" (A) "Parce que le déclencheur que vous avez demandé est à la page 135."