Conception de base de données pour le point dans le temps “instantané” de données?

Comment concevoir une base de données qui prend en charge une fonctionnalité qui permettrait à l'utilisateur de l'application pour créer un instantané de leurs données à un point dans le temps, un peu comme le contrôle de version.

Il serait de donner à l'utilisateur la possibilité de revenir en arrière et voir ce que leurs données ressemblait dans le passé.

Supposons que les données en cours "snapshotted" est complexe et comprend des jointures de tables multiples.

Je suis à la recherche d'un moyen de donner à chaque utilisateur de l'application de la capacité de capture instantanée de leurs données et de revenir à elle. Tout instantanés de base de données n'est pas ce que je cherche.

EDIT: Merci pour vos réponses. La 6NF réponse est convaincante qu'est la suggestion de normaliser les données de l'instantané en raison de sa simplicité.

Précisions: ce n'est pas un entreposage de données question, ni est-il une question à propos de la sauvegarde de la bd et de la restauration; son sujet de la façon de construire un schéma qui nous permet de capturer l'état d'un ensemble spécifique de données à un point dans le temps. Les captures d'écran sont générés par les utilisateurs de l'application quand ils l'entendent. Les utilisateurs ne sont pas instantané de l'ensemble de la DB, juste l'objet de données qui les intéressent.

  • SQL Server 2005 ou 2008. Cependant, si il y a un autre SGBDR qui a un construit en solution à ce type de problème, je serais désireux d'en entendre parler. Thx
  • est-il une extension sur postgresq pour la gestion des versions d'une table?
InformationsquelleAutor saille | 2009-04-06
  1. 10

    Nous l'avons fait une fois par la création de séparer les tables de base de données contenant les données que nous voulions instantané, mais dénormalisée, c'est à dire chaque enregistrement contenait toutes les données nécessaires pour faire sens, pas de références à des id qui peuvent ou peuvent ne plus exister. Il a également ajouté une date à chaque ligne.

    Puis nous avons produit des déclencheurs spécifiques des inserts ou des mises à jour qui fait une jointure sur toutes les tables concernées, et l'a inséré dans l'instantané tables.

    Cette façon, il serait trivial pour écrire quelque chose qui a restauré les données des utilisateurs à un point dans le temps.

    Si vous avez une table:

    utilisateur:

    id, firstname, lastname, department_id

    département:

    id, name, departmenthead_id

    votre capture d'écran de la table utilisateur pourrait ressembler à ceci:

    user_id, user_firstname, user_lastname, department_id, department_name, deparmenthead_id, deparmenthead_firstname, departmenthead_lastname, snapshot_date

    et une requête quelque chose comme

    INSERT INTO usersnapshot
