, , , , , , , Power Week 2025 : 3 jours pour se connecter, apprendre et faire rayonner la communauté IBM i

Cela n’a pas pu vous échapper, la semaine prochaine c’est (déjà) la Power Week, événement gratuit coorganisé par IBM France et Common France :

Durant ces 3 jours dédiés au Power Systems, au stockage, au Power11, à l’IA, à l’IBM i, AIX, Linux, la modernisation … retrouvez l’ensemble des speakers, des partenaires et des clients qui font la force de notre plateforme.

Un programme riche (et international)

Pendant trois jours, les participants auront accès à des sessions animées par les meilleurs experts, venus de France, d’Allemagne, des États-Unis … Parmi eux, des IBM Champions, reconnus pour leur expertise et leur engagement auprès de la communauté, partageront leurs connaissances sur des sujets variés : modernisation, sécurité, SQL, DevOps, IA, cloud hybride, et bien plus encore.

👉 Consultez le programme complet ici https://powerweek2025.sched.com/

Un événement gratuit, ouvert à tous

La Power Week est 100 % gratuite et ouverte à tous les professionnels de l’IBM i : développeurs, architectes, DSI, chefs de projet, consultants… C’est une opportunité rare de bénéficier de contenus de qualité sans contrainte logistique ni financière.

La force de la communauté

Au-delà des conférences, la Power Week est un lieu de rencontre et d’échange. Elle permet de :

  • Réseauter avec d’autres professionnels confrontés aux mêmes enjeux
  • Confronter les points de vue, partager des bonnes pratiques
  • Découvrir les clubs utilisateurs comme Common France, qui jouent un rôle dans l’animation de la communauté en France, mais aussi au niveau Européen.

Ces moments d’échange sont essentiels pour faire évoluer les pratiques, identifier des solutions concrètes, et tisser des liens durables.

Vers le prochain grand rendez-vous : Common Europe Congress à Lyon

La Power Week est aussi une étape vers un autre événement majeur : le Common Europe Congress, qui se tiendra à Lyon du 14 au 17 juin prochain. Ce congrès réunira la communauté IBM i européenne autour de conférences, ateliers, et moments conviviaux. Une occasion unique de faire rayonner notre territoire et notre expertise.

C’est la première fois en France depuis 1997, une autre ère !

Gaia et Volubis

Retrouvez toutes les informations sur Common France : https://commonfrance.fr/

Les speakers de Gaia et Volubis sont très heureux de participer à cette célébration : échange, partage, connaissance.

En tant que sociétés liées à la formation, il est dans notre ADN de participer à ces initiatives, comme nous le faisons depuis longtemps : les Universités IBM i depuis 2011, Pause Café en physique ou en ligne, articles de blogs …

N’hésitez pas à solliciter nos speakers sur place !

/par
, , Query en V7R6

Query est de moins en moins utilisé sur IBMi.

Mais certain d’entre vous continuent de l’utiliser et depuis la version 7.6 l’option 1 ne fonctionne plus.

Quand vous lancez cette option rien rien ne se passe …

==>STRQRY

Pas de panique ce problème est connu chez IBM

L’apar DT435933 semble décrire ce problème : http://ibm.com/mysupport/s/defect/aCIKe000000XwKIOA0/dt435933?language=en_US

il est corrigé par la SJ05457 https://www.ibm.com/mysupport/s/fix-information/aDrgJ000000006TSAQ/fi0135164?language=en_US

Une fois la récupération et l’application de la PTF, tout fonctionne normalement

APYPTF LICPGM(5770SS1) SELECT(SJ05457)
Objet QQUDA de QSYS type *PGM rebaptisé QPZA002137.
Objet QPZR002137 de QSYS type *PGM rebaptisé QQUDA.
PTF 5770SS1-SJ05457 V7R6M0 appliquée provisoirement à bibliothèque QSYS

Conclusions:

Mais n’oubliez pas vous devez continuer à migrer vos querys vers des requêtes SQL, plus faciles à gérer

U

/par
, Génération d’un UUID

Un UUID (Universally Unique Identifier), également appelé GUID (Globally Unique Identifier), est un identifiant conçu pour être unique à l’échelle mondiale. Il est couramment utilisé dans les échanges de données via des webservices pour identifier de manière fiable des ressources.

