Discussion :

[louroulou]

Bonjour à tous,

j'ai un gros soucis dans la conception de mon MCD.

• Voila j'ai besoin de découper mon organisation en petits sous-ensemble que nous pourrions appeler équipes. Il y a une centaine d'équipes. Les équipes sont constitués d'un code logique et d'un nom.
  
• À chaque équipe on associe une section (il y a une dizaine de sections). Il n'y a pas plus de 2 niveaux dans le modèle. A chaque section on a au moins une équipe et pour un équipe on a une et une seule section.
  
• Bon maintenant, les équipes vont évoluer, passer d'une section à une autre, être supprimé, être créé, être dédoublé, ... et cela très régulièrement (au moins une fois par an).
  
• J'ai besoin de savoir chaque année quelle équipe est nouvelle, quelle équipe disparait, quelle équipe à changer de place, ... J'ai également besoin de savoir si deux équipes sont mixé, quel est la nouvelle équipe et vice versa.
  
• J'ai aussi besoin de la liste des équipes en 2009 et faire "mapper" cette liste avec celle de l'année d'avant pour que je puisse voir l'évolution de l'organisation.
  
• Enfin les équipes ont toutes un code (A, B, C, ...) et un certain ordre à respecter en fonction dudit code. Si l'équipe C devient A l'année d'après j'ai besoin de voir :

2009 __________________________2008
A : équipe machin______________A :équipe truc
B : équipe bidule_______________B : équipe bidule
C : équipe chouette____________C : équipe machin
D : équipe truc________________D : équipe chouette

là c'est un cas simple encore, mais quand les équipes sont dédoublés, qu'il y en a de nouvelles ....


Comment puis-je modéliser tous ça, et bien sûr garder l'historique de tous les changement

un grand merci

[fsmrel]

Bonjour,

Le principe général et fondamental est de dissocier le présent du passé.

Considérons le cas du code (A, B, C, ...) indépendamment de la contrainte de l’ordre à respecter (qui a priori se résout par un trigger au niveau logique, mais ne mélangeons pas).

Soit EQUIPE le nom de l’entité-type utilisée pour décrire une équipe. Dotons-la d’un identifiant composé d’un attribut prenant des valeurs non significatives (par exemple un entier auto-incrémenté au niveau logique), qu’elle conserve sa vie durant.

Cette entité-type sera dotée d’un attribut correspondant au code (appelons-le par exemple CODE). Il sera doublé d’un attribut permettant de savoir à quelle date le code a été affecté à l’équipe. Appelons-le CODE_DATE_DEBUT. Dans la mesure où l’on ne connaît pas la date à laquelle ce code sera obsolète, en toute logique on ne prévoit pas d’attribut CODE_DATE_FIN. En revanche, pour ce qui concerne le passé, on met en oeuvre une entité-type EQUIPE_CODE_HISTO permettant de connaître les anciens codes utilisés pour l’équipe dont les attributs sont CODE (sous-entendu ancien), CODE_DATE_DEBUT et CODE_DATE_FIN.

Supposons maintenant que l’équipe puisse changer de section, en totale indépendance des changements de codes. L’entité-type EQUIPE sera dotée d’un attribut SECTION_DATE_DEBUT, représentant la section à laquelle est actuellement rattachée l’équipe. Concernant le passé, là encore on mettra en œuvre une entité-type dédiée, par exemple EQUIPE_SECTION_HISTO, dont les attributs sont SECTION_ID (au niveau tabulaire s'entend), SECTION_DATE_DEBUT et SECTION_DATE_FIN.

Etc.

[louroulou]

Je suis arrivé à mes fins,

merci beaucoup
je ne suis pas sûr d'avoir suivi exactement toutes tes recommandations mais tes pistes m'ont énormément avancé.

L'idée est d'avoir une table A avec un id neutre et un nom
et une autre table B avec un autre id neutre + id de la table A + propriétés diverses + date début + date fin.

Bon tout marche pas mal, j'ai fait des tests c'est robuste.

Maintenant un petit rigolo est arrivé et m'a dit "c'est quoi l'intérêt d'avoir des dates de fin ? (qui par défaut sont égales à 9999/12/31 pour faire simple). ?

bonne question, pourquoi ne pas juste mettre une date de mise à jour.
Je demande alors a mon système donne mois un aperçu de toutes les équipes à tel date.

Je prend paramètre doit être strictement supérieur à date de mis à jour (correspond à la date de début finalement).

Le problème : si je fais ca et que la requête me sors plusieurs enregistrement (il aurait pu y avoir plusieurs changement et donc plusieurs lignes avec des date de mise à jour inférieur au paramètre).

Est il possible dans la risquête de dire
1) classe tout par ordre chronologique
2) ne conserve que les dates < au paramètre entré (qui est une date...)
3) si tu trouves plusieurs lignes tu ne prends que la dernière, c'est elle qui est valide.

Avantage : si j'enlève les date début et fin, c'est beaucoup plus léger pour l'utilisateur qui n'a plus qu'à rentrer la date de mis à jour dès qu'il change qq chose dans les tables. Limite on peut mettre la date d'aujourd'hui comme valeur par défaut.

Sinon l'utilisateur doit :
aller dans le dernier enregistrement changer la date de fin qui par défaut est 9999/12/31 et la changer par la date de la veille.
créer un nouvel enregistrement avec la date d'aujourd'hui comme date de début et 9999/12/31 comme date de fin.

Je préfère avoir une seule date...

Merci à tous