Discussion :

[patgabjoe]

Bonjour,

Je suis sur Poweramc 11 et j'aimerais savoir s'il existe une possibilité d'inverser le sens de la flèche entre les 2 tables : la table Parent devient fils et inversement, et cela en 1 ou 2 clics.
Je veux dire pas là sans être obligé de modifier dans les propriétés de la contrainte, le nom des tables (les inverser) et surtout en reconstruisant les liens.

Merci bien.
Patrick

[fsmrel]

Bonsoir,


Je suppose que vous parlez du MPD, auquel cas :

Outils \ Options du modèle : Notation du modèle : CODASYL

(soit 3 clics...)

[patgabjoe]

Bonjour,

C'est sympa mais ce n'est pas cela que je souhaitais réaliser.
Je veux corriger une erreur faite sur plusieurs jointures. J'ai inversé les contraintes, et je n'ai pas trop envie de refaire toutes celles-ci.

En fait, si je modifie la jointure en double cliquant dessus et que j'inverse table parent et table enfant l'ensemble des jointures faites n'existent plus, et donc je me vois dans l'obligation de tout refaire. C'est un peu gênant surtout quand plusieurs colonnes constituent la clé et que l'on a pas une parfaite connaissance du modèle. Je dois modéliser à partir des liens qui sont fait dans les catalogues impromptus.

J'ai pas trouver d'autres méthodes que de faire cela table par table.
S'il existait un outil pour cela je serais vraiment très ravi ...

Merci pour votre aide.

[fsmrel]

Bonjour patgabjoe,

En fait, si je modifie la jointure en double cliquant dessus et que j'inverse table parent et table enfant l'ensemble des jointures faites n'existent plus, et donc je me vois dans l'obligation de tout refaire.

Si j'ai bien compris, les rôles parent - enfant entre deux tables T1 (référencée) et T2 (référençante) doivent être permutés. En l'occurrence, vous aurez à supprimer le lien existant, puis hélas définir les nouveaux attributs dans T1 qui permettront de référencer T2...

Une solution pourrait permettre de générer automatiquement ces nouveaux attributs dans T1 :

Générer un MCD à partir du MPD (dans lequel sont conservés les liens à permuter). Pour éviter de loucher sur les ronds merisiens et gagner du temps, utiliser la notation Entité/Relation pour ce MCD (Options du modèle). Ceci fait, cliquer sur le lien connectant T1 et T2 pour ouvrir la fenêtre Propriétés de la relation et permuter les noms entre Entité 1 qui devient T2 et Entité 2 qui devient T1. Le sens de la relation a changé. Au final, générer un nouveau MPD.
Pour voir, commencez en utilisant avec un MPD comportant seulement deux tables...


Bon courage

[patgabjoe]

Merci mais là cela devient plus complexe il me semble, surtout que je n'ai jamais travaillé avec les MCD sous POwerAMC.
Il me faudrait tester cela cependant.
Merci pour l'aide.
Patrick

[fsmrel]

je n'ai jamais travaillé avec les MCD sous POwerAMC.
Patrick

C'est l'occasion de mettre les boeufs devant la charrue...

[patgabjoe]

J'oubliais sur les contraintes, comment se fait-il que lorsque je "glisse" 2 ou plusieurs tables, dont les jointures ont déjà été réalisées, que PowerAMC ne me mettent pas les tables avec leurs jointures.

C'est dérangeant de faire glisser les jointures réalisées, surtout quand dans son schéma on a 200 tables car il faut savoir où elles se trouvent les bonnes jointures ... et c'est pas évident croyez moi et c'est une énorme perte de temps surtout que lorsque les tables existent déjà il va faire des alias.
Une vraie galère.
Peux-être y-a-t-il une astuce ?

Merci.

[fsmrel]

Vous donnez l’impression de faire les modifications au niveau MPD. Si tel est le cas, vous vous embarquez effectivement dans galère sans nom. Sinon, n’hésitez pas à produire un MCD à partir du MLD et agir comme je vous l’ai suggéré, même avec 200 tables ça doit être jouable. Commencez les inversions dans le MCD, concernant évidemment les associations les plus simples. Si vous avez des problèmes au niveau MCD, vous pouvez me les signaler (et ça peut intéresser d’autres forumeurs).

[patgabjoe]

Bonjour,
Je veux bien faire votre méthode, mais je ne peux importer mon MPD dans un MCD car il m'indique version 6 limité ?
Aurais-je pas compris ce qu'il faut faire sinon existe-t-il une autre possibilité ?
Merci.

[fsmrel]

Si vous avez une version bridée, alors je ne sais quoi vous dire, sinon que votre direction fasse le nécessaire financièrement parlant...

[patgabjoe]

J'ai une version 11 chez moi qu'il me faut installer alors pour mes tests.
En revanche c'est possible sous Vista ???

Quant à la demande à ma boite de services ... faut pas rêver

Une dernière chose qui à engendré pas mal de soucis sur le modèle, c'est l'appellation que donne PowerAMC aux tables : Parent et Enfant.
Il serait dans la logique de penser que la table Parent corresponde à la table de FAIT, et bien c'est le contraire si on regarde le code qui est généré pour la création des clés étrangères.

Exemple : Table Eleve / Table Classe : il faut mettre la Table Classe en tant que table Parent si on veut générer une clé étrangère du type :

alter table ELEVE
add constraint FK_NUM_CLASSE foreign key (ID_CLASSE)
references CLASSE (ID_CLASSE)

