Bientôt la version 3.1

Bonjour,

Une nouvelle version de Looping est dans les tiroirs :D ; voici les principales fonctionnalités que vous y retrouverez :

Bientôt disponible dans la version 3.1 (objectif : fin mars 2021) :

• Amélioration de la navigation dans les modèles : zoom, déplacement, ...
• Recherche de textes dans les MCD, MLD et requêtes SQL
• Paramétrage de fonds bicolores pour les classes d'entités et les associations
• Possibilité de rajout de code SQL avant et après la création d'une table
• Choix de la position d’une clé étrangère dans la clé primaire de la table associée
• Option "ON CASCADE" au niveau de chaque lien d'une association
• ... et plein d'autres optimisations, astuces et petits ajustements !

​

Et un peu plus tard, dans la version 3.2 :

• Affichage dans les MCD des clés concernées par une rubrique
• Option "Crow's foot" pour les liens des MLD graphiques
• Urbanisation des grands modèles : définition de vues partielles

Merci encore Paprick pour toutes ces évolutions, j'en salive déjà, miam :ccool:

Salve !

Paprick, je me joins au Capitaine pour te remercier. On fera chauffer la machine ! :P

Super ! Merci ! Bien hâte !

Ce serait possible d'avoir une version compilée en 64 bits ? Ça m'éviterait peut-être les problèmes que je rencontre à l'installation de Wine 64 + 32 pour faire tourner Looping sous ma Mageia Linux. :mrgreen:

Bonsoir Philippe,

Citation:

---

Envoyé par CinePhil

Ce serait possible d'avoir une version compilée en 64 bits ? Ça m'éviterait peut-être les problèmes que je rencontre à l'installation de Wine 64 + 32 pour faire tourner Looping sous ma Mageia Linux. :mrgreen:

---

Je vais regarder ça : s'il n'y a pas d'incompatibilité incontournable, je produirai la version 64 bits dès le prochain Looping 3.1... je te tiens au courant au plus vite. :pc:

Bonjour Patrick,

Dans les pattes d'association non reflexives, on ne peut pas choisir de suffixer les FK, or ce serait parfois utile.

Par exemple, dans le MCD ci-dessous, la table issue de WO hérite deux fois de l'identifiant US, du coup, le script propose US_ident et US_ident_1 ce qui n'est pas très pratique

Pièce jointe 631899

Citation:

---

Envoyé par escartefigue

Dans les pattes d'association non reflexives, on ne peut pas choisir de suffixer les FK, or ce serait parfois utile.
Par exemple, dans le MCD ci-dessous, la table issue de WO hérite deux fois de l'identifiant US, du coup, le script propose US_ident et US_ident_1 ce qui n'est pas très pratique

---

