Discussion :

[Minskaya]

Bonjour tout le monde,

Je suis en train de migrer un tres vieux MCD de la version 6 vers la version 12 de poweramc et je voudrais savoir comment je peux personnaliser le nom et le code de mes Relations car chaque fois que je genere le mpd poweramc tente de me renommer les Keys de ces tables et une fois ou deux j'ai coché sans faire attention ce qui m'a posé de petits soucis : les objets n'avait plus le meme nom et les scripts de migration en prod n'ont pas apprécié, bien sur la version 6 les générer avec le bon nom.

J'ai une petite question subsidiaire : a partir de ce MCD je genere 4 MPD pour 4 types de base différentes mais j'ai beaucoup de choses en commun dans ces 4 modèles et notamment les index alternatifs, y a t il moyen de mutualiser tout ca ? Je n'ai pas trouve le comment indiquer qu'un attribut devait être indexé dans le MCD et d'ailleurs je ne suis pas sur que ce soit sa place mais cela m'aurait bien arrangé.

Merci de votre aide

[Minskaya]

En ce qui concerne le deuxième point, je viens de découvrir les Modèles logiques qui semble repondre à mon besoin.
Y a t il une facon de recopier rapidement tous les index de mes 3 mpd vers le mld ? J'ai essayé le copier/coller, la comparaison de modèle et le merge de modèle mais sans succés

Thx

[fsmrel]

Bonsoir Minskaya,

poweramc tente de me renommer les Keys

C'est-à-dire ? Renommer les attributs ? les contraintes ?

