Nouveau forum consacré au logiciel de modélisation Looping créé par le professeur Patrick Bergougnoux

Version imprimable

11/11/2020, 18h21
CinePhil

Nouveau forum consacré au logiciel de modélisation Looping créé par le professeur Patrick Bergougnoux

Chers membres du Club,

Le professeur Patrick Bergougnoux, alias Paprick vient de sortir la version 3.0 de son logiciel de modélisation Looping.

Comme Looping est de plus en plus utilisé et abordé dans le forum Schéma et dans les discussions parlant de modélisation des données, la rédaction de DVP a décidé de créer un sous-forum pour Looping dans la rubrique "ALM / Outils".

Vous pourrez ainsi communiquer en direct avec son concepteur et avec les membres aguerris à l'utilisation de Looping. Vous pourrez aussi faire votre lettre au Père Noël en matière d'évolution de Looping.

À bientôt sur nos forums;)
13/11/2020, 22h18
f-leb

Très bonne idée ce sous-forum, longue vie à Looping :ccool:
16/11/2020, 19h03
escartefigue

Re bonjour Paprick,

Dans le sujet https://www.developpez.net/forums/d2.../#post11646567
Je découvre les liens courbes, fort élégants du reste, qui relient les sous-types "salarié" et "bénéficiaire".
C'est un plus d'une prochaine version ou bien déjà disponible avec la v3, auquel cas, mais komankonfédonctesque ? Point n'y parviens-je !

EDIT trouvé : double clic sur le lien, puis cocher la case "lissage cassure" :P
Trop bien :ccool: :bravo:
16/11/2020, 19h11
Paprick

Citation:

Envoyé par escartefigue

EDIT trouvé : double clic sur le lien, puis cocher la case "lissage cassure" :P
Trop bien :ccool: :bravo:

Et si tu jongles habillement avec les cassures, tu peux faire de très jolies choses ! :lun:
17/11/2020, 03h04
fsmrel

2 pièce(s) jointe(s)

Bonsoir Patrick,

A propos de l’ordre des attributs dans la clé primaire d’une table issue d’une association du MCD.

Examinons le MCD et le MLD figurant au chapitre 14 de ton ouvrage Modélisation Conceptuelle de Données - Une démarche pragmatique. J’ai pris cet exemple parce qu’il correspond (à une CIF près) à celui sur lequel nous nous sommes penchés, en compagnie du Capitaine :

Pièce jointe 584140

La table EMPRUNT a pour clé primaire le triplet

{NumCarte, CodeOuvrage, DatePret}

Mais voilà, le DBA a besoin que l’ordre des attributs dans la clé soit différent, par exemple :

{DatePret ,NumCarte ,CodeOuvrage}.

Il ne semble pas que l’on puisse demander à Looping d’effectuer ce changement, donc il faudra retoucher manuellement le code SQL de création des tables (sans oublier de propager le changement sur les éventuelles clés étrangères :weird:).

Pour pouvoir agir sur cet ordre au stade MCD, je verrai par exemple quelque chose comme ceci, où la fenêtre associée à la patte connectant CALENDRIER et EMPRUNT permettrait de préciser la position de l’attribut dans l’identifiant de l’association (c’est-à-dire dans la clé primaire générée pour la table EMPRUNT) :

Pièce jointe 584141

Même principe pour les autres pattes branchées sur l’association EMPRUNT.

Patrick, ton avis ?
17/11/2020, 03h43
Paprick

1 pièce(s) jointe(s)

Bonsoir François,

La solution que j'ai prévue dans la version 3.1 va tout à fait dans ce sens ; voici la fenêtre des liens qui sera proposée :
Pièce jointe 584146
Cela permettra même de choisir la position des identifiants relatifs ;).
Et pour les clés alternatives composées, on pourra préciser la position entre parenthèses à la suite du nom de l'index.

Qu'en penses-tu ?
17/11/2020, 06h49
escartefigue

