Discussion :

[Tidus159]

Bonjour,

dans le cadre d'un projet je doute sur la meilleure conception à adopter. Je viens ici pour avoir votre point du vu.

Mon problème porte sur la modélisation d'un contrat : il est finalisé après 4 étapes :
RFO (request for offer), lettre d'intention SI OUI, offre éventuelle, SI OFFRE ACCEPTEE Contrat
ce qui reviendrait à faire
RFO 0 1 ---- 11 Intentio 01 ----- 11 Offre 01 ----- Contrat

ou faire une entité complète contrat regroupant des dateRFO, dateIntention, dateOffre, dateContrat et un éventuel état sur l'entité "en cours RFO, refusé RFO, ..., contracté, terminé"

Quel est votre avis ?

Merci par avance.
@+,
Emilien.

[CinePhil]

Demande toi si les informations des différentes étapes sont identiques et invariables.

Je ne comprends pas bien ce qu'est la RFO mais ensuite une offre peut être modifiée et le contrat peut ne pas refléter exactement l'offre. Une offre peut avoir des variantes et des options alors qu'un contrat est en principe figé mais peut faire l'objet d'avenants.

Il faudrait que tu nous en dises plus sur le domaine que tu veux modéliser.
S'agit-il de travaux de bâtiment, de prestations informatiques, de fourniture de matériels, de contrats de maintenance... ?

[Tidus159]

Bonjour,

merci pour ta réponse.
Il s'agit effectivement de prestations informatiques.

Voici les règles de gestion que j'ai pu recenser.

Une RFO est simplement une proposition d'une entreprise à laquelle nous allons répondre GO ou PAS GO.
La lettre d'intention montre cette intention. GO signifie que l'on va proposer une offre. (Ce premier enchaînement montre que ces deux entités pourraient aussi être fusionnées)

Une offre peut être révisée mais son historique n'est pas important (j'ai un attribut nbRevision).

Un contrat peut effectivement être modifié par un avenant. J'ai modélise cela avec une boucle dessus. Contrat 0 1----(commentaire et date avenant)---- 0 1Contrat . Ceci me permet de garder un historique et d'avoir le contrat à jour (celui dont id_contrat_avenant sera NULL). (=> Tous les contrats pointeront sur les mêmes lignes des entités)

Ce que je remarque :
L'avantage de travailler avec 4 entités est de se débarrasser de tests pour avoir l'état de l'offre (ou contrat).
L'inconvénient et la charge de travail qui est plus importante et peut être que contrat est plus "fourre-tout" :


EDIT :
Normalement le contrat sera exactement comme l'offre au début. L'objectif est d'avoir un système rapide pour l'utilisateur : je ne vois pas le chef de projet rentrer petit à petit RFO, Intention, Offre puis enfin Contrat, quand, avec l'existant, il rentre directement un contrat (l'objectif de ma solution est d'obtenir des indicateurs sur différentes étapes comme, par exemple, cette offre). Après je vais peut être trop loin à penser déjà en terme d'ergonomie...

@+,
Emilien.

[CinePhil]

Si je comprends bien, une RFO est plutôt une demande d'offre venant d'un client existant ou potentiel plutôt qu'une proposition. La proposition, c'est plutôt l'offre que vous allez faire à ce client ?

Quelle proportion de RFO entraîne une lettre d'intention ?
Combien de lettres d'intention engendrent une offre ?
Combien d'offres sont couronnées de succès et génèrent une commande ?

En mettant tout dans une seule table, tu risques d'avoir un grand nombre de lignes avec des colonnes à NULL parce que le processus n'aura pas été jusqu'au bout, ce qui nuit aux performances lors des recherches.

Je pense qu'il vaut mieux séparer ces notions dans des entités différentes et les associer :
RFO -0,1----Entraîner----1,1- Lettre_intention -0,1----Engendrer----1,1- Offre -0,1----Générer----1,1- Commande

[Tidus159]

Bonjour,

je ne savais pas pour les performances et le NULL, donc déjà ça fait un critère de choix en plus !
Oui, une RFO est une demande d'offre (j'aurais du le traduire directement, désolé).

