IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Looping Discussion :

choisir la colonne (champ) de la clé étrangère


Sujet :

Looping

  1. #1
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 591
    Points
    3 591
    Billets dans le blog
    8
    Par défaut choisir la colonne (champ) de la clé étrangère
    Bon Patrick
    Une petite suggestion: le choix de la colonne (champ) de la clé étrangère.
    Dans cet exemple...
    Nom : Sans titre.png
Affichages : 1293
Taille : 8,4 Ko
    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...
    Nom : Sans titre.png
Affichages : 1161
Taille : 4,2 Ko
    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.
    @+

  2. #2
    Membre émérite
    Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    Juin 2019
    Messages
    712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2019
    Messages : 712
    Points : 2 877
    Points
    2 877
    Par défaut
    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" .

    Nom : alassane.jpg
Affichages : 1238
Taille : 60,9 Ko

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

  3. #3
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 591
    Points
    3 591
    Billets dans le blog
    8
    Par défaut
    Salut
    Merci pour l'explication
    Citation Envoyé par Paprick Voir le message
    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.
    @+

  4. #4
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 170
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 170
    Points : 7 422
    Points
    7 422
    Billets dans le blog
    1
    Par défaut
    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)

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 385
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 385
    Points : 39 883
    Points
    39 883
    Billets dans le blog
    9
    Par défaut
    @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.

  6. #6
    Futur Membre du Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Février 2022
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Février 2022
    Messages : 6
    Points : 7
    Points
    7
    Par défaut
    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

  7. #7
    Membre émérite
    Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    Juin 2019
    Messages
    712
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2019
    Messages : 712
    Points : 2 877
    Points
    2 877
    Par défaut
    Bonsoir,
    Citation Envoyé par sdonnet31 Voir le message
    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) .

  8. #8
    Futur Membre du Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Février 2022
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Février 2022
    Messages : 6
    Points : 7
    Points
    7
    Par défaut
    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 !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Choisir les colonnes (champs) d'un état avant son affichage
    Par Stéph utilisateur d'acces dans le forum IHM
    Réponses: 11
    Dernier message: 11/06/2011, 11h10
  2. Choisir une colonne selon un champs d'une autre Table
    Par DzBadBoy dans le forum Access
    Réponses: 6
    Dernier message: 03/10/2009, 17h01
  3. [MySQL] Savoir si un champ est une clé étrangère
    Par mattyeux dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 14/01/2008, 23h22
  4. [SQL] Requête SELECT avec un paramètre pour choisir une colonne
    Par svergeylen dans le forum PHP & Base de données
    Réponses: 6
    Dernier message: 26/12/2007, 18h36
  5. Quel type choisir pour un champs identity ?
    Par fmcce dans le forum Sybase
    Réponses: 1
    Dernier message: 12/10/2006, 11h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo