Discussion :

[escartefigue]

Bonjour,

À ce propos :

Dans le formulaire concernant : Entité
Serait il possible d'ajouter des notions de préfixe et suffixe en plus du nom et la même chose pour le nom logique ?
Ce préfixe et / ou suffixe viendrait se greffer automatiquement sur chaque rubrique avant et / ou après du nom conceptuel ou logique.

Je suis moi même adepte de l'utilisation d'un préfixe commun au type d'entité et aux attributs qui la composent, du moins dans les cas où la codification est libre, car en entreprise, c'est rarement le cas.

Toutefois, deux remarques :

• l'utilisation au niveau type d'entité est insuffisant : il faut aussi le faire pour les associations n_aires porteuses d'attributs ;
• il serait dangereux de modifier le préfixe automatiquement dans les colonnes par une simple mise à jour d'une cellule au niveau du type d'entité, l'impact sur l'existant étant lourd de conséquences.

[Paprick]

Bonjour,

Tu as tout à fait raison capitaine !
J'ai quand même réfléchi à une solution qui respecterait l'interface actuelle, n'entrainerait pas de conséquences néfastes avec une gestion centralisée de préfixe ou suffixe, et qui répondrait à la demande de DontShootMe !
En rajoutant un bouton "Renommer" dans la fenêtre "Entité" (entre "Modifier" et "Supprimer"), on pourrait provoquer un remplacement de caractères (une sorte de <Ctrl+H> de Word) dans tous les noms de rubriques de la classe en question.
De cette manière, on règle les changements de préfixe ou suffixe, et on ne met pas ma pagaille ailleurs .
Qu'en pensez-vous ?

[escartefigue]

Pourquoi pas, même si je reste circonspect à cause des impacts sur les objets SQL (vues, triggers, fonctions...) et évidemment, sur tous les traitements utilisant ces objets...

[Paprick]

Pourquoi pas, même si je reste circonspect à cause des impacts sur les objets SQL (vues, triggers, fonctions...) et évidemment, sur tous les traitements utilisant ces objets...

Tu as raison d'être prudent !
Mais cette fonction se contenterait de faire ce qu'on peut déjà faire manuellement en modifiant les noms un à un.

[Picsonald]

Et ben dis donc, le topic que j'ai ouvert il y a quelques années a eu du succès ! C'est cool !

J'utilise et je continue d'utiliser Looping régulièrement depuis : il me rend un grand service Merci !

J'ai une nouvelle suggestion à proposer :
Lorsque j'utilise Looping pour de gros schémas, j'ai parfois des entités qui sont liées "à tout" (ou presque).
Mais si, vous savez, c'est assez souvent le cas d'entités nommées "Utilisateur", "Client", "Document", "Individu", "Entreprise" : ce genre d'entité que toutes les autres entités doivent référencer pour avoir un haut degré de traçabilité.
Exemple :

Voir ces associations nombreuses et sans sens métier profond peut parfois desservir le lecteur, sur un grand modèle.

Serait-il possible que Looping propos une fonctionnalité pour "masquer" des associations/liens (et donc les liens correspondants en vue UML ou MLD) ?
Dès lors, l'association & le lien deviendraient invisibles, et le schéma gagnerait en lisibilité.
Cette suggestion est issue de la fonctionnalité qu'offre MySQL Workbench, pour cacher des relations (le draw split).
Voyez plutôt :

Dans MySQL Workbench, les "pattes" de la relation restent visibles, et permettent de cliquer dessus pour restaurer une pleine visibilité si besoin. Lorsque l'on survole la table, l'ensemble des liens réapparait en filigrane.
Dans Looping, j'imaginais les associations & liens disparaitre totalement, et pouvoir être réaffiché avec une petite case à cocher du même genre que la case "Illustrations" ou "Rubriques", qui alterne la visibilité des ces éléments.
La case pourrait s'appeler "Liens masqués" ou "Associations masquées" : et les éléments masqués pourraient ainsi apparaitre (idéalement au premier plan).
Cependant : même masqués, ces éléments continueraient d'impacter la vue UML & MLD et bien sûr le script SQL final.

Bonne soirée & bon week-end !

[Paprick]

Bonsoir,

