Discussion :

[ced]

Bonjour,

Voici un extrait de modèle conceptuel fait sous Looping 4 :


Et voici le MLD correspondant créé par Looping :


Le problème se situe au niveau de la table de passage COL_PROTOCOLE, où la donnée issue de l'entité fictive VALIDITE est automatiquement nommée VALIDITE_1 par Looping.
Pourtant, je n'ai pas spécifié de suffixe à la clé étrangère dans la patte vers VALIDITE dans le MCD.
Le problème semble venir de la relation VALIDER entre COLONNE et VALIDITE, qui génère bien une clé étrangère VALIDITE dans COLONNE.
Si j'enlève cette relation, alors VALIDITE_1 se renomme en VALIDITE dans la table de passage COL_PROTOCOLE.
Comment faire pour supprimer le suffixe _1 ?

Merci d'avance,

ced

[escartefigue]

Bonjour Ced,

Quand une colonne est présente plusieurs fois dans une même table du MLD, le suffixe _1 est ajouté par défaut à l'une d'entre elles.
C'est le cas par exemple avec les associations réfléxives de type parent enfant.
Je soupçonne donc que l'une des entité-types concourant à l'association (protocoler) qui donne la table "COL_PROTOCOLE" (si j'ai bien compris) est identifiée relativement à l'entité-type [VALIDITE], or, comme cette entité-type [VALIDITE] participe aussi à l'association, on a bien deux fois la même colonne.
Pour avoir un nom plus parlant que ce simple suffixe, il faut cliquer sur le lien d'association concerné pour attribuer un nom particulier

[ced]

Bonjour escartefigue,

Merci pour la réponse.
J'ai effectivement oublié de dire qu'attribution du nom à la clé étrangère sur la patte était, dans le cas présent, sans aucun effet (ni même ajouter un suffixe).

ced

[escartefigue]

Pourtant, avec Looping V4 dans ce cas de figure, j'obtiens bien le nom souhaité :



Après, trouver un cas fonctionnel ou E1 et E2 identifié relativement à E1 participent tous les deux à une asso ternaire, j'ai du mal à l'imaginer...

[Paprick]

Bonjour,

Je viens de reproduire le phénomène et, effectivement, Looping devrait mieux réagir en cas d'entités fictives :

• Même s'il est vrai que VALIDITE se promène un peu dans toutes les clés, il n'est présent qu'une fois dans COL_PROTOCOLE et le suffixe _1 pourrait donc être évité.
• De plus, le suffixe ou le remplacement des clés étrangères n'est pas pris en compte dans le cas d'entité fictives : il est vrai que VALIDITE n'est pas vraiment une clé étrangère, mais Looping pourrait quand même la renommer.

Je vais donc regarder tout ça pour la version 4.1 actuellement en développement.

[escartefigue]

Vu la réponse de Paprick, je n'ai visiblement pas compris le contexte

[ced]

Merci Paprick pour la prise en compte du problème.
C'est vrai que dans mon modèle, VALIDITE se promène partout. Mais ça symbolise toujours la même information conceptuelle : une période de validité (au même titre qu'une entité fictive CALENDRIER amenant une date peut se promener partout dans un modèle).

Pour l'instant, je vais corriger manuelle le script SQL généré.
Une info en avant-première sur l'échéance de sortie de la très attendue v 4.1 ?

[fsmrel]

Hello,

Vous avez dit : bizarre ? Comme c’est bizarre...

J’arrive un peu la bourre, mais j’ai créé un MCD voisin de celui de CED :




Dans le MLD, J’ai bien la colonne VALIDITE et pas VALIDITE_1 :




Bien entendu, si je définissais d’entrée une colonne VALIDITE pour l’association protocoler, alors la colonne VALIDITE de la table COL_PROTOCOLE serait renommée VALIDITE_1, comme l’a écrit très justement escartefigue.

Bref, quelque chose m’échappe dans cette histoire, bizarre... Qu’ai-je raté ?

[Paprick]

Bonjour François,

Tout cela est effectivement bizarre : en effet, en reprenant exactement le même modèle que toi, j'ai bien le problème du VALIDITE_1 !
Par contre, comment se fait-il que la rubrique CONDITONS apparaisse dans le MLD alors qu'elle n'existe pas dans le MCD... Es-tu sûr que ton MLD correspond au MCD ?

Autrement, pour résoudre le problème de CED, il y a une solution simple qui donnera le bon résultat sans modifier le code SQL : il suffit de déclarer une rubrique "normale" VALIDITE dans COLONNE et de supprimer l'association VALIDER. Le problème du VALIDITE_1 disparaitra (ce qui contribue à la bizarrerie !) et le modèle sera tout aussi correct avec un MLD strictement identique ; en effet, l'intérêt d'une classe fictive est de contribuer à la clé primaire de l'association : or, pour cette date, ce n'est pas le cas .

[ced]

Oui, c'est effectivement la solution que j'ai utilisée jusque-là. Un attribut VALIDITE dans COLONNE et la suppression de la relation.

ced

[fsmrel]

Es-tu sûr que ton MLD correspond au MCD ?

Le MCD que j’ai proposé est antérieur au MLD...

Voici le dernier MCD :


Si tu veux, je peux te transmettre mon fichier .loo par mp, tu me dis.

[Paprick]

Si tu veux, je peux te transmettre mon fichier .loo par mp, tu me dis.

Non, c'est ok : en fait, tu as fait ce que je viens de suggérer à CED ; en supprimant l'association VALIDER, ça fonctionne .