Discussion :

[fsmrel]

Bonjour Paprick,

C’est encore moi avec mes problèmes de ON DELETE CASCADE...
C’est bon pour les associations entre classes. Mais il y a le cas des sur-types (cf. page 238 de ton ouvrage) : quand je supprime une personne, qu’il s'agisse d’un administratif ou d’un enseignant, je ne la supprime pas qu’à moitié : le métabolisme doit pouvoir s’exprimer pleinement, en une seule fois, donc une case à cocher sur le lien porteur de la flèche serait la bienvenue...

[Paprick]

Bonsoir,

C’est encore moi avec mes problèmes de ON DELETE CASCADE...
C’est bon pour les associations entre classes. Mais il y a le cas des sur-types (cf. page 238 de ton ouvrage) : quand je supprime une personne, qu’il s'agisse d’un administratif ou d’un enseignant, je ne la supprime pas qu’à moitié : le métabolisme doit pouvoir s’exprimer pleinement, en une seule fois, donc une case à cocher sur le lien porteur de la flèche serait la bienvenue...

Actuellement, l'option est proposée au niveau des liens des sous-types, mais il est vrai que l'on a du mal à imaginer que l'on puisse garder une des classes fille si la la classe mère est supprimée...
Et si je respecte la logique de décomposition d'un héritage (cf. pages 217 et 220 du livre), l'option doit effectivement être prise côté classe mère...
Certes, on arrive au même résultat, surtout si l'on prend l'option de valider par défaut les CASCADE dans les propriétés, mais je suis d'accord que c'est plutôt le lien vers la classe mère qui doit centraliser le choix...
Modif en perspective pour la version 4.1 !

[escartefigue]

Bonjour à tous

Une suggestion de confort : faciliter le redimensionnement des blocs de texte libre.

Je m'explique : j'ai pour habitude d'ajouter une zone de texte dans mes MCD pour y inclure l'URL du fil de discussion quand il s'agit d'une discussion issue du site developpez.net. Mais, quel que soit le zoom utilisé, j'ai beaucoup de mal à positionner la souris pour que le pointeur change de forme signifiant l'activation du redimensionnement. Le moindre mouvement fait perdre cette possibilité.

[fsmrel]

Bonjour Paprick,

Dans le MCD ci-dessous, on traite de marchandises selon des règles de gestion dont celles qui m’intéressent sont les suivantes :

RG01 – Une marchandise relève d’une famille de marchandises et une seule.
RG02 – Il y a quatre familles de marchandises : Produits d’origine animale, Végétaux et produits végétaux, Produits destinés à l'alimentation animale, Animaux vivants.
RG03 – Chaque marchandise est composée de lots, lesquels relèvent tous donc d’une seule famille, celle de la marchandise qu’ils composent.
RG04 – Chaque lot fait référence à une (occurrence de) nomenclature.
RG05 – Chaque (occurrence de) nomenclature fait référence à une des quatre familles ci-dessus.
RG06 – La famille dont relève un lot et la famille de la nomenclature référencée par ce lot doivent être la même.

Dans mes tentatives de modélisation avec Looping, j’avais notamment pensé au MCD suivant, mais il l’a invalidé...:



Ainsi, Looping accepte qu'un sous-type soit identifié relativement à une nomenclature, mais refuse que l'identifiant du lot participe à la clé primaire de la table inférée du sous-type :  

