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

StackOverflow https://stackoverflow.com/questions/800331

  •  03-07-2019
  •  | 
  •  

Question

Je lisais au sujet des 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?

Quelle est la différence avec un SGBDR normal? Ne pouvons-nous pas avoir une base de données normale, c’est-à-dire un SGBDR et avoir un déclencheur qui associe un horodatage à chaque transaction qui a lieu? Peut-être il y aurait un coup de performance. Mais je suis toujours sceptique sur les bases de données temporelles ayant une solide cause sur le marché.

Les bases de données actuelles prennent-elles en charge une telle fonctionnalité?

Était-ce utile?

La solution

Une base de données temporelle stocke efficacement une série temporelle de données, généralement en ayant une échelle de temps fixe (telle que des secondes ou même des millisecondes), puis en ne stockant que les modifications des données mesurées. Un horodatage dans un SGBDR est une valeur discrètement stockée 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 telles que SCADA. La base de données PI de OSISoft ( http://www.osisoft.com/ ) est un système bien établi.

Autres conseils

Considérez votre agenda / journal de rendez-vous - il va du 1er janvier au 31 décembre. Nous pouvons maintenant interroger le journal pour des rendez-vous / des entrées de journal n'importe quel jour Cet ordre est appelé heure de validité . Cependant, les rendez-vous / entrées ne sont généralement pas insérés dans l'ordre.

Supposons que je souhaite savoir quels rendez-vous / entrées étaient dans mon agenda le 4 avril. C’est-à-dire tous les documents qui figuraient dans mon journal le 4 avril. C’est le délai de transaction .

Etant 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 de validité qui couvre la période de la saisie et une heure de début et de fin de transaction qui indique la période durant laquelle l'entrée est apparue dans la liste. agenda.

Cet arrangement est nécessaire lorsque l'agenda peut subir une révision historique . Supposons le 5 avril que je réalise que le rendez-vous que j’ai eu le 14 février a effectivement eu lieu le 12 février, c’est-à-dire que je découvre une erreur dans mon journal. Je peux corriger l’erreur en corrigeant l’image de temps valide. dans l'agenda du 4 avril serait faux, SAUF, les temps de transaction pour les rendez-vous / entrées sont également stockés. Dans ce cas, si j'interroge mon agenda le 4 avril, il indiquera qu'un rendez-vous existait le 14 février mais si j'interroge le 6 avril, il affichera un rendez-vous le 12 février.

Cette fonctionnalité de voyage dans le temps d’une base de données temporelle permet d’enregistrer des informations sur la manière dont les erreurs sont corrigées dans une base de données. Cela est nécessaire pour obtenir une image fidèle de l’audit 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 commerciales doivent être stockées dans ce schéma bitemporel afin de fournir un véritable enregistrement d’audit et de maximiser la veille stratégique - d’où la nécessité de prendre en charge une base de données relationnelle. Notez que chaque élément de données occupe un carré (éventuellement non limité) dans le modèle temporel bidimensionnel, raison pour laquelle les utilisateurs utilisent souvent un index GIST pour implémenter une indexation bitemporale. Le problème ici est qu’un index GIST est réellement conçu pour les données géographiques et que les exigences relatives aux données temporelles sont quelque peu différentes.

Les contraintes d’exclusion de PostgreSQL 9.0 devraient fournir de nouveaux moyens d’organiser les données temporelles, par exemple. les périodes de transaction et les périodes valides 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 la date de validité des données, ainsi que sur les données elles-mêmes, et vous permet d’interroger sur les aspects temporels. Vous vous retrouvez face à des tables "heure de validité" et "heure de transaction", ou "tables bitemporales" impliquant à la fois les aspects "heure de validité" et "heure de transaction". Vous devriez envisager de lire l’un de ces deux livres:

Les bases de données temporelles sont souvent utilisées dans le secteur des services financiers. Une des raisons est que vous êtes rarement (voire jamais) autorisé à supprimer des données. Par conséquent, les champs ValidFrom - ValidTo des enregistrements sont utilisés pour indiquer quand un enregistrement était correct.

À part la lecture de l’article de Wikipedia ? Une base de données qui gère un " journal d'audit " ou un journal de transaction similaire aura certaines propriétés d'être "temporel". Si vous avez besoin de réponses à des questions sur qui a fait quoi à qui et quand , vous avez un bon candidat pour une base de données temporelle.

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. Vous devez disposer d’une base de données normale pour stocker un horodatage pour chaque ligne. Si vous avez besoin de beaucoup de débit, le fait de savoir que les données sont temporelles et que les mises à jour et les suppressions 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 simplement stockées dans un SGBDR normal. PostgreSQL, par exemple, contient des extensions temporelles , ce qui facilite un peu la tâche.

Deux raisons me viennent à l’esprit:

  1. Certains sont optimisés pour l'insertion et la lecture seule et peuvent apporter des améliorations spectaculaires
  2. Certains ont une meilleure compréhension du temps que le SQL traditionnel, ce qui permet de regrouper les opérations par seconde, minute, heure, etc.

Juste une mise à jour, la base de données Temporal arrive dans SQL Server 2016.

Pour dissiper tous vos doutes quant à la nécessité d’une base de données temporelle plutôt que de la configuration à l’aide de méthodes personnalisées, et avec quelle efficacité & amp; de manière transparente, SQL Server le configure pour vous, vérifiez la vidéo détaillée et la démonstration sur Channel9.msdn ici: https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

Lien MSDN: https: // msdn. microsoft.com/fr-fr/library/dn935015(v=sql.130).aspx

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

Vérifiez cette vidéo sur l'utilisation des tables temporelles dans SQL Server 2016.

Outre "quelles nouvelles choses puis-je en faire", il peut ê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 l'expression "normale". Base de données SQL. En tant que tel, il peut vous donner une solution unifiée à des problèmes qui semblaient auparavant ne pas être liés. Par exemple:

  • Concurrence sur le Web Lorsque votre base de données dispose d'une interface utilisateur Web qui permet à plusieurs utilisateurs d'effectuer des modifications CRUD standard, vous devez faire face au problème de modifications simultanées sur le Web . En gros, vous devez vérifier que la modification des données entrantes n’affecte pas les enregistrements qui ont été modifiés depuis la dernière fois que cet utilisateur a vu ces enregistrements. Mais si vous avez une base de données temporelle, il est fort probable qu'elle associe déjà quelque chose comme un "ID de révision". avec chaque enregistrement (en raison de la difficulté de rendre les horodatages uniques et ascendants monotones). Si tel est le cas, cela devient naturel, "déjà intégré". mécanisme permettant d'empêcher la superposition des données d'autres utilisateurs lors des mises à jour de la base de données.
  • Archives juridiques / fiscales 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 des conseils sur les schémas de facturation et vous avertissant de ne pas supprimer des enregistrements ou de normaliser de manière naturelle. manière, ce qui peut entraîner une incapacité à répondre à des questions juridiques de base telles que "Oubliez leur adresse actuelle, à quelle adresse avez-vous envoyé cette facture en 2001?" Avec un cadre de base temporel, toutes les machinations à ces problèmes (elles sont généralement à mi-chemin pour avoir une base de données temporelle) disparaissent. Il vous suffit d'utiliser le schéma le plus naturel et de le supprimer lorsque cela vous semble judicieux, sachant que vous pouvez toujours revenir en arrière et répondre avec précision aux questions historiques.

D'autre part, le modèle temporel lui-même est à mi-chemin du contrôle de révision complet, ce qui pourrait inspirer d'autres applications. Par exemple, supposons que vous déployez votre propre installation temporelle par-dessus SQL et que vous autorisiez la création de branches, comme dans les systèmes de contrôle de révision. Même un nombre limité de succursales pourrait faciliter la proposition de " sandboxing " - la possibilité de jouer avec la base de données et de la modifier avec abandon sans provoquer de modifications visibles pour les autres utilisateurs. Cela facilite la formation extrêmement réaliste des utilisateurs sur une base de données complexe.

La création de branches simples avec une installation de fusion simple pourrait également simplifier certains problèmes courants de flux de travail. Par exemple, une organisation à but non lucratif peut avoir des volontaires ou des travailleurs faiblement rémunérés pour effectuer la saisie de données. Donner à chaque travailleur sa propre branche pourrait permettre à un superviseur de réviser son travail ou de l’améliorer (par exemple, une déduplication) avant de le fusionner dans la branche principale où il deviendrait visible par "normal". utilisateurs. Les branches 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 toute modification indésirable possible; vous ne ferez que fusionner les modifications qui ont du sens.

D'après ce que je comprends, les bases de données temporelles sont destinées à stocker certains types d'informations temporelles. Vous pouvez simuler cela avec un SGBDR standard, mais en utilisant une base de données qui la 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ête.

Pour moi, cela revient un peu à travailler avec une base de données spécifique au SIG plutôt qu’un SGBDR. Bien que vous puissiez déplacer les coordonnées dans un SGBDR classique, il peut être plus rapide de disposer des représentations appropriées (par exemple, via des fichiers de grille) et il est utile de disposer de primitives SQL pour des éléments tels que la topologie.

Il existe des bases de données académiques et certaines commerciales. Timecenter contient des liens.

Un autre exemple d'utilisation d'une base de données temporelle est celui dans lequel les données évoluent dans le temps. J'ai travaillé pendant quelques années chez un détaillant d'électricité, où nous avons stocké les relevés de compteurs pendant des tranches de 30 minutes. Ces relevés de compteur peuvent être révisés à tout moment, mais nous devons tout de même pouvoir consulter l'historique des modifications apportées aux 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, les bases de données temporelles fonctionnent bien.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top