Base de données temporelle - Temporal database

Une base de données temporelle stocke des données relatives à des instances temporelles. Il offre des types de données temporelles et stocke des informations relatives au temps passé, présent et futur. Les bases de données temporelles peuvent être uni-temporelles, bi-temporelles ou tri-temporelles.

Plus précisément , les aspects temporels comprennent généralement le temps valide , le temps de transaction ou temps de décision .

• Le temps de validité est la période de temps pendant laquelle un fait est vrai dans le monde réel.
• L'heure de la transaction est l'heure à laquelle un fait a été enregistré dans la base de données.
• Le moment de la décision est le moment où la décision a été prise sur le fait.

Uni-temporel

Une base de données uni-temporelle a un axe de temps, soit la plage de validité, soit la plage de temps du système.

Bi-temporel

Une base de données bi-temporelle a deux axes de temps :

• heure valide
• heure de transaction ou heure de décision

Tri-temporel

Une base de données tri-temporelle a trois axes de temps :

• heure valide
• heure de la transaction
• temps de décision

Cette approche introduit des complexités supplémentaires.

Les bases de données temporelles s'opposent aux bases de données actuelles (à ne pas confondre avec les bases de données actuellement disponibles), qui ne stockent que des faits considérés comme vrais à l'heure actuelle.

Caractéristiques

Les bases de données temporelles prennent en charge la gestion et l'accès aux données temporelles en fournissant une ou plusieurs des fonctionnalités suivantes :

• Un type de données de période, y compris la possibilité de représenter des périodes sans fin (infini ou pour toujours)
• La possibilité de définir des attributs de période de validité et de transaction et des relations bitemporelles
• Temps de transaction maintenu par le système
• Clés primaires temporelles , y compris les contraintes de période sans chevauchement
• Contraintes temporelles, y compris l'unicité sans chevauchement et l' intégrité référentielle
• Mise à jour et suppression des enregistrements temporels avec division et fusion automatiques des périodes de temps
• Requêtes temporelles à l'heure actuelle, à des moments passés ou futurs, ou sur des durées
• Prédicats pour interroger des périodes de temps, souvent basés sur les relations d'intervalle d'Allen

Histoire

Avec le développement de SQL et son utilisation dans des applications réelles, les utilisateurs de bases de données se sont rendu compte que lorsqu'ils ajoutaient des colonnes de date aux champs clés, certains problèmes survenaient. Par exemple, si une table a une clé primaire et certains attributs, l'ajout d'une date à la clé primaire pour suivre les modifications historiques peut entraîner la création de plus de lignes que prévu. Les suppressions doivent également être gérées différemment lorsque les lignes sont suivies de cette manière. En 1992, ce problème a été reconnu, mais la théorie des bases de données standard n'était pas encore à la hauteur de ce problème, pas plus que la norme alors nouvellement formalisée.

Richard Snodgrass a proposé en 1992 que des extensions temporelles de SQL soient développées par la communauté des bases de données temporelles. En réponse à cette proposition, un comité a été formé pour concevoir des extensions à l'édition 1992 de la norme SQL (ANSI X3.135.-1992 et ISO/IEC 9075:1992) ; ces extensions, connues sous le nom de TSQL2, ont été développées en 1993 par ce comité. Fin 1993, Snodgrass a présenté ce travail au groupe responsable de la norme nationale américaine pour le langage de base de données SQL, le comité technique ANSI X3H2 (maintenant connu sous le nom de NCITS H2). La spécification préliminaire du langage est apparue dans l'enregistrement SIGMOD de l'ACM de mars 1994. Sur la base des réponses à cette spécification, des modifications ont été apportées au langage et la version définitive de la spécification du langage TSQL2 a été publiée en septembre 1994.

Une tentative a été faite pour incorporer des parties de TSQL2 dans le nouveau standard SQL SQL:1999 , appelé SQL3. Des parties de TSQL2 ont été incluses dans une nouvelle sous-norme de SQL3, ISO/IEC 9075-7, appelée SQL/Temporal. L'approche TSQL2 a été fortement critiquée par Chris Date et Hugh Darwen . Le projet ISO chargé du support temporel a été annulé vers la fin de 2001.

