Discussion :

[switch1]

salut tout le monde.
je travaille sur power amc 11 et j'ai un souci.
j'ai deux entités A et B qui sont reliées par une association de type 1,1
A--(0,1)----------ASSOCIATION------------(1,1)B
lorsque je génère le modèle power amc transforme l'association a une entité qui contient les deux ids des tables A et B ?
svp comment je peux configurer power amc pour que je puisse avoir l'id de la table A comme cle étranger dans l'entite B.(sans passer par la nouvelle entité )
merci de votre aide

[fsmrel]

Normalement, Power AMC crée un cycle, en définissant pour la table B une clé étrangère référençant la table A et pour la table A une clé étrangère référençant la table B.

Cela dit, au niveau MCD, utilisez-vous la notation Merise ou la notation Entité-Relation ?

Dans ce dernier cas, l'entité-type B peut-elle être identifiée relativement à A ?

[switch1]

au début ça était merise+e/s mais malgré je choisis merise comme notation pour toute relation 1,1 il me crée une nouvelle entité
merci de votre aide .

[switch1]

normalement l'entité B va recevoir l'id de l'entité A et c'est tt
svp si y'a une façon de configurer ces réglés de passage sous power amc si nn si y'a d'autre logiciels
merci de votre aide

[fsmrel]

Bonjour,

Il faudrait que vous joigniez une image du MCD et du MLD.

Je rappelle qu'en toute logique, Power AMC (ou autre AGL) doit produire un MLD avec cycle (symétrie des cardinalités maximales à 1 oblige). On intervient alors manuellement au niveau du MLD pour rompre le lien selon lequel B est parent de A.

[switch1]

merci de votre aide
ci joint un petit exemple de mcd et le mpd équivalent.
l'entité usr est liée avec une entité candidat et une autre recruteur avec une relation de type 1.1
comme vous vous voyez pour chaque relation power amc crée une entité .
normalement ce que je veux c'est que l'entité candidat reçoit l'id de l'entité usr comme FK et l'attribut date_inscriptionCand .
merci de votre aide.

[fsmrel]

Vos associations-types est_inscrit et est_inscrit2 sont porteuses de données et Power AMC décide en conséquence d'en faire des tables, ce qui n'est pas faux. En effet, pour ne pas procéder ainsi, il faudrait qu'il sache dans quelle table migrer les attributs dateInscriptionRec et dateInscriptionCand. Vous avez certainement une idée à ce sujet, mais pas lui. En conséquence, à vous de procéder à cette migration dès le MCD.

Là où Power AMC s'emmêle les pinceaux, c'est quand il décide que la clé primaire des tables est_inscrit et est_inscrit2 est composée du couple {emailUsr, idRec}. Ceci est un bug. Il aurait dû créer deux clés, une primaire et l'autre alternative {emailUsr} et {idRec}.

[switch1]

merci

[switch1]

merci de votre aide .
Si dans le mcd j'introduis l'attribut DateINscriptionCand dans la table Candidat il va en fait insérer l'id de la table USR vers la table candidat(comme clef étrangère not null puisque un candidat doit avoir au moins une occurrence de l'entité USER) et vise versa mais cette fois la clef étrangère peut être nulle(puisque un user peut ne pas avoir une occurrence de l'entité Candidat).
c'est bien mais !
lorsque je vais insérer des données dans ces deux tables ?je dois insérer une ligne dans la table USR ((FK)idcandidat =nulle),après je vais insérer une ligne dans la table candidat dont l'attribut FK idUser = l'user que je viens d'insérer.et finalement mettre a jour la ligne USER que j'ai déjà insérer !!! c'est un peu lourd
normalement avec une relation
A:0,1-----ASSOCIATION--------B 1,1
l'id de la table A migre vers l'entité B comme FK et si l'association est porteuse des données,elles vont aussi migrer vers l'entité B comme des attributs simple .
alors je pense que la seule solution pour obtenir ceux ci c'est de changer les cardinalites de la relation comme suit :
User (0,n) -----------est_inscrit----------(1,1)Candidat
svp qui ce que vous pensez de cela ?
je crois que dans une relation de type 1,1 il ne faut pas traduire l'association comme entité même si elle est est porteuse de data .parce que si non dans notre cas par exemple(USR CANDIDAT) je peux avoir un candidat avec plusieurs user en relation ==>erreur parce que j'ai déclaré que un candidat est lie avec une et une seule occurrence de l'entité USER .
aussi dans une relation 1,1 A(0,1)---------ASSOCIATION-----(1,1)B
même si l'association n'est pas porteuse POWER AMC met l'id de chaque entité dans l'autre !!!a mon avis il suffit que l'id d'une table soit insérer dans l'autre et surtout l'id de l'entité A migre vers l'entité B comme FK(comme ça je peux insérer des données facilement )

je vous remercie beaucoup

[fsmrel]

Si dans le mcd j'introduis l'attribut DateINscriptionCand dans la table Candidat il va en fait insérer l'id de la table USR vers la table candidat(comme clef étrangère not null puisque un candidat doit avoir au moins une occurrence de l'entité USER) et vise versa mais cette fois la clef étrangère peut être nulle(puisque un user peut ne pas avoir une occurrence de l'entité Candidat).
c'est bien mais !

Souvenez-vous que je vous ai dit : en toute logique, Power AMC (ou autre AGL) doit produire un MLD avec cycle (symétrie des cardinalités maximales à 1 oblige). et qu’on peut intervenir manuellement au niveau du MLD pour rompre le lien gênant. Ceci fait, il faut garantir la règle selon laquelle pour un Usr il y a au plus un candidat (même principe pour un recruteur). Pour cela, il faut définir UsrId comme clé alternative (<ak>) de la table Candidat :


Pour cela, vous accédez à la fenêtre "Propriétés de la table" de la table Candidat :

Cliquer sur l’onglet « Clés »

Icône "Insérer une ligne" => apparition d'une ligne Cle_2.

Sur cette ligne, choisir "Sélectionner tout" (ou clic droit sur la ligne entière).
=> Message "Vous ne pouvez pas modifier...", on s'en fiche : cliquer sur "Oui".

Apparition d'une nouvelle fenêtre "Propriétés de la clé Cle_2".

Onglet Colonnes, cliquer sur "Ajouter des colonnes" :
Cocher la case UsrId, et faire OK à volonté.

UsrId apparaît dans le MLD en tant qu'alternate key <ak> (et évidemment aussi en tant que clé étrangère (<fk>)).

[switch1]

d'accord je vous remercie beaucoup de votre aide .
je vois pas a quoi sert de définir la clef étrangère idUsr comme clef alternative ??
si c'est pour assurer que chaque valeur de idUSR apparait au plus une fois dans la table candidat bein j'ai déjà lit votre conversation ici
http://www.developpez.net/forums/d47...t/#post4336889
j'ai teste mais cela ne marche pas (j'ai pu insérer deux ligne dans la table candidat avec même valeur de la clef étrangère qui est en meme temps une clef alternative, sous mysql 5) et je sais même pas pour quoi normalement une clef alternative est un ou plusieurs attributs qui peuvent identifier chaque ligne de l'entité et qui est pas une clef primaire !!!
si non j'ai déjà essaye le même exemple (candidat user avec une association porteuse) sous win'design 5 et il a introduit idUser(comme FK) et l'attribut date d'inscription dans l'entité candidat .mais j'ai pas du temps pour recommencer a 0 la conception puisque je manipule plus de 30 entité dans le cadre d'un projet de fin d'étude licence 3.
je crois que je vais continuer avec power amc.je vais changer les cardinalites entre usr et candidat de 1.1 a 1.n pour obtenir l'id de l'entité usr et les attribut de la relation est_inscrit dans l'entité candidat
je vous remercie infiniment de votre soutien