Voici trois méthodes permettant de générer des UUID sur votre système IBM i.

1) En SQL

Depuis peu, la génération d’UUID est possible directement en SQL via la fonction scalaire GENERATE_UUID.

Nécessite :

IBM i 7.5 : SF99950 niveau 8

IBM i 7.4 : SF99704 niveau 29

2) En RPG

Il est également possible de générer un UUID en RPG en utilisant l’API MI _GENUUID. Pour obtenir le résultat au format hexadécimal, il convient de l’associer à la procédure cvthc.

**free
ctl-opt dftactgrp(*no);

dcl-s uuidHexa   char(32) inz ;
dcl-c UUID_VERSION 4;

// DS d'un UUID
dcl-ds DSUUID qualified template;
   bytesProv  uns(10)  inz(%size(DSUUID));
   bytesAvail uns(10)  inz(0);
   version    uns(3)   inz(0);
   *n         char(7)  inz(*allx'00');
   uuid       char(16) inz(*allx'00');
End-ds;
dcl-ds UUID      likeds(DSUUID) inz(*LIKEDS);

// Prototype récupération UUID
dcl-pr generUUID extProc('_GENUUID');
   dsuuid likeds(DSUUID);
End-pr;

// Conversion caractère -> hexa
dcl-pr CharToHex ExtProc('cvthc');
   hexResult    Char(65534)  Options(*VarSize);
   charInput    Char(32767)  Options(*VarSize);
   charNibbles  Int(10)  Value;
End-Pr;

dcl-pi *n ;
end-pi ;

UUID.version = UUID_VERSION;

// génération de l'UUID
generUUID(UUID);

// Conversion en hexa
CharToHex ( uuidHexa : UUID.uuid : %Size(UUID.uuid) * 2 );

dsply %concat('-':%subst(uuidHexa:1:8):%subst(uuidHexa:9:4):
      %subst(uuidHexa:13:4):%subst(uuidHexa:17:4):
      %subst(uuidHexa:21:12)) ;

*inlr = *on;

3) Opensource

Dernière proposition, utiliser la commande uuidgen.

Nécessite libuuid1

/par
, , Schéma de base données dans VSCode

Il est possible avec certains logiciels de voir le schéma relationnel de votre base de données sous forme de diagramme.

Exemple dans DBEAVER :

L’inconvénient est qu’il faut ouvrir une fenêtre supplémentaire.

Si vous travaillez dans VSCode, voici une petite astuce pour afficher un schéma de BDD.

Installation de l’extension

Tout d’abord il faut installer l’extension DBML Entity-Relationship Diagrams visualizer :

https://marketplace.visualstudio.com/items?itemName=bocovo.dbml-erd-visualizer

Si vous ne l’avez pas encore fait, installer l’extension Code For i

https://marketplace.visualstudio.com/items?itemName=HalcyonTechLtd.code-for-ibmi

Récupération et compilation

Ensuite télécharger et compiler le programme RPG / commande ci-dessous :

Sources

Compiler en remplaçant <BIBOBJ> et <BIBSRC> par votre bibliothèque :

CRTSQLRPGI OBJ(<BIBOBJ>/TODBML) SRCFILE(<BIBSRC>/QRPGLESRC) CLOSQLCSR(*ENDMOD) OPTION(*EVENTF) DBGVIEW(*SOURCE) TGTRLS(*CURRENT) RPGPPOPT(*LVL2)
CRTCMD CMD(<BIBOBJ>/TODBML) PGM(<BIBOBJ>/TODBML) SRCFILE(<BIBSRC>/QCMDSRC) ALLOW(*ALL) CURLIB(*NOCHG) PRDLIB(*NOCHG)

Ajout de l’action Code for i

Ajouter l’action dans VSCode en remplaçant <BIBOBJ>, <BIBBDD>, <PATH> par votre bibliothèque, la bibliothèque de base de données et le chemin du fichier à générer :

?<BIBOBJ>/TODBML LIB(<BIBBDD>) PATH('<PATH>')

Paramètres de la commande:

LIB : Bibliothèque de la base de données

PATH : Le chemin du fichier dbml qui sera généré

Exemple :

ps : Vous pouvez faire une action de type « fichier » avec rafraichissement de filtre.

Lancer l’action

Visualisation du diagramme

