Posture de données temporelles – Wikipedia

Sous stockage de données temporelles (aussi Historisation Verlé) Dans les technologies de l’information, l’adhésion au développement du temps des données lors du stockage du temps est stockée dans une base de données.

Souvent, il est suffisant pour enregistrer la valeur valide (aujourd’hui) actuelle dans une base de données, et lors du changement, l’ancienne valeur de données est simplement écrasée. Cependant, s’il est nécessaire de documenter toutes les modifications, un stockage de données temporelles est requis. Cela permet de reconstruire la valeur valide à quel moment ou – dans des cas moins fréquents – ne sera valide qu’à l’avenir.

Dans le cas de la posture de données temporelle, deux types de considération de temps sont pertinents:

• Temps de validité : La période pendant laquelle un élément de données est valable dans le monde réel.
  Exemple: Un article au prix de 1,95 € est plus cher du 1er juin 2006 à 2,25 €.
• Temps de transaction (aussi Temps de traitement ): Le moment où un élément de données a été stocké dans la base de données.
  Exemple: L’ajustement des prix ci-dessus de l’article a été modifié le 25 mai 2006 et inclus dans la base de données.

Dans certains cas, les deux types sont en fait pertinents, car vous utilisez également l’expression ” bitemporal “. Cela s’applique, par exemple, à la question suivante liée aux exemples ci-dessus: Quel prix un client a-t-il été appelé le 20 mai 2006 pour l’achat de l’article, par lequel l’achat ne devrait avoir lieu que le 15 juin 2006?

Les détails sur le stockage des données temporelles sont définis (souvent également en relation avec l’archivage des données) comme des exigences pour la sécurité de révision des systèmes d’information. B. Combien de temps les changements doivent être démontrables.

Les variantes suivantes existent dans l’illustration des données temporelles:

• Utilisation de bases de données temporelles
  Ce sont des systèmes de base de données dans lesquels il existe déjà une prise en charge supplémentaire du stockage de données temporelles qui va au-delà de la prise en charge des types de données liés au temps. Pour le moment, cependant, il n’y a que des prototypes pour cela et il n’y a toujours pas de système de base de données commercial disponible qui étendrait les exigences du stockage de données temporelles. ^[d’abord]
• Utilisation de bases de données spatio-temporelles
  Ce sont des systèmes de base de données qui, en plus de prendre en charge les données dépendants du temps, sont également conçus pour le stockage des informations spatiales. Cependant, l’accent est mis sur les informations spatiales. Ces bases de données sont utilisées, par exemple, dans la zone de l’élément routier.
• Illustration dans les bases de données relationnelles conventionnelles
  Étant donné que la prise en charge des types de données temporelles se trouve également dans les systèmes de base de données relationnels conventionnels, les données temporelles peuvent être stockées en principe dans de telles bases de données, par lesquelles les attributs temporels sont cartographiés comme des attributs “normaux”. Les aspects temporels doivent être traités avec les programmes d’application ou via un cadre utilisé pour le développement des applications.
• Illustration dans d’autres bases de données (par exemple des bases de données d’objets)
  Pour d’autres systèmes de bases de données, en particulier les bases de données orientées objet, il n’y a pas d’uniformité et de distribution comparable aux systèmes relationnels, de sorte qu’une déclaration générale sur la cartographie des données temporelles n’est pas possible. Néanmoins, la plupart des aspects ci-dessous peuvent également être transférés dans de telles bases de données.

Dans la section suivante, les propriétés générales de la gestion des données temporelles sont prises en compte, qui s’appliquent largement à toutes les illustrations mentionnées ci-dessus. Ceci est suivi d’une explication détaillée de l’illustration des données temporelles dans les bases de données relationnelles conventionnelles. De plus amples informations sur les autres variantes d’imagerie peuvent être trouvées pour expliquer elles-mêmes les systèmes de gestion de la base de données.

Les termes les plus importants concernant le stockage de données temporelles sont expliqués ci-dessous. Ces explications sont essentiellement coïncidées avec le soi-disant “consensus Gossar” (voir les liens Web).

Temps de valeur et temps de transaction [ Modifier | Modifier le texte source ]]

Comme mentionné au début, le temps de validité ( Temps valide ) Le temps ou la période où un fait s’applique dans l’image modélisée du monde réel (le monde de référence). Les périodes futures et passées peuvent être pertinentes.