Sujet important en effet
En l'attente, j'ai remarqué que c'est l'ordre inverse de rattachement des "pattes" qui est appliqué pour l'ordonnancement des attributs dans la clef primaire de la table associative ;)
17/11/2020, 08h59
CinePhil

Citation:

Envoyé par Paprick

Bonsoir François,

La solution que j'ai prévue dans la version 3.1 va tout à fait dans ce sens ; voici la fenêtre des liens qui sera proposée :
Pièce jointe 584146
Cela permettra même de choisir la position des identifiants relatifs ;).
Et pour les clés alternatives composées, on pourra préciser la position entre parenthèses à la suite du nom de l'index.

Qu'en penses-tu ?

Que veut dire la case à cocher : "Clé étrangère dans index" ?
17/11/2020, 12h40
Paprick

Citation:

Envoyé par CinePhil

Que veut dire la case à cocher : "Clé étrangère dans index" ?

La notion d'index est utilisée par Looping pour définir des clés alternatives composées : en indiquant un nom d'index dans la zone qui s'affiche quand on coche la case correspondante (case à cocher UNIQUE pour les rubriques et cette case "Clé étrangère dans index" pour les clés étrangères), toutes les rubriques ayant le même nom d'index composent une clé alternative (qui se traduit par un UNIQUE en SQL).
Cette option est donc proposée dans les pattes des associations pour permettre d'intégrer les clés étrangères dans ces index.
De plus, il est possible d'associer une rubrique à plusieurs index en séparant les noms d'index par un |
17/11/2020, 20h11
fsmrel

7 pièce(s) jointe(s)
Bonjour,

@Paprick,

Puisqu'on est dans la série « composition des identifiants ».

Prenons par exemple le cas de l’entité-type FOURNISSEUR, au début du chapitre 12 de Modélisation Conceptuelle de Données - Une démarche pragmatique :

Pièce jointe 584210

Pour les besoins de la cause, je définis maintenant des identifiants alternatifs.

Ci-dessous, l’attribut Nom devient élément de l’identifiant alternatif {Nom, CodePostal}, symbolisé par l’index 1, et cet attribut devient aussi élément de l’identifiant alternatif {Nom, Ville}, symbolisé par l’index 2 (les noms des index sont séparés par le caractère « | ») :

Pièce jointe 584209

A son tour, l’attribut CodePostal est lui aussi élément de l’identifiant alternatif {Nom, CodePostal}, symbolisé par l’index 1 :

Pièce jointe 584211

L’attribut Ville est élément de l’identifiant alternatif {Nom, Ville}, symbolisé par l’index 2 :

Pièce jointe 584212

Code SQL résultant (MySQL) :
```
CREATE TABLE FOURNISSEUR
(
   IdFournisseur INT AUTO_INCREMENT,
   Nom VARCHAR(50) NOT NULL,
   Adresse VARCHAR(80) NOT NULL,
   CodePostal CHAR(5) NOT NULL,
   Ville VARCHAR(50) NOT NULL,
   IBAN CHAR(27) NOT NULL,
   CONSTRAINT FOURNISSEUR_PK PRIMARY KEY(IdFournisseur),
   CONSTRAINT FOURNISSEUR_1_AK UNIQUE(Nom, CodePostal),
   CONSTRAINT FOURNISSEUR_2_AK UNIQUE(Nom, Ville),
   CONSTRAINT FOURNISSEUR_AK UNIQUE(IBAN)
) ; 
```
Va tutto bene !

Mais voilà que pour le DBA (encore lui...) les attributs de la clé alternative FOURNISSEUR_1_AK sont à réordonner ainsi :

CONSTRAINT FOURNISSEUR_1_AK UNIQUE(CodePostal, Nom)

Peut-être me trompé-je, mais j’ai le sentiment que, pour le moment, je suis obligé de réordonner manuellement dans le code SQL (sauf à supprimer l’identifiant alternatif puis le recréer...).

Question :

