Magasin d'événements

Un magasin d'événements est un type de base de données optimisée pour le stockage d'événements.

Conceptuellement, un système de stockage d'événements enregistre uniquement les événements affectant une entité , un dossier ou une politique . L'état de l'entité à n'importe quel moment de son historique peut être reconstitué en rejouant ses événements contributifs dans l'ordre séquentiel. Les événements (et leurs données correspondantes ) sont les seuls faits « réels » qui doivent être stockés dans la base de données. Tous les autres objets peuvent être dérivés de ces événements, c'est-à-dire qu'ils sont instanciés en mémoire par le code d'exécution selon les besoins (par exemple, pour l'affichage dans une interface utilisateur ). En théorie, tout objet agrégeant des données d'événements enregistrées n'est pas stocké dans la base de données. Ces objets sont construits à la volée , en parcourant l'historique des événements. Lorsque l'instance de l'objet agrégé n'est plus nécessaire, elle peut simplement être supprimée (libérée de la mémoire).

Par exemple, le concept de stockage d'événements d'une base de données peut être appliqué aux contrats d'assurance ou aux dossiers de retraite. Dans ces contrats ou dossiers, l'instanciation de chaque objet qui les compose (la personne , les partenaires , les emplois, etc.) peut être dérivée et instanciée en mémoire à partir d'événements réels.

Un élément crucial d'une base de données de stockage d'événements est que chaque événement possède une double chronologie : cela permet aux systèmes de stockage d'événements de corriger les erreurs des événements qui ont été saisis auparavant dans la base de données.

Les deux dates sont :

• La date de validité est la date à laquelle l'événement est devenu valide.
• La date de transaction est la date à laquelle l'événement est enregistré dans la base de données.

Un autre aspect crucial d'une base de données d'événements est l'impossibilité de modifier les événements enregistrés. Une fois enregistrés, même les événements erronés ne peuvent plus être modifiés. La seule façon de les corriger est d'instancier un nouvel événement avec les nouvelles valeurs et d'utiliser la double chronologie. Un événement de correction reprend les nouvelles valeurs de l'événement original, avec les données de cet événement corrigé, mais une date de transaction différente. Ce mécanisme garantit la reproductibilité à chaque instant, même pour la période précédant la correction. Il permet également de reproduire des situations à partir d'événements erronés (si nécessaire).

L'un des avantages du concept de magasin d'événements est qu'il facilite grandement la gestion des effets des événements rétroactifs (événements qui prennent effet avant les événements précédents et qui peuvent même les invalider).

Un système de stockage d'événements simplifiera le code car il ne sera plus nécessaire de revenir en arrière sur les situations erronées et de les intégrer aux nouvelles situations correctes.

L'inconvénient est que le code doit réinstancier tous les objets en mémoire en fonction des événements à chaque fois qu'un appel de service est reçu pour un dossier ou une politique spécifique.

Dans les bases de données classiques, la gestion des événements antérieurs pour corriger les erreurs précédentes peut s'avérer complexe, car elle implique souvent l'annulation de toutes les transactions et objets erronés antérieurs, puis la mise en place des nouvelles transactions et objets corrects. Dans un système de stockage d'événements, seul le nouvel événement (et ses faits associés) est enregistré. Le code recalcule ensuite les transactions et les objets en fonction des nouveaux faits en mémoire.