En revanche, la période de transaction ( Temps de transaction ) Le moment où un fait a été enregistré dans la base de données et donc la période au moment où ce fait était considéré comme un reflet correct du monde. Contrairement à la période de validité, la période de transaction ne peut jamais se référer à l’avenir. Un exemple intéressant de données temporelles peut être trouvé dans la base de données Wikipedia elle-même, dans laquelle se déroule un calendrier de transaction des articles, ^[2] Pour pouvoir reconstruire les versions d’un article à différents moments (voir la liste des versions de cet article).

Si les temps de validité et de transaction sont pertinents, on parle de stockage de données basé sur Bitemema. Dans ce contexte, il convient également de noter que le temps de transaction peut être déterminé par le système (par exemple le système de base de données), tandis que le temps de validité doit être spécifié par l’utilisateur.

Dans le consensus Gossar, il y a aussi le concept de temps personnalisé ( Temps défini par l’utilisateur ^[3] ). Ceci est destiné à délimiter d’autres fois qui montrent des attributs «normaux» dans la base de données (comme une date de naissance) de l’élevage de données temporelles. Ce nom est malheureux, car le temps de validité est également défini par l’utilisateur.

Comme un instantané ( Instantané ) Si vous vous référez à des données temporelles à un temps fixe pour la validité et éventuellement également la période de transaction. Un tel instantané fait généralement référence à l’heure actuelle. Une base de données sans prise en charge temporelle offre uniquement un tel instantané, c’est pourquoi de telles bases de données sont également appelées dates d’instantané.

Temps, intervalles de temps et temps [ Modifier | Modifier le texte source ]]

Un temps ( Instantané ) représente un point sur une chronologie utilisée. Différentes granulations peuvent être utilisées (par exemple, précision, précision).

Les informations sur le temps peuvent être ancrées (fixes) ou dangereuses. Un temps ancré fait référence à une période spécifique ou à un intervalle de béton dans l’échelle de temps. Une période de temps est un intervalle de temps non sophistiqué.

Les intervalles ancrés dans le temps sont également utilisés comme périodes ( Période de temps ) désigné. Le terme intervalle sans déclaration supplémentaire est trompeur à cet égard, en particulier parce que le terme est utilisé pendant une période de SQL.

Le plus petit intervalle de temps possible avec une certaine granularité est chronone ^[3] Décrit, par exemple, ce serait un jour.

Horaire [ Modifier | Modifier le texte source ]]

L’horodatage est appelé l’ajout d’une référence temporelle à un attribut de données ou à une ligne de données, conjointement avec des bases de données relationnelles, également appelées tupel. Une distinction est faite entre la validité, la transaction et le bimememaum.

En général, il n’est pas défini au début comment cette référence de temps est techniquement montrée. Cela peut être un moment simple qui exprime la validité à un seul moment précis. Cependant, la référence de temps est plus courante sous la forme d’un intervalle de temps. La forme la plus générale ici est un élément temporel si appelé, ^[3] Cela représente beaucoup d’un ou plusieurs intervalles de temps.

Cette référence est également faite dans le consensus Gossar comme horodatage ( Horodatage ) désigné. ^[3] Il est important ici que cela ne soit pas confondu avec la signification conventionnelle de ce terme, car il s’agit d’une forme beaucoup plus abstraite d’un horodatage.

Une distinction est faite lors du remplissage des horodatages explicite et implicite Horodatage. Dans le temporisateur explicite, le horodatage n’est pas fourni par le système de base de données, mais doit être explicitement fourni par le programme d’application (ou par l’architecture utilisée, par exemple un déclencheur de base de données). Il n’y a qu’un horodatage implicite avec des bases de données temporelles “réelles”, où le système de base de données prend généralement cette tâche. Il convient de noter que cela ne peut être complètement encapsulé que dans le cas de la période de transaction, la période de validité doit également être explicitement spécifiée dans la période de validité, mais les bases de données temporelles offrent souvent des interfaces spéciales et ne gèrent pas le horodatage comme attribut normal.

Tempage à horaire Tupel contre attribut [ Modifier | Modifier le texte source ]]

Lors de l’introduction d’un calendrier, la question se pose à quel niveau vous le complétez. Fondamentalement, chaque attribut qui ne se comporte pas de manière synchrone avec un autre devrait être versé pour lui-même, c’est-à-dire avec son propre temps. Cette procédure est appelée horodatage d’attribut.

Cependant, l’effort administratif technique pour un horodatage d’attribut est remarquable, de sorte que vous versionz souvent tous les attributs d’une ligne de données (d’une tupel) ensemble, bien que les attributs ne se comportent pas de manière synchrone dans le temps. C’est ce qu’on appelle un horodatage Tupel.