Depuis décembre 2011, ISO/IEC 9075, Database Language SQL:2011 Partie 2 : SQL/Foundation a inclus des clauses dans les définitions de table pour définir les « tables de période d'application » ( tables horaires valides ), « tables versionnées par le système » ( heure de transaction tables) et « tables de période d'application versionnées par le système » ( tables bitemporelles ). Une différence substantielle entre la proposition TSQL2 et ce qui a été adopté dans SQL:2011 est qu'il n'y a pas de colonnes cachées dans le traitement SQL:2011, ni de nouveau type de données pour les intervalles ; à la place, deux colonnes de date ou d'horodatage peuvent être liées ensemble à l'aide d'une PERIOD FORdéclaration. Une autre différence est le remplacement des modificateurs d'instruction controversés (préfixes) de TSQL2 par un ensemble de prédicats temporels.

Les autres fonctionnalités de la norme SQL:2011 liées aux bases de données temporelles sont le fractionnement automatique des périodes, les clés primaires temporelles, l'intégrité référentielle temporelle, les prédicats temporels avec l'algèbre d'intervalle d' Allen et les requêtes en tranches temporelles et séquencées.

Exemple

À titre d'illustration, considérons la courte biographie suivante d'un homme fictif, John Doe :

John Doe est né le 3 avril 1975 au Kids Hospital of Medicine County, en tant que fils de Jack Doe et Jane Doe qui vivaient à Smallville. Jack Doe a fièrement enregistré la naissance de son premier-né le 4 avril 1975 à l'hôtel de ville de Smallville. John a grandi comme un garçon joyeux, s'est avéré être un étudiant brillant et a obtenu son diplôme avec mention en 1993. Après l'obtention de son diplôme, il est allé vivre seul à Bigtown. Bien qu'il ait déménagé le 26 août 1994, il a oublié d'enregistrer officiellement le changement d'adresse. Ce n'est qu'au tournant des saisons que sa mère lui rappelle qu'il doit s'inscrire, ce qu'il fait quelques jours plus tard, le 27 décembre 1994. Bien que John ait un avenir prometteur, son histoire se termine tragiquement. John Doe a été accidentellement heurté par un camion le 1er avril 2001. Le coroner a signalé sa date de décès le même jour.

Utiliser une base de données non temporelle

Pour stocker la vie de John Doe dans une base de données actuelle (non temporelle), nous utilisons une table Person (Name, Address) . (Afin de simplifier, Name est défini comme la clé primaire de Person .)

Le père de John a officiellement déclaré sa naissance le 4 avril 1975. À cette date, un fonctionnaire de Smallville a inséré l'entrée suivante dans la base de données : Person(John Doe, Smallville). Notez que la date elle-même n'est pas stockée dans la base de données.

Après l'obtention de son diplôme, John déménage, mais oublie d'enregistrer sa nouvelle adresse. L'entrée de John dans la base de données n'est modifiée que le 27 décembre 1994, date à laquelle il la rapporte finalement. Un responsable de Bigtown met à jour son adresse dans la base de données. La table Person contient maintenant Person(John Doe, Bigtown). Notez que les informations de John vivant à Smallville ont été écrasées, il n'est donc plus possible de récupérer ces informations dans la base de données. Un fonctionnaire accédant à la base de données le 28 décembre 1994 apprendrait que John habite à Bigtown. Plus techniquement : si un administrateur de base de données exécutait la requête SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'le 26 décembre 1994, le résultat serait Smallville. L'exécution de la même requête 2 jours plus tard entraînerait Bigtown.

Jusqu'à sa mort, la base de données indiquerait qu'il vivait à Bigtown. Le 1er avril 2001, le coroner supprime l'entrée John Doe de la base de données. Après cela, l'exécution de la requête ci-dessus ne renverrait aucun résultat.

Date	Événement du monde réel	Action de base de données	Ce que la base de données montre
3 avril 1975	Jean est né	Rien	Il n'y a personne qui s'appelle John Doe
4 avril 1975	Le père de John annonce officiellement la naissance de John	Inséré : personne (John Doe, Smallville)	John Doe vit à Smallville
26 août 1994	Après l'obtention du diplôme, John déménage à Bigtown, mais oublie d'enregistrer sa nouvelle adresse	Rien	John Doe vit à Smallville
26 décembre 1994	Rien	Rien	John Doe vit à Smallville
27 décembre 1994	John enregistre sa nouvelle adresse	Mise à jour : personne (John Doe, Bigtown)	John Doe vit à Bigtown
1er avril 2001	Jean meurt	Supprimé : personne (John Doe)	Il n'y a personne qui s'appelle John Doe

Utilisation d'un seul axe : temps valide ou temps de transaction

