Discussion :

[CinePhil]

Bonjour,

Dans Looping j'ai un cas typique de CIF :

Règles de gestion :
R1 : Un contrat de sous-traitance concerne un client et un client peut être concerné par plusieurs contrats de sous-traitance.
R2 : Un contrat de sous-traitance peut faire l'objet de plusieurs comptes-rendus et un compte-rendu être l'objet d'un seul contrat de sous-traitance.
R3 : Un client peut valider plusieurs comptes-rendus et un compte-rendu peut être validé par un client.
R4 : Un client ne peut valider un compte-rendu que s'il est l'objet d'un contrat de sous-traitance qui le concerne. <== CIF

Je clique sur CIF, je tire un premier lien vers l'association "Valider" mais ensuite je n'arrive pas à tirer des liens vers les entités-types Client, Contrat_sous_traitance et Compte-rendu.

Dans quel ordre doit-on faire ça et comment ?

[Paprick]

Bonsoir,

Si j'ai bien compris, "Contrat" n'est pas directement relié à l'association "Valider" qui associe "Client" et "Compte-rendu".
Or, une CIF ne concerne que les classes d'entités associées autour d'une même association (dans le cas d'une tri-pattes notamment), ce qui expliquerait pourquoi Looping ne veut pas tirer un lien entre "Valider" et "Contrat"...
Dans ton cas, je pense qu'il s'agit plutôt d'une contrainte inter-associations d'inclusion (outil à gauche de la CIF dans Looping), avec :
- "Faire l'Objet" en association cible (à sélectionner en 1er),
- "Valider" en association émettrice",
- les classes d'entités concernées en pivot.
A noter que Looping ne génèrera rien de spécifique au niveau du MLD et donc du script SQL : pour cela, il faut rajouter une règle de gestion avec le code SQL décrivant le code de la contrainte.

N'hésite pas à envoyer une image du modèle pour regarder ça de plus près.

[fsmrel]

Philippe,


Te voici donc "loopingueur" !


Je suis d’accord avec Paprick, une CIF est en fait une contrainte d’unicité et ne concerne pas ton problème. Quoi qu’il en soit, tu peux te simplifier la vie, il te suffit de modéliser par exemple ainsi :

L’identification relative utilisée pour la cardinalité 1,1 portée par la patte connectant COMPTE_RENDU et CON_COM n’est pas indispensable, mais au stade SQL cela permet d’éviter la jointure des tables COMPTE_RENDU_VALIDÉ et CONTRAT pour connaître l’identifiant du client concerné. A la limite, l’entité-type COMPTE_RENDU_VALIDÉ peut dégager, au profit d’un booléen dans COMPTE_RENDU (un compte-rendu est validé ou pas).

 

[Paprick]

Je plussoie la solution de François ! avec un petit faible pour le booléen dans COMPTE_RENDU.
L'identifiant relatif ne s'impose donc pas, et le schéma relationnel devient à la fois simple et efficace.

[CinePhil]

Vous avez raison tous les deux. Le compte-rendu peut avoir d'autres états que validé par le client donc je supprime l'association. J'en ai créé une autre avec une table de référence des états de compte-rendu.

Merci.