Ouvrir le fichier et cliquer sur l’icone « show diagram » en haut à droite.

A vous de jouer !

Il est intéressant de constater que la richesse du rendu semble proportionnelle à la densité des relations dans la base… une coïncidence, sans doute 🙂

/par
, , , , Analyser les certificats TLS par SQL

Si comme nous vous avez de nombreux certificats sur vos systèmes, le ménage peut s’avérer compliqué. En effet, au fur et à mesure des renouvellements, les nouveaux certificats sont installés, les nouvelles autorités également.

Mais les suppressions de certificats sont souvent remises à plus tard. Et l’on se retrouve avec un nombre importants de certificats pour lesquels il est préférable de contrôler la non utilisation avant suppression.

SQL va nous aider ici, avec le service qsys2.certificate_info (cf https://www.ibm.com/docs/en/i/7.6.0?topic=services-certificate-info-table-function) capable de nous donner la liste des certificats et leurs attributs.

qsys2.certificate_info

Permet d’obtenir facilement les principales informations sur les certificats et autorités de certification du magasin *SYSTEM :

La même vue dans DCM :

Et on remarque donc la nécessité du ménage (dans mon cas).

Premièrement, comment faire la distinction entre les certificats et les autorités de certifications ? En utilisant la colonne PRIVATE_KEY_STORAGE_LOCATION.

Autorité de certification

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
  where( PRIVATE_KEY_STORAGE_LOCATION <> 'SOFTWARE' or PRIVATE_KEY_STORAGE_LOCATION  is null)

Certificat

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
    where PRIVATE_KEY_STORAGE_LOCATION = 'SOFTWARE'

Validité

Le premier élément trivial : quels sont les certificats périmés :

select CERTIFICATE_LABEL,
       VALIDITY_START,
       VALIDITY_END,
       DOMAIN_NAMES,
       SUBJECT_COMMON_NAME,
       SUBJECT_ORGANIZATION,
       ISSUER_COMMON_NAME,
       ISSUER_ORGANIZATION,
       PRIVATE_KEY_STORAGE_LOCATION 
  from table (
      qsys2.certificate_info(certificate_store_password => '*NOPWD')
    )
  where validity_end <= current timestamp
  order by validity_end asc  ;

Lien

Les certificats sont émis (signés) par des autorités de certification, le lien entre les deux est donc un élément indispensable.

Nous pouvons donc maintenant répondre aux questions suivantes :

Pour chaque certificat client/serveur, quel est l’autorité de certification ?

Mais cela génère des doublons :

En effet, nous faisons le lien via le Common Name de l’autorité. Mais celui-ci n’est pas obligatoirement unique, et c’est bien le cas sur les autorités locales créées via les assistants de configuration IBM i.

Pour avoir un identifiant unique, il nous faut utiliser les identifiants de clés, qui elles sont distinctes :

Mais cette information est absente de la fonction table qsys2.certificate_info.

Nous donnerons une solution (pas si simple) lors d’un prochain article dédié.

Malgré tout, ce problème ne concerne « que » les certificats générés depuis une autorité locale, elle même créée via les assistants IBM i, les autorités publiques ayants des noms uniques.

Si l’on prend un certificat acheté via Gandi :

On obtient bien une information unique et exploitable.

Pour chaque autorité, quels sont les certificats émis ?

Par exemple :

Extrait du résultat :

Par extension, quelles sont les autorités inutilisées ?

Produit :

Et le ménage ?

Avec les requêtes précédentes, vous pouvez isoler les certificats et autorités périmés ou les autorités inutilisés (dans notre cas les autorités n’ayant pas généré de certificat). Et vous pouvez donc les supprimer de façon ciblée.

Attention : les autorités et certificats peuvent être utiles et utilisés en dehors des liens vus ici. Ces requêtes permettent donc d’aider à la décision, mais ce n’est pas un automatisme !

Pour aller plus loin

Nous pouvons inclure l’analyse des applications DCM : liens applications/certificats.

Et également utiliser les API RSE pour automatiser la suppression des certificats.

Et rendre nos requêtes récursives pour permettre de suivre une hiérarchie à plus d’un niveau

Voir l’idea soumise pour avoir le lien certificat -> autorité dans la vue qsys2.certificate_info : https://ibm-power-systems.ideas.ibm.com/ideas/IBMI-I-4628

/par
, , , , SQL : « dump » des enregistrements d’une table

Suite à des demandes multiples, je propose une implémentation de « DUMP » des enregistrements d’une table (plutôt d’un objet *FILE / PF-DTA, que ce soit un PF ou une table).

L’idée est d’obtenir u script SQL contenant les instructions INSERT permettant de reproduire les données dans une autre base.

A l’image de la commande mariadb-dump par exemple (https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump). C’est un moyen commun de faire des sauvegarde/restauration de la base pour ces technologies.

DMPSQL

Oui, je ne détaille pas ici le processus de mise à jour, c’est classique : téléchargement des images et clés sur ESS, PRUV pour les contrôle etc …

Le fichier SQLSAMPLE/EMPLOYEE est ici produit par :

CALL QSYS.CREATE_SQL_SAMPLE ('SQLSAMPLE')

Cette procédure vous permet de créer et recréer des bases de données à des fins d’exemple et de tests.

Contenu du fichier :

Il s’agit d’une table très classique, représentative de la plupart des données dans nos applications.

Exemple d’usage :

DMPSQL FILE(SQLSAMPLE/EMPLOYEE)
SQLSCRIPT('/home/NB/employee.sql')

Le résultat de notre commande :

Le fichier est en UTF-8 afin de permettre la gestion de l’ensemble des caractères usuels.

Le code est disponible ici : https://github.com/FrenchIBMi/Outils/tree/master/DMPSQL

Usage ?

Cela permettait de répondre à plusieurs demandes.

Premièrement, la réplication de données sans utiliser les commandes de sauvegarde/restauration. Ces dernières nécessitent des droits élevés, alors qu’ici nous ne faisons que manipuler de la donnée.

Deuxièmement, dans le cadre de traitement de journaux (initialement en vue d’une fonction de type CDC), pour permettre d’isoler un enregistrement que l’on souhaite répliquer (avec ou sans transformation) dans une autre table.

Vous trouverez certainement d’autres usages !

Limites

Le code est fourni « as is », pour démonstration.

Quelques limites d’usage actuellement

  • Types de colonnes non supportées actuellement : CLOB, BLOB, DATALINK, XML, GRAPHIC, VARGRAPHIC, {VAR}CHAR CCSID 65535
  • Pas plus de 16Mo par enregistrement
  • On ne gère pas les alias, partitions, IASP
  • 250 colonnes maximum
  • En cas de multi-membres, seul le premier membre est traité

On peut bien évidemment ajouter de nouvelles fonctionnalités !

N’hésitez pas à donner un feedback, améliorer le code

/par
, , Utiliser l’instruction merge en SQL

Vous avez une instruction SQL , MERGE qui est assez PUISSANTE pour fusionner des fichiers
Voici un exemple complet :


Il intègre les éléments suivants
-La création
-La mise à jour
-La suppression


On a 2 tables Products et Mouvements

Les règles choisies sont les suivantes :

-Si le produit existe on ajoute la quantité
-S’ il est nouveau, on le créé
-Si nom du produit est SUPPRESSION, on supprime

J’ai utilisé la convention de nommage *SYS

et dans tous les cas on met à jour la date de modification

-- voici les scripts pour tester 
-- Création de la table des produits
-- Option *SYS et *NONE 
CREATE TABLE GDATA/PRODUCTS (
    PRODUCT_NUMBER  DECIMAL(10, 0)      NOT NULL ,
    PRODUCT_NAME    VARCHAR(100)        NOT NULL,
    QUANTITY        DECIMAL(10, 0)      NOT NULL DEFAULT 0,
    LAST_UPDATE_TS  TIMESTAMP           NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (PRODUCT_NUMBER)
    );
-- alimentation du fichier
INSERT INTO GDATA/PRODUCTS VALUES(1, 'CLOU', 50, current timestamp) ;
INSERT INTO GDATA/PRODUCTS VALUES(2, 'VIS', 20, current timestamp) ;
INSERT INTO GDATA/PRODUCTS VALUES(3, 'ECROU', 25, current timestamp) ;
INSERT INTO GDATA/PRODUCTS VALUES(4, 'RONDELLE', 120, current timestamp) ;
-- Création de la table des mouvements
CREATE TABLE GDATA/MOUVEMENTS (
    PRODUCT_NUMBER  DECIMAL(10, 0)      NOT NULL ,
    PRODUCT_NAME    VARCHAR(100)        NOT NULL,
    QUANTITY        DECIMAL(10, 0)      NOT NULL DEFAULT 0,
    LAST_UPDATE_TS  TIMESTAMP           NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (PRODUCT_NUMBER)
    );
-- alimentation de la tables des mouvements
INSERT INTO GDATA/MOUVEMENTS VALUES(1, 'CLOU', 30, current timestamp) ; -- changement de quantité
INSERT INTO GDATA/MOUVEMENTS VALUES(3, 'SUPPRESSION', 0, current timestamp) ; -- suppression
INSERT INTO GDATA/MOUVEMENTS VALUES(5, 'RESSORT', 100, current timestamp); -- Nouveau
-- Fusion des 2 tables 
MERGE INTO GDATA/PRODUCTS AS T  -- T est l'alias de la table CIBLE (PRODUCTS)
USING GDATA/MOUVEMENTS AS S      -- S est l'alias de la table SOURCE (MOUVEMENT)
ON (T.PRODUCT_NAME = S.PRODUCT_NAME) -- La jointure se fait sur le nom du produit
-- 1. Gérer la suppression si le produit correspond ET que la source indique 'SUPPRESSION'
WHEN MATCHED AND S.PRODUCT_NAME = 'SUPPRESSION' THEN
    DELETE
-- 2. Gérer la mise à jour si le produit correspond ET que la source N'indique PAS 'SUPPRESSION'
WHEN MATCHED AND S.PRODUCT_NAME <> 'SUPPRESSION' THEN
    UPDATE SET T.QUANTITY = T.QUANTITY + S.QUANTITY,
               T.LAST_UPDATE_TS = CURRENT_TIMESTAMP
-- 3. Gérer l'insertion si le produit NE correspond PAS ET que la source N'indique PAS 'SUPPRESSION'
WHEN NOT MATCHED AND S.PRODUCT_NAME <> 'SUPPRESSION' THEN
    INSERT (PRODUCT_NUMBER, PRODUCT_NAME, QUANTITY, LAST_UPDATE_TS)
    VALUES (S.PRODUCT_NUMBER, S.PRODUCT_NAME, S.QUANTITY, CURRENT_TIMESTAMP);

Remarque :

Vous pouvez également utiliser la commande CPYF avec le paramètre MBROPT(*UPDADD) mais plus compliqué de gérer les suppressions.

Bien sur , bien tester tous les cas

/par
, Visual Explain : affichage des index considérés

Access Client Solutions 1.1.9.8, disponible depuis avril 2025, amène son lot d’évolutions. Une m’a particulièrement intéressée : l’affichage des index considérés.

Visual Explain, les index ?

Visual Explain permet d’afficher le plan d’exécution de la requête SQL : l’ensemble des étapes nécessaires à l’obtention du résultat, de la façon la plus optimisée possible.

Pour déterminer la façon la plus optimisée, le moteur SQL va réécrire la requête, considérer les index/LF existants, exploiter les statistiques de chaque table, index ou clé sous-jacents aux tables utilisées dans la requête.

Dans le plan affiché, pour une première analyse macroscopique, on cherche en général les éléments suivants :

  • Scan de table : on préfère utiliser des accès par index plutôt que parcourir l’ensemble de la table. Il s’agit d’analyser pourquoi aucun index ne satisfait les conditions de la requête
  • Les index utilisés : même si l’on se félicite de l’utilisation d’index, il est souvent possible de faire mieux
  • Les index recommandés : justement pour faire mieux !

Une information est disponible mais difficilement exploitable : l’optimiseur explique pour chaque index trouvé pourquoi il a été utilisé, ou pourquoi il ne l’a pas été.

Un exemple

Nous avons une table dans laquelle nous consolidons certains événements logués par nos serveurs web (access_log générés par Apache). Aujourd’hui cette table HTTPLOG contient environ 240 millions d’entrées, et dispose bien évidemment d’un certains nombres d’index existants :

Prenons une requête basique :

L’affichage de Visual Explain nous montre :

En sélectionnant l’étape « Test de table », le volet de droite indique :

Ce sont la liste des index que l’optimiseur a regardé et le chiffre correspond au code qui indique pourquoi il n’a pas été utilisé. Il est possible d’aller chercher le détail des codes dans les messages (il faut activer les messages de débogage).

Cette information est accessible pour chaque étape du plan, dans le cas de jointure ou de sous-requête.

Index considérés

Prenons une autre requête SQL permettant d’analyser toutes les requêtes HTTP authentifiées et dont le retour provoque un warning ou une erreur (autre que code HTTP 200 OK).

Visual Explain nous donne :

Nous retrouvons bien entendu nos informations sur les index :

Mais il est maintenant possible de demander ces informations pour l’ensemble de la requête :

Et d’obtenir des libellés plus parlants :

Cela vous donne plus d’informations quant à l’usage des index. Pour compléter, l’index advisor nous donne :

A noter que l’optimiseur ne propose pas d’index dérivé par exemple, ou difficilement les index EVI … Gardez donc un œil critique sur ces informations, mais leur compréhension est nécessaire.

/par
, , Gestion du SQLCODE dans un SQL embarqué

En SQL embarquée la gestion des erreurs est différente par rapport à un RPGLE classique.


Essentiellement sur 2 points


1) Ca ne plante pas
Vous pouvez donc avoir des erreurs silencieuses
Il est très important de traiter les SQLCODE
Même si vous pensez ne pas en avoir besoin
Les 3 lignes suivantes peuvent être ajoutées sans risque !