Le temps valide est le temps pendant lequel un fait est vrai dans le monde réel. Une période de temps valide peut être dans le passé, s'étendre sur l'heure actuelle ou se produire dans le futur.

Pour l'exemple ci-dessus, pour enregistrer l'heure valide, la table Person a deux champs ajoutés, Valid-From et Valid-To . Ceux-ci spécifient la période pendant laquelle l'adresse d'une personne est valide dans le monde réel. Le 4 avril 1975, le père de John a enregistré la naissance de son fils. Un fonctionnaire insère alors une nouvelle entrée dans la base de données indiquant que John habite à Smallville depuis le 3 avril. Notez que bien que les données aient été insérées le 4, la base de données indique que les informations sont valides depuis le 3. Le fonctionnaire ne sait pas encore si ou quand John déménagera à un autre endroit, le champ Valid-To est donc défini sur l' infini (∞). L'entrée dans la base de données est :

Person(John Doe, Smallville, 3-Apr-1975, ∞).

Le 27 décembre 1994, John signale sa nouvelle adresse à Bigtown où il vit depuis le 26 août 1994. Une nouvelle entrée dans la base de données est créée pour enregistrer ce fait :

Person(John Doe, Bigtown, 26-Aug-1994, ∞).

L'entrée d'origine Person (John Doe, Smallville, 3-Apr-1975, ∞)n'est pas supprimée, mais l' attribut Valid-To est mis à jour pour refléter le fait que l'on sait maintenant que John a cessé de vivre à Smallville le 26 août 1994. La base de données contient maintenant deux entrées pour John Doe

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, ∞).

Lorsque John meurt, son entrée actuelle dans la base de données est mise à jour indiquant que John ne vit plus à Bigtown. La base de données ressemble maintenant à ceci

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Apr-2001).

Utilisation de deux axes : temps valide et temps de transaction

Le temps de transaction enregistre la période pendant laquelle une entrée de base de données est acceptée comme correcte. Cela permet des requêtes qui montrent l'état de la base de données à un moment donné. Les périodes de transaction ne peuvent se produire que dans le passé ou jusqu'à l'heure actuelle. Dans un calendrier de transaction, les enregistrements ne sont jamais supprimés. Seuls de nouveaux enregistrements peuvent être insérés et les enregistrements existants mis à jour en définissant l'heure de fin de leur transaction pour montrer qu'ils ne sont plus à jour.

Pour activer l'heure de la transaction dans l'exemple ci-dessus, deux champs supplémentaires sont ajoutés à la table Person : Transaction-From et Transaction-To . Transaction-From est l'heure à laquelle une transaction a été effectuée, et Transaction-To est l'heure à laquelle la transaction a été remplacée (qui peut être infinie si elle n'a pas encore été remplacée). Cela fait de la table une table bitemporelle .

Que se passe-t-il si l'adresse de la personne telle qu'elle est stockée dans la base de données est incorrecte ? Supposons qu'un fonctionnaire ait accidentellement saisi la mauvaise adresse ou la mauvaise date ? Ou, supposons que la personne ait menti au sujet de son adresse pour une raison quelconque. Dès la découverte de l'erreur, les fonctionnaires mettent à jour la base de données pour corriger les informations enregistrées.

Par exemple, du 1er juin 1995 au 3 septembre 2000, John Doe a déménagé à Beachy. Mais pour éviter de payer la taxe de séjour exorbitante de Beachy, il ne l'a jamais signalé aux autorités. Plus tard, lors d'une enquête fiscale, on découvre le 2 février 2001 qu'il était en fait à Beachy à ces dates. Pour enregistrer ce fait, l'entrée existante sur John vivant à Bigtown doit être divisée en deux enregistrements distincts, et un nouvel enregistrement inséré enregistrant sa résidence à Beachy. La base de données apparaîtrait alors comme suit :

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001).

Cependant, cela ne laisse aucune trace que la base de données ait jamais affirmé qu'il a vécu à Bigtown du 1er juin 1995 au 3 septembre 2000. Cela peut être important à savoir pour des raisons d'audit, ou à utiliser comme preuve dans l'enquête fiscale du fonctionnaire. Le temps de transaction permet de capturer cette connaissance changeante dans la base de données, puisque les entrées ne sont jamais directement modifiées ou supprimées. Au lieu de cela, chaque entrée enregistre quand elle a été entrée et quand elle a été remplacée (ou supprimée logiquement). Le contenu de la base de données ressemble alors à ceci :