Pour chaque index serait-il possible de choisir la position des attributs dans les identifiants alternatifs ? Par exemple, ci-dessous l’attribut Nom est en position 2 dans le cas de l’index 1 tandis qu’il est en position 1 dans le cas de l’index 2 :

Pièce jointe 584213

Pour mémoire, avec AMC pour chaque entité-type on dispose d’une fenêtre « Identifiants » fournissant la liste des identifiants de cette entité-type, et pour chacun de ces identifiants on peut afficher une fenêtre « Attributs » permettant d’y ajouter, supprimer des attributs, avec la possibilité de les réordonner (à la manière dont on réordonne les rubriques dans la fenêtre « Entité » avec Looping).

Toujours avec AMC, en option on a la possibilité de voir à quels identifiants appartiennent les attributs :

Pièce jointe 584215

Si Looping proposait quelque chose d’analogue plutôt que les noms des attributs en gras comme ci-dessous, j’avoue que cela ne serait pas pour me déplaire...

Pièce jointe 584218

Patrick, qu’en penses-tu ? Peut-être suis-je à la bourre sur ce sujet ? :koi:
17/11/2020, 21h12
Paprick

Bonsoir,

Citation:

Envoyé par fsmrel

Question : Pour chaque index serait-il possible de choisir la position des attributs dans les identifiants alternatifs ? Par exemple, ci-dessous l’attribut Nom est en position 2 dans le cas de l’index 1 tandis qu’il est en position 1 dans le cas de l’index 2

Comme indiqué dans un post précédent concernant la future version 3.1, "pour les clés alternatives composées, on pourra préciser la position entre parenthèses à la suite du nom de l'index", ce qui nous donnerait par exemple Index1(2) | Index2(1) ...

Citation:

Toujours avec AMC, en option on a la possibilité de voir à quels identifiants appartiennent les attributs. Si Looping proposait quelque chose d’analogue plutôt que les noms des attributs en gras comme ci-dessous, j’avoue que cela ne serait pas pour me déplaire...

La mise en gras indique la présence d'une rubrique dans une clause UNIQUE, et il faut effectivement cliquer sur la rubrique en question pour voir dans quel(s) index elle intervient. L'afficher directement dans le MCD ne me parait pas opportun dans la mesure où les noms d'index peuvent être longs, et leur nombre est illimité... Mais bon, on peut toujours réfléchir à la question...:cfou:
17/11/2020, 23h00
fsmrel

1 pièce(s) jointe(s)

Bonsoir Patrick,

Citation:

Envoyé par Paprick

Comme indiqué dans un post précédent concernant la future version 3.1, "pour les clés alternatives composées, on pourra préciser la position entre parenthèses à la suite du nom de l'index", ce qui nous donnerait par exemple Index1(2) | Index2(1) ...

Parfait, Patrick, j’avais dû pas bien interpréter ton propos.

Citation:

Envoyé par Paprick

Bonsoir,
La mise en gras indique la présence d'une rubrique dans une clause UNIQUE, et il faut effectivement cliquer sur la rubrique en question pour voir dans quel(s) index elle intervient. L'afficher directement dans le MCD ne me parait pas opportun dans la mesure où les noms d'index peuvent être longs, et leur nombre est illimité... Mais bon, on peut toujours réfléchir à la question...:cfou:

Il ne s’agit surtout pas de faire figurer le nom des index, mais simplement des symboles brefs et suffisamment parlants, "ai1", "ai2", etc., à l’initiative de l’AGL, et je n’en demande pas plus. Je te dis pas le désastre si AMC (que j’ai connu dès sa création, par SDP à Suresnes (voir Xiao-Yun Wang sur Internet)) affichait plutôt le nom de mes contraintes ! :fou:

Toutes choses égales, cela vaut bien sûr pour le MLD. Avec AMC :

Pièce jointe 584238
18/11/2020, 01h09
Paprick

Bonsoir François,

Citation:

Envoyé par fsmrel

Il ne s’agit surtout pas de faire figurer le nom des index, mais simplement des symboles brefs et suffisamment parlants, "ai1", "ai2", etc., à l’initiative de l’AGL