LotViande = (#NomenclatureId, ***CLE_INCOMPLETE***, #(#MarchandiseId, LotId));
LotVegetal = (#NomenclatureId, ***CLE_INCOMPLETE***, Etat, #(#MarchandiseId, LotId));
LotAnimalVivant = (#EspeceId, ***CLE_INCOMPLETE***, Puce, Sexe, #(#MarchandiseId, LotId));
LotOrigineAnimale = (#NomenclatureId, ***CLE_INCOMPLETE***, #(#MarchandiseId, LotId));

Par curiosité j’ai récupéré dans mon grenier une vieille version de PowerAMC et lui ai proposé le même MCD. Sans sourciller, comme clé primaire SQL d’un lot il propose le triplet : {MarchandiseId, LotId, NomenclatureId}.

Qui a raison ? Looping ? AMC ? A y regarder de près, sémantiquement et ontologiquement parlant (pardon pour ces gros mots), un lot spécialisé reste un lot et un sous-type n’est pas une association entre surtype et nomenclature.

Avantage donc à Looping ! Mais alors que faire pour qu’il ne rouspète plus ? J’ai finalement monté la barre d’un cran, en procédant du coup à la généralisation des nomenclatures et en établissant l’association non plus entre un sous-type de lot et « sa » nomenclature, mais carrément entre les surtypes Lot et Nomenclature. Je ne sais pas si j’ai bien fait, mais je trouve en tout cas que le montage est cohérent :

Pièce jointe 632721

Paprick, ton avis ?  

Discussion à l’origine de ce message : Demande d’aide modélisation héritage. 

A noter que la règle de gestion RG06 fait l’objet d’un trigger de validation cf. post #25 de la même discussion.

A noter encore que pour contrôler la contrainte d’exclusion entre sous-types, il y a d’autres triggers à pondre. A titre d’exemple, j’en ai codé un (cf. à nouveau le post #25), mais ce trigger est un bourrin et il y a certainement beaucoup mieux. Si un spécialiste SQL passe par ici...

En tout cas, merci à Looping de m’avoir fait prendre conscience que j’étais sémantiquement à côté de la plaque (tout comme AMC)...

Et en route pour Looping 4.1 !

[Paprick]

Bonjour François,

Sacré cas d'école que tu nous poses là !
Sur un plan sémantique, je te rejoints totalement et je pense que AMC a une façon bien cavalière d'établir cette clé primaire.
Je vais pour ma part me positionner sur un plan purement conceptuel.
En terme d'héritage, il existe 2 façons de modéliser les choses : spécialisation ou généralisation.

SPECIALISATION
Les sous-types viennent compléter les informations du sur-type dont ils récupèrent l'identifiant ; par conséquent, ils n'ont pas leur propre identifiant et c'est à ça qu'on les reconnait.
Dans ton exemple, les sous-types ont leur propre identifiant récupéré via l'identification relative : Looping ne va donc pas considérer dans la clé primaire les identifiants du sur-type et va les laisser en simple clé étrangère.

GENERALISATION
Les sous-types ont leur propre existence, et les informations du sur-type viennent compléter celles du sous-type ; par conséquent, ils ont leur propre identifiant et c'est à ça qu'on les reconnait.
Comme indiqué ci-dessus, c'est le cas dans ton exemple.

AMC fait une sorte de mélange des deux en considérant que la clé primaire est composée des identifiants du sur-type et du sous-type... Conceptuellement, c'est très ambigu et cette ambiguïté se retrouve au niveau sémantique comme tu l'as très bien signalé. Par ailleurs, ce faisant, AMC ne distingue pas les notions de spécialisation et de généralisation.

Revenons donc à nos moutons (en l'occurence, ton exemple) : nous sommes donc dans le cas d'une généralisation. Les sous-types ont leur propre identifiant, et si cet identifiant se limite à l'identifiant relatif, il n'est plus unique (compte-tenu de la cardinalité 0,n qu'il y a de l'autre côté de l'association). Par conséquent, Looping considère la clé comme incomplète.

Alors, Looping peut obtenir le même résultat que AMC (si c'est vraiment ce que l'on veut) : il faut alors décomposer l'héritage avec des associations 0,1--(asso)---1,1(R), et là on voit bien que sémantiquement, ça devient contestable, et l'héritage est très ambigu...

Certes, on pourrait aussi imaginer l'équivalent d'un (R) sur le lien du sous-type dans le cas d'une généralisation... techniquement, c'est facile à faire (simple case à cocher), mais ça ne me plait pas...
Mais après tout, ça reste la responsabilité du concepteur... Looping n'est que l'exécutant !

Qu'en penses-tu ?

[fsmrel]

Ave Paprick,

Sur un plan sémantique, je te rejoints totalement et je pense que AMC a une façon bien cavalière d'établir cette clé primaire.

On est bien en phase.

Revenons donc à nos moutons (en l'occurence, ton exemple) : nous sommes donc dans le cas d'une généralisation. Les sous-types ont leur propre identifiant, et si cet identifiant se limite à l'identifiant relatif, il n'est plus unique (compte-tenu de la cardinalité 0,n qu'il y a de l'autre côté de l'association). Par conséquent, Looping considère la clé comme incomplète.

On est toujours d’accord et comme je l’ai précédemment souligné, étant donné Looping se positionne au niveau sémantique, la seule conclusion qui s’impose est qu’il a totalement raison.

Alors, Looping peut obtenir le même résultat que AMC (si c'est vraiment ce que l'on veut) : il faut alors décomposer l'héritage avec des associations 0,1--(asso)---1,1(R), et là on voit bien que sémantiquement, ça devient contestable, et l'héritage est très ambigu.

Clairement, on passerait de la bonne logique à une tambouille où l’on mélangerait ketchup et chantilly, beurk ! 

A propos de tambouille, en fouillant encore dans mes archives, j’ai récupéré une discussion dans laquelle PostgreSQL traite de l’héritage et confond allègrement être et avoir, c’est-à-dire que si pour nous une ellipse peut être un cercle (et un cercle est une ellipse), PostgreSQL considère qu’une ellipse peut avoir un cercle (et un cercle appartenir à une ellipse), ce qui sémantiquement n’est quand même pas pareil… Soit dit en passant, je me rends compte que, tant bien que mal, j’avais réussi à me servir de ce SGBD (y-compris pour faire de la vraie spécialisation)...

Certes, on pourrait aussi imaginer l'équivalent d'un (R) sur le lien du sous-type dans le cas d'une généralisation... techniquement, c'est facile à faire (simple case à cocher), mais ça ne me plait pas...

Ça ne me plaît pas non plus ! Ne touche à rien ! C’est cette histoire de clé incomplète qui m’a troublé et forcé à réfléchir pour en arriver au MCD que j’estime cette fois-ci aller dans le bon sens, en procédant à la généralisation des nomenclatures et en établissant un lien classique entre Lot et Nomenclature. Si tu avais mis en oeuvre la case à cocher que tu évoques, je n’en serais pas arrivé à ce dernier MCD (qui reste encore à valider à partir de l’ensemble des règles de gestion) :



J’en conclus, que Looping est loin devant AMC et PostgreSQL quant à la prise en compte des aspects sémantiques et ontologiques et qu’il ne doit surtout pas régresser. On trouvera toujours des pinailleurs, des esprits chagrins pour (tenter de) démontrer que tu as tort, mais peu importe les sophismes dont ils devront faire usage. Fermez le ban ! 

[Ken...]

Hey,

Déjà merci M. Bergougnoux pour votre logiciel que je trouve bien plus optimisé, simple, et efficace que d'autres. Il m'est bien pratique pour mes études et mon travail.

Un petit truc assez dérangeant sur Looping est le défilement horizontal. Alors soit je n'utilise pas correctement le logiciel, soit il manque une petite fonctionnalité. Je m'explique :

On a actuellement la simple mollette de souris qui permet de défiler de haut en bas. Super !
On a aussi actuellement le Ctrl molette pour le Zoom. Génial

Mais pourquoi pas le Shift molette pour le défilement horizontal comme beaucoup d'autres logiciels ?

Merci d'avoir pris le temps de lire !

[Paprick]

Bonjour,

Mais pourquoi pas le Shift molette pour le défilement horizontal comme beaucoup d'autres logiciels ?

Pourquoi pas dans la version 4.1 ! Pouvez-vous me donner des exemples de logiciels qui font ça ? Je n'en trouve pas...
Sachez, en attendant, que vous pouvez utiliser, avec la plupart des souris, le défilement horizontal en pressant sur les côtés de la molette .
En tout cas, ça marche très bien avec ma souris.
Vous pouvez également maintenir le bouton droit de la souris enfoncé et déplacer le modèle dans tous les sens .

[Ken...]

Bonjour

Pourquoi pas dans la version 4.1 ! Pouvez-vous me donner des exemples de logiciels qui font ça ? Je n'en trouve pas...

Vous avez par exemple Figma (logiciel de maquette d'application) en ligne

Et pour la molette latéral ma souris au bureau et chez moi n'ont pas cette fonctionnalité. Merci pour le clique droit je l'utiliserais

[escartefigue]

Bonjour,

Je reproduis ici une proposition faite dans ce sujet :

https://www.developpez.net/forums/d2.../#post11938479

Bonjour Paprick

il me vient une suggestion pour une prochaine version de Looping : ajouter la possibilité de modifier la couleur de tel ou tel lien (au moyen d'un clic droit et d'une fenêtre contextuelle par exemple), de sorte à faciliter la lecture du MCD dans les cas tels que celui présenté par François où les connexions se croisent.
On pourrait même étendre cette possibilité à tous les types d'objets

[docdu92]

Petit pb que j'ose à peine signaler tant est fabuleux votre logiciel ainsi que la qualité de la communication !
Un MCD avec un item d'une entité type coportant DEFAULT ... et la case NOT NULL cochée
produit un MPD avec NOT NULL précédant DEFAULT ...
Avec Firebird et Flamerobin une erreur est générée.
Pour contourner je mentionne, en finale, NOT NULL dans la zone en prose sans utiliser la case NOT NULL.
Qu'en pensez vous ?

[Paprick]

Bonsoir,
C'est effectivement étrange car tous les SGBD que j'ai testés acceptent le NOT NULL avant le DEFAULT...
Mais vous avez bien réagi, et votre solution est tout à fait valable !

[docdu92]

Bonjour à tous
Le paramétrage [FK]_[classe]
conduit parfois à des libellés très longs ...
car classe comporte le libelle du "champ" _ et le titre de l'entité type
Vous parait-il opportun de proposer [FK]_[le libelle] car le libellé lorsqu'il est unique dans la base peut suffire ?
Si oui de même pour [classe]_[FK].
Si je peux me permettre ... merci, à votre prochaine version tant attendue !!

[Paprick]

Bonjour,

Bonjour à tous
Le paramétrage [FK]_[classe]
conduit parfois à des libellés très longs ...
car classe comporte le libelle du "champ" _ et le titre de l'entité type
Vous parait-il opportun de proposer [FK]_[le libelle] car le libellé lorsqu'il est unique dans la base peut suffire ?
Si oui de même pour [classe]_[FK].
Si je peux me permettre ... merci, à votre prochaine version tant attendue !!

J'avoue ne pas bien comprendre cette demande ... En effet, [Classe] ne comporte pas le libellé du champ, seulement le nom de la classe d'entités...
Merci de proposer un exemple concret avec le résultat produit par Looping, et ensuite le résultat souhaité.

[docdu92]

Bonjour,


J'avoue ne pas bien comprendre cette demande ... En effet, [Classe] ne comporte pas le libellé du champ, seulement le nom de la classe d'entités...
Merci de proposer un exemple concret avec le résultat produit par Looping, et ensuite le résultat souhaité.

Voici ce que j'ai obtenu en s'inspirant de "outils pour la gestion d'un restaurant" dans Publié (www.developpez.net) le 9 août 2013 - Mis à jour le 4 juin 2016.
C'est en pièce jointe utilisée avec wine & Ubuntu 22.04.
Dans la sortie SQL, me trompant et m'en rendant compte en lisant votre réponse, j’escomptai trouver un nom de clef étrangère FK_FAC_ID ou FK_FAC_ID_TE_FACTURE_FAC ...
Or [FK] produit FAC_ID ce qui est presque ce que je souhaitait.
Maintenant j'ai retrouvé FK_FAC_ID produit par clic sur la patte de l'association du côté de l'entité type origine Cardinalité / Rôle / Libellé (FK_FAC_ID) / Renommer clef étrangère coché.
La vue MDL est plus "immédiate" que la sortie SQL !
Merci (de bien vouloir m'excuser et) de m'avoir remis sur le bon chemin.

[Paprick]

Or [FK] produit FAC_ID ce qui est presque ce que je souhaitait.
Maintenant j'ai retrouvé FK_FAC_ID produit par clic sur la patte de l'association du côté de l'entité type origine Cardinalité / Rôle / Libellé (FK_FAC_ID) / Renommer clef étrangère coché.

Une solution simple pour arriver au résultat que vous souhaitez est d'indiquer dans la propriété "Nom clé étrangère" : FK_[FK]

[ced]

Bonjour,

Une petite correction à apporter au code SQL généré sur les commentaires de tables ou de colonne (je n'ai testé que pour les tables) : si le commentaire contient une apostrophe, il faudrait doubler cette apostrophe dans le script généré.
Par exemple, actuellement on a la commande suivante générée automatiquement au niveau du SQL :

Code sql :

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

COMMENT ON TABLE MA_TABLE IS 'Exemple d'apostrophe';

Qui provoque une erreur à l'exécution...
Il faudrait alors corriger par :

Code sql :

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

COMMENT ON TABLE MA_TABLE IS 'Exemple d''apostrophe';

Merci d'avance
ced

PS : une idée de la date de publication de la v4.1 ?

[DontShootMe]

Ayant posté au mauvais endroit ===> ici <=== je recopie mon message au bon endroit


Bonjour,

je m'adresse particulièrement à Paprick.

Avant toute chose : MERCI !
Vraiment Merci beaucoup pour votre œuvre.

Je lis beaucoup sans me connecter, mais aujourd'hui, ne serait ce que pour vous remercier je le fais.
Je sais que développer un logiciel demande beaucoup de temps, et que les détails sont souvent les choses qui font la différence.
Aussi j'aimerais vous soumettre une idée concernant looping.

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.

Code :

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
19
20
21
22
23
24
25
26
Entité
            [ préfixe ] [ nom conceptuel                          ] [ suffixe  ]
            [ CLI_    ] [ client                                  ] [          ]
                        
                        [ préfixe ] [ nom logique                    ] [ suffixe  ]
                        [  cli_   ] [ te_client_cli                  ] [          ]


Rubriques
Id
Nom Conceptuel
Nom Logique
Type

 1
 [ CLI_ ][ ID ][ ] CLI_ID
 [ cli_ ][ id ][ ] cli_id
 INTEGER

 -
 [ CLI_ ][ ENSEIGNE ][ ] CLI_ENSEIGNE
 [ cli_ ][ enseigne ][ ] cli_enseigne
 TEXT

Ceci permettra de revenir parfois sur les changements de préfixe / suffixe, en les changeant une seule fois au niveau de l'entité sans avoir à revenir sur chaque rubrique !


Par avance merci.
Bien entendu, s'il vous plaît, continuez !

[Paprick]

Bonjour,

Merci de votre intérêt pour Looping.
Votre proposition est intéressante et adaptée pour ceux qui adoptent une méthode de nommage de rubriques basée sur un préfixe qui rappelle le nom de la classe d'entités... et surtout qui en changent fréquemment.
Je trouve cependant que, pour quelques utilisateurs et pour un usage assez occasionnel, cela alourdirait trop l'interface que j'ai voulu la plus simple possible.
Et puis, tout cela peut être fait manuellement, même si ça prend un peu de temps... mais pas souvent !
Je garde quand même l'idée en tête.

Bonne continuation !

[DontShootMe]

Bonjour,

Merci pour votre réponse.
Cependant je me permet de vous présenter d'autres arguments.

Votre proposition est intéressante et adaptée pour ceux qui adoptent une méthode de nommage de rubriques basée sur un préfixe qui rappelle le nom de la classe d'entités... et surtout qui en changent fréquemment.

Il ne s'agit de changement fréquent ou pas, mais plutôt d'avoir une idée très clair dés le départ du but à atteindre, ce qui pour moi, est très difficile et cela justifie / motive l'utilisation de Looping.
Lors de la phase de création il n'est pas évident de tout prévoir, et parfois une table / entité nommée X sera changée en Y puis en Z dans le but d'affiner / ajuster la sémantique.

De plus beaucoup de table/entité de référence sont construite de la même manière, et fort heureusement Looping permet le copier - coller d'une classe d'entité.
Il faut alors changer chaque rubrique de la nouvelle classe d'entité, alors qu'avec les préfixes / suffixes ce travail sera beaucoup plus rapide et moins fastidieux grâce à cet accélérateur" !

cela alourdirait trop l'interface que j'ai voulu la plus simple possible.

C'est une chose que je comprend !
Cela pourrait être caché derrière une option / paramètre à activer ?

Ou bien une fonctionnalité cachée =>

Code :

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

1
2
3
4
Nom conceptuel : [   (PREF_)TABLE(_SUFF)                                       ]
Nom Logique : [    (pref_)te_tablename_pref(_suff)                       ]
- tous ce qui précède le nom  et est entre parenthèse ( ou autre signe quelconque )  serait le préfixe
- tous ce qui suit le nom et est entre parenthèse ( ou autre signe quelconque ) serait le suffixe

De cette façon l'interface n'en serait pas changée / alourdie.

Je n'insiste pas plus, qu'elle que soit votre décision j'en serait satisfait.
Encore une fois je vous remercie pour tout le travail accompli, et celui qui vient.

Bonne continuation.