La décision de la procédure que vous choisissez dépend principalement de la fréquence du changement des attributs individuels. En règle générale, les attributs avec un degré élevé de changement seront plus susceptibles d’être utilisés pour eux-mêmes, en revanche, les attributs avec une basse fréquence de changement. ^[4]

Normalisation temporelle ( Fusionné ) [ Modifier | Modifier le texte source ]]

Avec le horodatage Tupel, cependant, le problème est inévitable qu’avec des évaluations selon lesquelles l’un des attributs partagés est évalué, on obtient les périodes suivantes dans lesquelles les valeurs d’attribut ne diffèrent pas. Ils auraient aimé résumer ces périodes. Un tel résumé est appelé normalisation temporelle (également Fusionné ^[3] ).

L’utilisation du calendrier Tupel n’est pas la seule raison pour laquelle vous avez besoin d’une normalisation temporelle. Par exemple, cette normalisation est également requise si vous n’évaluez que les données bitemporales séparément après la validité ou la période de transaction. De plus, un tel résumé est également souhaitable si vous liez plusieurs talent fournis avec l’heure (jointure).

Formellement, un résumé des valeurs d’attribut similaires est compris par normalisation temporelle, chaque fois qu’elle est possible en fonction des types de données utilisés pour le horodatage. ^[5] Lorsque vous utilisez des intervalles de temps pour l’empilement horaire, les intervalles consécutifs doivent être résumés avec les mêmes valeurs d’attribut, lors de l’utilisation d’éléments temporels, toutes les périodes sont résumées, à laquelle une valeur d’attribut spéciale se produit.

Dans l’exemple suivant, le prix et le stock de roulement cible sont versés ensemble pour les données de l’article. Si le prix et le stock de roulement cible sont évalués seuls sans normalisation, quatre intervalles individuels seraient obtenus. En raison de la normalisation temporelle, deux intervalles individuels peuvent être résumés pour a.

Illustration dans les systèmes de base de données relationnels conventionnels [ Modifier | Modifier le texte source ]]

L’image des données temporelles dans les bases de données relationnelles conventionnelles est possible, mais il n’y a pas de procédure standardisée pour la mise en œuvre, car cela dépend beaucoup des exigences respectives. L’augmentation de la complexité et les inconvénients de la représentation des données temporelles par rapport à une image instantanée “conventionnelle” sont significatives, de sorte qu’il existe également diverses illustrations simplifiées, dont chacune est possible.
Les inconvénients suivants sont associés au soutien des données temporelles:

• Le volume de données augmente considérablement. Une fonction de nettoyage peut être nécessaire que des données anciennes archivées ou supprimées.
• L’accès à la valeur actuelle devient beaucoup plus complexe (effort de mise en œuvre, performance), cela est particulièrement important, car dans de nombreux cas, c’est de loin la forme d’accès la plus courante.
• Les conditions d’intégrité dérivées dérivées du modèle ER (sans vue temporelle) ne peuvent plus être montrées sans plus de NO en utilisant les clés primaires et l’utilisation d’une intégrité référentielle.

Il n’est donc pas opportun de soutenir une illustration temporelle pour les données pour lesquelles cela n’est pas absolument nécessaire en raison des exigences. Cela signifie également que lorsqu’il s’agit de l’introduction fondamentale de la dépendance temporelle, toutes les relations ne doivent pas être converties en principe.

Dans ce qui suit, divers aspects conceptuels sont présentés en cas de données temporelles d’image à part entière. Enfin, la discussion de diverses illustrations simplifiées est également réalisée.

Horaire [ Modifier | Modifier le texte source ]]

En règle générale, des intervalles de temps sont utilisés pour la chronologie. Puisqu’il n’y a pas d’intervalle de temps (fixe) en tant qu’attribut explicite dans les bases de données relationnelles, il y a deux hommages à temps (par exemple du type DATE ou Horodatage ) Dans le cas bitemporal, dans chaque cas, dans la définition du tableau qui définissent le début et la fin de l’intervalle de temps.
Il existe deux approches de base: ^[6]

1. Représentation d’intervalle : Supplément de deux fois par ligne de données (démarrage, fin)
2. Représentation des points : Compléter une seule fois qui définit le début de la ligne, la fin est implicitement définie par le début de la ligne suivante

Les deux approches présentent leurs avantages et leurs inconvénients:

1. Inconvénients du Représentation d’intervalle :
   • Les lignes qui se chevauchent peuvent être insérées sans violer l’intégrité de la base de données. Une validation séparée est requise (par exemple, à l’aide du déclencheur de la base de données).
   • Une valeur particulière est nécessaire pour identifier une validité indéfinie. Pour cela, zéro ou la date minimale ou maximale possible peut être utilisée (voir ci-dessous).
   • En cas de changement de valeur, l’adaptation (planification) de la ligne précédemment valide peut être requise en plus d’insérer une nouvelle ligne.
2. Inconvénients du Représentation des points :
   • La détermination des données à un moment spécial (en attendant) est difficile et nécessite une sous-question ( Sous-sélection ).
   • La fin de la validité ou des interruptions de validité ne peut être démontrée que par le fait que tous les attributs de données de la ligne sont vides ( NUL ).
   • Dans le cas bimémporal, le Représentation des points ne sont pas utilisés pour les deux dimensions de temps (voir l’exemple).

Dans le Représentation d’intervalle Si vous êtes également confronté au choix d’utiliser un intervalle fermé ou demi-ouvert sur le côté droit, c’est-à-dire H. La fin elle-même ne fait plus partie de l’intervalle. Beaucoup parle pour cette dernière variante, sinon un chronone devrait être ajouté à la fin lors de la détermination de l’incapacité des intervalles, qui, par exemple, dans le type de données Horodatage La base de données quelle que soit la base de données n’est pas du tout possible.

L’exemple suivant représente les requêtes SQL pour les deux variantes en cas de horodatage de validité. Art Non ) déterminé. Le début de la validité est chacun par la colonne Gueligab exprimé pour le Représentation d’intervalle Si la fin de la validité Jeune Tigab défini (c’est un intervalle à moitié ouvert sur le côté droit). De plus, en cas de validité indéfinie, il est supposé que la date maximale possible est saisie.

 SÉLECTIONNER  Art Non ,  Prix   DEPUIS  Article  COMME  un   OÙ  un . Gueligab  <= =  DATE ACTUELLE      AND a.UngueltigAb > CURRENT_DATE

 SÉLECTIONNER  Art Non ,  Prix   DEPUIS  Article  COMME  un   OÙ  un . Gueligab  =  ( SÉLECTIONNER  Max ( Gueligab )                           FROM Artikel
                        WHERE ArtNr = a.ArtNr
                          AND GueltigAb <= CURRENT_DATE
                      )

Une telle requête dans le cas bimporal est encore plus complexe. Dans cet exemple également, des intervalles de demi-ouverture sont utilisés sur le côté droit, l’intervalle de la période de transaction est utilisé par Enregistré sur le et Doucement Sont définis. Dans le Représentation des points Il convient de noter qu’il n’est pas possible de compléter le début de l’intervalle en tant qu’attribut pour la période de transaction, ici au moins pendant la période de transaction, un intervalle doit être utilisé afin qu’une interprétation raisonnable soit possible. Différent de l’exemple ci-dessus, la valeur de la date actuelle (exprimée par DATE ACTUELLE ), mais être déterminé à des moments spécifiés, exprimés par les paramètres : Préliminaire et : Niveau de pré-Data .

 SÉLECTIONNER  Art Non ,  Prix   DEPUIS  Article  COMME  un   OÙ  un . Gueligab  <= =  : Préliminalité      AND a.UngueltigAb > :VorgGueltigkeit
    AND a.ErfasstAm <= :VorgDatenstand
    AND a.GeloschtAm > :VorgDatenstand

 SÉLECTIONNER  Art Non ,  Prix   DEPUIS  Article  COMME  un   OÙ  un . Gueligab  =  ( SÉLECTIONNER  Max ( Gueligab )                           FROM Artikel
                        WHERE ArtNr = a.ArtNr
                          AND GueltigAb <= :VorgGueltigkeit
                          AND ErfasstAm <= :VorgDatenstand
                          AND GeloeschtAm > :VorgDatenstand
                      )
    AND a.ErfasstAm <= :VorgDatenstand
    AND a.GeloeschtAm > :VorgDatenstand

Dans l’exemple ci-dessus, il convient de noter pour la fin de la période de transaction où la date maximale possible est entrée pour la ligne actuellement valide. Souvent, cependant, c’est plutôt dans ce cas NUL utilisé, car la requête est alors valide (non formée) est plus facile ( Geloeschtam est nul ). Dans ce cas, cependant, la requête pour les données passées, comme dans l’exemple ci-dessus, devient plus compliqué. La colonne doit être là dans chaque cas Doucement Peut être remplacé par la construction suivante:

 CAS  QUAND  Doucement  EST  NUL  ALORS  '9999-12-31'  AUTRE  Doucement  FIN  

