Discussion :

[escartefigue]

bonjour François

En effet, mais c'est moins lisible que le MCD originel (moins naturel en tout cas à mes yeux) et au stade SQL, on récupère une table supplémentaire qui n'a pas vraiment de raison d'être.
Mais bon, je retiens l'argument de Paprick : dans la mesure où les contraintes ne sont pas directement gérées par Looping du MCD vers le DDL, on ne saurait lui reprocher de ne pas les gérer dans l'autre sens.
J'y ajoute que comme les autres logiciels de modélisation font moins bien (et le plus souvent ne proposent rien du tout au sujet du DDL des contraintes), ça me va bien.
Sans compter que le fait que les DBA aient toujours un peu de travail me va bien aussi

[fsmrel]

Ave Capitaine,

au stade SQL, on récupère une table supplémentaire qui n'a pas vraiment de raison d'être.

 
Une table en plus (table Annulation) ça n’est pas un problème dans la mesure où :

(1) Elle est saine (non polluée par NULL),

(2) Elle permet d’éviter ainsi le piège des clés étrangères nullables (cf. les posts #16 et #40, ta table E3 contient une telle clé étrangère : "FOREIGN KEY(E1ident) REFERENCES E1(E1ident)", sans oublier bien entendu la clé étrangère nullable, conséquence de l’auto-référence,

(3) La table supplémentaire Annulation permet d’éviter la double référence à E1 (cf. ta table E3, "FOREIGN KEY(E1ident_1) REFERENCES E1(E1ident)", "FOREIGN KEY(E1ident) REFERENCES E1(E1ident)".

Bref, la table supplémentaire pallie de façon simple les impedimenta évoqués.

Quant à la lisibilité des MCD, je pense que le MCD rétroconçu ci-dessous n’est quand même pas d’une limpidité exemplaire dans sa partie droite...

Et pourtant c’est le MCD sur lequel les développeurs devront s’appuyer, avec le souci constant de l’auto-référence (horresco referens, sic !), jamais simple à manipuler...  

[escartefigue]

Non obstante his omnibus argumentis, persevero

Pour moi, conceptuellement parlant, le schéma le plus lisible est celui portant la contrainte, l'originel donc, mais à l'impossible nul n'est tenu

[fsmrel]

@Capitaine,

Perseverare, diabolicum...  


Je reprends ton MCD :

Figure 1

Pour obtenir un LDD ne posant aucun problème, ça serait chouette si Looping prenait l’initiative :

1) de faire une copie (sous le capot !) de ton MCD, puis

2) supprimer la contrainte d’inclusion

3) transformer aussi sec l’association "annuler" en entité-type

Figure 2

4) supprimer l’association "A_E1"

Figure 3

5) créer le code SQL :

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
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,
   PRIMARY KEY(e1id, e3seq),
   FOREIGN KEY(e1id) REFERENCES E1(e1id)
);
 
CREATE TABLE Annuler(
   e1id SMALLINT,
   e3seq SMALLINT,
   PRIMARY KEY(e1id, e3seq),
   FOREIGN KEY(e1id, e3seq) REFERENCES E3(e1id, e3seq)
);

6) Supprimer le MCD ayant servi à créer le DDL.

Et voilà. Ton MCD n'est pas touché et la contrainte est assurée au stade SQL. C’est-y pas une proposition honnête ?

@Paprick,

Ton avis ?

[Paprick]

Bonsoir,

Cet exemple repend le principe de ton post "Contraintes d'inclusion (du MCD au code SQL)".
Et ma réflexion est la même !

[E mds]

Un grans merci pour l'ajout de la rétroconception !
Cela fonctionne parfaitement avec un script où les "foreign key" sont intégrées dans les "create table".
En revanche, cela ne semble pas marcher avec un script où les "foreign key" sont déclarées séparément, dans des "alter table" (comme les scripts exportés par phpMyAdmin). Est-ce que j'ai loupé un truc ou doit-on adapter le script pour que tout soit dans les "create table" avant de faire la rétroconception ?
Merci d'avance !

Emds

[Paprick]

Bonjour,

Un grans merci pour l'ajout de la rétroconception !
Cela fonctionne parfaitement avec un script où les "foreign key" sont intégrées dans les "create table".
En revanche, cela ne semble pas marcher avec un script où les "foreign key" sont déclarées séparément, dans des "alter table" (comme les scripts exportés par phpMyAdmin). Est-ce que j'ai loupé un truc ou doit-on adapter le script pour que tout soit dans les "create table" avant de faire la rétroconception ?

Tout est prévu pour que cela fonctionne également avec les ADD FOREIGN KEY dans des ALTER TABLE.
Merci de m'envoyer votre script SQL pour que je regarde ce qui coince.

[E mds]

