Discussion :

[escartefigue]

Bonjour à tous et bonnes fêtes de fin d'année

Voici quelques nouvelles propositions d'évolutions concernant le déjà excellent Looping.

Avec le modèle conceptuel suivant, pour lequel [entité 1] et [entité 2] utilisent des identifiants de type "libre" définis comme "smallint generated by default as identity", alors que [entité 3] et [entité 4] utilisent des identifiants de type "entier" :



j'obtiens le script qui suit (après avoir opté pour le SGBD DB2) :

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
CREATE TABLE Entité_1(
   ident1 smallint generated by default as identity,
   PRIMARY KEY(ident1)
);
 
CREATE TABLE Entité_2(
   ident2 smallint generated by default as identity,
   PRIMARY KEY(ident2)
);
 
CREATE TABLE Entité_3(
   ident3 SMALLINT,
   PRIMARY KEY(ident3)
);
 
CREATE TABLE Entité_4(
   ident4 INT,
   PRIMARY KEY(ident4)
);
 
CREATE TABLE Asso_1(
   ident1 smallint generated by default as identity,
   ident2 smallint generated by default as identity,
   PRIMARY KEY(ident1, ident2),
   FOREIGN KEY(ident1) REFERENCES Entité_1(ident1),
   FOREIGN KEY(ident2) REFERENCES Entité_2(ident2)
);
 
CREATE TABLE Asso_2(
   ident3 SMALLINT,
   ident4 INT,
   PRIMARY KEY(ident3, ident4),
   FOREIGN KEY(ident3) REFERENCES Entité_3(ident3),
   FOREIGN KEY(ident4) REFERENCES Entité_4(ident4)
);

Pour ce qui concerne les tables issues des types d'entité, rien à redire.

Mais, pour ce qui concerne les tables associatives, deux observations :

• curieusement, les attributs FK formant la PK de (asso_2) sont "nullables";
• également, pour (asso_1) dont les identifiants sont hérités de types libres, alors toutes ses propriétés sont répétées dans la table associative.
  
  c'est parfait pour ce qui concerne le type (char, integer, date...) ou la longueur, mais pas pour la propriété "generated" et ses options, car, bien évidemment, on veut conserver la même valeur que celle des tables parentes.

[escartefigue]

On observe le même phénomène pour l'héritage avec spécialisation: la PK du sous-type est nullable

[Paprick]

Bonjour Capitaine, et tous mes vœux pour cette nouvelle année !

Concernant les clés non nullables, Looping est toujours parti du principe que, lors qu'un attribut fait partie de la PK, il est implicitement NOT NULL : est-ce bien le cas ?

Et pour le type libre "SMALLINT GENERATED BY DEFAULT AS IDENTITY" (type compteur), c'est sûr que le type complet ne doit pas être repris dans la définition de la clé étrangère !
Tu auras sûrement remarqué que pour les identifiants explicitement définis de type "Compteur", Looping effectue la transformation.

Et bien rassure toi, tu peux aussi le faire avec les types libres !
Pour cela, il suffit que tu fasses suivre le type par celui de la clé étrangère précédé de # ; dans ton cas : SMALLINT GENERATED BY DEFAULT AS IDENTITY #SMALLINT

D'ailleurs, ça me fait penser que je n'ai pas indiqué cette astuce dans mon dernier livre...

Sache également que tu peux prédéfinir des types personnalisés depuis : Menu principal -> Paramètres LDD -> Types libres prédéfinis.

A très bientôt !

PS : La version 5.0 est dans les tuyaux pour 2026 avec :

• du multilingue (français, anglais ,espagnol),
  
• des optimisations suite à différentes demandes (dont les tiennes),
  
• la génération par l'IA de MCD à partir d'une description textuelle du système d'information.

[escartefigue]

Bonjour Paprick

Merci pour ta réponse et tous mes meilleurs vœux également

Il va sans dire que tous les attributs d'une PK sont "non nullables", mais justement, ce que je voulais dire, c'est que le script généré par Looping ne contient pas cette déclarative "not null" dans les FK constitutives de la PK des tables associatives ou des tables des sous-types.
Ce faisant, avec DB2 for Z/OS, le script est refusé en l'état, et je suis contraint d'ajouter autant de fois cette déclarative, c'est à dire pour toutes les tables associatives et pour tous les sous-types.

Autre particularité de DB2 for Z/OS : aucun index n'est créé implicitement (y compris l'index PK), je dois donc tous les ajouter dans le script, mais je m'en accommode bien volontiers, d'autant plus que la codification des noms d'objets est dépendante du site de production et le paramétrer dans looping ajouterait probablement de la complexité inutile (pour autant que je m'en souvienne, Power-AMC est une usine à gaz sur ce chapitre).

Merci pour l'astuce du symbole # associé aux types libres, j'ai d'abord cru que ça ne fonctionnait pas, mais si : il faut juste choisir un autre type puis réaffecter le type libre désiré

EDIT du coup, j'ai jouté "not null" après le symbole # dans la définition de mes types libres, ça résout l'absence de la clause "not null" pour les PK héritées des types libres, mais le problème subsiste pour les types standards.

[Paprick]

Bonjour Capitaine,