Comme tu le sais, je ne souhaite pas alourdir la représentation des modèles simples, les multiples clés alternatives composées ne faisant pas partie de cette catégorie ! ;)
Mais, toujours soucieux de répondre aux demandes les plus sophistiquées provenant d'experts dans ton genre :mrgreen:, voici ce qui est envisageable avec la version 3.1 de Looping : proposer, en option, l'affichage des clés concernées par une rubrique en lieu et place des types de données. Je rajoute donc une option "Affichage types données" dans les propriétés avec les choix "Types SGBD" (par défaut) et "Clés concernées".
On aurait alors la possibilité de remplacer, par exemple, NUMFAC CHAR(8) par NUMFAC PK,AK2 ou (seulement dans un MLD) REF INT par REF PK,AK1,FK

Qu'en penses-tu ?
18/11/2020, 02h54
fsmrel

1 pièce(s) jointe(s)

Hello Patrick,

Citation:

Envoyé par Paprick

Mais, toujours soucieux de répondre aux demandes les plus sophistiquées provenant d'experts dans ton genre :mrgreen:

Eh oui, des gens comme ça y en a, pour te forcer à réaliser des exploits (et encore tu connais pas Raoul, celui qui ventile façon puzzle quand ça va pas dans les modèles, il pourrait t’emmener mine de rien au message #1000 et à la V40, voire plus...)

En tout cas, grand merci !

Citation:

Envoyé par Paprick

Je rajoute donc une option "Affichage types données" dans les propriétés avec les choix "Types SGBD" (par défaut) et "Clés concernées".

C’est bien dans la fenêtre Propriétés > MLD – SQL que figurerait l’option "Affichage types données", c’est ça ?

De toutes façons, ce que tu proposes a l’air bien sympathique.

Au fond, à moins que je ne raisonne comme un tambour, si je choisis "Clés concernées", outre la table FOURNISSEUR, l’entité-type FOURNISSEUR elle aussi ressemblerait assez à ce que j’ai fait avec AMC :

Pièce jointe 584252

Ai-je compris de travers ?
18/11/2020, 03h05
Paprick

Hello,

Citation:

Envoyé par fsmrel

C’est bien dans la fenêtre Propriétés > MLD – SQL que figurerait l’option "Affichage types données", c’est ça ?

Presque ! Comme cet affichage se fera aussi dans le MCD, je vais placer le choix dans "Propriétés > Options générales" derrière 'Usage du gras".

Citation:

Au fond, à moins que je ne raisonne comme un tambour, si je choisis "Clés concernées", outre la table FOURNISSEUR, l’entité-type FOURNISSEUR elle aussi ressemblerait assez à ce que j’ai fait avec AMC

Tout à fait ! :ccool:
18/11/2020, 03h58
fsmrel

1 pièce(s) jointe(s)

Ah ben dis donc, ah ben dis donc, ah ben dis donc... Well, well, well ! Trop bien :hola: Et je pèse mes mots. Je vais dire à Raoul d’aller chercher une bouteille chez la Polonaise, mais allons-y mollo quand même... Pièce jointe 584253
18/11/2020, 17h49
fsmrel

3 pièce(s) jointe(s)
Salve, Patrick, c’est encore moi !

Remarques relatives aux actions de compensation (ON DELETE / UPDATE)

Looping 3.0 permet la déclaration au stade MCD des actions de compensation ON DELETE / UPDATE : belle initiative ! Mais quelques remarques.

Soit le diagramme suivant :

Pièce jointe 584319

A titre d’exemple, l’excellent ouvrage Modélisation Conceptuelle de Données - Une démarche pragmatique utilise les mots-clés "Merise", "MCD", "UML", "MLD", "champ", "CODASYL".

Or pour cet ouvrage "champ" est à remplacer par "rubrique" et "CODASYL" est à supprimer : au stade SQL on interviendra directement sur la table UTILISER :
```
DELETE FROM UTILISER
    WHERE LivreId = 
       (SELECT LivreId 
        FROM   LIVRE 
        WHERE  Titre = 'Modélisation Conceptuelle de Données - Une démarche pragmatique'
      AND MotCleId = 
       (SELECT MotCleId 
        FROM   MOT_CLE 
        WHERE  MotCleLibelle = 'CODASYL'))
;
UPDATE UTILISER 
    SET MotCleId = 
        (SELECT MotCleId 
         FROM   MOT_CLE 
         WHERE  MotCleLibelle = 'rubrique')
    WHERE LivreId = 
        (SELECT LivreId 
         FROM   LIVRE 
         WHERE  Titre = 'Modélisation Conceptuelle de Données - Une démarche pragmatique'
      AND MotCleId = 
        (SELECT MotCleId 
         FROM   MOT_CLE 
         WHERE  MotCleLibelle = 'champ'))
;
```
So far, so good. Supposons maintenant qu’on veuille supprimer l’ouvrage Vingt ans dans un mur, la vie d’une brique, lequel utilise aussi des mots-clés. Allons-y tranquillement :
```
DELETE FROM LIVRE 
    WHERE Titre ='Vingt ans dans un mur, la vie d''une brique' 
;
```
Las ! Le SGBD refusera la suppression parce que la table UTILISER contient des références à l’ouvrage en cause (table LIVRE).

Pour arriver à nos fins :

Soit on procède en deux temps, en commençant par supprimer ces références puis en supprimant enfin l’ouvrage ;

Soit on définit une action de compensation ON DELETE CASCADE pour l’association UTILISER, auquel cas, sans se préoccuper des références dont il est l’objet, on peut tout de suite supprimer l’ouvrage, le déclenchement de la suppression de ses références sera automatiquement assuré par le SGBD.

Pièce jointe 584318

Mais ! Symétrie oblige, la suppression d’un mot-clé déclenche aussi la suppression automatique de ses références dans la table UTILISER. Si (par inadvertance...) je supprime le mot-clé "MCD", c’est quand même fâcheux pour les ouvrages traitant de la modélisation des données...

Autrement dit, à mon sens, les actions de compensation ON DELETE / UPDATE devraient être présentées non pas dans la fenêtre « Association », mais à un niveau plus fin, c’est-à-dire au niveau des pattes d’association (ainsi je cocherai la case « ON DELETE CASCADE » pour la patte connectant LIVRE et UTILISER, et m’abstiendrai pour l’autre patte).

Je passe au MCD de la page 254 de ton ouvrage. Si l’on peut envisager que la suppression d’un adhérent « cascade » automatiquement sur ses adhésions, il est difficilement concevable que la suppression d’une activité cascade elle aussi sur les adhésions (tête des adhérents !) Là encore, les pattes de l’association ADHESION devraient pouvoir être dotées d’actions de compensation différentes...

Pièce jointe 584321

La réflexion portait sur les associations.

Sous-types et actions de compensation (disons ON DELETE)

Manifestement, les actions de compensation sont ignorées dans le cas des sous-types. Il faut donc procéder en deux temps pour supprimer un personnel qui est un administratif (cf. page 221 de ton ouvrage), c’est bien dommage, alors que justement la suppression d’un personnel dans la table PERSONNEL ne peut que cascader (sinon il faudra qu’on m’explique) dans la table ADMINISTRATIF (ou ENSEIGNANT, toutes choses égales).
18/11/2020, 21h56
Paprick

Bonsoir François,

Citation:

Envoyé par fsmrel

Autrement dit, à mon sens, les actions de compensation ON DELETE / UPDATE devraient être présentées non pas dans la fenêtre « Association », mais à un niveau plus fin, c’est-à-dire au niveau des pattes d’association (ainsi je cocherai la case « ON DELETE CASCADE » pour la patte connectant LIVRE et UTILISER, et m’abstiendrai pour l’autre patte).

Tu as tout à fait raison, et j'avais bien conscience de cette limite quand j'ai implanté cette option.
Je suis en train de réfléchir sur la meilleure manière, sans trop alourdir l'interface, de ramener cette CASCADE au niveau du lien (ce qui permettra par la même occasion de l'intégrer dans le cadre de l'héritage).:traine:
18/11/2020, 22h31
fsmrel

Patrick,

Je suis désolé pour cette surcharge de travail, mais je sais que tu ne rechignes jamais, donc que tu mettras tout en oeuvre pour faire avancer notre science, si humble soit-elle. Et comme disait mon voisin du dessus « Ad augusta per angusta » ! Et mon voisin d’en dessous « Haut les coeurs » ! Et celui d’à-côté « Plutôt que baisser les bras, levons le coude » !

On y croit.
24/11/2020, 16h14
Picsonald

Bonjour à tous,
Merci pour l'ouverture de ce Merise sur Looping !
Je l'utilise beaucoup dans les cours que je donne. Il est très pratique, et la v3.0 est tout simplement excellente !
Longue vie au forum et à Looping !
01/02/2023, 16h54
fsmrel

Au sujet de la classe d'entité fictive CALENDRIER

Bonsoir,

Merci Paprick de nous avoir offert la possibilité de définir des classes d’entités fictives.

Comment procédait-on avant que Looping n'arrivât ? Cela me conduit à faire une mise au point au sujet de l’entité-type (classe d'entité) DATE (CALENDRIER).