EXEC SQL ... ;
IF SQLCODE <> 0;
DSPLY ('nompgm' + ' : ' + %CHAR(SQLCODE) ;
ENDIF;


Permettra d’avoir un message dans la log qui peut vous aider en cas de probléme.

2) On n’a le résultat de la dernière instruction dans le SQLCODE.

Le risque est donc sur une boucle, il est possible que le SQLCODE soit parasité par une autre requête SQL dans une autre fonction par exemple 

dou sqlcode <> 0                    ;
  exec sql ... ;                                         
  if sqlcode <> 0                   ;
    leave                           ;
  endif                             ;
enddo                               ;

Pour éliminer ce probléme vous devez sauvegarder votre SQLCODE dans une variable de travail

Votre boucle deviendra

// Déclaration de la variable de travail ! 
DCL-S  W_SQLCODE like SQLCODE; 
//
dou w_sqlcode <> 0                    ;
  exec sql ... ;                                         
  if sqlcode <> 0                   ;
    leave                           ;
  endif                             ;
  W_SQLCODE = SQLCODE                 ;
enddo

Ainsi vous êtes sur de tester le bon SQLCODE

Remarque :
Pour ceux qui utilisent le sqlstate, la remarque est la même.
Vous pouvez être plus précis que <> 0 ;

