Considérez votre rendez-vous/journal journal - cela va du 1er janvier au 31 Dec. Maintenant, nous pouvons requête de l'agenda pour les rendez-vous/les entrées de journal tous les jours. Cette commande est appelée la période de validité. Toutefois, les nominations et les entrées ne sont pas habituellement inséré dans l'ordre.
Supposons que je voudrais savoir ce que les nominations et les entrées ont été dans mon journal, le 4 avril. C'est, de tous les enregistrements qui existait dans mon journal, le 4 avril. C'est le temps de transaction.
Étant donné que les nominations et les entrées peuvent être créés et supprimés etc. Une entrée typique a un début et de fin de la période de validité qui couvre la période de l'entrée et un début et à la fin de la transaction qui indique la période au cours de laquelle l'entrée est apparu dans le journal.
Cet arrangement est nécessaire lorsque le journal peut subir une révision historique. Supposons que le 5 avril, je me rends compte que le rendez-vous que j'avais 14 Février réellement eu lieu le 12 février dernier, c'est à dire, je découvre une erreur dans mon journal que je peux corriger l'erreur, de sorte que la période de validité de l'image est corrigée, mais maintenant, ma requête de ce qui était dans le journal, le 4 avril serait une erreur, à MOINS que, le temps de transaction pour les rendez-vous/les inscriptions sont également stockés. Dans ce cas, si j'ai une requête mon journal du 4 avril, il va montrer un rendez-vous existe le 14 février, mais si j'ai une requête à compter du 6 avril, il montrerait un rendez-vous le 12 février.
Ce voyage dans le temps caractéristique temporelle de base de données permet d'enregistrer des informations sur la façon dont les erreurs sont corrigées dans une base de données. Cela est nécessaire pour une véritable vérification de l'image de données qui enregistre lors des révisions ont été faites, et permet des requêtes relatives à la façon dont les données ont été révisées au cours
temps.
La plupart des professionnels de l'information doivent être stockés dans ce bitemporale schéma afin de permettre un véritable enregistrement d'audit et de maximiser la business intelligence - d'où le besoin de soutien dans une base de données relationnelle. Notez que chaque élément de données occupe une (peut-être illimitée) dans le carré des deux dimensions de temps qui est pourquoi les gens utilisent souvent un index GIST à mettre en œuvre bitemporale d'indexation. Le problème ici est que l'ESSENTIEL de l'indice est vraiment conçu pour les données géographiques et les exigences pour les données temporelles sont un peu différentes.
PostgreSQL 9.0 contraintes d'exclusion devrait fournir de nouvelles méthodes d'organisation temporelle des données de transaction et valide les Périodes de temps ne doit pas se superposer pour le même tuple.