L'idée est intéressante mais elle soulève quelques réserves dans notre cas.
En effet, MySQL Workbench travaille directement sur des MLD (notation Crow's Foot), ce qui rend les liens moins nécessaires à la compréhension du modèle (présence des clés étrangères dans les tables, et pattes représentant les cardinalités collées aux tables).
Au niveau MCD, la perte des liens serait beaucoup plus gênante pour la cohérence et compréhension du modèle, en particulier pour les associations multiples de part et d'autre qui peuvent être porteuses de rubriques.
Rappelons qu'il est déjà possible d'alléger la représentation graphique en utilisant l'affichage simplifié des associations (même si cela ne les fait pas disparaître).
Autre petite astuce (surtout pour le MLD) : aller dans les propriétés et passer les liens en couleur blanche : en 2 clics, vous réglez le problème des liens !!!
Enfin, il serait intéressant que vous utilisiez les fonctions d'urbanisation de Looping qui permettent de définir des vues partielles de modèles : cela peut être très utile, en particulier pour les grands modèles.

Bonne continuation !

[escartefigue]

Bonjour Paprick, bonjour à tous

Je constate un petit bug visiblement lié à la participation d'une entité-type fictive dans une association n-aire :
à partir du moment où une entité-type fictive participe à une ternaire :

• on ne peut pas choisir la place de son identifiant dans la PK de la table associative
• la place choisie pour les identifiants des autres types d'entité de l'association dans la PK de la table associative est inopérant

Exemple, dans l'extrait ci-dessous, je souhaite que la date issue de [CA_calendrier] soit la première composante de la PK de ma table associative AF_affecter, pour trouver plus facilement les affectations d'une date.




La boite de dialogue de la patte CA_ vers AF_ ne propose pas le choix dans la PK de la table associative :



Si je décoche la notion de table fictive, alors ce choix est disponible.
Je peux alors agencer les PK constitutives de ma FK de la table associative comme je le souhaite, le script SQL respecte ce choix, mais, dès que je recoche "Classe d'entité fictive", je perds cet ordre

Ce n'est évidemment pas un bug majeur, on peut intervenir à posteriori dans le script, mais c'est dommage.

[Paprick]

Bonjour Capitaine,

Ta remarque est tout à fait judicieuse, mais elle s'inscrit néanmoins dans une problématique plus large.
Je m'explique : dans le cas des entités relatives, les clés étrangères sont systématiquement mises en tête (ce qui est légitime compte tenu du rapport entre entités faibles et fortes).
Or, les entités fictives donnent lieu à la génération d'une rubrique "classique", et ne peuvent donc pas participer à l'ordre des "vraies" clés étrangères.
Si tu décomposes l'association et que tu mets la date dans la classe d'entités issue de la décomposition, tu obtiens le même MLD... avec la même contrainte (date derrière les clés étrangères)...

Cependant, n'étant pas partisan des modifications à posteriori dans le DDL, voici ce que j'ai fait pour régler ce problème dans une situation similaire à la tienne :

• Activer l'option "Nom contrainte clé" (si ce n'est pas déjà fait).
• Créer une "Règle" (que l'on peut associer graphiquement avec un lien à l'entité fictive pour plus de lisibilité).
• Dans la partie "Script SQL associé à la règle", faire un ALTER TABLE avec la suppression de la contrainte de clé primaire (comme elle n'est pas référencée par une autre table, pas de problème), puis le rajout de la contrainte avec la bonne clé primaire.

Une autre approche, plus élégante, consiste à conserver la clé primaire existante et créer une clé alternative grâce à la fonction "index composé" de Looping :

• Activer l'option "Proposer index composé" (si ce n'est pas déjà fait).
• Cocher la case correspondante sur chaque lien en indiquant par exemple : "Index(1)", "Index(2)" et "Index(3)" en fonction de l'ordre souhaité.
• La date peut alors être placée en première position, et la contrainte UNIQUE correspondante est générée dans le DDL.

Qu'en penses-tu ?

[escartefigue]

Prenons l'exemple ci-dessous :
La mission est une ET faible du projet, je peux affecter des véhicules à des missions, mais, à un instant "t" un véhicule n'est affectable qu'à une seule mission :



Looping génère le script PRIMARY KEY(VH_ident, CA_date),, c'est dommage, car ici, même en présence d'une ET faible, il n'y a aucun inconvénient à séquencer les FK comme je le souhaite, c'est à dire avec CA_date en premier

En activant l'option "Proposer index composé", j'ai bien aussi la contrainte UNIQUE(CA_date, VH_ident), mais c'est dommage de doublonner un index dans ce cas
[EDIT] je rappelle que dans le cas particulier de MySQL qui confond allègrement index PK et index cluster , on aura en plus un rangement physique des données dans l'ordre des véhicules, pas top dans ce cas.

Si c'était VH_véhicule qui était ciblée par la contrainte, là OK, je comprendrais que la PK de l'ET faible soit positionnée en premier.

Bon je le reconnais, c'est un point de confort

[Paprick]

Je comprends le besoin mais, comment indiqué plus, ces entités fictives ne génèrent pas vraiment des clés étrangères, mais les transforment en rubriques ordinaires.
La solution de la règle avec le ALTER est donc la plus appropriée, et elle ne prend que quelques minutes à mettre en œuvre.
Visuellement, tu peux même la "planquer" derrière l'association pour ne pas alourdir graphiquement le modèle !
Tu as essayé ?

[escartefigue]

Oui c'est opérationnel

[escartefigue]

Bonjour,

Avec DB2 for Z/OS, la version mainframe donc, déclarer une contrainte PK ou une contrainte unique ne génère pas automatiquement un index pour vérifier la contrainte.
Il faut donc ajouter dans le script les instructions CREATE INDEX correspondantes.
Je ne sais pas s'il en va de même avec les clones DB2 for I (AS/400) et DB2 developper.

@Paprick : pourrait on envisager que les ordres CREATE INDEX soient automatiquement ajoutés dans le DDL quand il s'agit de DB2, ce qui impliquerait peut-être (si les clones DB2 incluent ces ordres dans le DDL), de considérer DB2 for Z/OS et les autres DB2 comme deux SGBD différents dans la liste déroulante de choix du SGBD. Ce qui est du reste le cas.

Bien sûr, le DDL est toujours altéré par le DBA pour en compléter le contenu, mais ce serait tout de même un plus

À noter : avec DB2 for Z/OS, déclarer une PK mono colonne sur la définition de la colonne ne génère pas de ligne dans la SYSIBM.SYSCONTRAINT alors que la contrainte PK explicite CONSTRAINT le fait.

En d'autres termes

Code SQL :

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

1
2
3
4
create table T1
      (  T1PK  integer  primary key
       , T1XX  [...]
      )

N'est pas la même chose que

Code SQL :

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

1
2
3
4
5
6
create table T1
      (  T1PK  integer  not null
       , T1XX  [...]
       , constraint PKT1
         primary key (T1PK)      
      )

Mais dans les deux cas, il n'y a pas de CREATE INDEX implicite.

[escartefigue]

Et je copie-colle ici une proposition faite dans le fil de discussion de la V4.1 :

Paprick : serait il possible que le zoom tienne compte de l'objet sur lequel on a mis le focus (l'entité, l'asso, la contrainte... sélectionnée) pour centraliser l'image redimensionnée, ce serait un + de confort, mais bien pratique

[Paprick]

Et je copie-colle ici une proposition faite dans le fil de discussion de la V4.1 :

Et je copie-colle la réponse !

Si tu sélectionnes plusieurs objets et que tu cliques sur "Ajuster à la fenêtre" (ou taper "0"), ça zoome sur la sélection . Tu peux ensuite dézoomer si nécessaire (avec le "-" par exemple).
N'oublie pas aussi que, en laissant le bouton droit de la souris enfoncé, tu peux bouger tout le modèle très facilement.
Mais je vais quand même regarder si on peut encore optimiser.

[escartefigue]

et même réponse : en fait, il ne s'agit pas tant d'afficher tout sur la même fenêtre que de placer l'objet ou les objets sélectionnés au centre de celle-ci (c'est à dire centrer, et non pas "centraliser" comme je l'ai écrit par erreur plus haut )

[Paprick]

Bonsoir Capitaine,

J'en déduis effectivement que tu n'es pas un adepte du <Ctrl>roulette de la souris !
Avec cette utilisation, le zoom s'effectue en fonction de la place du curseur de la souris, ce qui est très bien.

Sinon, il est vrai que Looping zoome à partir du milieu de la zone graphique.
Afin de t'être agréable, je vais donc faire une modification pour qu'il zoome en fonction de l'objet sélectionné (quand il y en a qu'un seul de sélectionné bien sûr !).

Par ailleurs, concernant la taille de la fenêtre de Rétroconception, envoie-moi une copie de ton écran 13" afin que j'évalue la taille à adopter.

[escartefigue]

Pour mon souci de troncature de la fenêtre "rétroconception" sur l'écran 13'', il faudra patienter un peu, puisque c'est un matos que j'avais emprunté avant de pouvoir installer la V4.1 sur mon poste.
Mais il me vient à l'esprit que je peux sans doute jouer sur le zoom ou la résolution pour contourner le problème.