Ce DB2 for Z/OS a effectivement des exigences que les autres SGBD que je connais n'ont pas...
Certes, je pourrais rajouter systématiquement "NOT NULL" pour les FK intervenant dans les PK, mais je trouve que ce n'est pas très cohérent par rapport aux autres composantes des PK qui, elles, n'en ont pas besoin...
Une solution consiste à rajouter "NOT NULL" dans la zone "Complément" : mais, dans la version actuelle de Looping, ce complément c'est pas repris pour les FK... d'ailleurs, ce manque-là mériterait d'être corrigé dans la prochaine version de Looping.
Idéalement, il faudrait même que l'on puisse indiquer "#NOT NULL" dans cette zone "Complément" pour que ça fonctionne comme pour les types libres.
Qu'en penses-tu ?

Concernant les index, c'est quand même anormal qu'ils ne soient pas créés implicitement pour les PK ! Pour pallier ce manque, n'hésite pas à créer une règle dont le code SQL se rajoutera automatiquement au script.

[Paprick]

Re,

J'ai une autre solution en attendant : tu peux créer un SGBD personnalisé "DB2 for Z/OS" (depuis Menu principal -> Paramètres LDD) basé sur DB2 en ajoutant "NOT NULL" dans la zone "Clé étrangère compteur".
Cela résoudra le problème pour les identifiants de type "Compteur"... que tu privilégies toujours par rapport aux identifiants signifiants, si ma mémoire est bonne !).

[escartefigue]

Je trouve d'autres bizarreries que je n'avais pas identifiées :

Jai défini un modèle personnalisé basé sur DB2




et défini deux types libres




puis réalisé ce MCD



Mais dans le script :

• la propriété "not null" est parfois répétée
• la propriété "generated..." l'est également

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
CREATE TABLE TCCOCPTE(
   CPTEIDEN integer generated by default as identity,
   TCCONCPT char(11) ,
   ETABIDEN smallint not null NOT NULL,
   GUICIDEN smallint NOT NULL,
   CTYPIDEN smallint generated by default as identity NOT NULL,
   PRIMARY KEY(CPTEIDEN),
   FOREIGN KEY(ETABIDEN, GUICIDEN) REFERENCES TRBQGUIC(ETABIDEN, GUICIDEN),
   FOREIGN KEY(CTYPIDEN) REFERENCES TCCOCTYP(CTYPIDEN)
);
COMMENT ON COLUMN TCCOCPTE.CPTEIDEN IS 'identifiant technique compte';
COMMENT ON COLUMN TCCOCPTE.TCCONCPT IS 'numéro du compte';
 
CREATE TABLE TCCOPROC(
   CPTEIDEN integer not null,
   MDTRIDEN integer not null,
   PROCDTDB date NOT NULL,
   PROCDTFN date NOT NULL,
   PROCMONT decimal(11,2)   NOT NULL,
   MDANIDEN integer not null NOT NULL,
   PRIMARY KEY(CPTEIDEN, MDTRIDEN),
   FOREIGN KEY(CPTEIDEN) REFERENCES TCCOCPTE(CPTEIDEN),
   FOREIGN KEY(MDTRIDEN) REFERENCES TRPEPERS(PERSIDEN),
   FOREIGN KEY(MDANIDEN) REFERENCES TRPEPERS(PERSIDEN)
);
COMMENT ON TABLE TCCOPROC IS 'procuration sur compte';
COMMENT ON COLUMN TCCOPROC.PROCDTDB IS 'date de début';
COMMENT ON COLUMN TCCOPROC.PROCDTFN IS 'date de fin';
COMMENT ON COLUMN TCCOPROC.PROCMONT IS 'Montant

Si je change le type de TCCOCTYP.CTYPIDEN pour remplacer le type libre par un compteur standard, alors la clause "generated" positionnée à tort disparait, mais j'ai deux fois "not null"

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE TCCOCPTE(
   CPTEIDEN integer generated by default as identity,
   TCCONCPT char(11) ,
   ETABIDEN smallint not null NOT NULL,
   GUICIDEN smallint NOT NULL,
   CTYPIDEN int not null NOT NULL,
   PRIMARY KEY(CPTEIDEN),
   FOREIGN KEY(ETABIDEN, GUICIDEN) REFERENCES TRBQGUIC(ETABIDEN, GUICIDEN),
   FOREIGN KEY(CTYPIDEN) REFERENCES TCCOCTYP(CTYPIDEN)
);

En résumé le "not null" ajouté dans les types perso pour résoudre les soucis de FK nullables dans les tables associatives pollue les FK des tables issues des types d'entité et le modèle personnalisé perturbe la clause "generated" des compteurs

[Paprick]

Il semblerait que les "NOT NULL" des FK voyagent mal à travers le passage par plusieurs tables (Identité relative, ...)
Peux-tu m'envoyer le .loo de ton MCD ? je m'en servirai de référence pour corriger le tir sur la prochaine version de Looping.

[escartefigue]

Oui c'est visiblement une conséquence de l'identification relative.

J'ai déposé le MCD ici :
http://escartefigue.developpez.com/E...D1_DB2_ZOS.loo

J'avais fait d'autres propositions d'améliorations, si des fois ça peut aussi être pris en compte, elles sont ici :
https://www.developpez.net/forums/d2...e-zones-texte/

et signalé un bug rencontré avec les types d'entité fictives ici :
https://www.developpez.net/forums/d2.../#post12108172

À ta disposition si besoin d'éclaircissements