En 2015, j’ai pondu un billet à propos de cette entité-type DATE :Que penser de la présence d'une entité-type DATE dans un MCD ?

Dans ce billet, J’ai tiré à vue, car cette entité-type devait se retrouver dans le MLD – puis dans le code SQL – :zekill: sous forme de table, avec les contraintes d’intégrité référentielle et tout le toutim, alors que c’était parfaitement inutile.

En ces temps « pré-Looping », DB-MAIN nous permettait de contourner la contrainte d’identification implicite et inconditionnelle formulée dans les pages 97 et 98 du monument Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), paragraphe II-D-3-d. Identification d'une relation type.

Avec l’identification explicite d’une association selon DB-MAIN, pas besoin d’entité-type DATE, dans l’exemple ci-dessous la date fait l’objet d’un attribut de l’association et entre dans la composition de l’identifiant :

https://www.fsmwarden.com/DVP_images...cite_mcd_2.png

Bien entendu, tout ça sent le souffre et Looping nous permet non seulement de respecter le dogme merisien, mais permet surtout d’éviter, avec intelligence et élégance, l’obligation de la création d’une table DATE parasite, grâce à la classe d’entité fictive CALENDRIER.

Encore une fois, merci Paprick ! :ccool:

-----

P.S.

Dans mon billet, en citant la page 138 de l’ouvrage de Nanci et Espinasse, je faisais en fait référence à la 3e édition de cet ouvrage.
02/02/2023, 14h26
escartefigue

Tout à fait d'accord, d'ailleurs, des ET fictives, j'en use sans retenue :)
À l'époque où j'utilisais DBMain ou Power AMC, j'intevernais dans le DDL, mais du coup, il fallait le faire à chaque évolution du modèle.
C'était donc à la fois invisible sur le MCD et plus risqué.
Encore un point à l'avantage de Looping.
Merci Paprick :ccool:
02/03/2023, 18h13
haythem.tuni

Un logiciel efficace merci pour le créateur

Citation:

Envoyé par CinePhil

Chers membres du Club,

Le professeur Patrick Bergougnoux, alias Paprick vient de sortir la version 3.0 de son logiciel de modélisation Looping.

Comme Looping est de plus en plus utilisé et abordé dans le forum Schéma et dans les discussions parlant de modélisation des données, la rédaction de DVP a décidé de créer un sous-forum pour Looping dans la rubrique "ALM / Outils".

Vous pourrez ainsi communiquer en direct avec son concepteur et avec les membres aguerris à l'utilisation de Looping. Vous pourrez aussi faire votre lettre au Père Noël en matière d'évolution de Looping.

À bientôt sur nos forums;)