«9999-12-31» est la date maximale possible, mais cette valeur dépend du système de base de données utilisé.

Déterminez la clé primaire [ Modifier | Modifier le texte source ]]

Dans les relations temporelles qui expriment les évolutions des états d’objets, il n’est pas possible d’identifier les tubes (lignes de données) sans impliquer la dimension temporelle. ^[7]

Lorsque vous utilisez le Représentation des points Pour le calendrier, la clé primaire “normale” est uniquement d’étendre l’attribut, qui est défini par le début de la validité. Pour l’exemple de l’article, en plus du numéro d’article, le début de la validité devrait également être inclus dans la clé primaire.

Lorsque vous utilisez le Représentation d’intervalle Il existe plusieurs alternatives. Le début ou la fin de l’intervalle peut être inclus dans la clé. Dans cette décision, il joue également un rôle dans la valeur d’un député pour une validité indéfinie: ^[8]

• La clé principale d’une relation est définie d’une part pour garantir que l’unicité, d’autre part, la définition de la clé primaire est également une question d’optimisation, car lorsque l’accès aux données de ces clés est utilisé comme index pour rechercher les lignes appropriées.
• La ligne actuellement valide est souvent requise en ce qui concerne le calendrier des transactions. Il s’agit de la ligne dans laquelle l’extrémité de validité est illimitée. Cela parlerait dans la clé primaire pour la fin de la validité.
• Dans les systèmes de base de données relationnels conventionnels NUL Pas possible comme colonne de clé primaire, c’est pourquoi la fin de la validité ne peut pas être incluse dans la clé si vous choisissez cette variante d’imagerie pour une fin illimitée de valide. Alternativement, l’utilisation de la valeur de temps maximale possible pour déterminer une validité indéfinie serait alors offerte.

Il convient également de noter que lors de l’utilisation du Représentation d’intervalle Aucune des variantes ne garantit que les lignes ne sont pas liées au chevauchement, qui doivent être vérifiées séparément.

Pour des raisons de performance, un attribut supplémentaire est parfois introduit dans les relations temporelles au lieu de la clé composée en tant que clé de substitution (clé artificielle) afin d’obtenir l’identification la plus courte possible d’une ligne de données. Dans de nombreux systèmes de base de données, ces clés de substitution ont la possibilité d’une allocation automatique d’identifications claires.

Tests d’intégrité [ Modifier | Modifier le texte source ]]

Comme déjà mentionné, les conditions d’intégrité, qui sont normalement couvertes par l’unicité de la clé primaire ou de l’intégrité référentielle, doivent être sécurisées autrement pour les données temporelles. Les variantes suivantes sont disponibles pour ceci:

Surtout lorsque vous utilisez des contraintes et des déclencheurs de la base de données, le problème peut se poser que l’intégrité peut être temporairement violée lors d’une mise à jour composée de plusieurs opérations de base de données et n’est pas respectée à nouveau que pour un cas de mise à jour après que toutes les opérations de base de données soient effectuées. Pour cela, le système de base de données doit offrir la possibilité de effectuer uniquement les tests d’intégrité à la fin d’une transaction. ^[9]

Lorsque vous utilisez le Représentation d’intervalle est, comme déjà mentionné, le test de liberté de chevauchement des lignes pour un objet est nécessaire. Vous trouverez ci-dessous une requête SQL exemplaire, les entrées qui se chevauchent pour les lignes (identifiées par Art Non ) à partir d’une table avec nom Article délivre, par lequel l’intervalle de la période de validité à travers Gueligab et Jeune Tigab est exprimé.

 SÉLECTIONNER  *  DEPUIS  Article  COMME  X ,  Article  COMME  et   OÙ  X . Art Non  =  et . Art Non   ET  X . Jeune Tigab  >  et . Gueligab   ET  et . Jeune Tigab  >  X . Gueligab   ET  '' Condition ( dans )  pour le  exclusion  le même  Doubler  dans  X  et  et ''  

Cette dernière condition est nécessaire pour qu’une ligne ne soit pas diagnostiquée comme se chevauchant avec elle-même. La façon dont la condition doit être formulée dépend de la clé primaire choisie, certains systèmes de base de données prennent en charge des fonctions spéciales ou des types de données pour identifier une ligne de table.