Rappel :
en dessus de 0 c’est des avertissements
en dessous c’est des erreurs
par exemple if sqlcode < 0 ; traitera les erreurs uniquement

/par
, , , Clé, contrainte et index : quelles différences ?

Dans une base de données bien définie, nos enregistrements sont identifiés par des clés (ie unique). Il existe toutefois différentes façon de matérialiser ces clés en SQL.

Première bonne résolution : on ne parlera pas ici des DDS (PF/LF) !

Quelques rappels

je n’insiste pas, mais une base de donnée relationnelle, DB2 for i dans notre cas, fonctionne à la perfection, à condition de pouvoir identifier nos enregistrements par des clés.

Cf https://fr.wikipedia.org/wiki/Forme_normale_(bases_de_donn%C3%A9es_relationnelles)

Une normalisation raisonnable pour une application de gestion est la forme normale de Boyce-Codd (dérivée de la 3ème FN).

Clés

Vous pouvez implémenter vos clés de différentes façons, voici une synthèse :

TypeOùSupport valeur nulle ?Support doublon ?Commentaire
Contrainte de clé primaireTableNonNonValeur nulle non admise, même si la colonne clé le supporte
Contrainte d’unicitéTableOuinon : valeurs non nulles
oui : valeurs nulles 		Gère des clés uniques uniquement si non nulles
Index uniqueIndexOuiNonGère des clés uniques.
La valeur NULL est supportée pour 1 unique occurrence
Index unique where not nullIndexOuisnon : valeurs non nulles
oui : valeurs nulles 		Gère des clés uniques uniquement si non nulles