Name, City, Valid From, Valid Till, Entered, Superseded

Person(John Doe, Smallville, 3-Apr-1975,  ∞,           4-Apr-1975,  27-Dec-1994).
Person(John Doe, Smallville, 3-Apr-1975,  26-Aug-1994, 27-Dec-1994, ∞          ).
Person(John Doe, Bigtown,    26-Aug-1994, ∞,           27-Dec-1994, 2-Feb-2001 ).
Person(John Doe, Bigtown,    26-Aug-1994, 1-Jun-1995,  2-Feb-2001,  ∞          ).
Person(John Doe, Beachy,     1-Jun-1995,  3-Sep-2000,  2-Feb-2001,  ∞          ).
Person(John Doe, Bigtown,    3-Sep-2000,  ∞,           2-Feb-2001,  1-Apr-2001 ).
Person(John Doe, Bigtown,    3-Sep-2000,  1-Apr-2001,  1-Apr-2001,  ∞          ).

La base de données enregistre non seulement ce qui s'est passé dans le monde réel, mais aussi ce qui a été officiellement enregistré à différents moments.

Utilisation de trois axes : temps de validité, temps de décision et temps de transaction

L'heure de décision est une alternative à la période de temps de transaction pour enregistrer l'heure à laquelle une entrée de base de données peut être acceptée comme correcte. Cela permet des requêtes qui montrent les faits officiellement reconnus à un moment donné, même s'il y a eu un retard dans la validation de ces faits dans la base de données. La prise en charge du temps de décision préserve l'intégralité de l'historique et évite la perte d'informations lors des mises à jour.

Les périodes de temps de décision ne peuvent se produire que dans le passé ou jusqu'au moment de la transaction. Comme dans un calendrier de transaction, les enregistrements ne sont jamais supprimés. Seuls de nouveaux enregistrements peuvent être insérés et les enregistrements existants mis à jour en définissant leur heure de fin de décision pour montrer qu'ils ne sont plus à jour.

Pour activer le temps de décision, deux champs supplémentaires sont ajoutés à une table de base de données : Décision à partir de et Décision à . Décision à partir de est l'heure à laquelle une décision a été prise, et Décision-à est l'heure à laquelle la décision a été remplacée (qui peut être l'infini si elle n'a pas encore été remplacée). Lorsqu'il est combiné avec le temps de transaction, cela fait de la table une table tritemporelle .

Ce qui suit est une liste d'événements réels qui se sont produits entre les élections présidentielles américaines de 1964 et 1976 :

Date	Décideur	Événement du monde réel
3 novembre 1964	Le collège électoral	Élection de 1964
5 novembre 1968	Le collège électoral	Élection de 1968
7 novembre 1972	Le collège électoral	Élection de 1972
10 octobre 1973	Spiro Agnew	Agnew démissionne
12 octobre 1973	Richard Nixon	Nixon nomme Ford
6 décembre 1973	Congrès	Le Congrès confirme Ford
9 août 1974	Richard Nixon	Nixon démissionne
20 août 1974	Gérald Ford	Ford nomme Rockefeller
19 décembre 1974	Congrès	Le Congrès confirme Rockefeller
2 novembre 1976	Le collège électoral	Élection de 1976

Supposons qu'il y ait un délai constant de 7 jours entre l'heure de décision et l'heure de transaction engagée dans la base de données. Ensuite, après l'élection de 1976, le contenu de la base de données serait :

                   President, Vice President, Valid From, Valid Till, Decision From, Decision To, Transaction From, Transaction To
