Discussion :

[Paprick]

Bonsoir Capitaine !

Je reviens vers toi pour une petite précision concernant l'exemple de modèle que tu as envoyé.
Au-delà du plantage que tu as eu, j'ai l'impression que tu as cherché à créer une contrainte inter-association d'inclusion...

J'ai essayé de reproduire la situation avec le MCD ci-dessous (la flèche sous la CIF utilisée à tort en lieu et place d'un lien)

Pour moi, l'outil "CIF" n'est pas le bon pour traiter cette modélisation : il te faut plutôt prendre l'outil "Contrainte" pour obtenir le résultat suivant :

Qu'en penses-tu ?

[fsmrel]

Bonjour,

Pour moi, l'outil "CIF" n'est pas le bon pour traiter cette modélisation : il te faut plutôt prendre l'outil "Contrainte"

Je dirai même plus, il faut utiliser l’outil précisé par Paprick, mais en notant bien que Looping ne traduit pas la contrainte d’inclusion en SQL, donc qu’il faut reprendre le code SQL à la main, comme cela fut fait dans le post #69.


Comme dit Paprick (post #70) :

la traduction correcte et automatique de tous les cas de contraintes d'inclusion, et autres contraintes inter-associations, parait complexe...

Comme je l’ai évoqué dans le post #76, à l’aune de la norme SQL, grâce à l’instruction "CREATE ASSERTION", la tâche n’est pas insurmontable, mais le résultat reste lourd et moins performant qu’avec la reprise à la main (cf. post #69). De toute façon les SGBD renâclent à mettre en oeuvre les assertions, en conséquence de quoi il faudrait que Looping s’embarque vers la génération des triggers pour "INSERT" et "UPDATE", mais là, d’un SGBD à l’autre, les triggers se ressemblent comme moi je ressemble à une danseuse étoile... La génération des triggers par l’AGL c’est Babel ! Comme dit Paprick (post #77) : illusoire...

 

[fsmrel]

Salve Paprick,


A propos de l’orthogonalité (indépendance).

Looping fait le choix (non négociable !) de reprendre, pour les clés étrangères, le même nom que la clé primaire (éventuellement préfixé).

=> Bye bye donc l’orthogonalité...

Pour reprendre l’exemple (1 à plusieurs) :

[E1{e1Id}]------1,1------(R)------0,N------[E2{e2Id}]
               Enfant            Parent

Où le nom du rôle (à gauche) est "Enfant" et le nom voulu pour la contrainte est "E1_E2_FK" :

Le nom de la contrainte de clé primaire de la table E1 généré par Looping est "E1_PK", so far, so good.

Mais en l’absence du cartouche "Nom de contrainte", je suis forcé :

(1) Dans le cartouche "Rôle", de remplacer "Enfant" par "E1_E2_FK" (et tant qu’à faire décocher "Afficher dans le modèle" qui ne joue plus son rôle).

(2) De supprimer le rôle "Parent".

=> Perte sémantique sèche quant aux rôles.


Pour passer à l’exemple (plusieurs à plusieurs) :

[E1{e1Id}]------0,N------(R)------0,N------[E2{e2Id}]
               Enfant            Parent

Cette fois-ci, côté orthogonalité c’est la cata, en effet je dois carrément virer les rôles, puisque Looping s’en sert pour suffixer les noms des colonnes de la table R...

Par ailleurs, une fois virés les rôles, les noms des clés étrangères générées sont "E1_R_FK" et "E2_R_FK" (référencé vers référençant). Pas de chance pour moi, car mes requêtes actuelles d’exploration des catalogues relationnels (mon côté DBA) sont plutôt du genre "R_E1_FK" et "R_E2_FK" (référençant vers référencé) : autrement dit, c’est le code SQL produit par Looping que je modifierai…


 

[Paprick]

Avé François,

Mais en l’absence du cartouche "Nom de contrainte", je suis forcé :

(1) Dans le cartouche "Rôle", de remplacer "Enfant" par "E1_E2_FK" (et tant qu’à faire décocher "Afficher dans le modèle" qui ne joue plus son rôle).
(2) De supprimer le rôle "Parent".

=> Perte sémantique sèche quant aux rôles.

As-tu pris en compte, dans ton raisonnement, la solution que je propose pour la prochaine version de Looping et expliquée dans mon précédent post ?
En effet, si tu précises les rôles pour préserver la sémantique dans le MCD, et que tu décoches la future case "Suffixer la clé étrangère", il me semble que tu obtiens le résultat que tu souhaites, à savoir affichage des rôles dans le MCD et Nom de la contrainte = "E2_E1_FK"

Pour passer à l’exemple (plusieurs à plusieurs) :
Cette fois-ci, côté orthogonalité c’est la cata, en effet je dois carrément virer les rôles, puisque Looping s’en sert pour suffixer les noms des colonnes de la table R...

Même chose, en cochant "Afficher dans le MCD" et en décochant "Suffixer la clé étrangère", le MCD est OK et les noms des rôles sont ignorés au niveau logique ; les noms des contraintes sont alors les suivants : "E1_R_FK" et "E2_R_FK".
Par contre, attention : en cas d'association réflexive, il faudra bien distinguer les deux noms de contraintes... Et là, rajouter les rôles en suffixe parait une bonne solution.

Pas de chance pour moi, car mes requêtes actuelles d’exploration des catalogues relationnels (mon côté DBA) sont plutôt du genre "R_E1_FK" et "R_E2_FK" (référençant vers référencé) : autrement dit, c’est le code SQL produit par Looping que je modifierai…

La question est donc "référençant_référencé" ou "référencé_référençant" (avec FK préfixé ou suffixé) ?
Personnellement, je reste ouvert sur ce point : François, si tu es absolument sûr que ton ordre est préférable, je suis prêt à inverser

[fsmrel]

Bonsoir Paprick,

Personnellement, je reste ouvert sur ce point : François, si tu es absolument sûr que ton ordre est préférable, je suis prêt à inverser

D'accord pour inverser. Disons que pour une table T, il est préférable (comme disent les Dupondt, c’est mon opinion et je la partage ) que les noms des contraintes : clés primaires, alternatives, étrangères, et autres contraintes (CHECK), soient nommées de façon homogène "T_suffixe_ad-hoc".

Pour reprendre à nouveau l’exemple (1 à plusieurs) :

[E1{e1Id}]------1,1------(R)------0,N------[E2{e2Id}]
               Enfant            Parent

=>

Clé primaire : "E1_PK"

Clé étrangère : "E1_E2_FK" (et non pas "E2_E1_FK")

Clé alternatives : "E1_AK_i"

Contraintes diverses : "E1_CHK_i" (pour complétude, sachant que Looping n’est en l’occurrence pas concerné).

Avec évidemment le cas particulier des clés étrangères en présence de réflexives :

"E1_E1_rôle1_FK", "E1_E1_rôle2_FK"

Comme du reste le fait actuellement Looping.

As-tu pris en compte, dans ton raisonnement, la solution que je propose pour la prochaine version de Looping et expliquée dans mon précédent post ?
En effet, si tu précises les rôles pour préserver la sémantique dans le MCD, et que tu décoches la future case "Suffixer la clé étrangère", il me semble que tu obtiens le résultat que tu souhaites, à savoir affichage des rôles dans le MCD et Nom de la contrainte = "E2_E1_FK"

Je suppose que tu fais référence à ceci (post #89) :

je ne verrais aucun inconvénient (euphémisme...) à la mise en place d’une case à cocher permettant d’éviter le renommage automatique (attributs et contraintes) quand on utilise la visualisation des rôles...

D’où quelque chose comme çà quand on préfère suffixer (et que de mon côté je décocherai sans état d'âme ) ?

Pourrait-on avoir le .exe correspondant pour voir ?

Sur ce, je vais ouvrir mes huîtres et mes praires

 

[Paprick]

Salut François,

Nous voilà parfaitement d'accord !
Je rajoute donc la case à cocher "Suffixer la clé étrangère" et je renomme mes noms de contraintes .

Par ailleurs, afin de prendre en compte certaines demandes suite à la sortie de la version 2.4, et comme la mise en oeuvre du MLD graphique s'avère assez complexe (il faudra donc être un peu patient !), je vais mettre en ligne dans les prochains jours une version 2.5 qui propose sans attendre quelques fonctionnalités supplémentaires :
- Possibilité d'ignorer le nom des rôles au niveau logique et nouvelle définition du nom des contraintes (cf. posts ci-dessus).
- Liste de types libres prédéfinis et modifiables à utiliser avec n'importe quel SGBD.
- Insertion de code SQL en début et en fin de script sans passer par les règles (définition de nouveaux types, de domaines SQL, ...).
- Possibilité d'insérer, au sein du code SQL de génération des tables, les commentaires des classes d'entités, des associations n,n et des rubriques.
- Et pour les fans d'identifiants non significatifs , nouveau "bouton magique" permettant l'ajout automatique, dans les classes d'entités, d'un identifiant "Id_NomClasse" de type entier auto-incrémenté.
Le MLD graphique suivra un peu plus tard : il s'agira alors de la version 3.0 de Looping.

[fsmrel]

Salve Paprick,

Well! J’attends donc de pouvoir secouer la V2.5...

Quant à la v3.0, prends ton temps, on sera patients, pas de problème.

Les huîtres et les praires venaient tout droit de Cancale, extra !

 

[Paprick]

Bonjour à tous,

Afin de prendre en compte certaines demandes suite à la sortie de la version 2.4, et comme la mise en oeuvre du MLD graphique s'avère assez complexe (il faudra donc être un peu patient !), je vais mettre en ligne dans les prochains jours une version 2.5 qui propose sans attendre quelques fonctionnalités supplémentaires :
- Possibilité d'ignorer le nom des rôles au niveau logique et nouvelle définition du nom des contraintes (cf. posts ci-dessus).
- Liste de types libres prédéfinis et modifiables à utiliser avec n'importe quel SGBD.
- Insertion de code SQL en début et en fin de script sans passer par les règles (définition de nouveaux types, de domaines SQL, ...).
- Possibilité d'insérer, au sein du code SQL de génération des tables, les commentaires des classes d'entités, des associations n,n et des rubriques.
- Et pour les fans d'identifiants non significatifs , nouveau "bouton magique" permettant l'ajout automatique, dans les classes d'entités, d'un identifiant "Id_NomClasse" de type entier auto-incrémenté.

Comme promis, voici la version 2.5 de Looping sur https://www.looping-mcd.fr
J'espère qu'elle répondra efficacement à vos attentes.
Prochaine étape : la version 3.0 avec le MLD graphique.

[escartefigue]

Bonjour vaillant professeur

Bonsoir Capitaine !

Je reviens vers toi pour une petite précision concernant l'exemple de modèle que tu as envoyé.
Au-delà du plantage que tu as eu, j'ai l'impression que tu as cherché à créer une contrainte inter-association d'inclusion...

Qu'en penses-tu ?

En effet, ma mésaventure s'est produite après avoir fait plusieurs allers-retours entre les deux icônes CIF et contrainte d'une part et lien et connecteurs d'autre part
C'est parce que je n'arrivai pas à établir les liens que j'ai pensé, à tort, avoir utilisé la mauvaise icône de contrainte
En résumé : contrarié par ma contrainte j'en fus contrit


Bonjour François

Bonjour,

Je dirai même plus, il faut utiliser l’outil précisé par Paprick, mais en notant bien que Looping ne traduit pas la contrainte d’inclusion en SQL, donc qu’il faut reprendre le code SQL à la main, comme cela fut fait dans le post #69.

j'en prends bonne note

[...] en conséquence de quoi il faudrait que Looping s’embarque vers la génération des triggers pour "INSERT" et "UPDATE", mais là, d’un SGBD à l’autre, les triggers se ressemblent comme moi je ressemble à une danseuse étoile... La génération des triggers par l’AGL c’est Babel ! Comme dit Paprick (post #77)

Et oui, des TRIGGERS, pas d'autre astuce hélas, c'est là qu'est l'os !

[escartefigue]

Bonjour à tous,


Comme promis, voici la version 2.5 de Looping sur https://www.looping-mcd.fr
J'espère qu'elle répondra efficacement à vos attentes.
Prochaine étape : la version 3.0 avec le MLD graphique.

Merci Paprick pour tout ce travail !
Je n'avais pas vu le petit bouton magique, excellente idée

[fsmrel]

Bonsoir à tous,


Paprick, merci pour cette chouette V2.5 !

Les noms des contraintes des clés primaires et étrangères (utilisation des suffixes) me conviennent parfaitement.
A Philippe et au Capitaine de voir ce qu’il en est de leur côté…


A propos de la fenêtre « Rubrique » :
« Autre » est apparu dans la V2.4 (et fort bienvenu !). Il pourrait y être renommé en quelque chose comme « Complément » ou terme équivalent, car le but de la manoeuvre est quand même bien de pouvoir compléter soi-même le paramétrage SQL de la colonne issue de la rubrique, par exemple en fonction du SGBD, sans importuner Looping.


Un ajout qui serait le bienvenu :

En effet, actuellement "rôle x" suffixe de facto le(s) attribut(s) de la clé primaire de la table issue du sous-type partie prenante, mais comme dans le cas de la fenêtre « Cardinalité », le suffixe affiché et le suffixe des attributs des tables SQL sont indépendants.

 

[Paprick]

Bonsoir François,

A propos de la fenêtre « Rubrique » :
« Autre » est apparu dans la V2.4 (et fort bienvenu !). Il pourrait y être renommé en quelque chose comme « Complément » ou terme équivalent, car le but de la manœuvre est quand même bien de pouvoir compléter soi-même le paramétrage SQL de la colonne issue de la rubrique, par exemple en fonction du SGBD, sans importuner Looping.

Remarque sémantique tout à fait justifiée : ce sera pris en compte dès la prochaine release.

En effet, actuellement "rôle x" suffixe de facto le(s) attribut(s) de la clé primaire de la table issue du sous-type partie prenante, mais comme dans le cas de la fenêtre « Cardinalité », le suffixe affiché et le suffixe des attributs des tables SQL sont indépendants.

Ce sont effectivement des options que nous avons négociées de haute lutte pour les rôles dans les associations : et comme nous n'allons pas en priver l'héritage, c'est également noté pour la prochaine release !

[escartefigue]

Bonjour,

Je me demande aussi s'il ne serait pas judicieux, dans le cas du choix du SGBD DB2, de proposer par défaut pour les colonnes de type "counter", l'option "GENERATED BY DEFAULT" plutôt que "GENERATED ALWAYS".
"GENERATED BY DEFAULT" permet comme son nom l'indique de conserver la valeur si fournie, c'est pratique pour recopier des données d'une database vers une autre.

Qu'en pense François qui connait bien DB2 ?

[fsmrel]

Buenos dias, amigos,

Je me demande aussi s'il ne serait pas judicieux, dans le cas du choix du SGBD DB2, de proposer par défaut pour les colonnes de type "counter", l'option "GENERATED BY DEFAULT" plutôt que "GENERATED ALWAYS".
"GENERATED BY DEFAULT" permet comme son nom l'indique de conserver la valeur si fournie, c'est pratique pour recopier des données d'une database vers une autre.

Qu'en pense François qui connait bien DB2 ?

J’ai beaucoup connu DB2 du temps où je sévissais, mais en tout cas sans utiliser "IDENTITY" (qui n’est arrivé qu’avec le millénaire). Cela dit, je reconnais que "GENERATED BY DEFAULT" aurait eu ma préférence. Que Paprick t’entende !

[escartefigue]

Nous sommes d'accord qu'il s'agit toutefois d'un point de détail sans la moindre urgence

[Paprick]

J’ai beaucoup connu DB2 du temps où je sévissais, mais en tout cas sans utiliser "IDENTITY" (qui n’est arrivé qu’avec le millénaire). Cela dit, je reconnais que "GENERATED BY DEFAULT" aurait eu ma préférence. Que Paprick t’entende !

Je vous entends, oh, éminents experts !
La modification sera donc faite à la prochaine release !

[fsmrel]

Bonsoir Paprick,

Je vous entends, oh, éminents experts !
La modification sera donc faite à la prochaine release !

Merci Paprick !

Ce sont effectivement des options que nous avons négociées de haute lutte pour les rôles dans les associations : et comme nous n'allons pas en priver l'héritage, c'est également noté pour la prochaine release !

Il est vrai que les négociations furent âpres, et j’en reviens à l’ « indémont[r]abilité » . Retour sur ce que j’ai écrit au sujet de la fenêtre « Rubrique » :

« Autre » est apparu dans la V2.4 (et fort bienvenu !). Il pourrait y être renommé en quelque chose comme « Complément » ou terme équivalent, car le but de la manoeuvre est quand même bien de pouvoir compléter soi-même le paramétrage SQL de la colonne issue de la rubrique, par exemple en fonction du SGBD, sans importuner Looping.

Et prenons le cas de l’attribut A de l’entité-type X, pour lequel AUTRE vaut params a, b, c. Par ailleurs cet attribut fait partie de l’identifiant de X. Au stade SQL, est-il raisonnable que la valeur de AUTRE soit héritée par l’attribut A appartenant à la clé étrangère F qui dans la table Y fait référence à X ?

Prenons l’exemple de la spécialisation avec AUTRE = 'DEFAULT 1'. Au stade SQL :

CREATE TABLE X
(
    xId   INT    DEFAULT 1, 
   CONSTRAINT X_PK PRIMARY KEY(xId)
); 

CREATE TABLE Y
(
    xId   INT    DEFAULT 1, 
   CONSTRAINT Y_PK PRIMARY KEY(xId),
   CONSTRAINT Y_FK FOREIGN KEY(xId) REFERENCES X(xId)
); 

Je trouve que 'DEFAULT 1' a tout d’une incongruité dans le cas de l’attribut xId de la table Y et mérite le passage au rasoir d’Ockham...

Qui plus est, dans le cas général, chaque éditeur de SGBD s’ingénie à nous bombarder de paramètres propres à flanquer mal à la tête ! Exemple de DB2 (ça parlera au Capitaine...) :

Avec DB2 je pourrais ne pas utiliser AUTRE et en passer par un ALTER TABLE pour définir la valeur par défaut, mais alors à quoi AUTRE servirait-il ? Pour ACCESS, AUTRE admet-il d’autres paramètres que DEFAULT ?

Je verrais bien une petite case à cocher accompagnant AUTRE, pour permettre ou non la propagation des paramètres des colonnes d’une table à d’autres.


Je suis en train d’investiguer du côté des clés alternatives multi-colonnes…

E2 est une entité-type de clé primaire {e2aId, e2bId}.
L’entité-type E21 est associée à E2 de la façon suivante :

Code SQL généré par Looping pour la table E21 :

CREATE TABLE E21
(
   e21Id         INT                  NOT NULL,
   e21Code       VARCHAR(8)  UNIQUE   NOT NULL,
   e2aId         INT                  NOT NULL,
   e2bId         INT                  NOT NULL,
   CONSTRAINT E21_PK PRIMARY KEY(e21Id),
   CONSTRAINT E21_E2_FK FOREIGN KEY(e2aId, e2bId) REFERENCES E2(e2aId, e2bId)
);

Concernant la table E21, prévois-tu la déclaration de la clé alternative {e2aId, e2bId} ? Actuellement, que la cardinalité portée par la patte connectant E2 et R soit 0,1 ou 0,N, le code SQL pour E21 est exactement le même...

 

[Paprick]

Bonsoir François,

Je verrais bien une petite case à cocher accompagnant AUTRE, pour permettre ou non la propagation des paramètres des colonnes d’une table à d’autres.

Comme souvent, tout à fait d'accord avec ta proposition ; par contre, cette case à cocher ne doit apparaître que s'il s'agit d'un identifiant. Et je pense qu'elle doit être décochée par défaut car les cas où ce "Complément" doit se propager me paraissent assez limités... d'ailleurs en existe-t-il vraiment ? As-tu des exemples ? dans le cas contraire, le complément devrait toujours rester sagement à la maison...
Et pour les types avec des paramètres loufoques, il y a toujours les "Types libres" qui peuvent maintenant être prédéfinis.

Concernant la table E21, prévois-tu la déclaration de la clé alternative {e2aId, e2bId} ? Actuellement, que la cardinalité portée par la patte connectant E2 et R soit 0,1 ou 0,N, le code SQL pour E21 est exactement le même...

Dans le cas d'une association 1,1/0,1 Looping privilégie le lien le plus simple en prenant dans E21 la clé étrangère issue de E2... ce qui donne effectivement le même résultat que pour une association 1,1/0,N.
Pour obtenir la clé {e2aId, e2bId}, il suffit d'indiquer l'identification relative sur le lien 1,1 et de retirer la clé primaire {e21Id} (ou de la laisser en clé alternative avec UNIQUE).
Comme tu le sais, Looping impose de choisir une clé primaire parmi les différentes clés candidates ; les autres clés alternatives peuvent être précisées avec UNIQUE si elles sont simples, ou par le biais d'une règle avec code SQL si elles sont composées.

[Paprick]

Après réflexion, je comprends mieux ta demande concernant la clé alternative...
En fait, en cas de 1,1/0,1, la clé étrangère issue de E2 doit effectivement être déclarée unique.
Pour les clés simples, pas de problème : il suffirait de rajouter UNIQUE derrière la rubrique.
Mais, en cas de clé composée, comme dans ton exemple, on est bon pour rajouter une contrainte du type : UNIQUE(e2aId, e2bId) ou CONSTRAINT E21_AK UNIQUE(e2aId, e2bId)
Ça te parait correct ?

[fsmrel]

Ave Paprick,

Comme souvent, tout à fait d'accord avec ta proposition ; par contre, cette case à cocher ne doit apparaître que s'il s'agit d'un identifiant.

Certes, la case à cocher ne doit apparaître que s'il s'agit d'un identifiant, puisque les effets secondaires sont uniquement les conséquences de la propagation. On peut aussi éviter systématiquement et « sagement » cette propagation, auquel cas la case à cocher n'a pas lieu d’être.

En fait, en cas de 1,1/0,1, la clé étrangère issue de E2 doit effectivement être déclarée unique.
Pour les clés simples, pas de problème : il suffirait de rajouter UNIQUE derrière la rubrique.
Mais, en cas de clé composée, comme dans ton exemple, on est bon pour rajouter une contrainte du type : UNIQUE(e2aId, e2bId) ou CONSTRAINT E21_AK UNIQUE(e2aId, e2bId)
Ça te parait correct ?

Ça me paraît parfaitement correct.
Maintenant, tu sais que "CONSTRAINT E21_AK UNIQUE(e2aId, e2bId)" aura toujours ma préférence ne serait-ce qu’en tant que DBA surveillant en permanence le comportement du SGBD, par exemple :

SELECT * FROM SYSIBM.SYSCONSTDEP WHERE DCONSTNAME LIKE 'E21%' ;