Looping version 4.1 disponible (avec Rétroconception)

**escartefigue** · 17/03/2025, 12h03

Envoyé par Paprick

Le fait que la contrainte génère une réflexive me parait normal (clé étrangère faisant référence à sa propre table) ; tu aurais d'ailleurs pu modéliser la contrainte avec cette réflexive.

Certes, mais on y perd en lisibilité, c'est facheux

Envoyé par Paprick

Par contre la disparition de E3seq est plutôt bizarre...

Probablement une conséquence de l'identification relative.

Envoyé par Paprick

Pour l'ordre des colonnes, vu que la génération initiale (avec superposition) est correcte, je pense que tu les as déplacées pendant que tu remettez de l'ordre dans le modèle

.

Bon sang, mais c'est bien sûr !
J'ai vérifié et tu as raison, désolé, j'ai du glisser par mégarde un attribut, ça m'arrive parfois en voulant déplacer un objet de cliquer légèrement à coté, et voilà ce que ça produit

Il reste aussi le redimensionnement de la fenêtre "rétro conception" (si possible, pour le confort sur petit écran)

**Paprick** · 17/03/2025, 12h17

Envoyé par escartefigue

Il reste aussi le redimensionnement de la fenêtre "rétro conception" (si possible, pour le confort sur petit écran)

Trop grande ? Trop petite ?
Pour une taille variable, c'est plus compliqué...

**Paprick** · 17/03/2025, 12h25

Envoyé par escartefigue

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

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.

**escartefigue** · 17/03/2025, 13h45

Envoyé par Paprick

Trop grande ? Trop petite ?
Pour une taille variable, c'est plus compliqué...

Idéalement, une taille variable, à défaut, un poil plus petit pour qu'on puisse activer les boutons en bas de la fenêtre tout en conservant le haut de la fenêtre.
Sur le portable 13'', je n'arrivais pas à activer les boutons.

Envoyé par Paprick

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).

En fait, je cherchais à centrer sur l'objet sélectionné, "ajuster à la fenêtre" permet de visualiser tout dans une seule fenêtre, mais sans centrer sur la sélection

Envoyé par Paprick

N'oublie pas aussi que, en laissant le bouton droit de la souris enfoncé, tu peux bouger tout le modèle très facilement.

Ça me va bien, par contre, la roulette, je n'arrive toujours pas à m'y faire

**tatayo** · 17/03/2025, 14h31

Paprick: j'ai honte

, je n'avais pas vu l'option en question...
Ça fonctionne parfaitement.

Merci.

Tatayo.

**fsmrel** · 17/03/2025, 19h11

Rétroconception : compaison du comportement de 3 systèmes.

Soit le MCD suivant(créé avec PowerAMC), où Chauffeur « hérite » de Employe (spécialisation) :

Le code SQL source, produit par PowerAMC :

Code SQL :

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
CREATE TABLE Employe 
(
      EmployeId                INT                      NOT NULL,
      Matricule                CHAR(8)                  NOT NULL,
      EmployeNom               VARCHAR(24)              NOT NULL,
      EmployePrenom            VARCHAR(24)              NOT NULL,
   CONSTRAINT EMPLOYE_PK PRIMARY KEY (EmployeId),
   CONSTRAINT EMPLOYE_AK UNIQUE (Matricule)
) ;
CREATE TABLE Chauffeur 
(
      EmployeId                INT                      NOT NULL,
      permis                   VARCHAR(24)              NOT NULL,
   CONSTRAINT CHAUFFEUR_PK PRIMARY KEY (EmployeId)
) ;
alter table Chauffeur
   add constraint CHAUFFEUR_EMPLOYE_FK foreign key (EmployeId)
      references Employe (EmployeId)

Message d’erreur lors de la rétroconception avec Looping :

« point-virgule manquant à la fin de ALTER TABLE Chauffeur »

Une fois ajouté le point-virgule, c’est ok !

Rétroconception avec PowerAMC (même code SQL), ça n’est pas top (le coup du 0,n)...

Avec MySQL Workbench, ça n’est pas top non plus... :

Voilà, voilà... and the winner is...

**Paprick** · 17/03/2025, 19h54

Envoyé par fsmrel

Rétroconception : comparaison du comportement de 3 systèmes.
Soit le MCD suivant(créé avec PowerAMC), où Chauffeur « hérite » de Employe (spécialisation) :

C'est quand même un comble que des outils comme PowerAMC ou MySQL Workbench génèrent un truc faux

