Discussion :

[Atchioum]

Bonjour,

depuis quelques jours je cherche à modéliser l'historique de plusieurs tables/attributs, sans succès.
Je ne trouve pas une conception viable.

Sans plus attendre voici le MCD réalisé actuellement :



A partir de celui ci et selon les règles ci dessous, pourriez vous me donner des pistes pour réaliser une modélisation d'un historique?

Voici mes règles de gestion :
-1 employe peut changer de job, il faut alors historiser l'ancien
-1 employe peut changer de territoire, il faut historiser l'ancien
-1 employe peut changer de call_number, il faut historiser l'ancien
-1 territoire peut voir ses clients (=customers) modifiés, il faudra historiser les anciens

-les jobs, territoires, employes et clients peuvent changer de nom, il n'y aura pas d'historisation.


Autant l'historique entre 2 tables, je saurai faire, autant ici je suis perdu
Avez vous une idée?



*petit ajout, j'ai parcouru le forum et plus précisément ces topics
http://www.developpez.net/forums/sho...d.php?t=334343

http://www.developpez.net/forums/sho...d.php?t=336896

http://www.developpez.net/forums/sho...d.php?t=342162
avant de poster.
Mais les cas restent "simplistes" entre 2 tables et je n'arrive pas à dégager quelque chose pour faire le mien.


*2eme ajout, désolé
Il y a une erreur dans la relation entre l'entite CUSTOMERS et l'association COMPREND, c'est 1,1 et non 0,n.
1 client n'est que sur un seul territoire.

[chewing-gum]

Bonjour,

Concernant toutes les informations à historiser, il y a une technique simple qui consiste à mettre la Date + un champ en tant que clé composée.

Exemple avec un employé qui change de job.

-1 employe peut changer de job, il faut alors historiser l'ancien

Tu devras faire 3 tables :

