Pourquoi avons-nous besoin d'une base de données temporelle?

tenez compte de votre journal intime - il va du 1er janvier au 31 décembre. Maintenant, nous pouvons interroger le journal pour des rendez-vous/entrées de journal n'importe quel jour. Cette commande est appelée la période de validité . Cependant, les nominations/entrées ne sont généralement pas insérées dans l'ordre.

supposez que je voudrais savoir quels rendez-vous/entrées étaient dans mon journal le 4 avril. C'est, de tous les enregistrements qui existait dans mon journal, le 4 avril. C'est le Heure de la transaction .

étant donné que les nominations/entrées peuvent être créées et supprimées, etc. Un enregistrement typique a une heure de début et de fin valide qui couvre la période de l'entrée et une heure de début et de fin de transaction qui indique la période pendant laquelle l'entrée est apparue dans le journal.

cette disposition est nécessaire lorsque le journal peut subir révision historique . Supposons que le 5 avril je réalise que le le rendez - vous que j'avais le 14 février a effectivement eu lieu le 12 février i.e. je découvre une erreur dans mon journal-je peux corriger l'erreur de sorte que l'image d'heure valide est corrigée, mais maintenant, ma question de ce qui était dans le journal le 4 avril serait fausse, à moins que, les temps de transaction pour les rendez-vous/entrées sont également stockées. Dans ce cas, si j'interroge mon journal à partir du 4 avril, cela indiquera qu'un rendez-vous existait le 14 février, mais si je interroge à partir du 6 avril, cela indiquerait un rendez-vous le 12 février.

cette caractéristique de voyage dans le temps d'une base de données temporelle 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 obtenir une image fidèle de la vérification des données qui enregistre les révisions effectuées et permet de poser des questions sur la façon dont les données ont été révisées. temps.

la plupart des informations d'affaires doivent être stockées dans ce schéma bitemporal afin de fournir un véritable dossier d'audit et de maximiser l'intelligence d'affaires - d'où la nécessité pour le soutien dans une base de données relationnelle. Notez que chaque élément de données occupe un carré (peut-être illimité) dans le modèle de temps bidimensionnel, c'est pourquoi les gens utilisent souvent un index GIST pour mettre en œuvre l'indexation bitemporal. Le problème ici est qu'un index GIST est vraiment conçu pour les données géographiques et les exigences pour les données temporelles sont quelque peu différentes.

PostgreSQL 9.0 les contraintes d'exclusion devraient fournir de nouvelles façons d'organiser les données temporelles, par exemple: les périodes de transaction et de validité ne devraient pas se chevaucher pour le même tuple.

si je comprends bien (et simplifiant énormément), une base de données temporelle enregistre des faits sur la validité des données ainsi que les données elles-mêmes, et vous permet de poser des questions sur les aspects temporels. Vous finissez par traiter des tables' valid time 'et' transaction time', ou' bitemporal tables 'impliquant à la fois des aspects' valid time 'et' transaction time'. Vous devriez envisager de lire l'un de ces deux livres:

• Darwen, Date et Lorentzos " données temporelles et le modèle relationnel "(épuisé),
• et (à une conception radicalement différente de l'extrême) " Temps de Développement Orientée Applications de Base de données dans SQL ", Richard T. Snodgrass, Morgan Kaufmann Publishers, Inc., San Francisco, juillet 1999, 504+xxiii pages, ISBN 1-55860-436-7. C'est épuisé, mais disponible en PDF sur son site Web au cs.arizona.edu (donc une recherche Google rend assez facile à trouver.)

les bases de données temporelles sont souvent utilisées dans l'industrie des services financiers. Une raison est que vous êtes rarement (si jamais) autorisé à supprimer des données, donc Valid from - ValidTo type Champs sur les enregistrements sont utilisés pour fournir une indication de quand un enregistrement était correct.

mis à part la lecture de article Wikipedia ? Une base de données qui maintient un" journal de vérification "ou un journal de transactions similaire aura certaines propriétés de"temporalité". Si vous avez besoin de réponses à des questions sur qui a fait quoi à qui et quand alors vous avez un bon candidat pour une base de données temporelle.

vous pouvez imaginer une simple base de données temporelle qui enregistre votre localisation GPS toutes les quelques secondes. Les possibilités pour la compression de données est grande, une base de données normale vous devez stocker un horodatage pour chaque ligne. Si vous avez beaucoup de débit requis, sachant que les données sont temporelles et que les mises à jour et les suppressions à une rangée ne sera jamais nécessaire permet au programme de laisser tomber une grande partie de la complexité hériter dans un RDBMS typique.

malgré cela, les données temporelles est généralement simplement stockées dans un SGBD. PostgreSQL , par exemple, a quelques prolongements temporels , ce qui rend cela un peu plus facile.

Deux raisons viennent à l'esprit:

1. certains sont optimisés pour insérer et lire seulement et peuvent offrir des améliorations de perf spectaculaires
2. certains ont une meilleure compréhension du temps que le SQL traditionnel-permettant de regrouper les opérations par seconde, minute ,heure, etc

juste une mise à jour, la base de données temporelle arrive à SQL Server 2016.

pour dissiper tous vos doutes sur la nécessité d'une base de données temporelle, plutôt que de configurer avec des méthodes personnalisées, et sur L'efficacité et la fluidité avec lesquelles SQL Server le configure pour vous, consultez la vidéo détaillée et la démo sur Channel9.msdn ici: https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

lien MSDN: https://msdn.microsoft.com/en-us/library/dn935015 (v=sql.130).aspx

actuellement avec la version CTP2 (beta 2) de SQL Server 2016, vous pouvez jouer avec elle.

Vérifier cette vidéo sur la façon d'utiliser Temporelle des Tables dans SQL Server 2016.

en plus de "ce que de nouvelles choses que je peux faire avec elle", il pourrait être utile d'envisager de "ce que des choses anciennes ne unifier?". La base de données temporelle représente une généralisation particulière de la base de données SQL "normale". En tant que tel, il peut vous donner une solution unifiée à des problèmes qui semblaient auparavant sans rapport. Par exemple:

• Web Competiency lorsque votre base de données possède une interface Web qui permet à plusieurs utilisateurs d'effectuer la création/mise à jour/suppression standard (CRUD) modifications, vous devez faire face au problèmes de modifications simultanées du web . Fondamentalement, vous devez vérifier qu'une modification des données entrantes n'affecte pas les enregistrements qui ont changé depuis que l'Utilisateur a vu ces enregistrements pour la dernière fois. Mais si vous avez une base de données temporelle, il est fort possible qu'elle associe déjà quelque chose comme un "ID de révision" à chaque enregistrement (en raison de la difficulté de rendre les horodatages uniques et monotones ascendants). Si oui, que devient le naturel, mécanisme "déjà intégré" pour prévenir le fracas des données des autres utilisateurs lors des mises à jour de la base de données.
• Juridique/Dossiers Fiscaux Le système juridique (y compris les taxes) met plutôt l'accent sur des données historiques que la plupart des programmeurs ne. Ainsi, vous trouverez souvent conseil sur les schémas pour les factures et tels qui vous avertit de se méfier de supprimer des dossiers ou de normaliser d'une manière naturelle-ce qui peut conduire à une incapacité de répondre questions juridiques de base comme " oubliez leur adresse actuelle, à quelle adresse avez-vous envoyé cette facture en 2001?"Avec un cadre temporel de base, toutes les machinations à ces problèmes (ils sont généralement à mi-chemin d'avoir une base de données temporelle) s'en vont. Vous utilisez juste le schéma le plus naturel, et supprimez quand il a du sens, sachant que vous pouvez toujours revenir en arrière et répondre aux questions historiques avec précision.

d'autre part, le modèle temporel lui-même est à mi-chemin pour compléter le contrôle de révision, qui pourrait inspirer d'autres applications. Par exemple, supposons que vous rouliez votre propre installation temporelle sur SQL et autorisiez la ramification, comme dans les systèmes de contrôle de révision. Même un branchement limité pourrait faciliter l'offre de" sandboxing " -- la possibilité de jouer et de modifier la base de données avec abandon sans causer de changements visibles aux autres utilisateurs. Il est donc facile de fournir une formation très réaliste aux utilisateurs sur une base de données complexe.

Simple le branchement avec une simple fonction de fusion pourrait également simplifier certains problèmes courants de flux de travail. Par exemple, un organisme à but non lucratif peut faire entrer des données par des bénévoles ou des travailleurs à faible revenu. En donnant à chaque travailleur sa propre branche, on pourrait facilement permettre à un superviseur d'examiner son travail ou de l'améliorer (p. ex., dé-duplification) avant de le fusionner à la branche principale où il deviendrait visible pour les utilisateurs "normaux". Les Branches pourraient aussi simplifier les permissions. Si un utilisateur est seulement autorisé à utiliser / voir leur unique branche, vous n'avez pas à vous soucier de prévenir toutes les modifications indésirables possibles; vous ne fusionnerez que les changements qui ont du sens de toute façon.

ma compréhension des bases de données temporelles est axée sur le stockage de certains types d'information temporelle. Vous pouvez simuler cela avec un RDBMS standard, mais en utilisant une base de données qui le supporte Vous avez intégré des idiomes pour beaucoup de concepts et le langage de requête pourrait être optimisé pour ce genre de requêtes.

pour moi, c'est un peu comme travailler avec une base de données spécifique au SIG plutôt qu'avec un SGBDR. Tandis que vous pourriez enfoncer des coordonnées dans un les RDBMS de type run-of-the-mill, ayant les représentations appropriées (par exemple, via des fichiers grid) peuvent être plus rapides, et avoir des primitives SQL pour des choses comme la topologie est utile.

il existe des bases de données universitaires et certaines commerciales. Timecenter a des liens.

un autre exemple où une base de données temporelle est utile est celui où les données changent avec le temps. J'ai passé quelques années à travailler pour un distributeur d'électricité où nous avons stocké les relevés de compteurs pendant 30 minutes. Ces relevés de compteurs pouvaient être révisés à tout moment, mais nous devions quand même pouvoir examiner l'historique des changements pour les relevés.

nous avons donc eu la dernière lecture (notre "compréhension actuelle" de la consommation pour les 30 minutes) mais pourrait regardez notre compréhension historique de la consommation. Quand vous avez des données qui peuvent être ajustées de telle façon que les bases de données temporelles fonctionnent bien.

(cela dit, nous l'avons sculpté à la main en SQL, mais c'était il y a longtemps. Je ne prendrais pas cette décision ces jours-ci.)