Franchement Capitaine, as-tu pensé un seul instant que Looping ne savait pas faire ça ?!!! :zekill::mouarf:
En fait, même si ça peut te paraître bizarre (mais c'est logique quand on y réfléchit bien), la FK est suffixée par le rôle situé sur la patte 0,n reliée à la classe d'entité d'où provient la FK en question. :lun:
Essaie, et tu me diras si c'est bien ce que tu recherches.

Salve les rois du Looping,

En passant, Paprick, peut-on espérer trouver un jour l’implémentation par Looping de la contrainte d’exclusion, ou de préférence celle de partitionnement, dans le genre de celle que je propose :

Code:

---

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

CREATE TABLE US ( usId VARCHAR(4), CONSTRAINT US_PK PRIMARY KEY(usId) ); CREATE TABLE SE ( usId VARCHAR(4), seId VARCHAR(4), CONSTRAINT SE_PK PRIMARY KEY(usId, seId), CONSTRAINT SE_US_FK FOREIGN KEY(usId) REFERENCES US(usId) ); CREATE TABLE WO ( woId VARCHAR(4), usId_US VARCHAR(4), usId_SE VARCHAR(4), seId VARCHAR(4), CONSTRAINT WO_PK PRIMARY KEY(woId), CONSTRAINT WO_US_FK FOREIGN KEY(usId_US) REFERENCES US(usId), CONSTRAINT WO_SE_FK FOREIGN KEY(usId_SE, seId) REFERENCES SE(usId, seId) , CONSTRAINT WO_PARTOCHE_CHK CHECK (usId_US IS NOT NULL AND usId_SE IS NULL AND seId IS NULL OR usId_US IS NULL AND usId_SE IS NOT NULL AND seId IS NOT NULL) );

---

En effet, l’exemple du Capitaine est récurrent dans les MCD, à en devenir canonique...

Bonsoir François,

Citation:

---

Envoyé par fsmrel

En passant, Paprick, peut-on espérer trouver un jour l’implémentation par Looping de la contrainte d’exclusion, ou de préférence celle de partitionnement, dans le genre de celle que je propose

---

Si on définit une règle formelle acceptée par tous les SGBD, la traduire dans Looping ne me poserait probablement aucun problème.
Une telle règle existe-t-elle pour l'ensemble des contraintes ? :weird:
Sinon, comme tu le sais, le code SQL de la règle peut actuellement être spécifiée via un ALTER TABLE dans une règle Looping qui se rajoutera automatiquement au script. :whistle:

Salve,

Citation:

---

Envoyé par Paprick

comme tu le sais, le code SQL de la règle peut actuellement être spécifiée via un ALTER TABLE dans une règle Looping qui se rajoutera automatiquement au script

---

Certes, mais la traduction en SQL de la contrainte d’exclusion serait un plus par rapport à ce que font d’autres AGL de modélisation des données (nada...).

Citation:

---

Envoyé par Paprick

Si on définit une règle formelle acceptée par tous les SGBD, la traduire dans Looping ne me poserait probablement aucun problème.

---

La contrainte que j’ai proposée est simple et conforme à la norme SQL. Les SGBD qui adhérent à la norme ne poseront pas de problème, sauf peut-être Access qui a sa propre norme. Avant la V8, MySQL accepte la contrainte, mais n’effectue strictement aucun contrôle...


Concernant la règle récurrente que j’ai évoquée, le principe est simple.

Soit E une entité-type, constituant le pivot de la contrainte d’exclusion (en fait de partitionnement dans ce que j’ai proposé). Soit A1 et A2 les deux associations constituant la portée de la contrainte. La contrainte implique la présence d’une cardinalités 0,1 sur chaque patte associée à E, puisqu’on est dans le « soit l’un, soit l’autre » (dans l’exemple du capitaine, un workout est associé soit à un user, soit à une sélection). Si les cardinalités ne sont pas toutes deux 0,1, on ne fait rien (cas du MCD de la figure 13.34 de l’ouvrage Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).


On ne traite pas 100% des cas d’exclusion, mais une partie quand même bien intéressante.

On se limite aux cas où Looping doit générer au stade SQL une table E pour laquelle il doit créer des clés étrangères FK1 et FK2 (une par patte), n’ayant aucun attribut en commun (et pour cause).

L’exemple ci-dessous n’est évidemment pas concerné. C’est une variante de la spécialisation des entités-types (cf. ici), où c’est bien plus compliqué à mettre en oeuvre car les contraintes ne concernent pas le pivot mais les autres entités-types (la norme SQL permet de traiter le cas grâce aux assertions, mais les SGBD ne se sont pas risqués à proposer l’instruction CREATE ASSERTION).

Pièce jointe 592654

En passant, quid des contraintes d’exclusion dans le cas des associations réflexives ?


Note : dans la définition donnée par l’Afcet, le pivot peut être constitué de plus d’une entité-type, mais on n’est plus dans le cas simple, aussi ai-je proposé qu’on se limite à ce que le pivot ne soit constitué que d’une seule entité-type.

Bonjour,

Je suis conscient que certains cas simples pourraient faire l'objet d'une génération de code assez standard pour être compris par tout SGBD respectant la norme SQL.
Mon problème, c'est qu'on est dans un nombre assez limité de cas, liés à la nature des contraintes (quid de l'inclusion, de la simultanéité, de la totalité, de la partition, ... :weird:) et de certaines configurations de cardinalités, d'association n-aires, de réflexives, ... pour lesquels un code personnalisé doit être mis en œuvre.
Bref, ne générer du code que dans des cas très spécifiques (même s'ils sont fréquents) conduirait le concepteur à revendiquer un traitement de tous les cas... et il aurait raison ! :?
Tu l'auras remarquer (en particulier avec les CIF), Looping ne fait pas les choses à moitié, et une génération SQL générique pour contrôler tous types de contraintes me parait illusoire...
Mais bon, je disais la même chose pour la génération des clés alternatives liées aux CIF à unicité incomplète, et finalement Looping est à ma connaissance le seul AGL du marché à le faire correctement ! :france::frenchy:

Malgré cette réticence à générer ce petit bout de code dans les cas particuliers que tu évoques, ce besoin m'a fait réfléchir à une évolution qui ne coûtent rien (ou presque), mais qui va dans le sens de la nécessité d'associer du code à toute contrainte. C'est pourquoi, je propose de rajouter dans la définition des contraintes (y compris pour l'héritage : spécialisation, généralisation) une zone de saisie du code SQL associé à la contrainte, ce qui évitera d'alourdir le modèle avec le rajout d'une règle, et qui formalisera la nécessité d'exprimer la contrainte dans le script SQL.
Et cela ne nous interdit pas de réfléchir à un petit bouton qui pourrait, dans certains cas particuliers, faire une proposition automatique de code... mais ça, c'est une autre histoire à méditer sereinement ! :zen:

Bonjour Paprick

Citation:

---

Envoyé par Paprick

Franchement Capitaine, as-tu pensé un seul instant que Looping ne savait pas faire ça ?!!! :zekill::mouarf:
En fait, même si ça peut te paraître bizarre (mais c'est logique quand on y réfléchit bien), la FK est suffixée par le rôle situé sur la patte 0,n reliée à la classe d'entité d'où provient la FK en question. :lun:
Essaie, et tu me diras si c'est bien ce que tu recherches.

---

Effectivement, ça fonctionne en ajoutant un rôle WO sur a patte US/Asso4 :) :ccool:

Par contre, étrangement, en ajoutant un rôle "SE" sur la patte SE/asso2, Looping me crée deux attributs dans WO l'un prenant le nom du rôle seul :weird:, l'autre, avec le rôle en suffixe

Pièce jointe 592736

Et le script :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TABLE WO_workout( WO_ident INTEGER, WO_date NUMERIC NOT NULL, WO_heure NUMERIC NOT NULL, US_ident_WO INTEGER, SE INTEGER, SE_ident_SE INTEGER, PRIMARY KEY(WO_ident), FOREIGN KEY(US_ident_WO) REFERENCES US_user(US_ident), FOREIGN KEY(SE, SE_ident_SE) REFERENCES SE_selection(US_ident, SE_ident) );

---

Si je choisis "renommer" et non "suffixer" même phénomène de doublette :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TABLE WO_workout( WO_ident INTEGER, WO_date NUMERIC NOT NULL, WO_heure NUMERIC NOT NULL, US_ident_WO INTEGER, SE_1 INTEGER, SE INTEGER, PRIMARY KEY(WO_ident), FOREIGN KEY(US_ident_WO) REFERENCES US_user(US_ident), FOREIGN KEY(SE_1, SE) REFERENCES SE_selection(US_ident, SE_ident) );

---

:koi: Y a un schmilblick ;)

Bonjour Capitaine,

Citation:

---

Envoyé par escartefigue

Par contre, étrangement, en ajoutant un rôle "SE" sur la patte SE/asso2, Looping me crée deux attributs dans WO l'un prenant le nom du rôle seul :weird:, l'autre, avec le rôle en suffixe

---

Les deux attributs correspondent à la clé composée de SE_selection liée à l'identifiant relatif.
Par contre, d'après ton premier script, le rôle SE vient renommer et non pas suffixer... :weird: (même si l'attribut venant de l'identifiant relatif est bien suffixé pour éviter toute ambiguïté).
Dans ma version, ça se comporte normalement, mais peut-être ai-je fait une correction entre temps... :calim2:
Peux-tu vérifier ?

OK en fait l'attribut "SE" est la colonne US_ident de SE_selection :aie: j'ai cru que c'était la colonne SE_ident qui était doublée avec un nom tronqué.
Perturbant !

Je reproduis le phénomène, même avec d'autres SGBD.

Pas grave puisque corrigé dans la 3.1 ;)

Citation:

---

Envoyé par escartefigue

OK en fait l'attribut "SE" est la colonne US_ident de SE_selection :aie: j'ai cru que c'était la colonne SE_ident qui était doublée avec un nom tronqué.

---

Dans la version 3.1, tu auras

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CREATE TABLE WO_workout( WO_ident INTEGER, WO_date NUMERIC, WO_heure NUMERIC, US_ident_WO INTEGER, US_ident_SE INTEGER, SE_ident_SE INTEGER, PRIMARY KEY(WO_ident), FOREIGN KEY(US_ident_WO) REFERENCES US_user(US_ident), FOREIGN KEY(US_ident_SE, SE_ident_SE) REFERENCES SE_selection(US_ident, SE_ident) );

---

Ca correspond à tes attentes ?