S’il est assuré par la clé principale qu’il ne peut y avoir qu’une seule entrée au début d’une validité, un test simplifié est également possible de la manière suivante:

 SÉLECTIONNER  *  DEPUIS  Article  COMME  X ,  Article  COMME  et   OÙ  X . Art Non  =  et . Art Non   ET  X . Jeune Tigab  >  et . Gueligab   ET  et . Gueligab  >  X . Gueligab  

Cette approche présente également l’avantage que les deux lignes d’un couple qui se chevauchent ne sont livrées qu’en ligne de résultats.

Exemple: entrée de catalogue ( Dépendant ) Fait référence aux articles ( Parent )

Le test de l’intégrité référentielle au sens temporel est encore plus complexe si la table de référence (le Dépendant -Able) ainsi que le tableau référencé (le Parent -Tabelle) a un calendrier. Pour chaque ligne de la Dépendant -Les tables sont vérifiées, si

1. un associé devant lui ou en même temps Parent -Ginde existe qui sont avec la période de Dépendant -Ifele chevauche,
2. une fin associée ou en même temps Parent -Ginde existe qui sont avec la période de Dépendant -Les chevauchent et se chevauchent et
3. Pour toutes les lignes du Parent -Table dont la fin de la période de la Dépendant -Gife ment (pas avec lui!), Un successeur direct existe toujours (pas de lacunes là où il dérange).

Il n’y a aucune violation de l’intégrité que si les trois conditions sont données. ^[dix]

Dans l’exemple indiqué, deux références d’entrées de catalogue ( Dépendant ) l’article ( Parent ). Il y a une entrée de catalogue pour la période du 1er mars 2006 au 31 août 2006 ainsi qu’une autre entrée de catalogue qui s’applique à partir du 1er septembre 2006 et est actuellement une entrée de catalogue actuelle. Pour toute la période requise par les entrées du calendrier, il faut s’assurer que l’article référencé existe, selon lequel les changements de prix de l’article ont lieu au cours de ces périodes (le prix ne semble pas être montré dans le catalogue). Les deux entrées de catalogue se réfèrent donc à deux lignes différentes de l’article. Dans cet exemple, il convient de noter que l’article du tableau définit à la fois le prix et l’existence de l’article, c’est-à-dire C’est-à-dire que l’article est dans la gamme au moment approprié.

Illustrations simplifiées [ Modifier | Modifier le texte source ]]

Comme alternative à une horodatage de transaction, dans le cas où seuls des cas plus rares, les données plus anciennes doivent être utilisées, peuvent être assurées par les mises à jour de la base de données de la journalisation (journalisation). Cependant, l’utilisation de fonctions centrales pour les mises à jour de la base de données est nécessaire pour la mise en œuvre d’un tel processus de protocole. De plus, des fonctions doivent être fournies que la reconstruction de l’ancienne base de données est en évaluant le protocole.

Dans le cas de l’emplacement horaire de validité, il est logique dans le cas des changements de données cycliques, au lieu d’utiliser les intervalles généralement utilisés pour l’empilement horaire, l’identification de la période de validité (par exemple, dans le cas d’un cycle de changement annuel, l’année seule peut être utilisée comme composant de clé primaire supplémentaire). Cette procédure présente également l’avantage que les concepts de partitionnement fournis par certains systèmes de base de données peuvent être utilisés pour augmenter l’efficacité.

Si la temporalité est uniquement nécessaire pour documenter les niveaux de données qu’une certaine fonction d’évaluation a été effectuée, l’événement d’exécution lui-même peut également être utilisé comme chronologie. Il convient toutefois de noter que cette approche devient discutable dès qu’il existe deux fonctions d’évaluation différentes de ces fonctions d’évaluation qui incluent des types de données similaires.

Une autre approche pour simplifier l’accès aux données actuelles consiste à externaliser l’historique dans des tables distinctes. Ceci est particulièrement intéressant en ce qui concerne les performances lors de l’accès aux données actuelles. Cette procédure est possible à la fois pour la transaction et le temps de validité, mais pour ce dernier uniquement si aucune donnée valide à l’avenir ne peut être enregistrée. De plus, le prix est relativement élevé car toutes les relations doivent être dupliquées.

Une posture de données temporelle conduit inévitablement à une croissance constante du volume de données, car les données obsolètes ne sont délibérément pas supprimées de la base de données. À cet égard, lors de l’introduction de la posture de données temporelle, il est nécessaire de faire des réflexions sur une procédure d’archivage de la base de données afin d’ajuster la base de données opérationnelle.