Quelle proportion de RFO entraîne une lettre d'intention ?
Un des indicateurs est justement nbLettreIntention / nbRFO. Dans le meilleur des montes, toute RFO entraîne une lettre d'intention mais un oublie, une mauvaise gestion pourrait faire que... (généralement l'entreprise à 3 jours pour répondre à une RFO).

Combien de lettres d'intention engendrent une offre ?
Si nous répondons GO (lettre d'intention), nous ferons une offre.

Combien d'offres sont couronnées de succès et génèrent une commande ?
Si l'offre est validée alors la commande (le contrat) est créé.

Bien qu'on soit d'accord, je trouve que c'est quand même un peu dommage d'avoir autant de tables : je pense que les relations que j'avais liées à T_CONTRAT_CTR vont peut être se multiplier pour se "greffer" à ces autres entités, pour avoir plus d'informations. Ceci sera sémentiquement juste (un contrat est normalement un peu différent d'une offre (par exemple sur la période théorique)) mais je crains que l'application / les utilisateurs n'utilisent pas ces informations et que cela me force à avoir de la copie "inutile".

Penses tu que ces ajouts soit utiles ? Ou que ce genre de rajout puisse se faire en "upgradant" la base de données plus tard ? (faut il mettre le paquet en conception tout de suite ou une mise à jour sera envisageable ?)

EDIT : en choisissant les attributs à mettre dans mes entités RFO INTENTION OFFRE je vois un autre problème : la redondance me guète.
Si je dois rentrer uniquement une RFO sans contrat derrière, je devrais mettre un objet - ou nom - pour que l'utilisateur puisse l'identifier.
Par contre si une lettre d'intention est envoyée ce nom sera sûrement le même (celui du contrat).

Si je ne mets pas de nom sur intention, offre, contrat, pour simplement obtenir le nom du contrat je devrais faire 4 jointures, n'est-ce pas de la contre performance ?

@+,
Emilien.

[CinePhil]

Quelle proportion de RFO entraîne une lettre d'intention ?
Un des indicateurs est justement nbLettreIntention / nbRFO. Dans le meilleur des montes, toute RFO entraîne une lettre d'intention mais un oublie, une mauvaise gestion pourrait faire que... (généralement l'entreprise à 3 jours pour répondre à une RFO).

Pas forcément une mauvaise gestion mais aussi une décision de gestion, si ta boîte a déjà un carnet de commandes surchargé ou trop d'offres à répondre en même temps ou des RFO avec très peu de chances d'aboutir à une commande...

Combien de lettres d'intention engendrent une offre ?
Si nous répondons GO (lettre d'intention), nous ferons une offre.

Donc tu peux fusionner l'offre et la lettre d'intention puisque les cardinalités sont (1,1 - 1,1).
=> Met les attributs de la lettre d'intention dans l'offre.
Peut-être que temporairement des colonnes de l'offre seront à NULL mais une fois l'offre envoyée elles seront toutes renseignées.

Combien d'offres sont couronnées de succès et génèrent une commande ?
Si l'offre est validée alors la commande (le contrat) est créé.

"Si"...
Mon ancien patron d'une boîte d'électricité considérait à l'époque qu'il rentrait 1 franc de commande pour 3 francs chiffrés en devis. Et en tant que chiffreur de devis, j'avais remarqué à peu près la même proportion en nombre de commandes par rapport aux devis, toutes tailles confondues et pour tous types de clients, récurrents ou prospects.

Selon cette proportion, qui ne s'applique peut-être pas à ton cas, en mettant tout dans la même table "T_CONTRAT_CTR", tu aurais environ 2/3 des lignes qui ne seraient en fait pas des contrats !

Bien qu'on soit d'accord, je trouve que c'est quand même un peu dommage d'avoir autant de tables : je pense que les relations que j'avais liées à T_CONTRAT_CTR vont peut être se multiplier pour se "greffer" à ces autres entités, pour avoir plus d'informations. Ceci sera sémentiquement juste (un contrat est normalement un peu différent d'une offre (par exemple sur la période théorique)) mais je crains que l'application / les utilisateurs n'utilisent pas ces informations et que cela me force à avoir de la copie "inutile".

Pas de la copie inutile !
il ne s'agit pas de duppliquer les attributs de la RFO dans l'offre et ceux de l'offre dans le contrat ! L'association entre les tables, par le mécanisme des clés étrangères, te permet de tout retrouver au moment du contrat en ayant saisi une seule fois l'information ! Il suffit même de créer une vue sur l'ensemble des trois tables pour avoir toutes les informations.

Penses tu que ces ajouts soit utiles ? Ou que ce genre de rajout puisse se faire en "upgradant" la base de données plus tard ? (faut il mettre le paquet en conception tout de suite ou une mise à jour sera envisageable ?)

Modifier la structure d'une BDD après coup est une opération lourde de conséquences pour les données et pour les applications qui l'utilisent, surtout si ces dernières s'adressent directement aux tables sans passer par des vues.

En tant qu'ancien qualiticien, j'ai appris qu'une erreur en conception coûte 10 fois plus cher qu'une erreur en réalisation.

EDIT : en choisissant les attributs à mettre dans mes entités RFO INTENTION OFFRE je vois un autre problème : la redondance me guète.
Si je dois rentrer uniquement une RFO sans contrat derrière, je devrais mettre un objet - ou nom - pour que l'utilisateur puisse l'identifier.
Par contre si une lettre d'intention est envoyée ce nom sera sûrement le même (celui du contrat).

Voir ci-dessus à propos de la redondance, à bannir évidemment de la BDD.

Si je ne mets pas de nom sur intention, offre, contrat, pour simplement obtenir le nom du contrat je devrais faire 4 jointures, n'est-ce pas de la contre performance ?

La jointure est l'opération la plus optimisée dans un SGBD parce que c'est justement le boulot principal d'un SGBD que de joindre les tables pour en extraire les informations. Il ne faut pas avoir peu des jointures. Tout bon SGBD sur une machine correctement dimensionnée peut effectuer des requêtes avec jointures multiples sur des tables de plusieurs millions de lignes en largement moins de temps qu'il ne faut pour l'écrire !

[Tidus159]

Bon j'ai fait un EDIT mais apriori tu y as répondu dans ton dernier point.

Je vais réfléchir un peu sur quelles associations mettre sur quelle entité (certainement en interviewant demain le responsable), car tout mettre sur RFO ne serait pas cohérent et tout mettre sur Contrat ne me permettra pas d'avoir les informations nécessaires si la ligne n'est pas créée.

Merci pour tes remarques en tout cas ;-).
Je reviendrai peut être pour confirmer cela.

Je voulais être sur de cette partie car j'ai une autre partie un peu similaire (demande_profil ; envoi_cv ; cv_accepte_et_interview_programmee ; interview_validee ; ...) ou j'avais aussi tout mettre dans une table ...

@+,
Emilien.

EDIT : ok pour ton EDIT ;-)

EDIT 2 : petite question concernant des éventuelles clefs étrangères pour remonter dans l'autre sens.
Avec la présence des 0 1, penses tu que mettre des clefs étrangères, qui seront en moyenne 1/2 (dans le cas de l'entreprise) NULL mais pourrait faciliter la remontée, serait une bonne idée ?

[CinePhil]

EDIT 2 : petite question concernant des éventuelles clefs étrangères pour remonter dans l'autre sens.
Avec la présence des 0 1, penses tu que mettre des clefs étrangères, qui seront en moyenne 1/2 (dans le cas de l'entreprise) NULL mais pourrait faciliter la remontée, serait une bonne idée ?

Je ne comprends pas la question.
Un petit schéma et un exemple de description de tables aiderait sans doute...

Je reprends mon MCD en intégrant la lettre d'intention et l'offre :
RFO -0,1----Entraîner----1,1- Offre -0,1----Générer----1,1- Commande

Avec ce MCD, les tables seraient par exemple les suivantes :
RFO (rfo_id...)
Offre (off_id, off_id_rfo...)
Commande (cmd_id, cmd_id_offre...)

On peut aussi utiliser l'identification relative, comme s'il s'agissait d'un héritage de tables :
RFO -0,1----Entraîner----(1,1)- Offre -0,1----Générer----(1,1)- Commande

Les tables sont alors simplifiées et partagent le même identifiant :
RFO (rfo_id...)
Offre (off_id_rfo...)
Commande (cmd_id_offre...)

cmd_id_offre est une clé étrangère faisant référence à la clé primaire de Offre qui est elle même une clé étrangère faisant référence à la clé primaire de RFO donc cmd_id_offre est en fait un identifiant de RFO.

[Tidus159]

Bonjour,

excellente idée l'identifiant relatif !
Par contre cela ne suffit pas pour demande qui peut avoir un avenant :
Demande (RFO_ID, DMD_ID, ...)
Est ce une bonne idée de mettre à la place d'un ID "auto increment" pour DMD_ID, un DMD_CODE qui sera géré manuellement ?

Au niveau de la convention de nommage, est-il préférable de garde le même nom RFO_ID dans toutes les tables ?

Pour la question c'était peut être stupide mais je proposais (grâce au 0 1) cela :
RFO(RFO_ID, ... , #OFFRE_ID (nullable))
...
Ceci étant ce n'est pas très utile car une requête permettra de trouver l'info rapidement...

@+,
Emilien.

[CinePhil]

excellente idée l'identifiant relatif !
Par contre cela ne suffit pas pour demande qui peut avoir un avenant :
Demande (RFO_ID, DMD_ID, ...)

Demande ?
On en a pas encore parlé je crois ? À quels moment ces demandes interviennent-elles ? Sont-elles rattachées à la RFO, à l'Offre ou à la commande ?

Est ce une bonne idée de mettre à la place d'un ID "auto increment" pour DMD_ID, un DMD_CODE qui sera géré manuellement ?

Si DMD_CODE fait plus de 3 caractères et fait partie de la clé primaire, ce n'est pas une bonne colonne pour constituer cette clé primaire.

D'après ta description de table Demande, une demande serait identifiée relativement à une RFO. DMD_ID ne serait alors pas exactement une colonne de type entier auto-incrémenté mais serait auto-incrémenté relativement à la RFO.
C'est comme le principe des chambres d'hôtel pour une chaîne d'hôtels :
Hotel -1,n----Avoir----(1,1)- Chambre

Hotel (hot_id...)
Chambre (ch_id_hotel, ch_numero...)
1, 1
1, 2
1, 3
...
2, 1
2, 2
2, 3
2, 4
...

Au niveau de la convention de nommage, est-il préférable de garde le même nom RFO_ID dans toutes les tables ?

C'est un débat...
C'est à toi de définir ta convention de nommage si elle ne t'es pas imposée. Je me suis inspirée de celle de SQLPro mais, contrairement à lui, toutes les colonnes de mes tables sont nommées avec l'acronyme de la table. Comme tu peux le voir dans l'exemple que je donne pour les chambres d'hôtel, l'identifiant de l'hôtel dans la table Chambre n'a pas gardé son nom hot_id ; je l'ai nommé ch_id_hôtel qui me semble plus clair ensuite quand on lit les requêtes.

Pour la question c'était peut être stupide mais je proposais (grâce au 0 1) cela :
RFO(RFO_ID, ... , #OFFRE_ID (nullable))

Surtout pas !
Tu introduis une redondance d'information qui peut entraîner des incohérences de données et tu peuples ta BDD de NULL.

[Tidus159]

Dans mon poste, je me suis trompé de terme (grosse bourde) => Demande est en fait Commande (heure de la sieste ?!)

Demande (RFO_ID, DMD_ID, ...)
Commande (RFO_ID, CMD_ID, ...)

Néanmoins ta réponse correspond exactement à ce que je pensais, la question est donc de savoir si cette auto incrémentation relative peut être automatisée (trigger) ?

La deuxième question est de savoir si c'est vraiment utile ?

Quand je voudrais la commande (contrat) non avenant je chercherai MAX(CMD_ID) WHERE RFO_ID = X (ça simplifie la requête car je croyais devoir jouer sur la boucle récursive de avenant, CMD_ID_AVENANT étant NULL pour la dernière commande)
avec l'entité Commande(RFO_ID, CMD_ID, ... CMD_ID_AVENANT#)

Utile donc ?

(un autre avantage de l'identification relative est de pouvoir savoir facilement quelles commandes sont physiquement les mêmes "avenantées" -correspondance avec RFO et OFFRE-)

OK pour la redondance et la multiplication possible de NULL...

@+,
Emilien.

[CinePhil]

Dans mon poste, je me suis trompé de terme (grosse bourde) => Demande est en fait Commande (heure de la sieste ?!)

Demande (RFO_ID, DMD_ID, ...)
Commande (RFO_ID, CMD_ID, ...)

OK.

Néanmoins ta réponse correspond exactement à ce que je pensais, la question est donc de savoir si cette auto incrémentation relative peut être automatisée (trigger) ?

Oui, c'est par exemple avec un trigger qu'on peut faire cette auto-incrémentation relative.
Ou bien, si le SGBD utilisé le permet, directement dans la requête d'insertion :

Code :

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

1
2
3
4
5
6
INSERT INTO commande (RFO_ID, CMD_ID/*...*/)
VALUES (12, (
  SELECT COALESCE(MAX(CMD_ID) + 1, 1)
  FROM commande
  WHERE RFO_ID = 12)/*...*/
)

La deuxième question est de savoir si c'est vraiment utile ?

Quoi ? L'identification relative ?
Voir ces liens donnés par fsmrel.

Quand je voudrais la commande (contrat) non avenant je chercherai MAX(CMD_ID) WHERE RFO_ID = X (ça simplifie la requête car je croyais devoir jouer sur la boucle récursive de avenant, CMD_ID_AVENANT étant NULL pour la dernière commande)
avec l'entité Commande(RFO_ID, CMD_ID, ... CMD_ID_AVENANT#)

Je ne comprends pas l'utilité de CMD_ID_AVENANT qui semble être une clé étrangère. Tu as une table séparée pour les avenants ?

[Tidus159]

Code :

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

1
2
3
4
5
6
INSERT INTO commande (RFO_ID, CMD_ID/*...*/)
VALUES (12, (
  SELECT COALESCE(MAX(CMD_ID) + 1, 1)
  FROM commande
  WHERE RFO_ID = 12)/*...*/
)

J'ai lu un article de SQL Pro qui disait que MAX était à proscrire (concurrence éventuelle d'accès) sur les ID. Cette requête ne rentre-t-elle pas dans ce cas ?
Quand je parlais de l'automatisation, je pensais plutôt à trigger.

La deuxième question est de savoir si c'est vraiment utile ?
Quoi ? L'identification relative ?
Voir ces liens donnés par fsmrel.

Non l'identification c'est top, je parlais de l'auto incrémentation relative (qui n'apporte pas grand chose dans mon cas ? (dans le cas des hotels ça permet d'avoir un numérotation physique logique))

Pour les avenants, j'ai modélisé ainsi :

COMMANDE 0 1 ------(est avenant)-------
0 1 ------(est contrat) -------
(boucle sur l'entité)
Le dernier contrat est une copie pointant sur les données du contrat de base

@+,
Emilien.

[CinePhil]

Code :

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

1
2
3
4
5
6
INSERT INTO commande (RFO_ID, CMD_ID/*...*/)
VALUES (12, (
  SELECT COALESCE(MAX(CMD_ID) + 1, 1)
  FROM commande
  WHERE RFO_ID = 12)/*...*/
)

J'ai lu un article de SQL Pro qui disait que MAX était à proscrire (concurrence éventuelle d'accès) sur les ID. Cette requête ne rentre-t-elle pas dans ce cas ?

Non parce que la sous-requête est exécutée dans la même transaction que le SELECT alors elle bloque la table pour les autres le temps de s'exécuter. Enfin je crois...

Quand je parlais de l'automatisation, je pensais plutôt à trigger.

Je pense que ça ferait la même chose.

Non l'identification c'est top, je parlais de l'auto incrémentation relative (qui n'apporte pas grand chose dans mon cas ? (dans le cas des hotels ça permet d'avoir un numérotation physique logique))

OK.

Pour les avenants, j'ai modélisé ainsi :

COMMANDE 0 1 ------(est avenant)-------
0 1 ------(est contrat) -------
(boucle sur l'entité)
Le dernier contrat est une copie pointant sur les données du contrat de base

1) Le couple de cardinalités (0,1 - 0,1) entraîne en toute rigueur la création d'une table associative, comme pour des cardinalités (0,n - 0,n).

2) Copie de données = redondance de données = interdit en BDD !

3) L'incrémentation relative permet de se passer de cette association.
RFO_ID, CMD_NUM
1, 1 => Contrat de base
1, 2 => 1er avenant
2, 1 => Contrat de base
2, 2 => 1er avenant

Si tu préfères, tu peux commencer l'incrémentation à 0 pour le contrat de base, ainsi tu as directement tes numéros d'avenants.

[Tidus159]

On est OK partout...
Sauf pour l'avenant.

Effectivement PowerAMC me faisait une table associative que j'allais supprimer.
Pourquoi ? car un avenant n'est avenant que d'un contrat.
J'ai un arbre à une branche en fait :
CONTRAT
1ER AVENANT (avenant de CONTRAT)
2EME AVENANT (avenant de 1ER AVENANT)

Je n'ai trouvé que cette solution...

Le problème de la redondance d'info. à cause de l'avenant : je ne sais pas quelles données vont être modifiées. Peut être le seront toutes ? Peut être aucune (juste un nombre dans une association (nb_heure_profil) ?).

La seule solution que je vois c'est de laisser tous les champs de COMMANDE être NULLABLE et que lors d'un avenant je n'insère que ceux qui sont modifiés... pas une solution jouable je trouve.

As tu une proposition ?

[CinePhil]

J'ai l'impression que tu n'as pas compris ce que j'ai expliqué dans mon précédent message...
Pas besoin de table Avenant !

Soit la table Commande que tu as commencé à définir et que j'ai reprise :
Commande (RFO_ID, CMD_NUM...)

Je remplis la table en commençant les CMD_NUM relatifs à chaque RFO_ID à 0, contrairement à mon précédent message où j'avais commencé à 1 par habitude :
1, 0 => Contrat de base
1, 1 => 1er avenant
2, 0 => Contrat de base
2, 1 => 1er avenant

Pour être encore plus concret, j'ajoute une colonnes et des données :
Commande (RFO_ID, CMD_NUM, CMD_LIBELLE...)
1, 0, 'Infogérance des serveurs' => Contrat de base
1, 1, 'Ajout d'un serveur Postgresql' => 1er avenant
2, 0, 'Réalisation d'un site web' => Contrat de base
2, 1, 'Ajout wiki' => 1er avenant

Effectivement PowerAMC me faisait une table associative que j'allais supprimer.

Et c'est Power AMC qui a raison mais dans le cas présent tu n'as pas besoin de l'association : Contrats et avenants sont dans la même table Commande et sont naturellement liés par RFO_ID.

Le problème de la redondance d'info. à cause de l'avenant : je ne sais pas quelles données vont être modifiées. Peut être le seront toutes ? Peut être aucune (juste un nombre dans une association (nb_heure_profil) ?).

Pour moi, un avenant n'est pas une modification des informations du contrat initial. C'est un ajout un retrait ou une modification de prestations mais on ne touche pas aux données initiales. Comme dans mon exemple, les libellés sont différents. Et si tu as des dates, et bien celle de l'avenant est différente de celle du contrat. Il est d'ailleurs possible qu'un avenant soit une moins-value par rapport au contrat initial si on retire une prestation ou si on change une prestation par une autre moins chère (et au passage on ne répercute pas la totalité de l'économie réalisée au client, ce qui augmente la marge pour le prestataire ! ).

Un avenant est une sous-commande qui a sa vie propre.

Pour prendre un cas que je connais mieux, l'installation électrique, on peut avoir un contrat de base pour une installation qui va durer 6 mois et en cours de chantier avoir un avenant pour ajouter des prises. Dès que ces prises sont installées, on facture l'avenant indépendamment du gros contrat.

La seule solution que je vois c'est de laisser tous les champs de COMMANDE être NULLABLE et que lors d'un avenant je n'insère que ceux qui sont modifiés... pas une solution jouable je trouve.

Non, sinon tu vas voir arriver fsmrel avec sa sulfateuse pour éliminer tous ces envahisseurs NULL !

[Tidus159]

Bonjour,

merci pour tes réponses.
Cette histoire d'avenant est... embêtante !
Effectivement dans ton sens un avenant est un contrat.
Pour moi un avenant c'était toute modification possible/ajout du/au contrat initial. L'objectif étant d'avoir un "historique" du contrat et biensûr avoir le contrat final réel.

Le problème est que contrat est le coeur de mon problème et donc au coeur de mon MCD.


Si l'avenant est simplement une modification du budget initial, si je crée une nouvelle ligne dans ma table, j'aurais du NULL partout.
C'est pour cela que j'avais mis une boucle (que j'ai laissé pour l'instant) mais comme tu l'as dit, ça fait beaucoup de redondance et de code pour pas grand chose.
L'idée serait de faire
CONTRAT 0n ----a avenant--------- 1 1 AVENANT
mais la encore avenant sera associé à toutes les entités du contrat de base.

Qu'en penses tu ?

@+,
Emilien.

[CinePhil]

Pour moi un avenant c'était toute modification possible/ajout du/au contrat initial. L'objectif étant d'avoir un "historique" du contrat et biensûr avoir le contrat final réel.

Ne devrais-tu pas alors simplement modifier les données du contrat sans ajouter de ligne et stocker dans une table d'historique ayant la même structure que la table T_CONTRAT_CTR les anciennes valeurs ?
Avec un trigger sur mise à jour, c'est automatisable.


À part ça ton MCD fait un peu peur à l'ouverture ! Quel fouillis !

Après un rapide coup d'oeil, j'y vois des choses bizarres ! Exemple...

T_REUNION_REU -0,1(ou 1,1 ?)----cloturee_par----0,n- T_PERSONNE_PRS

Si la cardinalité de gauche est 1,1, les attributs portés par l'association sont à transférer dans T_REUNION_REU.
Tu vois, ton MCD n'est vraiment pas clair !

[Tidus159]

Oui, j'aime bien l'idée de l'historisation du contrat.

Donc je dois créer T_CONTRAT_HISTORIQUE_CTH et je dois dédoubler toutes les associations sur T_CONTRAT_CTR et les appeler HIS ? En effet, si c'est une données d'association qui est modifiée (comme par exemple CTR_PRO_NB_H_CONTRACTEES) ?

T_CONTRAT_CTR 0 N--------- a historique ---------------- 1 1 T_CONTRAT_HISTORIQUE_CTR
et j'aurais par exemple
T_CONTRAT_HISTORIQUE_CTR 0 n ------------- TJ_CONTRAT_H_PAR_PROFIL_HISTORIQUE ---------- 0n T_PROFIL_PRO
?

Je vais regarder sur le forum comment faire un historique dans ce style

Concernant le MCD, j'ai volontairement laissé dans les associations (0 1) les données, mais je me suis appliqué à les nommer correctement (pour la génération auto' du MPD). (Pour ton exemple, en fait c'est bien du 0 1 mais les cardinalités se sont mal affichées avec l'association effectue_pour sur PowerAMC).

[CinePhil]

Oui, j'aime bien l'idée de l'historisation du contrat.

Donc je dois créer T_CONTRAT_HISTORIQUE_CTH et je dois dédoubler toutes les associations sur T_CONTRAT_CTR et les appeler HIS ? En effet, si c'est une données d'association qui est modifiée (comme par exemple CTR_PRO_NB_H_CONTRACTEES) ?

T_CONTRAT_CTR 0 N--------- a historique ---------------- 1 1 T_CONTRAT_HISTORIQUE_CTR
et j'aurais par exemple
T_CONTRAT_HISTORIQUE_CTR 0 n ------------- TJ_CONTRAT_H_PAR_PROFIL_HISTORIQUE ---------- 0n T_PROFIL_PRO
?

Je pensais à historiser seulement la table des contrats sinon ça va devenir usine à gaz !

Concernant le MCD, j'ai volontairement laissé dans les associations (0 1) les données, mais je me suis appliqué à les nommer correctement (pour la génération auto' du MPD). (Pour ton exemple, en fait c'est bien du 0 1 mais les cardinalités se sont mal affichées avec l'association effectue_pour sur PowerAMC).

Essaie quand même de réorganiser ton MCD parce que là tu vois qu'il est limite illisible !