Discussion :

[alassanediakite]

Bon Patrick
Une petite suggestion: le choix de la colonne (champ) de la clé étrangère.
Dans cet exemple...

Dans la table tvaleur, la clé primaire est constituée de idcapteuret instant.

• en gardant idcapteur pour faire la clé primaire, looping ajoute idcapteur_1 pour faire la clé étrangère
• en enlevant idcapteur, je ne peut pas bien choisir la clé

Ce problème est géré par oracle datamodeler...

Merci pour votre immense œuvre.
PS/ je ne peux toujours pas avoir la version numérique du livre. Est-ce possible d'avoir une version pour Adobe Digital Edition.
@+

[Paprick]

Bonsoir,

Il ne faut surtout pas déclarer la clé étrangère "idcapteur" comme une rubrique de "tvaleur" !
En fait, pour qu'une clé étrangère fasse partie de la clé primaire de la table associée, il faut utiliser la notion d'identifiant relatif.
Voici le modèle correspondant avec le MLD qui va avec : on voit bien que la clé primaire de "tvaleur" est composée de "Idcapteur" de "instant" .

Pour le livre (qui explique bien cette notion d'identifiant relatif ), désolé mais la version numérique n'existe qu'au format Kindle.

[alassanediakite]

Salut
Merci pour l'explication

désolé mais la version numérique n'existe qu'au format Kindle.

C'est pas grave je pourrais tenter la version papier si l'occasion se présente. L'achat par le poste n'est pas très évident.
@+

[StringBuilder]

Bonjour,

J'ai un problème similaire : dans une association, je souhaite pouvoir décider du nom de la colonne de clé étrangère qui sera générée.

En effet, actuellement j'ai deux entités :

Affaire (ID)
Dossier (ID)

Je crée une CIF pour qu'une affaire contiennent 0,n dossiers et qu'un dossier soit contenu dans 1,1 affaire

Si je change la vue en "MLD", une clé étrangère est créée dans mon entité Dossier, nommée "ID_1".
C'est franchement pas parlant, je voudrais pouvoir choisir son nom (par exemple "ID_Affaire", ou "ID_Parent" par exemple).
J'ai d'autant plus besoin de nommer explicitement mes relations qu'une affaire par exemple concerne plusieurs clients, et que je fais avoir plusieurs clé étrangères vers la même table de référence, et plusieurs clés étrangères vers des tables de références distinctes... Si toutes les clés étrangères s'appellent ID_1, ID_2, ID_x ça va pas le faire...

Avec des noms de clés plus parlantes (idaffaire, etc.) ça résoudrait partiellement le problème, mais pas complètement : quand j'ai 4 clients sur une affaire dont l'un est donneur d'ordre, le second MOA, etc. je voudrais pas avoir idacteur_1, xxx mais idacteur_do, id_acteur_moa, etc.

Enfin, vu que je fais du reverse engineering, je souhaite être totalement libre du nommage dans le MCD/MLD : prendre une règle du genre "CONCAT("ID", nomentite, nomasso) sertait pas mal, mais pas suffisante dans mon cas.

Avez-vous une solution ?

-- Edit : désolé, vous aviez déjà répondu sur un autre topic : https://www.developpez.net/forums/d2.../#post11727959
Si je peux me permettre, c'est pas très explicite comme méthode : un double clic sur le nom de la colonne FK depuis la vue MLD pourrait ouvrir la définition de la relation 0,n associée, ça serait plus ergonomique (selon moi)

[escartefigue]

@Stringbuilder

Plusieurs solutions possibles

La première consiste à systématiquement utiliser un préfixe ou un suffixe d'entité-type, unique, et que l'on retrouve dans chaque attribut de l'entité type concerné.
Par exemple "AF" pour affaire et "DO" pour dossier
Ce faisant, la FK identifiant l'affaire héritée dans la table issue de l'entité-type [DOSSIER] s'appellera AF_ident
L'avantage est qu'on sait d'emblée d'où vient chaque clef étrangère.
Autre avantage : cette méthode, si utilisée avec rigueur, facilite grandement les analyses d'impact.

La deuxième solution, applicable avec Looping, est d'affecter un rôle à la patte de l'association, ce rôle permettra soit de suffixer la FK soit de la renommer en fonction d'une case à cocher.

Voici un exemple de MCD dans lequel j'ai utilisé les deux solutions :

Pièce jointe 607550

La boite de dialogue permettant d'utiliser le rôle :

Pièce jointe 607551

Et le script correspondant (ici décliné pour SQL server, mais le principe reste le même quelque soit le SGBD) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE AF_affaire(
   AF_ident INT IDENTITY,
   AF_dtdeb DATE NOT NULL,
   AF_resume VARCHAR(256),
   PRIMARY KEY(AF_ident)
);
 
CREATE TABLE DO_dossier(
   AF_ident_xxx INT,
   DO_ident INT IDENTITY,
   DO_date DATE NOT NULL,
   DO_truc VARCHAR(50) NOT NULL,
   PRIMARY KEY(AF_ident_xxx, DO_ident),
   FOREIGN KEY(AF_ident_xxx) REFERENCES AF_affaire(AF_ident)
);

A noter : en cas d'association réflexive de type composant / composé ou parent / enfant, la deuxième solution doit être appliquée (en combinaison ou pas avec la première) car deux FK sont héritées de la même entité-type. Cette deuxième solution correspond également à votre besoin en cas d'associations multiples entre client et affaire

Exemple : un article peut entrer dans la compositions de zéro à plusieurs articles et peut être composé de zéro à plusieurs articles
Ce qui donne le MCD suivant
l'association étant de type "n" de chaque coté, elle deviendra une table, c'est pourquoi je lui ai également affecté un préfixe "CO" (elle pourrait d'ailleurs être porteuse d'attributs tels que le nombre de composants ) :

Pièce jointe 607553

Et le script correspondant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE AR_article(
   AR_ident INT IDENTITY,
   AR_reference CHAR(8) NOT NULL,
   AR_description VARCHAR(50) NOT NULL,
   PRIMARY KEY(AR_ident),
   UNIQUE(AR_reference)
);
 
CREATE TABLE CO_composer(
   AR_ident_composé INT,
   AR_ident_composant INT,
   PRIMARY KEY(AR_ident_composé, AR_ident_composant),
   FOREIGN KEY(AR_ident_composé) REFERENCES AR_article(AR_ident),
   FOREIGN KEY(AR_ident_composant) REFERENCES AR_article(AR_ident)
);

EDIT : dans le premier exemple avec les affaires et les dossiers, j'ai oublié de supprimer le type "identity" qui n'a pas lieu d'être pour la colonne DO_ident.

[sdonnet31]

Bonjour,

J'ai exactement le même besoin.
Je "subis" des règles de nommage sur les entités et leurs propriétés. Et donc, dans le cas où une entité possède de nombreuses relations 0,1/1,1, on se retrouve dans les MLD et SQL, avec des id_1, id_2, ... qui rend le sujet assez illisible. Et derrière, on ne peut pas proprement développer une appli qui attaque du SQL avec des id_1, id_2, ...
Pourrais-je suggérer d'ajouter un champ sur la fiche "Rubrique" de la PK : "nom des FK" ?
Par exemple une table "user" aurait une PK "id", avec un nom de FK : "user_id", nom qui serait repris dans toutes les entités liées à "user" en 0,1/1,1

Ca ne résoudrait tout sauf un seul cas particulier : deux relations déclarées entre les deux mêmes entités.

Ou autre alternative : cette propriété "nom de FK", serait portée la cardinalité. On serait dans une situation de cas par cas, mais ça permettrait de tout gérer.

Sylvain

[Paprick]

Bonsoir,

Pourrais-je suggérer d'ajouter un champ sur la fiche "Rubrique" de la PK : "nom des FK" ?
Par exemple une table "user" aurait une PK "id", avec un nom de FK : "user_id", nom qui serait repris dans toutes les entités liées à "user" en 0,1/1,1

Première bonne nouvelle : ce paramétrage sera possible dans la version 4 de Looping (disponible dans quelques mois) .

Ou autre alternative : cette propriété "nom de FK", serait portée la cardinalité. On serait dans une situation de cas par cas, mais ça permettrait de tout gérer.

Deuxième bonne nouvelle : ça existe déjà ! Il suffit d'affecter un rôle sur la patte 0,N ou 1,N dans la fenêtre cardinalité, et de demander à préfixer ou renommer la clé étrangère (sans forcément l'afficher dans le MCD) .

[sdonnet31]

Deuxième bonne nouvelle : ça existe déjà ! Il suffit d'affecter un rôle sur la patte 0,N ou 1,N dans la fenêtre cardinalité, et de demander à préfixer ou renommer la clé étrangère (sans forcément l'afficher dans le MCD) .

Ah super, je n'avais pas vu. Je vais m'en servir de suite.

Merci !