Options possibles [ Modifier | Modifier le texte source ]]

Contrairement aux données non temporelles, l’archivage avec l’élevage de données temporelles n’est pas nécessaire pour pouvoir reconstruire des conditions supprimées ou modifiées d’un objet, car cela est de toute façon possible en utilisant un horodatage de transaction.

Pour cette raison, selon la situation, la variante la plus simple est le nettoyage ( Passe l’aspirateur ) La base de données temporelle suffisante, c’est-à-dire H. Suppression des données plus anciennes. Cependant, il est également nécessaire ici que le processus de nettoyage maintient la cohérence de la base de données, qui est également un aspect principal même avec un archivage de base de données orienté vers l’application “correct.

Il existe différentes procédures pour l’archivage de la base de données orientée vers l’application. Une caractéristique de classification principale de ces variantes est la distinction entre une archive indépendante et une archive d’intégration. Une archive indépendante elle-même représente une base de données cohérente et peut être accessible directement si nécessaire. Une archive d’intégration, en revanche, ne sert qu’à lire les données à la base de données opérationnelle si nécessaire ( Recouvrement ou Se remémorer ).

Critères de coupe [ Modifier | Modifier le texte source ]]

Il est nécessaire de déterminer les critères clairs et compréhensibles qui définissent lorsqu’un élément de données est supprimé de la base de données opérationnelle. Dans le cas des bases de données bitemporales, la période de transaction est initialement disponible, i. H. Par exemple, tous les enregistrements de données dans lesquels la fin de la transaction est plus ancienne qu’une date de clé définie sont supprimés de la base de données et, si nécessaire, archivés.

Surtout, l’utilisation de la période de transaction a l’avantage que celle-ci est attribuée par le système et ne peut pas être influencée par l’utilisateur, il n’est donc pas possible que les données nouvellement enregistrées se réfèrent à une période qui a été externalisée aux archives.

L’utilisation du temps de transaction n’est pas possible si seul le temps de validité est géré. De plus, même dans le cas bitemporal, il est certainement souvent nécessaire en plus de la période de transaction, la période de validité comme critère.

Assurer la cohérence [ Modifier | Modifier le texte source ]]

Le processus d’ajustement et d’archivage ne doit pas mettre en danger la cohérence de la base de données opérationnelle. En cas d’archive indépendante, cela s’applique également à la base de données utilisée pour l’archivage.

Exemple: nettoyage de la base de données à la date du 1er juillet 2006

En ce qui concerne les données temporelles, cela signifie ce qui suit:

• Les intervalles pour la validité ou le temps de transaction d’un objet ne doivent pas se chevaucher.
• Pour les relations entre les objets, l’intégrité référentielle doit également être préservée au sens temporel (voir également les tests d’intégrité)
• Les données doivent être normalisées temporellement, c’est-à-dire H. Il peut devoir être un Fusionné être effectué.

Lors de la suppression des données de la base de données opérationnelle, il peut être nécessaire de réduire les intervalles pour assurer l’intégrité référentielle. ^[11]

L’exemple suivant devrait clarifier ceci: dans la base de données, toutes les données doivent être externalisées, dont la validité est avant le 1er juillet 2006. Cela signifie que la version de l’élément peut être supprimée de la base de données avec le prix de 1,95 €. Cependant, afin de continuer à assurer l’intégrité référentielle, la version de l’article doit être réduite au prix de 2,25 €. Il en va de même pour l’entrée du catalogue “printemps / été 2006”. Si l’intégrité doit également être conservée dans les archives en cas d’archive indépendante, les homologues coupés des intervalles doivent être insérés dans les archives. Cela indique également que dans la base de données des archives après chaque autre archivage Fusionné C’est nécessaire, car les parties des intervalles sont archivées dans le processus d’archivage suivant.

Le retour est le plus problématique dans ce contexte, surtout si le remboursement n’est que partiellement et non global pendant une période totale, et que les données re-storées sont également laissées dans les archives ( Recouvrement ). Ensuite, certaines mesures pour garantir la cohérence doivent être prises, car lors, par exemple, des chevauchements peuvent également se produire entre les intervalles de temps d’un objet.

Vous trouverez ci-dessous une liste des cas d’application typiques pour le stockage de données temporelles. Cependant, cette liste ne prétend pas être terminée.

Maison de données [ Modifier | Modifier le texte source ]]