Désolée, c'est moi qui avais fait une fausse manip : la rétroconception fonctionne aussi avec les "alter table" (clés étrangères, auto incrément...).
En revanche, dans Looping, est-il possible d'ajouter InnoDB dans les "create table" de sorte que, lors de l'exécution du script dans phpMyAdmin, les clés étrangères soient prises en compte ?
Merci d'avance.
Emds

[Paprick]

Désolée, c'est moi qui avais fait une fausse manip : la rétroconception fonctionne aussi avec les "alter table" (clés étrangères, auto incrément...).
En revanche, dans Looping, est-il possible d'ajouter InnoDB dans les "create table" de sorte que, lors de l'exécution du script dans phpMyAdmin, les clés étrangères soient prises en compte ?

Oui, il suffit d'aller dans le menu principal (bouton en haut à gauche) et de choisir "Paramètres LDD" suivi de "Compléments script LDD" : indiquer alors l'instruction "ENGINE=InnoDB" dans la zone "Code SQL de fin de création de table" .

[E mds]

Ahhh super ! Merci !
Il est vraiment parfait ce logiciel ;-)

[E mds]

En revanche, lors de la rétroconception, même si les clés étrangères sont repérées et remises dans le script, le "ENGINE=InnoDB" n'est pas remis dans le script : est-ce normal ?
J'esplique :
- j'ai fait un MCD et ajouté "ENGINE=InnoDB" à la fin de chaque "CREATE TABLE" (avec "paramètres LDD") ;
- dans phpMyAdmin, j'ai créé une BDD et exécuté le script : les tables ont bien été créés en innoDB ;
- j'ai exporté le script (en décochant tout sauf les "auto increment", pour avoir un script le plus simple possible (le script contient "ENGINE=InnoDB" dans les "CREATE TABLE") ;
- dans Looping, j'ai créé un nouveau projet et demandé une rétroconception à partir de l'export ;
- j'ai obtenu un MCD correct, les "FOREIGN KEY" correctement implémentées dans les "CREATE TABLE" ;
- en revanche, il n'y a pas "ENGINE=InnoDB" dans les "CREATE TABLE".
C'était juste pour savoir si c'était normal.

Merci d'avance !
Emds

[Paprick]

Bonjour,

Les paramètres LDD sont sauvegardés avec le modèle.
Par conséquent, si un nouveau modèle est créé, il faut les repréciser.
La solution est de le prévoir dans le modèle par défaut : "looping.loo" (à créer dans le répertoire de Looping.exe) ou autre modèle de votre choix demandé lors de la création d'un nouvel MCD en cas d'absence de looping.loo

[E mds]

Ok ! Encore une fois merci pour cette réponse rapide et précise.

[plepoutre]

Rien à voir avec les questions difficiles autour de la rétro-conception :

- tout d'abord un très grand merci pour ce logiciel si efficace. Je le recommande à chaque fois que possible !

- Mon petit problème :
Lorsque je souhaite affecter des tables à une couleur ou à une vue, je sélectionne deux entités et je clique droit : parfois ca marche, parfois je bascule en mode "outil lien".
C'est aléatoire. J'ai pas compris la logique du tout, est-ce un bug ? Suis-je idiot ?


Merci pour tes efforts !

[Paprick]

Bonjour,

Normalement, si tu cliques droit sur une des entités sélectionnées, Looping te proposera la fenêtre de choix de couleur et de vue.
Mais si tu cliques à côté de ces entités sélectionnées, il te proposera en effet l'outil précédemment utilisé (comme toujours dans n'importe quelle autre situation).

Dis-moi si ça fonctionne bien comme ça chez toi !

[plepoutre]

Bonjour,

Normalement, si tu cliques droit sur une des entités sélectionnées, Looping te proposera la fenêtre de choix de couleur et de vue.
Mais si tu cliques à côté de ces entités sélectionnées, il te proposera en effet l'outil précédemment utilisé (comme toujours dans n'importe quelle autre situation).

Dis-moi si ça fonctionne bien comme ça chez toi !

Wow génial d'avoir un retour si rapide. Je pense avoir compris le "problème" : la fonction marche fort bien en vue MCD mais de façon aléatoire dans la vue UML. Je vais utiliser la vue MCD en attendant !

[Paprick]

Je pense avoir ciblé le problème (ce n'est pas aléatoire) : la fenêtre n'est pas proposée dès lors qu'une classe d'association est incluse dans la sélection ...
En effet, c'est indirectement lié au fait que seules les classes d'entités sont concernées par les vues (sachant que les vues et les couleurs font fenêtre commune !).
Je vais me pencher sur ce phénomène pour la prochaine version !

[chsimon_su]

Bonjour à tous,

Je viens de découvrir Looping (et ce forum), et vraiment MERCI @paprick !

--
Christian

[cmukumba]

Bonjour,

Je tiens à remercier cette belle innovation,

je voudrais toutefois demander s'il existe un version MacOS de cette application sans passer par une couche du Virtual Machine.

Merci.