Attention donc à la définition de UNIQUE : à priori ce qui n’est pas NULL est UNIQUE.

Concrètement ?

Prenons un cas de test simpliste pour montrer la mécanique : un fichier article avec une clé et un libellé

Clé primaire

La colonne CODE admet des valeurs nulles, mais est fait l’objet de la contrainte de clé primaire.

A la création de la contrainte de clé primaire, le système créé automatiquement une contrainte de type CHECK pour interdire l’utilisation de valeur nulle dans cette colonne :

Avec :

La clé primaire joue son rôle avec des valeurs non nulles :

Et des valeurs nulles :

On retrouve ici le nom de la contrainte générée automatiquement !

Avec une contrainte de clé unique ?

Le comportement est identique sur une clé non nulle.

Mais avec une clé nulle (ou dont une partie est nulle si elle composée) :

On peut ajouter un index unique pour gérer le problème. Dans ce cas, une et une seule valeur nulle sera acceptée :

Mais dans ce cas pourquoi ne pas utiliser une clé primaire ??

Clé étrangère, jointure

Ajoutons un fichier des commandes, ici une simplification extrême : 1 commande = 1 article.

On ajoute une contrainte de clé étrangère qui matérialise la relation entre les tables commande et article. Pour cette contrainte commande_FK, il doit exister une contrainte de clé primaire ou de clé unique sur la colonne CODE dans la table article.