Un entrepôt de données est une base de données qui a été principalement créée pour analyser les données et est alimentée par un ou plusieurs autres systèmes (principalement des bases de données opératoires). En règle générale, une importation de données est effectuée périodiquement pour transférer les données des systèmes opérationnels dans l’entrepôt de données.

Dans une telle constellation, il est également nécessaire de compléter l’ajout de dépendance au temps dans l’importation périodiquement effectuée des données. Le début de la validité est le moment de l’importation. Cela a l’avantage que le système opérationnel n’est pas accablé par la complexité requise pour la protection temporelle des données, mais les évaluations dépendant du temps via l’entrepôt de données sont toujours possibles.

Étant donné que l’importation est généralement effectuée avec un cycle constant (par exemple mensuellement), aucun intervalle ne doit être utilisé pour la chronologie, mais la période de validité peut être identifiée au moyen d’un seul attribut (voir également des illustrations simplifiées). De plus, une table de dimension peut être construite pour le temps dans le sens des sternschemas, ce qui permet des évaluations dans le cadre du traitement analytique en ligne (OLAP).

Déclaration de salaire [ Modifier | Modifier le texte source ]]

Un cas typique pour l’exigence de données bimpronaux est une déclaration de salaire. Entre autres choses, l’affiliation d’un employé à un groupe salarial doit être enregistrée correctement (temps de validité). En cas de correction ultérieure (temps de transaction) d’un groupe de salaire attribué ou même de la période d’affectation de ce groupe, il doit rester compréhensible sur quelle base un processus de facturation a fonctionné.

Gestion des risques dans la zone bancaire [ Modifier | Modifier le texte source ]]

En particulier par les réglementations définies par le règlement Basel II, les institutions de crédit et les prestataires de services financiers doivent être en mesure de documenter de manière compréhensible, sur la base des informations (par exemple, l’équité et les notations) quelle décision a été prise.

Cela nécessite un horodatage complet de transaction, parfois aussi une illustration bitemporale. Ce dernier est requis, par exemple, pour les notes d’un emprunteur, car d’une part, elle doit être enregistrée au moment où une telle évaluation a été effectuée par une agence de notation (date d’évaluation). D’un autre côté, il doit également être documenté lorsque cette nouvelle évaluation était connue de l’établissement de crédit et incluse dans la base de données.

• C.J. Date, Hugh Darwen, Nikos A. Lorentzos: Temps et théorie relationnelle. Bases de données temporelles dans le modèle relationnel et SQL . 2e édition. Morgan Kaufmann, Waltham, Massachusetts 2014, ISBN 978-0-12-800675-7.
• Tom Johnston: Données bitemporales. Théorie et pratique . Morgan Kaufmann, Waltham, Massachusetts 2014, ISBN 978-0-12-408055-3.
• Thomas Myrach: Bases de données temporelles dans les systèmes d’information de l’entreprise . Teubner, Wiesbaden 2005, ISBN 3-519-00442-9.
• Richard T. Snodgrass, Christian S. Jensen: Développer des applications de base de données axées sur le temps dans SQL . Morgan Kaufmann, San Francisco 2000, ISBN 1-55860-436-7 ( Arizona.edu [PDF; 5.0 Mb ]).

1. ↑ Myrach 2005, page 23
2. ↑ Table de révision . Disposition de la base de données des bénéfices
3. ↑ ^{un b c d C’est} Consensus Gossar, définition Temps défini par l’utilisateur , Chronon , Élément temporaire , Horodatage , Se fondre
4. ↑ Myrach 2005, page 389–392
5. ↑ Myrach 2005, page 63
6. ↑ James Clifford, Abdullah Uz Tansel: Sur une algèbre pour les bases de données relationnelles historiques. Deux vues . Dans: Shamkant B. Navathe (éd.): Actes de la Conférence internationale ACM Sigmod 1985 sur la gestion des données . ACM Press, 1985, ISBN 0-89791-160-1, S. 247–265 , est ce que je: 10.1145 / 318898.318922 .
7. ↑ Myrach 2005, page 134
8. ↑ Bela Stantic, John Thornton, Abdul Sattar: Une nouvelle approche du modèle maintenant dans les bases de données temporelles. (PDF; 167 kb) 2003, Récupéré le 25 juin 2010 .
9. ↑ Myrach 2005, page 158, 164, 173ff
10. ↑ Snodgrass, Jensen, 1999 (PDF; 5,0 Mo), page 127ff.
11. ↑ Théorie et pratique des bases de données BiteMemporal et de leur archivage, Pfister, 2005 ( Mémento à partir du 28 septembre 2007 Archives Internet ), Page 68fff