Pourquoi avons-nous besoin d'une base de données temporelle?
Je lisais sur les bases de données temporelles et il semble qu'elles aient intégré des aspects temporels. Je me demande pourquoi aurions-nous besoin d'un tel modèle?
En quoi est-il différent d'un SGBDR normal? Ne pouvons-nous pas avoir une base de données normale, c'est-à-dire un SGBDR et dire avoir un déclencheur qui associe un horodatage à chaque transaction qui se produit? Peut-être y aurait-il un impact sur les performances. Mais je reste sceptique quant aux bases de données temporelles ayant un dossier solide sur le marché.
L'une des bases de données actuelles prend-elle en charge une telle fonctionnalité?
Une base de données temporelle stocke efficacement une série chronologique de données, généralement en ayant une échelle de temps fixe (comme des secondes ou même des millisecondes), puis en stockant uniquement les changements dans les données mesurées. Un horodatage dans un SGBDR est une valeur stockée discrètement pour chaque mesure, ce qui est très inefficace. Une base de données temporelle est souvent utilisée dans des applications de surveillance en temps réel comme SCADA. Un système bien établi est la base de données PI d'OSISoft ( http://www.osisoft.com/ ).
Pensez à votre rendez-vous/journal intime - il va du 1er janvier au 31 décembre. Maintenant, nous pouvons interroger le journal pour les rendez-vous/entrées de journal n'importe quel jour. Cette commande est appelée heure valide. Cependant, les rendez-vous/entrées ne sont généralement pas insérés dans l'ordre.
Supposons que j'aimerais savoir quels rendez-vous/entrées étaient dans mon journal le 4 avril. Autrement dit, tous les enregistrements qui existaient dans mon journal le 4 avril. C'est le temps de transaction.
Étant donné que les rendez-vous/entrées peuvent être créés et supprimés, 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.
Cet arrangement est nécessaire lorsque l'agenda peut subir révision historique. Supposons que le 5 avril, je réalise que le rendez-vous que j'ai eu le 14 février s'est effectivement produit le 12 février, c'est-à-dire que je découvre une erreur dans mon journal - je peux corriger l'erreur afin que l'image de l'heure valide soit corrigée, mais maintenant, ma requête de ce qui était dans l'agenda du 4 avril serait erroné, À MOINS QUE, les temps de transaction pour les rendez-vous/entrées soient également stockés. Dans ce cas, si j'interroge mon agenda à partir du 4 avril, cela montrera qu'un rendez-vous existait le 14 février, mais si j'interroge à partir du 6 avril, il affichera un rendez-vous le 12 février.
Cette fonction 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. Ceci est nécessaire pour une véritable image d'audit des données qui enregistre les révisions et permet des requêtes concernant la façon dont les données ont été révisées au fil du temps.
La plupart des informations commerciales doivent être stockées dans ce schéma bitemporel afin de fournir un véritable enregistrement d'audit et de maximiser la Business Intelligence - d'où le besoin de support dans une base de données relationnelle. Notez que chaque élément de données occupe un carré (éventuellement non borné) dans le modèle temporel bidimensionnel, c'est pourquoi les gens utilisent souvent un index Gist pour implémenter l'indexation bitemporelle. Le problème ici est qu'un indice Gist est vraiment conçu pour les données géographiques et les exigences pour les données temporelles sont quelque peu différentes.
Les contraintes d'exclusion de PostgreSQL 9.0 devraient fournir de nouvelles façons d'organiser les données temporelles, par exemple les périodes de transaction et d'heure valide ne doivent pas se chevaucher pour le même tuple.
Si je comprends bien (et simplifie énormément), une base de données temporelle enregistre des faits sur le moment où les données étaient valides ainsi que les données elles-mêmes, et vous permet d'interroger sur les aspects temporels. Vous finissez par traiter des tables de "temps valide" et de "temps de transaction", ou des "tables bitemporelles" impliquant à la fois des aspects de "temps valide" et de "temps de transaction". Vous devriez envisager de lire l'un de ces deux livres:
- Darwen, Date et Lorentzos " Données temporelles et modèle relationnel " (épuisé),
- et (à un extrême radicalement différent) " Developing Time-Oriented Database Applications in 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 tant que PDF sur son site Web à cs.arizona.ed (donc une recherche Google le rend assez facile à trouver).
Les bases de données temporelles sont souvent utilisées dans l'industrie des services financiers. L'une des raisons est que vous êtes rarement (voire jamais) autorisé à supprimer des données, donc ValidFrom - Les champs de type ValidTo sur les enregistrements sont utilisés pour fournir une indication du moment où un enregistrement était correct.
Juste une mise à jour, la base de données temporelle arrive sur SQL Server 2016.
Pour effacer tous vos doutes quant à la raison pour laquelle il faut une base de données temporelle, plutôt que de configurer avec des méthodes personnalisées, et avec quelle efficacité et transparence SQL Server la 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.
Vérifiez cette vidéo sur la façon d'utiliser les tables temporelles dans SQL Server 2016.
Deux raisons me viennent à l'esprit:
- Certains sont optimisés pour l'insertion et la lecture seule et peuvent offrir des améliorations de performances spectaculaires
- Certains ont une meilleure compréhension du temps que le SQL traditionnel - permettant de regrouper les opérations par seconde, minute, heure, etc.
En plus de lire le article Wikipedia ? Une base de données qui conserve un "journal d'audit" ou un journal de transactions similaire aura certaines propriétés d'être "temporelle". Si vous avez besoin de réponses aux questions sur qui a fait quoi à qui et quand , alors vous avez un bon candidat pour une base de données temporelle.
Outre "quelles nouvelles choses puis-je en faire", il pourrait être utile de considérer "quelles anciennes choses unifie-t-il?". 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 ne semblaient pas liés auparavant. Par exemple:
- Accès concurrentiel Web Lorsque votre base de données possède une interface utilisateur Web qui permet à plusieurs utilisateurs d'effectuer des modifications CRUD (Create/Update/Delete) standard, vous devez faire face au - problème de changements Web simultanés . 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, elle associe très probablement déjà quelque chose comme un "ID de révision" à chaque enregistrement (en raison de la difficulté de rendre les horodatages uniques et ascendants monotones). Si tel est le cas, cela devient le mécanisme naturel "déjà intégré" pour empêcher le clobber les données des autres utilisateurs lors des mises à jour de la base de données.
- Dossiers juridiques/fiscaux Le système juridique (y compris les taxes) met davantage l'accent sur les données historiques que la plupart des programmeurs. Ainsi, vous trouverez souvent conseils sur les schémas de factures et tels que vous avertit de vous méfier de supprimer des enregistrements ou de normaliser de manière naturelle - ce qui peut conduire à une incapacité à répondre à des questions juridiques de base comme "Oubliez" leur adresse actuelle, à quelle adresse avez-vous envoyé cette facture en 2001? " Avec une base de cadre temporel, toutes les machinations à ces problèmes (elles sont généralement à mi-chemin pour avoir une base de données temporelle) disparaissent. Vous utilisez simplement le schéma le plus naturel et supprimez lorsque cela a du sens, sachant que vous pouvez toujours revenir en arrière et répondre avec précision aux questions historiques.
D'un autre côté, le modèle temporel lui-même est à mi-chemin pour achever le contrôle des révisions, ce qui pourrait inspirer d'autres applications. Par exemple, supposons que vous déployez votre propre fonction temporelle au-dessus de SQL et autorisez la ramification, comme dans les systèmes de contrôle de révision. Même des branchements limités pourraient faciliter l'offre de "sandboxing" - la possibilité de jouer avec et de modifier la base de données avec abandon sans provoquer de changements visibles pour les autres utilisateurs. Cela permet de fournir facilement une formation utilisateur très réaliste sur une base de données complexe.
Une simple branche avec une simple fonction de fusion pourrait également simplifier certains problèmes courants de workflow. Par exemple, un organisme sans but lucratif peut avoir des bénévoles ou des travailleurs à bas salaire qui font la saisie des données. Donner à chaque travailleur sa propre succursale pourrait permettre facilement à un superviseur de revoir son travail ou de l'améliorer (par exemple, la déduplication) avant de le fusionner dans la succursale principale où il deviendrait visible pour les utilisateurs "normaux". Les succursales pourraient également simplifier les autorisations. Si un utilisateur est uniquement autorisé à utiliser/voir sa branche unique, vous n'avez pas à vous soucier d'empêcher toutes les modifications indésirables possibles; vous ne ferez que fusionner les changements qui ont du sens de toute façon.
Vous pouvez imaginer une base de données temporelle simple qui enregistre simplement votre position GPS toutes les quelques secondes. Les possibilités de compression de ces données sont excellentes, une base de données normale dont vous auriez besoin pour stocker un horodatage pour chaque ligne. Si vous avez beaucoup de débit requis, le fait de savoir que les données sont temporelles et que les mises à jour et les suppressions d'une ligne ne seront jamais nécessaires permet au programme de supprimer une grande partie de la complexité héritée d'un SGBDR typique.
Malgré cela, les données temporelles sont généralement stockées dans un SGBDR normal. PostgreSQL, par exemple, a quelques extensions temporelles , ce qui rend cela un peu plus facile.
Un autre exemple de cas où une base de données temporelle est utile est celui où les données changent au fil du temps. J'ai passé quelques années à travailler pour un détaillant d'électricité où nous avons stocké des relevés de compteurs pendant des blocs de 30 minutes. Ces relevés de compteurs pouvaient être révisés à tout moment, mais nous devions tout de même pouvoir revenir en arrière sur l'historique des modifications des relevés.
Nous avions donc la dernière lecture (notre "compréhension actuelle" de la consommation pour les 30 minutes) mais nous pouvions revenir sur notre compréhension historique de la consommation. Lorsque vous avez des données qui peuvent être ajustées de telle manière que les bases de données temporelles fonctionnent bien.
(Cela dit, nous l'avons sculpté à la main dans SQL, mais c'était il y a longtemps. Je ne prendrais pas cette décision de nos jours.)
Ma compréhension des bases de données temporelles est orientée vers le stockage de certains types d'informations temporelles. Vous pouvez simuler cela avec un SGBDR standard, mais en utilisant une base de données qui le prend en charge, vous avez des idiomes intégrés pour de nombreux concepts et le langage de requête peut être optimisé pour ce type 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. Bien que vous puissiez insérer des coordonnées dans un SGBDR courant, avoir les représentations appropriées (par exemple, via des fichiers de grille) peut être plus rapide, et avoir des primitives SQL pour des choses comme la topologie est utile.
Il existe des bases de données académiques et certaines commerciales. Timecenter a quelques liens.