La contrainte se déclenche si l’article référencé n’existe pas :

Cas identique mais en s’appuyant sur la table article_unique qui dispose d’une clé unique et non primaire :

Dans ce cas les valeurs nulles sont supportées, en multiples occurrences (sauf à ajouter encore une fois un index unique au niveau de la commande).

Récapitulons ici nos données pour comprendre les jointures :

Démarrons par ARTICLE & COMMANDE :

La table ARTICLE ne peut pas avoir de clé nulle, donc pas d’ambiguïté ici

Avec right join ou full outer join nous accèderons au lignes de commande pour lesquelles CODE = null.

C’est le comportement attendu.

Voyons avec ARTICLE_UNIQUE et COMMANDE :

Ici on pourrait s’attendre à obtenir également les lignes 11 et 12 de la table COMMANDE : le CODE est nulle pour celles-ci, mais il existe une ligne d’ARTICLE pour laquelle le code est null. Il devrait donc y avoir égalité.

En réalité les jointures ne fonctionnent qu’avec des valeurs non nulles

De même que la clause WHERE :

Il faut donc utiliser ce style de syntaxe :

C’est à dire :

  • soit remplacer les valeurs nulles par des valeurs inexistantes dans les données réelles
  • soit explicitement indiquer la condition de nullité conjointe

Bref, syntaxiquement cela va rapidement se complexifier dans des requêtes plus évoluées.

Clé composée

Evidemment, c’est pire ! Imaginons que l’on ait une clé primaire/unique dans la table ARTICLE composée de 2 colonnes (CODE1, CODE2), et donc présentes toutes les deux dans la table COMMANDE :

Et les performances ?

En utilisant la jointure, l’optimiseur est capable de prendre en charge des accès par index :

Mais en utilisant IFNULL/COALESCE, ces valeurs deviennent des valeurs calculées, ce qui invalide l’usage des index :

Ce n’est donc pas viable sur des volumes plus importants. Il existe des solutions (index dérivés par exemple) mais la mécanique se complique encore !

Préconisations

De façon générale pour vos données de gestion, en excluant les fichier de travail (QTEMP a d’autres propriétés), les fichiers de logs, les fichier d’import/export …

  • Pas de valeur NULL dans vos clés
    • Pour les clés atomique c’est une évidence, pour les clés composées c’est beaucoup plus simple
  • Une contrainte de clé primaire pour toutes vos tables !
    • N’hésitez pas à utiliser des clés auto-incrémentées
  • Des contraintes d’unicités ou des index uniques pour vos autres contraintes d’unicité, techniques ou fonctionnelles
    • Pas d’excès, sinon il y a un défaut de conception (cf les formes normales)
  • Si possible des contraintes de clé étrangère pour matérialiser les relations entre les tables
    • Délicat sur l’existant, les traitements doivent tenir compte du sens de la relation
  • Favorisez l’usage des clés, contraintes et index par l’optimiseur
    • Scalabilité entre vos environnements de développement/test et la production
/par