... avec une table Chauffeur qui se retrouve avec un identifiant relatif qui ne garantie pas l'unicité...

[/QUOTE]

**escartefigue** · 18/03/2025, 08h09

Pour autant que je me souvienne, dans Power AMC, l'identification relative est symbolisée par les parenthèses autour des cardinalités sans le R
Le MCD Power AMC est donc correct coté [Chauffeur], par contre l'employé ayant plusieurs permis n'est pas conforme au modèle initial. Etonnant pour un produit payant et largement répandu en entreprise

Quant à workbench, c'est un argument de plus pour ne pas modéliser avec cet outil (à moins d'accepter de guillotiner les employés ayant perdu leur permis

)

**Paprick** · 18/03/2025, 11h36

Bonjour,

Envoyé par escartefigue

Pour autant que je me souvienne, dans Power AMC, l'identification relative est symbolisée par les parenthèses autour des cardinalités sans le R
Le MCD Power AMC est donc correct coté [Chauffeur], par contre l'employé ayant plusieurs permis n'est pas conforme au modèle initial. Etonnant pour un produit payant et largement répandu en entreprise

Quant à workbench, c'est un argument de plus pour ne pas modéliser avec cet outil (à moins d'accepter de guillotiner les employés ayant perdu leur permis

)

En effet, le (1,1) indique également l'identification relative : d'ailleurs, Looping propose aussi cette notation en option :
Nom : Héritage.jpg
Affichages : 326
Taille : 70,7 Ko

Nom : Héritage.jpg
Affichages : 326
Taille : 70,7 Ko

Le problème se situe bien au niveau de la cardinalité 0,n qui laisse la porte ouverte à la non-unicité de la PK de la table "Chauffeur" !

**Paprick** · 20/03/2025, 01h02

Bonsoir Capitaine,

Le cas de ton ALTER ci-dessous m'a beaucoup préoccupé :

Envoyé par escartefigue

Code SQL :

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

1
2
3
4
5
--la personne qui annule DOIT ETRE celle qui a validé
alter table E3
add constraint E3INC001
foreign key (E1ident_annul, E3seq)
references E3 (E1ident_valid, E3seq)

Et je me suis rendu compte que, en provoquant une nouvelle utilisation de E1ident_annul en tant que clé étrangère, on arrive à une situation qui n'a pas d'équivalent au niveau conceptuel.
Cette clé étrangère avec ce même nom n'est donc pas modélisable : Looping ne peut donc pas générer le MCD correspondant

...

Par contre, Looping ne devrait pas trafiquer pour générer un truc bizarre, mais plutôt indiquer l'impossibilité de traiter l'instruction : c'est en ce sens que je vais faire évoluer la rétroconception pour un meilleur contrôle de ce type d'instruction.

**escartefigue** · 20/03/2025, 09h37

Avec le même nom ? D'un coté c'est l'identifiant d'annulation E1ident_annul et de l'autre l'identifiant de validation E1ident_valid.
Cette contrainte d'inclusion me semble tout à fait classique : seule la personne qui a validé peut annuler.

Par contre, là où il y a coquille, c'est au niveau cardinalité, il devrait y avoir 0,1 et non pas 0,n de E1 vers E3 : une annulation ne se fait au plus qu'une seule fois

Mais ça ne change pas la contrainte.

**Paprick** · 20/03/2025, 14h03

Envoyé par escartefigue

Avec le même nom ? D'un coté c'est l'identifiant d'annulation E1ident_annul et de l'autre l'identifiant de validation E1ident_valid.
Cette contrainte d'inclusion me semble tout à fait classique : seule la personne qui a validé peut annuler.
Par contre, là où il y a coquille, c'est au niveau cardinalité, il devrait y avoir 0,1 et non pas 0,n de E1 vers E3 : une annulation ne se fait au plus qu'une seule fois

Mais ça ne change pas la contrainte.

Pour la cardinalité 0,n il y avait bien coquille à cause de l'identifiant relatif

: c'est corrigé !
Concernant la contrainte d'inclusion, elle est effectivement classique mais, comme tu le sais, Looping ne traite pas ces contraintes au niveau du DDL : c'est la raison pour laquelle il faut décrire le code SQL qui va bien.
Et ce code est tellement variable en fonction des contraintes (inclusion, partition, exclusion mutuelle, totalité, ...) et du SGBD qui les met en œuvre, qu'il est illusoire de vouloir tout automatiser.
Certes, le cas que tu proposes est relativement simple, mais en général on doit faire appel à des procédures stockées et autres triggers qui doivent répondre aux caprices du langage associé au SGBD.