Je trouve cela pas forcément bien pensé.
Dans la modélisation (type référentielle) on la flèche ainsi faite :
FAIT ----> DIMENSION

Merci tout de même pour toutes ces réponses.

[fsmrel]

Bonsoir patgabjoe,

J'ai une version 11 chez moi qu'il me faut installer alors pour mes tests.
En revanche c'est possible sous Vista ???

En espérant que vous pourrez ouvrir le fichier de type MPD et que vous serez autorisé à générer le MCD à partir du MPD.
Quant à Vista, je ne l’utilise pas, donc je ne me prononce pas.

Une dernière chose qui à engendré pas mal de soucis sur le modèle, c'est l'appellation que donne PowerAMC aux tables : Parent et Enfant.

Il est exact que Power AMC aurait pu éviter de parler de table parente et de table enfant.
La notion de table parente est tout à fait informelle et ne figure ni dans la norme SQL ni dans la théorie relationnelle. Disons qu’il y a extrapolation hasardeuse, voire trompeuse au plan sémantique de considérer comme parente une table, simplement parce qu’elle est une référence pour une autre table : considérer la table DIMENSION comme « parente » de la table FAIT, sémantiquement ça ne veut rien dire. Tout au plus, peut-on dire que la table FAIT, est la source d’une contrainte référentielle ayant pour cible la table DIMENSION.

Par ailleurs deux tables T1 et T2 peuvent très bien jouer simultanément les deux rôles vis-à-vis l’une de l’autre :
Considérez la table DEPARTEMENT des départements d’une entreprise et la table SALARIE des salariés de l’entreprise : tels salariés sont rattachés à tel département, mais dans l’autre sens, un département est dirigé par un de ses salariés...

Cela dit, comme je l’ai signalé dans mon premier message, on peut flécher dans un sens (notation officielle CODASYL) ou dans l’autre (notation paraît-il relationnelle). Comme dit Blaise Pascal, « Vérité en deçà des Pyrénées, erreur au delà.»

En tout cas, c’est patgabjoe qui subit les conséquences de prétendues parentés...

[patgabjoe]

Bonjour,
Je suis en version 15 maintenant pour faire mes tests.
J'ai bien générer mon MCD.
J'ai modifier les relations.
Mais lors de la regénération du MPD il me supprime :

Les colonnes affectées aux contraintes (onglet Joins)
Le nom de la contrainte dans l'onglet Integrity.

Est-ce normal tout ça ?
Merci

[fsmrel]

Bonjour,

Pourriez-vous montrer un exemple concret avec quelques tables, que je puisse le reproduire avec la V11 de l'AGL ?

A bientôt

[patgabjoe]

Bonsoir,

un exemple concret et très simple.

Table de Fait : F_PRIMES
Table de Dimensions : D_ELEVEUR

F_PRIMES a comme clé primaire key_primes

D_ELEVEUR a comme clé primaire key_eleveur

la jointure entre F_PRIMES et D_ELEVEUR est la colonne key_eleveur que l'on retrouve dans F_PRIMES mais sous le nom id_eleveur

On a donc (initialement) dans l'onglet "Général"

Table Parent : F_PRIMES
Table enfant : D_ELEVEUR

et dans l'onglet "Joins"

A gauche : id_eleveur et à droite key_eleveur

Mais lors de ma modif dans le MCD (inversion des tables) et puis regénération du MPD alors j'ai bien le changement pour les tables (elles ont été permutées) mais les colonnes de jointure ont disparu

Je ne sais pas si c'est bien clair ?

Merci en tout cas

[fsmrel]

Quand on produit le MCD, D_ELEVEUR est considérée comme entité-type faible et n’a donc pas d’identifiant propre. SI on permute le rôle des entités-types, on se retrouve donc avec une entité-type parente sans identifiant, ce qui n’est pas bon du tout :

=> on laisse tomber.

En revanche, on va essayer ça directement au niveau MPD.

Situation initiale (key_eleveur est PK et FK) :



Cliquer sur la référence (la flèche qui relie les deux tables) et permuter les rôles entre table parent et table enfant : D_ELEVEUR devient parente. On doit avoir ça :



On se retrouve avec les attributs en double dans F_PRIMES : id_eleveur et key_eleveur. Dans l’onglet « JOINS », vous remplacez key_eleveur par id_eleveur. key_eleveur disparaît d'office du schéma. Ça doit donner directement :



Chez moi ça marche.. Merci de me tenir au courant.

[patgabjoe]

Bonjour,

J'aimerais bien tester cela, sauf que chez moi les rôles n'existent pas. L'emplacement est vide.

Que faire ?

[fsmrel]

Bonjour patgabjoe,

Voulez-vous dire que, au départ, dans les boîtes que j’ai marquées, là où figurent les noms de la table parent et de la table enfant il n’ y a rien ?

[patgabjoe]

Si là j'ai quelque chose. C'est dans les cellules Rôles où je n'ai rien.

PS : je viens de modifier le message où j'avais mis "Exactement !" : erreur de ma part.

[fsmrel]

Il y a un petit quiproquo, d’où mon image précédente. En fait les cellules Rôles dont vous parlez n’interviennent pas dans ce dont nous traitons. La permutation concerne « Table parent » et « Table enfant » : Ce sont F_PRIMES et D_ELEVEUR que vous devez perrmuter. ce qui doit donner au résultat :