---------------------------------------------------------------------------------------------------------------------------------- 
Administration(Lyndon Johnson,    Hubert Humphrey, 20-Jan-1965, 20-Jan-1969,  3-Nov-1964,           ∞, 10-Nov-1964,           ∞)
Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1969, 20-Jan-1973,  5-Nov-1968,           ∞, 12-Nov-1968,           ∞)
Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 20-Jan-1977,  7-Nov-1972,           ∞, 14-Nov-1972, 17-Oct-1973)
Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 20-Jan-1977,  7-Nov-1972, 10-Oct-1973, 17-Oct-1973,           ∞)
Administration( Richard Nixon,        Spiro Agnew, 20-Jan-1973, 10-Oct-1973, 10-Oct-1973,           ∞, 17-Oct-1973,           ∞)
Administration( Richard Nixon,           (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973,           ∞, 17-Oct-1973, 13-Dec-1973)
Administration( Richard Nixon,        Gerald Ford,           ∞, 20-Jan-1977, 12-Oct-1973,           ∞, 19-Oct-1973, 13-Dec-1973)
Administration( Richard Nixon,           (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973,  6-Dec-1973, 13-Dec-1973,           ∞)
Administration( Richard Nixon,           (Vacant), 10-Oct-1973,  6-Dec-1973,  6-Dec-1973,           ∞, 13-Dec-1973,           ∞)
Administration( Richard Nixon,        Gerald Ford,           ∞, 20-Jan-1977, 12-Oct-1973,  6-Dec-1973, 13-Dec-1973,           ∞)
Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973, 20-Jan-1977,  6-Dec-1973,           ∞, 13-Dec-1973, 15-Aug-1974)
Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973, 20-Jan-1977,  6-Dec-1973,  8-Aug-1974, 15-Aug-1974,           ∞)
Administration( Richard Nixon,        Gerald Ford,  6-Dec-1973,  9-Aug-1974,  8-Aug-1974,           ∞, 15-Aug-1974,           ∞)
Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 20-Jan-1977,  8-Aug-1974,           ∞, 15-Aug-1974, 26-Dec-1974)
Administration(   Gerald Ford, Nelson Rockefeller,           ∞, 20-Jan-1977, 20-Aug-1974,           ∞, 27-Aug-1974, 26-Dec-1974)
Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 20-Jan-1977,  8-Aug-1974, 19-Dec-1974, 26-Dec-1974,           ∞)
Administration(   Gerald Ford,           (Vacant),  9-Aug-1974, 19-Dec-1974, 19-Dec-1974,           ∞, 26-Dec-1974,           ∞)
Administration(   Gerald Ford, Nelson Rockefeller,           ∞, 20-Jan-1977, 20-Aug-1974, 19-Dec-1974, 26-Dec-1974,           ∞)
Administration(   Gerald Ford, Nelson Rockefeller, 19-Dec-1974, 20-Jan-1977, 19-Dec-1974,           ∞, 26-Dec-1974,           ∞)
Administration(  Jimmy Carter,     Walter Mondale, 20-Jan-1977, 20-Jan-1981,  2-Nov-1976,           ∞,  9-Nov-1976,           ∞)

Considérez la question de savoir qui serait président et vice-président pendant une période valable du 1er janvier 1977 :

• Nixon/Agnew lors de l'utilisation d'une heure de décision et d'une heure de transaction du 14-Nov-1972
• Nixon/(Vacant) lors de l'utilisation d'une heure de décision et d'une heure de transaction du 17-Oct-1973
• Nixon/Ford lors de l'utilisation d'une heure de décision et d'une heure de transaction du 8 août 1974
• Ford/(Vacant) lors de l'utilisation d'une heure de décision du 8 août 1974 et de l'heure de transaction actuelle
• Ford/Rockefeller lors de l'utilisation d'une heure de décision et d'une heure de transaction du courant

Modélisation bitemporelle

Un modèle bitemporel contient à la fois le temps de validité et le temps de transaction. Cela fournit à la fois des informations historiques et de restauration . Les informations historiques (par exemple : "Où habitait Jean en 1992 ?") sont fournies par l'heure de validité. L'annulation (par exemple : "En 1992, où la base de données croyait-elle que John vivait-elle ?") est fournie par l'heure de la transaction. Les réponses à ces exemples de questions peuvent ne pas être les mêmes - la base de données peut avoir été modifiée depuis 1992, ce qui entraîne des résultats différents pour les requêtes.

L'heure de validité et l'heure de la transaction ne doivent pas nécessairement être les mêmes pour un même fait. Par exemple, considérons une base de données temporelle stockant des données sur le XVIIIe siècle. L'heure de validité de ces faits se situe entre 1701 et 1800. L'heure de la transaction indiquerait quand les faits ont été insérés dans la base de données (par exemple, le 21 janvier 1998).

Évolution du schéma

Un problème difficile est la prise en charge des requêtes temporelles dans une base de données de temps de transaction sous un schéma évolutif . Afin d'obtenir une qualité d'archivage parfaite, il est essentiel de stocker les données sous la version du schéma sous laquelle elles sont apparues pour la première fois. Cependant, même la requête temporelle la plus simple réécrivant l'historique d'une valeur d'attribut devrait être réécrite manuellement sous chacune des versions de schéma, potentiellement des centaines comme dans le cas de MediaWiki [1] . Ce processus serait particulièrement éprouvant pour les utilisateurs. Une solution proposée consiste à fournir une réécriture automatique des requêtes, bien que cela ne fasse pas partie de SQL ou de normes similaires.

