Bitemporal Database Design Question

Question

Je suis en train de concevoir une base de données qui doit stocker le temps de transaction et l'heure valide, et j'ai du mal à stocker efficacement les données et à normaliser ou non les attributs. Par exemple, j'ai une table client qui a les attributs suivants: ID, nom, ClientType (par exemple corporation), RelationshipType (par exemple client, prospect), RelationshipStatus (par exemple actif, inactif, fermé). ClientType, RelationshipType et RelationshipStatus sont des champs variables dans le temps. La performance est une préoccupation car cette information sera liée à de grands ensembles de données provenant de systèmes existants. Dans le même temps, la structure de la base de données doit être facilement maintenable et modifiable. J'ai l'intention de diviser la piste de vérification et l'historique à un point dans le temps dans des tableaux séparés, mais je suis aux prises avec la meilleure façon de le faire.

Quelques idées que je:

1) Trois tableaux: Client, ClientHist et ClientAudit. Le client contiendra l'état actuel. ClientHist contiendra tous les états précédemment valides, et ClientAudit sera à des fins d'audit. Pour faciliter la discussion, oublions ClientAudit et supposons que l'utilisateur ne commet jamais d'erreur de saisie. En procédant ainsi, j'ai deux façons de mettre à jour les données. Tout d'abord, je pourrais toujours exiger que l'utilisateur fournisse une date d'entrée en vigueur et enregistrer un enregistrement sur ClientHist, ce qui entraînerait l'écriture d'un enregistrement dans ClientHist chaque fois qu'un champ est modifié. En variante, je ne pouvais demander à l'utilisateur de fournir une date d'entrée en vigueur que lorsque l'un des attributs variant dans le temps (c'est-à-dire, ClientType, RelationshipType, RelationshipStatus) change. Cela entraînerait l'écriture d'un enregistrement dans ClientHist uniquement lorsqu'un attribut variable dans le temps est modifié.

2) Je pourrais diviser les attributs variant dans le temps en une ou plusieurs tables. Si je vais cette route, dois-je mettre tous les trois dans une table ou créer deux tables (un pour RelationshipType et RelationshipStatus et un pour ClientType). La création de plusieurs tables pour les attributs variant dans le temps augmente considérablement la complexité de la conception de la base de données. Chaque table aura également des tables d'audit associées.

Des pensées?

Answer 1

Beaucoup dépend (ou je pense) de la fréquence à laquelle les données sensibles au temps seront modifiées. Si les changements sont peu fréquents, alors j'irais avec (1), mais si les changements se produisent beaucoup et pas nécessairement toutes les valeurs sensibles au temps à la fois, alors (2) pourrait être plus efficace - mais je voudrais Pensez-y d'abord très attentivement, car il serait difficile à gérer et à maintenir. J'aime l'idée d'exiger que les utilisateurs entrent des daes efficaces, parce que cela pourrait servir à réduire la quantité de détails que vous enregistrez - par exemple, peu importe les changements qu'ils apportent aujourd'hui, ils ne produisent qu'une ligne historique. en vigueur demain (bien que la table d'audit puisse devenir assez grande). Mais pouvez-vous réellement amener les utilisateurs à entrer des données quelque peu abstraites?

Answer 2

Vous pouvez essayer une seule table Client avec 4 colonnes de date pour gérer les 2 dimensions temporelles. Quelque chose comme (client_id, ..., valid_dt_start, valid_dt_end, audit_dt_start, audit_dt_end). Cette conception est très simple à travailler avec et je voudrais essayer de voir comment échelles avant d'aller avec quelque chose de plus compliqué.