Historiser en UML

Bonjour,

Je suis en train de faire le diagramme de classe d'un système composé d'un annuaire de clients.

Le système ira chercher divers éléments dans l'annuaire.

Ces éléments évlouant au cours du temps il me faut les historiser.

Soit je crée des factures super lourdes avec une copie des éléments de l'annuaire à l'instant de la création de la facture. Soit j'historise les données de l'annuaire.

Je préfère de loin la première solution. Le problème c'est que je ne vois pas du tout comment faire.

J'ai deux tables, CLIENT et CLIENT_ELEM, la deuxième contenant divers éléments en fonction du client (nom, prénom, adresse à malibu, etc).

J'ai pensé mettre un boolean actif/inactif dans la classe CLIENT_ELEM. Est ce une bonne solution ?

Je peux aussi mettre une date dans CLIENT_ELEM et la facture s'arrange pour récupérer les infos en fonction de la date.

Sinon je fais les deux, et une date et un boolean.

Là ça me ratatine le cerveau j'ai du mal à y voir clair.

J'en viens à me demander s'il ne faut pas lier CLIENT à une classe DATECLI et transformer CLIENT_ELEM en classe association.

Je vous remercie de votre aide.

:)

En fait il y a plusieurs solutions mais celle pour laquelle j'avais opte c'est la creation de table d'archives: CLIENTArchive et CLIENT_ELEMArchive avec les caracteristiques necessaires supplementaires (date d'archivage par exemple) mais inutiles pour l'utilisation des objets non archives.
Juste avant chaque modification sur ta table, tu copies les lignes qui t'interessent en mettant a jour les caracteristiques supplementaires.
Dans un souci de clarte et de facilite de traitement et d'archivage, il est plus judicieux d'utiliser des tables (ou classes, au final c'est la meme chose) a part.
Effectivement la taille de ta base sera consequente mais elles sont fait pour ca :). Et puis, en fonction de ton SGBD, tu as aussi la possibilite d'enregistrer tes donnees sous un autre format, plus pratique a stocker.

Regarde aussi du cote des DP memento et aussi la notion de temporal pattern expliquee par Martin Fowler: http://www.martinfowler.com/eaaDev/timeNarrative.html

Salut,
Je pense qu'il faut garder la classe CLIENT contenant les attributs que vous voulez mette au niveau de la classe CLIENT_ELEM (en supprimant celle ci), et de mettre une classe FACTURE avec comme attributs: num facture...et qui sera liée avec la classe CLIENT, tout en mettant une classe association: DATE.
Pour le booléen, je ne vois pas trop l'utilité.
Voilà, c'est mon avis !

Coucou,

Alors je me suis renseigné auprès d'une amie chercheuse et voilà donc comment j'ai fait (en gros) :

http://img208.imageshack.us/img208/9...nstitregi8.jpg

Donc en fait il n'y a pas de notion de date, on joue juste avec les pointeurs.
Ma facture pointe sur une adresse donnée à un instant donné et mon client pointe sur une adresse donnée à un instant donné, et ce n'est pas forcément la même adresse, sauf au moment de la création de la facture.

Je sais pas si je suis très clair :roll:
Dîtes moi si vous ne pigez pas, j'active l'alerte email sur ce message.

En tous cas merci de vos réponses :)

Citation:

---

Envoyé par wahou85

Donc en fait il n'y a pas de notion de date, on joue juste avec les pointeurs.
Ma facture pointe sur une adresse donnée à un instant donné et mon client pointe sur une adresse donnée à un instant donné, et ce n'est pas forcément la même adresse, sauf au moment de la création de la facture.

---

Salut,
que voulez vous dire par "pointer" ?
Bon courage!

Par pointer je veux dire déterminer.

Une facture détermine une adresse. Si j'ai la facture j'obtiens l'adresse qui va avec.

De même, si j'ai un cient, j'obtiens l'adresse qui lui est associée.

D'un point de vue bdd je mets une clé étrangère fk_adresse_id dans la table facture.
Et, dans la table client, j'ai une clé étrangère fk_adresse_id.

Comme ça si le client change d'adresse je change la clé étrangère dans la table client mais dans ma table facture, j'ai encore l'id de l'ancienne adresse. Donc je n'ai plus de problème :)

Bonjour,

Concernant la conception d'une base de donnée, il est conseillé d'utiliser un formalisme dédié : Merise par exemple. L'utilisation d'UML n'apporte rien dans votre cas si ce n'est des erreurs (où sont les multiplicités par exemple ?).

Un formalisme dédié a l'avantage d'introduire :
- un vocabulaire dédié : les notions de clé primaire, clé étrangère par exemple sont absents d'UML par défaut.
- Des relations dédiés : la relation "implements" d'UML n'a aucune signification dans les BDD par exemple
- etc...

Une bonne conception commence par l'identification de son "espace technique" (objets ? composants ? base de données ? ...) et le choix des méthodes et outils dédiés. C'est une erreur fréquente et une piqure de rappel s'impose. ;)


Bonne continuation. :D