[fsmrel]

Bonsoir,

je vois pas a quoi sert de définir la clef étrangère idUsr comme clef alternative ??

Ça permet de garantir que pour un candidat il n’y a qu’un seul Usr. Sinon, pour un Usr on peut avoir autant de candidats qu’on en veut et ceci est contraire à vos règles de gestion.

si c'est pour assurer que chaque valeur de idUSR apparait au plus une fois dans la table candidat bein j'ai déjà lit votre conversation ici
http://www.developpez.net/forums/d47...t/#post4336889
j'ai teste mais cela ne marche pas (j'ai pu insérer deux ligne dans la table candidat avec même valeur de la clef étrangère qui est en même temps une clef alternative, sous mysql 5)

Forcément, dans la discussion à laquelle vous faites référence, on peut résoudre le problème au niveau conceptuel, alors qu'ici, c’est au niveau logique qu’il faut agir.

Si vous suivez mon conseil, à partir du MLD :

Power AMC produit alors le code suivant :

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
16
17
18
/*==============================================================*/
/* Nom de SGBD :  MySQL 4.0                                     */
/*==============================================================*/
create table Usr
(  Usrid                          int           not null,
   Usrlibelle                     varchar(48)   not null,
   primary key (Usrid)
);
create table Candidat
(  CandidatId                     int            not null,
   Usrid                          int            not null,
   CandidatNom                    varchar(48)    not null,
   DateInscr                      datetime       not null,
   primary key (CandidatId),
   key AK_Cle_2 (Usrid)
);
alter table Candidat add constraint FK_AB foreign key (Usrid)
      references Usr (Usrid) on delete restrict on update restrict;

la clé alternative définie par l’AGL pour la table Candidat est bien {Usrid}.

je sais même pas pour quoi normalement une clef alternative est un ou plusieurs attributs qui peuvent identifier chaque ligne de l'entité et qui est pas une clef primaire !!!

Considérez une hypothétique table des membres de developpez.com :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
 
CREATE TABLE Membre
(    MbrId            INTEGER        NOT NULL
   , Pseudonyme       VARCHAR(16)    NOT NULL
   , DateInscription  DATE           NOT NULL
   , Localisation     VARCHAR(48)    NOT NULL
   , AdrCourriel      VARCHAR(128)   NOT NULL
 , CONSTRAINT MbrPk PRIMARY KEY (MbrId)
 , CONSTRAINT CK2 UNIQUE (Pseudonyme)
 , CONSTRAINT CK3 UNIQUE (AdrCourriel)) ;

La clé primaire est ici {MbrId}. Mais comme le pseudonyme d’un membre et son adresse de courriel lui appartiennent en exclusivité, on définit deux clés alternatives {Pseudonyme} et {AdrCourriel} pour garantir cette contrainte d’unicité (clause UNIQUE, renommée en KEY avec MySQL}.

je vais changer les cardinalites entre usr et candidat de 1.1 a 1.n

Dommage. Bonne chance pour la suite.

[switch1]

Dommage. Bonne chance pour la suite.

bon je vous remercie de votre aide.
puisque l'idée de changer les cardinalies vous plait pas alors je vais laisser les cardinalites entre candidat et user 1.1 .comme ça je serais content par la suite.
merci encore fsmrel .