SELECT user.id AS user_id, user.firstname AS user_firstname, user.lastname AS user_lastname,
department.id AS department_id, department.name AS department_name
departmenthead.id AS departmenthead_id, departmenthead.firstname AS departmenthead_firstname, departmenthead.lastname AS departmenthead_lastname,
GETDATE() AS snapshot_date
FROM user
INNER JOIN department ON user.department_id = department.id
INNER JOIN user departmenthead ON department.departmenthead_id = departmenthead.id

    Ainsi, chaque ligne dans l'instantané est vrai pour le moment dans le temps, même si le département ou le chef de service a changé entre-temps.

    • Cela me rappelle de l'exportation d'un fichier CSV à l'exception de la sortie est stockée dans la base de données.
    InformationsquelleAutor Kamiel Wanrooij
  2. 18

    Ce n'est PAS facile.

    Vous êtes à la demande, en substance, pour un temps de Base de données (Ce que Christopher Date d'appels Sixième Forme Normale, ou 6NF).

    Être 6NF, un schéma doit également être 5NF, et, en gros, pour chaque donnée, vous avez besoin de fixer un intervalle de temps pour lequel la référence à cette valeur est applicable. Puis dans les jointures, la jointure doit inclure uniquement les lignes qui sont à l'intérieur de l'intervalle de temps considéré.

    Temporelle de la modélisation est dur, c'est ce que 6e Forme Normale adresses -- et n'est pas bien pris en charge en courant RDBMSes.

    Le problème est le niveau de granularité. 6 à la Forme Normale (ce que je comprends) prend en charge temporelle de la modélisation par tout non-clé (non-clé:, c'est à dire, rien "sur" l'entité qui peut changer sans l'entité de perdre son identité) d'un rapport distinct. Pour cela, vous ajoutez un timestamp ou intervalle de temps ou de numéro de version. Tout en faisant une jointure permet de résoudre le problème de granularité, mais cela signifie également que vos requêtes sont va être plus compliqué et plus lent. Il exige également de trouver toutes les clés et les attributs non-clé; ce qui a tendance à être un grand effort.

    En gros, partout où vous avez une relation ("ted possède le GM certificat d'actions avec l'id 789"), vous ajoutez un moment: "ted possède le GM certificat d'actions avec l'id 789 maintenant", de sorte que vous pouvez à la fois dire, "fred possède le GM certificat d'actions avec l'id 789 du 3 Février 2000 à hier". Bien évidemment, ces relations plusieurs-à-plusieurs, (ted peut posséder plus d'un certificat est désormais, et de plus d'un au cours de sa vie, trop, et fred ont déjà possédé le certificat jack possède maintenant).

    Nous avons donc un tableau des propriétaires, et une table de certificats d'actions, et un plusieurs-à-plusieurs table qui concerne les propriétaires et les certificats par id. À la plusieurs-à-plusieurs table, nous avons ajouter un date_debut et un end_date.

    Maintenant, imaginez que chaque état/province/taxes foncières les dividendes sur les certificats d'actions, donc, aux fins de l'impôt pour enregistrer le certificat de l'action du propriétaire de l'état de résidence.

    Où réside le propriétaire peut évidemment varier de façon indépendante avec d'actionnariat; ted peuvent vivre dans le Nebraska, acheter 10 actions, obtenir un dividende au Nebraska, les taxes, les déplacer vers le Nevada, vend 5 actions à fred, acheter 10 actions.

    Mais pour nous, c'est ted peut se déplacer vers le Nebraska à un certain moment, acheter 10 actions à un certain moment, obtenir un dividende à un certain moment, qui Nebraska, les taxes, les déplacer à Neveda à un certain moment, de vendre 5 actions à fred à un certain moment, acheter 10 actions plus à un certain moment.

    Nous avons besoin de tous que si nous voulons calculer les taxes ted doit, dans le Nebraska et dans le Nevada, qui se joignent à la correspondance de chevauchement des intervalles de dates dans person_stockcertificate et person_address. L'adresse d'une personne n'est plus un-à-un, c'est l'un-à-plusieurs, parce que c'est l'adresse pendant l'intervalle de temps.

    Si ted achète dix actions, ne nous un modèle buy événement avec une seule date d'achat, ou ajouter un date_bought à chaque action? Dépend de la question que nous devons le modèle de réponse.

    • Une solution générique est certainement difficile à accomplir, mais pour un usage suffisant de cas et de sous-ensemble de vos données, une solution comme je l'ai décrit, pourrait être acceptable.
    InformationsquelleAutor tpdi
  3. 2

    Avoir instantanés et/ou d'un audit trail est une base de données commune exigence. Pour de nombreuses applications, la création de l'ombre ou de la vérification des tables est facile et simple tâche. Alors que la base de données des sauvegardes et des journaux de transactions sont bons à avoir, ils ne sont pas un système de contrôle de version.

    Fondamentalement, vous avez besoin de créer une ombre de la table avec toutes les colonnes de la table de base, puis le programme d'installation se déclenche sur la table de base de placer une copie de la ligne dans l'ombre de la table quand il est mis à jour ou supprimé.

    Grâce à un peu de logique, vous pouvez recréer ce que les données ressemblait à un moment donné dans le temps. Pour un moyen facile de le configurer dans Sybase voir: http://www.theeggeadventure.com/wikimedia/index.php/Sybase_Tips#create_.27audit.27_columns

    Si vous avez besoin de faire beaucoup de l'historique des instantanés, alors vous pouvez conserver les données dans la même table. Fondamentalement, créez deux colonnes - un ajout et de suppression de la colonne. L'inconvénient est que pour chaque requête, vous devez ajouter une clause where. Bien sûr, vous pouvez créer une vue, qui n'affiche que les enregistrements actifs. Cela devient un peu plus compliqué si vous avez une base de données normalisée avec plusieurs tables, le tout avec l'histoire.

    Toutefois, il ne fonctionne pas. Vous pouvez tout simplement ajouter " et "supprimer" colonnes sur chaque table, et puis, votre requête est le moment d'intérêt. Lorsque les données sont modifiées, vous devez copier la ligne courante, et le marquer comme étant supprimés.

    InformationsquelleAutor brianegge
  4. 1

    Utilisation Journal Des Déclencheurs

    Toutes les modifications de données sont recueillies, donnant la possibilité d'interroger comme si, à n'importe quel point dans le temps.

    InformationsquelleAutor grokster
  5. 0

    SQL Server 2005 (à partir de) Édition Entreprise a la capacité de créer des Instantanés de base de données

    InformationsquelleAutor Mitch Wheat
  6. 0

    Oracle à partir de la version 9i avoir un retour de flamme de la technologie, qui est dans Oracle 10g et 11g beaucoup améliorée et vous pouvez voir l'état de votre base de données à un moment donné dans l'histoire, à condition de permettre un retour de flamme.

    Vérifier ce document: Flashback Aperçu

    InformationsquelleAutor zendar
  7. 0

    Avec SQL Server au moins, vous pouvez utiliser la journalisation Complète et conserver les journaux de transactions entre chaque jeu de sauvegarde.

    Ensuite, vous pouvez faire un point de sauvegarde.

    C'est une mauvaise solution.

    Qu'est-ce exactement est-ce que votre client veut? Est-ce à des fins d'analyse (c'est à dire les questions comme combien de commandes, nous n'avions d'il y a deux semaines) ? Parce que c'est exactement le problème que d'un datawarehouse en résout.

    InformationsquelleAutor Ryan Barrett
  8. 0

    Vous pouvez utiliser les fichiers journaux générés par votre SGBDR pour obtenir des clichés de vos données. Normalement, les journaux sont utilisés pour fournir de récupération de base de données. Cependant, ils peuvent également être utilisés pour répliquer les données sur plusieurs SGBDR instances ou pour obtenir des instantanés des données.

    Pour obtenir un aperçu de vos données, il suffit de prendre en compte tous les grumes produites avant le moment voulu dans le temps. Vous puis "play-back" de ces journaux pour obtenir l'effectif de la base de données avec vos données restaurée.

    Comment accéder et "play-back" les journaux dépend du béton SGBDR le produit que vous utilisez.

    Une autre possibilité est d'utiliser des bases de données temporelles. Ils ont le temps-aspects construit et de permettre à des "back-in-time". Recherchez "Oracle Flashback de la Technologie", par exemple.
    http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10795/adfns_fl.htm#ADFNS1008

    InformationsquelleAutor paweloque
  9. 0

    Peut-être envisager d'utiliser une solution NoSql comme MongoDB pour regrouper l'ensemble de vos données relationnelles dans un document unique, puis le stocker ce document avec un timestamp ou de numéro de version. Des Solutions comme Kafka Connecter ou Oracle Golden Gate simplifier la tuyauterie de données relationnelles dans le NoSql magasins.

    InformationsquelleAutor mancini0
  10. 0

    Je voudrais utiliser un champ d'horodatage sur chaque table, si il est le maître de la table ou de fait/table de transactions. Et toutes les tables doivent être inséré même lorsque l'objectif est de mettre à jour.

    • Voir Comment Répondre & droit de vote de la flèche de la souris textes. Cela ajoute rien d'utile à 10 ans très voté réponses à un très voté question.
    InformationsquelleAutor Hadi Ismanto