Discussion :

[PtiBubu]

Bonjour,
Je rencontre un problème souvent rencontré en base de données: l'historisation.

Voici un extrait de la base de données actuelle :


Je souhaite compléter ce shéma pour pouvoir historiser toutes les informations concernant un organisme (descriptif, email, adresse, tel/fax, ..etc)
Pour chaque modification du contenu, on souhaite connaître : l'auteur et la date de la modif., le type d'élément modifié et son contenu.

Merci de votre aide, car là je patauge
Bruno

[KiLVaiDeN]

Je n'ai pas l'impression que ce que tu souhaites s'appelle une "historisation" mais plutot "conserver une trace des actions".

Je suppose que tu utilises un serveur d'application pour que les utilisateurs fassent des actions sur tes tables : pour chacune de ces actions, tu peux renseigner une table "actions", qui contiendra le type de modification, le champ modifié, et l'auteur.

Si tout se passe en SQL, je vois mal comment t'en sortir, mis à part le fait que certains SGBDR possèdent une "journalisation" des évènements, mais je ne sais pas si il est facilement exploitable ( je ne m'en suis jamais servi ).

Bonne chance ! Peut-être que quelqu'un d'autre a un meilleur commentaire à faire que moi.

[PtiBubu]

Merci pour ta réponse; en effet il serait possible de passer par une journalisation des évenements; mais l'intêret de ma question est que je souhaite (ou je veux) conserver une approche totalement objet afin de traiter les infos dans mon appli d'où la nécessité de modéliser ça en UML.
Et pour ça je ne vois pas... :'|

[KiLVaiDeN]

Et bien tu pourrais rajouter dans ton modèle une entité "action" qui serait décrite comme ça :

- type d'action : INSERT, UPDATE, DELETE
- table(s) concernée(s) : LISTE DES TABLES
- colonne(s) concernée(s) : LISTE DES COLONNES
- anciennes valeurs (si UPDATE ou DELETE) : LISTE DES ANCIENNES VALEURS
- nouvelles valeurs (si UPDATE ou INSERT) : LISTE DES NOUVELLES VALEURS
- auteur de l'action : INFORMATIONS DE L'AUTEUR
- date de l'action

Et on pourrait imaginer d'autres choses, c'est un début, est-ce ce que tu souhaites ?

[ego]

Comme KiLVaiDeN. C'est d'ailleurs un pattern proposé dans XDE DataModeler le pattern "Audit Trail Pattern".
A toi de voir si tu fais une seule table pour l'audit ou une table d'audit par table de ton modèle initial.
Si le "qui" a modifié est lié au login de la connexion à ta base, tu pourras même mettre en place des triggers sur tes tables initiales sinon, tu devras tout faire dans ton code.

[Nip]

Je reprends le sujet puisque je bosse avec PtiBubu sur la modélisation de cette appli . Une précision, il s'agit de la modélisation UML et pas de de celle de la BD.

Merci pour vos remarques et j'ai travaillé sur le modèle UML entre temps; je suis tombé sur un pattern intéressant "historic mapping" que l'on peut trouver sur le site de Martin Fowler: Temporal Property. En bref il permet de traiter les propriétés de l'objet qui changent au cours du temps.
En gros pour l'exemple, j'aurais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class Organisme{
//get adresse actuelle
Adresse getadress();
//adresse à une date donnée
Adresse getadress(Date);

void changeAdresse(Adresse newadress,Date changeDate);

Voila le diagramme UML tel qu'il se présente dans sa version (très) simplifiée.

Faut encore que je reflechisse à tout ça mais si vous avez des commentaires, n'hésitez pas.
Je regarde aussi très attentivement vos propositions et ce "Audit Trail Pattern".

Merci.