S'il s'agit du nom des contraintes, peut-être trouverez-vous des éléments de réponse dans la discussion amorcée par AAAWBBBWCCC (qui du reste n'a jamais daigné se fendre du moindre petit merci suite à la réponse qui lui fut donnée...)

je genere 4 MPD pour 4 types de base différentes

Qu'entendez-vous par "4 types de base différentes" ? (1) relationnelle, (2) hiérarchique, (3) réseau, (4) liste inverse ?

notamment les index alternatifs

Qu'entendez-vous par "index alternatifs" ?

Je n'ai pas trouve le comment indiquer qu'un attribut devait être indexé dans le MCD

Quel est votre objectif ? un index de performance ? un index unique ?


Dans tout cela, il faudrait que vous fournissiez des exemples précis pour qu'on comprenne ce que vous recherchez.

[fsmrel]

J'ai posté avant d'avoir vu votre allusion au modèle logique. Je comprends mal votre histoire d'index, car ce concept n'existe ni au niveau conceptuel, ni au niveau logique, mais seulement au niveau physique. Quel est votre SGBD ?

[Minskaya]

Bonsoir fsmrel,
Depuis hier soir que je parcours le forum en large en travers, je suis devenu un de vos fervents lecteurs

C'est-à-dire ? Renommer les attributs ? les contraintes ?

Non, le nom de l'objet qui dans l'arbre se trouve dans Keys et qui donnera naissance à la contrainte lors de la génération des scripts sql.
La contrainte elle a le bon nom, c'est la "Clé" qui n'est pas bonne : cela me génère plein de faux positifs dans la fenêtre du merge (cf capture).

Qu'entendez-vous par "4 types de base différentes" ? (1) relationnelle, (2) hiérarchique, (3) réseau, (4) liste inverse ?

4 bases relationnelles pour 4 SGBD différents

Qu'entendez-vous par "index alternatifs" ?

Les index de performances.
Il faut que je duplique tout ces index dans mes 4 MPD sans faire d'erreur, je pense que le MLD est la solution à ce problème.
Par contre si j'avais un moyen de copier la 100aine d'index déja existant dans mes MPD dans le MLD, j'éviterai un oubli.

Il faut que je sois sûr de ne pas introduire de régression dans la génération des scripts de mes bases.

En tout cas, merci vous m'avez déjà bcp aidé au travers des réponses que vous avez posté dans ce forum.

[Minskaya]

YEAH !!!!
J'avance : je viens de voir que l'on peut générer le MLD à partir d'un MPD.
Donc je générer 3 MLD à partir de chacun de mes MPD, et à chaque fois je merge dans le MLD généré depuis le MCD.
De cette façon je suis sur de ne rien oublier.

[fsmrel]

Bonsoir Minskaya,


Si tout va bien, tant mieux. Pour ma part je ne dispose pas de la V12 d'AMC, mais seulement de la V11, laquelle, comme la V6 ne permet pas de générer de MLD Il me devient donc difficile de juger...

Bonne route à vous !

[Minskaya]

Et bien, je progresse mais j'ai toujours le problème n°1 : le nom des Clés de mes relations n'est pas le bon ce qui me fait beaucoup trop de différence à controler quand je génère le MPD

[fsmrel]

Bonsoir Minskaya,

Reprenons l’image que vous proposez :






Quel nom de clé doit être retenu au bout du compte pour le MPD : PK_FLGSAMPLEITEM ? PK_FLGTESTITEM ?

[Minskaya]

Bonsoir fsmrel,

Bonsoir Minskaya,

Reprenons l’image que vous proposez :




Quel nom de clé doit être retenu au bout du compte pour le MPD : PK_FLGSAMPLEITEM ? PK_FLGTESTITEM ?

PK_FLGTESTITEM est la bonne clé
La fenetre de gauche (From CDM) est systématiquement fausse pour les relations

[fsmrel]

Reprenons les choses à zéro et partons d’un exemple simple.


MCD :


MLD :



Quand vous dites qu’il y a un problème pour les relations, voulez-vous dire que ci-dessous c’est le nom Identifiant_B qui ne convient pas pour la table R dérivée de l’association R (relation) du MCD ? Le problème de nommage concerne-t-il A et B ?



N.B. Je rappelle que j'utilise AMC V11.

[Minskaya]

Quand vous dites qu’il y a un problème pour les relations, voulez-vous dire que ci-dessous c’est le nom Identifiant_B qui ne convient pas pour la table R dérivée de l’association R (relation) du MCD ?

Oui, c'est bien ça

Le problème de nommage concerne-t-il A et B ?

Non, A et B sont corrects.

Le problème se situe juste sur les tables de relation dans le MLD et apparemment le SQL généré est lui correct. Mais cela oblige toute personne qui modifie le MCD à verifier l'ensemble des modifications ce qui n'inspire pas confiance : du coup cela représente un frein à la migration en v12

[fsmrel]

Partant du MCD, je ne sais pas agir autrement que manuellement sur le nom donné par AMC à la clé apparaissant dans l’arborescence, IDENTIFIANT_B dans l’exemple que j’ai donné et qui peut devenir IDENTIFIANT_A ou je ne sais quoi un autre jour.

Cela dit, cela ne m'a jamais gêné. Que le code SQL généré soit correct, stable et maîtrisable, suffit, non ? En effet, on peut contrôler le nommage des objets impliqués dans les scripts, comme je l’ai montré dans la discussion à laquelle je vous ai renvoyé (et qui concerne plus les clés étrangères, mais le principe est le même). Pour reprendre l’exemple que j’ai utilisé, si je veux qu’AMC génère un script dans lequel le nom des contraintes de clé primaire des tables A, B, R soit respectivement A_PK, B_PK et R_PK, au niveau MPD je passe par (avec la V11, mais avec la V12 ça ne doit pas changer) :

SGBD > Editer le SGBD courant

Et dans l’onglet « Général », je remplace la valeur de ConstName de PKey par « %TABLE%_PK », ainsi le nom de chaque contrainte de clé primaire sera conforme à la structure que j’ai définie :



Si cela ne suffit pas, alors je n'ai pas saisi votre problème...

[Minskaya]

Cela dit, cela ne m'a jamais gêné. Que le code SQL généré soit correct, stable et maîtrisable, suffit, non ?

En effet, on peut contrôler le nommage des objets impliqués dans les scripts, comme je l’ai montré dans la discussion à laquelle je vous ai renvoyé

Oui, il est bien sur vital que le code sql soit stable.
Je souhaitais aller + loin afin de minimiser les changements d'habitude des utilisateurs de la v6 mais si ce n'est pas possible tant pis je vais tacher de les convaincre de faire avec.

Dans tous les cas, encore merci pour le temps que vous m'avez consacré.