1. la première contenant les EMPLOYE (tu l'as déjà faite).
2. la seconde contenant les JOB (déjà faite aussi).
3. la troisième contenant tous les JOB que les EMPLOYES ont faits à une DATE précise.

Ce qui donne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
TABLE JOB_EMPLOYE

EMPLOYE_ID   |  JOB_ID   |  DATE
-------------------------------------------------------------------
1               1           2011/01/01
1               2           2011/06/06
1               3           2012/01/01
2               1           2005/02/02
2               2           2007/01/01
.........

Attention : la clé primaire de la table JOB_EMPLOYE est composée de 3 champs : l'EMPLOYE_ID, le JOB_ID, la DATE.
PRIMARY KEY(EMPLOYE_ID, JOB_ID, DATE)

-1 employe peut changer de territoire, il faut historiser l'ancien

C'est le même principe que pour les employés et les jobs.

-1 employe peut changer de call_number, il faut historiser l'ancien

Tu dois créer une table spécifique qui contiendra les "call_number" de chaque employé avec une date comme identifiant pour les call_number.

-1 territoire peut voir ses clients (=customers) modifiés, il faudra historiser les anciens

Tu dois faire une table d'association 0,N --- 0,N et encore une fois, ajouté la date en identifiant.


Je n'ai pas de logiciels pour tracer un MCD sur cet ordinateur mais tu as au moins une réponse textuelle

[Atchioum]

Merci pour ta réponse

Je ne voulais pas y penser mais à te lire, il semble bien qu'il va falloir récréer plus ou moins la même base identique (meme assos, meme relation, meme entité) avec pour seule différence l'ajout de date.

Je n'ai pas de quoi faire un MCD ici, je posterai demain un MCD afin de voir si c'est la bonne approche.

[Atchioum]

Voici mon MCD modifié pour y intégrer l'historique.
Il me parait étrange, faut il bien laisser une table HISTO_EMPLOYE sans association?





(je viens de voir que j'ai omis la date pour l'association HISTO_TERRITORY_CUSTOMER)

[Richard_35]

Bonjour Atchioum et Chewing-gum,

Je me permets de m'immiscer, Chewing-gum, désolé...

Suggestion :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Job -0,n---[Affecter]---0,n- Employe -0,n---[Travailler]---0,n- Territorie -0,n---[Affecter]---1,n- Customer
           Date_Affectation     |            Date_Travail                         Date_Affectation
                                |
                               1,n
                                |
                          [Posséder n°]
                         Date_Attribution
                                |
                               1,n
                                |
                           Call Number

Remarques :

• ton historique est, de fait, dans tes entités/associations ;
• tu peux supprimer les propriétés historisées des entités principales ;
• ces propriétés sont retrouvables dans les entités/associations via la date stockée.

[Atchioum]

Cela pourrait grandement simplifier les choses en effet
Par contre, on perd les associations 1,1 et 1,n dans ce cas?

J'ai peur aussi d'avoir énormément de données dans une seule table. Je pense notamment à celle qui relie CUSTOMERS et TERRITORY, la 1ere ayant des dizaine de milliers de record (voir centaine de millier : plus de 150 000) , la seconde des milliers.
Avec l'historique + l'actuel, cela risque d'être lourd.


Voici mes règles de bases et le nombre de ligne théorique pour chaque table :

-1 job est attribué à 0 ou N employe (à historiser), 1 employe n'a qu'un job
-0 ou 1 seul territoire est affecté à 0 ou 1 employe (à historiser)
-1 call_number est attribué à 1 employé à un instant T
-1 territoire contient 0 ou N customers (à historiser)
-1 client fait parti de 0 ou 1 territoire (à historiser)


JOBS aurait environ une centaine de record
EMPLOYES, 3000/4000
TERRITORIES, 1000/3000
CUSTOMERS, 150 000


Je vais refaire un MCD avec vos idées, je repost ca ensuite.
Merci à vous

[Richard_35]

Par contre, on perd les associations 1,1 et 1,n dans ce cas?

==> c'est normal, puisque c'est la réalité : un employé est affecté à un job, mais pour une période bien particulière. Il est, d'ailleurs, possible qu'il récupère ce même job à une autre période. Maintenant, il me semble entrevoir que tu parles, là, de l'intégrité des données, des tables donc. Ces tables seront les suivantes (examines bien les clés primaires) :

Job(IdJob, ...) ;
Employe(IdEmploye) ;
Job_Employe(#IdJob, #IdEmploye, Date_Affectation, ...).

idem, pour les autres entités. Les dates de début sont les dates de fin + 1 jour du précédent enregistrement.

Avec l'historique + l'actuel, cela risque d'être lourd.

==> la modélisation ne s'occupe pas de la volumétrie. En revanche, une mauvaise modélisation peut entraîner une volumétrie plus importante que nécessaire.

Je complète tes règles de gestion :
-1 job est attribué à 0 ou N employe (à historiser), 1 employe n'a qu'un job à une date ;
-0 ou 1 seul territoire est affecté à 0 ou 1 employe (à historiser) à une date ;
-1 call_number est attribué à 1 employé à un instant T (j'allais le dire...) ;
-1 territoire contient 0 ou N customers (à historiser) ;
-1 client fait parti de 0 ou 1 territoire (à historiser) à une date.

[Atchioum]

Vu comme cela, c'est mieux il est vrai.
J'en parle aux collègues pour avoir leurs avis et je reviens clôturer ou continuer ce thread

[Atchioum]

N'étant pas de grands analystes, nous allons vous faire confiance.
On va donc s'orienter sur cette modélisation :




Merci à vous 2.

Si d'autres personnes ont des remarques pour compléter, je suis aussi preneur


*oups à nouveau une erreur, c'est 1,n pour les relations entre l'employe et le call_number

[Richard_35]

Il faut supprimer l'attribut "call_number" de l'entité "Employe" : il est retrouvé, pour une date donnée, dans l'hstorique.

J'ai noté qu'il peut exister des "call_number" orphelin d'employé.

N'étant pas de grands analystes, nous allons vous faire confiance.

==> nous t'avons, simplement, aidé à modéliser : il te suffit, maintenant, de traduire en français l'ensemble des cardinalités (minimum/maximum) ainsi que l'unicité des entités (1 ligne par xxx) pour contrôler que ce MCD respecte tes règles de gestion.

Sinon, cela m'a l'air tout bon.

[Atchioum]

On valide le mcd :p

On apporte juste une modif, on va mettre une date de début ainsi qu'une date de fin pour notre historisation, car si demain un employe nous quitte, avec 1 seul date on ne sait pas gérer.

Merci encore !