Bref, tout ça pour dire que, si Looping ne génère pas seul la contrainte au niveau du DDL, il ne peut bien évidemment pas déduire une contrainte en fonction d'un DDL dans le cadre d'une rétroconception

...
Donc, en résumé, tout ce qui est codé en SQL par le concepteur (contraintes, règles, ...) ne sera pas traité par Looping si cela ne peut pas être modélisé sans le code en question.

**fsmrel** · 20/03/2025, 14h42

Ave,

Envoyé par Paprick

Par contre, Looping ne devrait pas trafiquer pour générer un truc bizarre, mais plutôt indiquer l'impossibilité de traiter l'instruction : c'est en ce sens que je vais faire évoluer la rétroconception pour un meilleur contrôle de ce type d'instruction.

On ne peut pas juger d’un DDL sur la base du nom des attributs ou des clés. Paprick, tu es un sage, mieux vaut prévenir que tenter de guérir, et un homme averti en vaut deux : à celui-ci de prendre ses responsabilités et décider en toute conscience de la modification du MCD obtenu par rétroconception (surrtout à partir d’un DDL SQL Ave,

**escartefigue** · 20/03/2025, 15h01

Envoyé par Paprick

Bref, tout ça pour dire que, si Looping ne génère pas seul la contrainte au niveau du DDL, il ne peut bien évidemment pas déduire une contrainte en fonction d'un DDL dans le cadre d'une rétroconception

...
Donc, en résumé, tout ce qui est codé en SQL par le concepteur (contraintes, règles, ...) ne sera pas traité par Looping si cela ne peut pas être modélisé sans le code en question.

En même temps c'est tout à fait logique, et dans la mesure où Looping fait plutôt mieux - voire beaucoup mieux - que les autres logiciels de modélisation (et pas uniquement sur ce chapitre), je ne saurais lui en tenir rigueur

**Paprick** · 20/03/2025, 19h18

Salut François,

Envoyé par fsmrel

Je reviens sur la façon dont les outils font de la rétroconception (cf. https://www.developpez.net/forums/d2.../#post12075119). A mon sens, WinDesign devrait entrer dans le jeu. L’as-tu en ta possession ? Si oui, peux-tu voir ce qu’il produit avec le bout de code SQL que j’ai proposé ? A défaut, peux-tu demander à ton excellent préfacier de le faire (je serais fort étonné qu’il ne dispose pas de l’outil...)
Si je m’en trouve le courage, j’essaierai de voir ce qu’on peut faire avec DB-MAIN...

Je viens de tester ton cas dans WinDesign et... échec..

:

Nom : Test.jpg
Affichages : 1834
Taille : 17,2 Ko

J'aurais pensé qu'il s'en sorte mieux...

**fsmrel** · 21/03/2025, 17h33

Ave,

J’ai voulu faire le test avec DB-MAIN, mais il me jette (licence périmée). Tant pis.

**fsmrel** · 31/03/2025, 18h57

Rétroconception, suite - cas des courses hippiques (cf. la discussion « Quel logiciel télécharger pour réaliser un MCD », le post #53).

Code SQL proposé ;

Code SQL :

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
27
28
29
30
31
32
33
34
35
36
CREATE TABLE COURSE(
   courseId INTEGER,
   courseNom VARCHAR(48) NOT NULL,
   courseDate DATE NOT NULL,
   PRIMARY KEY(courseId)
);
 
CREATE TABLE CHEVAL(
   chevalId INTEGER,
   chevalNom VARCHAR(48) NOT NULL,
   chevalDateNaissance DATE,
   PRIMARY KEY(chevalId)
);
 
CREATE TABLE JOCKEY(
   jockeyId INTEGER,
   licence CHAR(50),
   jockeyNom VARCHAR(48) NOT NULL,
   jockeyPrenom VARCHAR(48) NOT NULL,
   PRIMARY KEY(jockeyId),
   UNIQUE(licence)
);
 
CREATE TABLE PARTICIPER(
   courseId INTEGER,
   chevalId INTEGER,
   poids NUMERIC(4,2) NOT NULL,
   numero SMALLINT NOT NULL,
   jockeyId INTEGER NOT NULL,
   PRIMARY KEY(courseId, chevalId),
   UNIQUE(courseId, jockeyId),
   UNIQUE(courseId, numero),
   FOREIGN KEY(courseId) REFERENCES COURSE(courseId),
   FOREIGN KEY(chevalId) REFERENCES CHEVAL(chevalId),
   FOREIGN KEY(jockeyId) REFERENCES JOCKEY(jockeyId)
);

MCD produit par Looping :

Code SQL produit par Looping à partir de ce MCD (table PARTICIPER) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE PARTICIPER(
   courseId INT,
   jockeyId INT,
   numero SMALLINT NOT NULL,
   poids DECIMAL(4,2) NOT NULL,
   chevalId INT NOT NULL,
   PRIMARY KEY(courseId, jockeyId),
   UNIQUE(courseId, numero),
   UNIQUE(courseId, chevalId),
   FOREIGN KEY(courseId) REFERENCES COURSE(courseId),
   FOREIGN KEY(jockeyId) REFERENCES JOCKEY(jockeyId),
   FOREIGN KEY(chevalId) REFERENCES CHEVAL(chevalId)
);

C’est tout bon ! (même si Miss PK a cédé sa place à une de ses dauphines...)

Rétroconception avec AMC :

MPD : Muy bien !

MLD : So far, so good !

MCD : Balek !

AMC a choisi la paire {courseId, chevalId} pour être l’ identifiant « primaire » de Participer. Ok.

Je demande la vérification du MCD : y a de l’eau dans le gaz car AMC répond que le MCD est invalide :

=>

Ainsi, l’identifiant alternatif Cle_2 est réduit à {}...

Pour sa part, l’identifiant alternatif Cle_3 est réduit à {numero} ; un seul dossard par participation à une course, c’est plutôt réducteur...

On est donc dans les choux. Histoire de voir comment réagit AMC avec un modèle plus simple, je lui propose le code SQL suivant :

Code SQL :

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
CREATE TABLE COURSE(
   courseId INTEGER,
   courseNom VARCHAR(48) NOT NULL,
   courseDate DATE NOT NULL,
   PRIMARY KEY(courseId)
);
 
CREATE TABLE JOCKEY(
   jockeyId INTEGER,
   licence CHAR(50),
   jockeyNom VARCHAR(48) NOT NULL,
   jockeyPrenom VARCHAR(48) NOT NULL,
   PRIMARY KEY(jockeyId),
   UNIQUE(licence)
);
 
CREATE TABLE PARTICIPER(
   courseId INTEGER,
   poids NUMERIC(4,2) NOT NULL,
   numero SMALLINT NOT NULL,
   jockeyId INTEGER NOT NULL,
   PRIMARY KEY(courseId, numero),
   UNIQUE(courseId, jockeyId),
   FOREIGN KEY(courseId) REFERENCES COURSE(courseId),
   FOREIGN KEY(jockeyId) REFERENCES JOCKEY(jockeyId)
);

AMC produit le MPD suivant :

Puis le MLD :

Jusque-là, tout va bien. Le MCD produit par AMC :

L’affaire se corse (chef-lieu Ajaccio). En effet, je demande la vérification du MCD et AMC répond qu’il y a de l’erreur :

De fait, l’identifiant alternatif Cle_1 ne contient aucun attribut, puisque les attributs courseId et jockeyId n’ont aucune raison d’être présents dans l’entité-type PARTICIPER.

Conclusion :

Pour faire de la rétroconception, je confirme, utilisons Looping !

**fsmrel** · 01/04/2025, 19h33

Ave !

Encore à propos de la rétroconception, un bémol

@paprick,

Je prends l’exemple que tu proposes dans la discussion « About Inclusion Constraints », post #40.

Le MCD proposé :

Le LDD inféré :

Code SQL :

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
CREATE TABLE Enseignant(
   Matricule INTEGER,
   Nom VARCHAR(50),
   Prenom VARCHAR(50),
   CONSTRAINT PK_Enseignant PRIMARY KEY(Matricule)
);
CREATE TABLE Matiere(
   CodeMatiere INTEGER,
   Libelle VARCHAR(50),
   Description TEXT,
   CONSTRAINT PK_Matiere PRIMARY KEY(CodeMatiere)
);
CREATE TABLE Maitriser(
   CodeMatiere INTEGER,
   Matricule INTEGER,
   CONSTRAINT PK_Maitriser PRIMARY KEY(Matricule, CodeMatiere),
   CONSTRAINT FK_Maitriser_Enseignant FOREIGN KEY(Matricule) REFERENCES Enseignant(Matricule),
   CONSTRAINT FK_Maitriser_Matiere FOREIGN KEY(CodeMatiere) REFERENCES Matiere(CodeMatiere)
);
CREATE TABLE Enseigner(
   CodeMatiere INTEGER,
   Matricule INTEGER,
   CONSTRAINT PK_Enseigner PRIMARY KEY(Matricule, CodeMatiere),
   CONSTRAINT FK_Enseigner_Maitriser FOREIGN KEY(Matricule, CodeMatiere) REFERENCES Maitriser(Matricule, CodeMatiere)
);

A partir de ce code SQL, j’effectue la rétroconception et obtiens le MCD :

La cardinalité 0,1 connectant Enseignant et Asso_1 devrait être 0,n.
De même, la cardinalité 0,1 connectant Matiere et Asso_2 devrait elle aussi être 0,n.

Le LDD produit à partir de ce dernier MCD, concernant la table Maitriser :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
 
CREATE TABLE Maitriser(
   CodeMatiere INT,
   Matricule INT,
   PRIMARY KEY(CodeMatiere, Matricule),
   UNIQUE(CodeMatiere),
   UNIQUE(Matricule),
   FOREIGN KEY(CodeMatiere) REFERENCES Matiere(CodeMatiere),
   FOREIGN KEY(Matricule) REFERENCES Enseignant(Matricule)
) ;

La clé primaire {CodeMatiere, Matricule} est la bonne, mais les clés alternatives {CodeMatiere} et {Matricule} jouent les trouble-fête ! J’essaie d’imaginer pourquoi il pourrait y avoir les dépendances fonctionnelles :

CodeMatiere → Matricule et Matricule → CodeMatiere

Mais je reste coi...

A noter que la clé primaire de la table Enseigner est la bonne.

En passant, la rétroconception avec PowerAMC :

La cardinalité portée par la patte connectant MAITRISER et FK_ENSEIGNER_MAITRISER devrait être 0,1.

Avec MySQL Workbench :

Même problème de cardinalité qu’avec AMC.

Affaire à suivre...

**Paprick** · 01/04/2025, 22h21

Bonsoir François,

Même si ça n'en a pas l'air, c'est en fait le même problème que celui signalé au Post #9.
Je suis en train de le régler.

**fsmrel** · 03/04/2025, 23h13

Salve,

@Capitaine,

Dans le post #16 de la discussion « Looping version 4.1 disponible (avec Rétroconception) », tu proposes ce MCD :

Looping en dérive le DDL :

Code SQL :

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
CREATE TABLE E1(
   E1ident SMALLINT,
   E1code CHAR(4) NOT NULL,
   E1libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(E1ident),
   UNIQUE(E1code)
);
 
CREATE TABLE E3(
   E1ident_1 SMALLINT,
   E3seq SMALLINT,
   E3nom VARCHAR(50) NOT NULL,
   E1ident SMALLINT,
   PRIMARY KEY(E1ident_1, E3seq),
   FOREIGN KEYE1ident_1) REFERENCES E1(E1ident),
   FOREIGN KEY(E1ident) REFERENCES E1(E1ident)
);

Et tu complètes par

Code SQL :

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

1
2
3
4
5
--la personne qui annule DOIT ETRE celle qui a validé
alter table E3
add constraint E3INC001
foreign key (E1ident_annul, E3seq)
references E3 (E1ident_valid, E3seq) ;

je suppose que E1ident_valid et E1ident_annul ont pris la place de E1ident et E1ident_1. Soit.

Les contraintes d’inclusion donnant, comme on le sait, quelques soucis lors de leur prise en compte avec SQL, afin de les éviter tant que faire se peut, que penses-tu en l’occurrence du MCD suivant ? (Ne te préoccupes pas des dates, elles sont là pour meubler).

Le LDD correspondant :

Code SQL :

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
CREATE TABLE E1(
   e1id SMALLINT,
   e1code CHAR(4) NOT NULL,
   e1libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(e1id),
   UNIQUE(e1code)
);
 
CREATE TABLE E3(
   e1id SMALLINT,
   e3seq SMALLINT,
   e3nom VARCHAR(50) NOT NULL,
   dateValidation DATE NOT NULL,
   PRIMARY KEY(e1id, e3seq),
   FOREIGN KEY(e1id) REFERENCES E1(e1id)
);
 
CREATE TABLE Annulation(
   e1id SMALLINT,
   e3seq SMALLINT,
   dateAnnulation DATE NOT NULL,
   PRIMARY KEY(e1id, e3seq),
   FOREIGN KEY(e1id, e3seq) REFERENCES E3(e1id, e3seq)
);