Les approches pour minimiser les complexités de l' évolution des schémas sont les suivantes :

• d'utiliser une base de données semi-structurée/base de données NoSQL qui réduit la complexité de la modélisation des données d'attributs mais ne fournit aucune fonctionnalité permettant de gérer plusieurs axes temporels.
• d'utiliser une base de données capable de stocker à la fois des données semi-structurées pour les attributs et des données structurées pour les axes temporels (par exemple, SnowflakeDB , PostgreSQL)

Implémentations dans des produits notables

Les implémentations suivantes fournissent des fonctionnalités temporelles dans un système de gestion de base de données relationnelle (SGBDR).

• La version 10.3.4 de MariaDB a ajouté la prise en charge de la norme SQL : 2011 en tant que « tables version système ».
• Base de données Oracle  – Oracle Workspace Manager est une fonctionnalité d'Oracle Database qui permet aux développeurs d'applications et aux administrateurs de bases de données de gérer les versions actuelles, proposées et historiques des données dans la même base de données.
• PostgreSQL version 9.2 a ajouté des types de données natifs à distance capables d'implémenter toutes les fonctionnalités de l'extension à contribution temporelle pgFoundry. Les types de plage PostgreSQL sont pris en charge par de nombreux opérateurs et fonctions natifs.
• Teradata propose deux produits. Teradata version 13.10 et Teradata version 14 ont des fonctionnalités temporelles basées sur TSQL2 intégrées dans la base de données.
• IBM DB2 version 10 a ajouté une fonctionnalité appelée « requête de voyage dans le temps » qui est basée sur les capacités temporelles de la norme SQL:2011 .
• Microsoft SQL Server a introduit les tables temporelles en tant que fonctionnalité pour SQL Server 2016. La fonctionnalité est décrite dans une vidéo sur le site Web « Channel 9 » de Microsoft.

Systèmes de gestion de base de données NoSQL non relationnels qui fournissent des fonctionnalités temporelles, notamment :

• TerminusDB est une base de données graphique open source complète qui prend en charge nativement le contrôle de version, les requêtes de voyage dans le temps et les fonctions de différence. Il possède une architecture de couche immuable basée sur un codage delta et des structures de données succinctes .
• MarkLogic a introduit la prise en charge des données bitemporelles dans la version 8.0. Les horodatages pour l'heure valide et système sont stockés dans des documents JSON ou XML.
• SirixDB stocke très efficacement des instantanés de documents XML et JSON (actuellement) dans un format binaire grâce à un nouvel algorithme de gestion des versions appelé instantané coulissant, qui équilibre les performances de lecture/écriture et ne crée jamais de pics d'écriture. Les requêtes de voyage dans le temps sont prises en charge nativement ainsi que les fonctions de différence.
• XTDB (anciennement Crux) fournit des requêtes Datalog bitemporelles ponctuelles sur les transactions et les documents ingérés à partir des journaux Kafka semi-immuables. Les documents sont automatiquement indexés pour créer des index de modèle Entité-attribut-valeur sans qu'il soit nécessaire de définir un schéma. Les opérations de transaction spécifient les heures de validité effectives. Les temps de transaction sont attribués par Kafka et permettent une évolutivité horizontale via des lectures cohérentes.
• RecallGraph est une base de données de graphes ponctuelles et unitemporelles (temps de transaction), construite sur ArangoDB . Il fonctionne sur le sous-système Foxx Microservice d' ArangoDB . Il présente une sémantique de type VCS dans de nombreuses parties de son interface et est soutenu par un suivi des événements transactionnels . La bitemporalité est répertoriée comme l'un des éléments de sa feuille de route de développement .

Alternatives

Des dimensions à évolution lente peuvent être utilisées pour modéliser des relations temporelles.

Lectures complémentaires

Voir également

• Modélisation d'ancrage
• Théorie des bases de données
• Boutique événementielle
• Base de données spatio-temporelle
• Base de données de séries temporelles

Les références

Liens externes

• "TimeCenter Home" . Centre de temps . Informatique de l'Université d'Arizona. Archivé de l'original le 24 février 2020.
• Relations temporelles en RDF
• Portée temporelle pour les triples RDF
• IBM DB2 10 pour z/OS
• Série d'articles Time and Time Again de Randy Weis et Tom Johnston
• Modèles temporels par Martin Fowler