Le fichier logique (LF) : une autre vue des mêmes données

Pourquoi les LF existent

Dès 1978, le recueil technique d'IBM sur le System/38 annonce, parmi les caractéristiques clés de ce que le système offre à ses utilisateurs, l'indépendance des programmes vis-à-vis de la structure physique des fichiers, grâce aux fichiers logiques. L'idée : les données sont rangées une fois, dans les PF ; chaque programme les voit comme il en a besoin, dans son ordre, avec ses zones, sans dupliquer les données.

Le même recueil décrit les LF comme des vues logiques et des ordres différents des données des PF, jusqu'à entremêler plusieurs PF dans un seul ordre (le LF multi-format). La documentation actuelle d'IBM ajoute un usage précieux : quand on ajoute une zone à un PF, un LF peut présenter l'ancien format aux programmes existants, qui n'ont pas besoin d'être recompilés.

Nos deux PF de départ :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* Pokemon : un enregistrement par Pokemon, toutes generations
     A          R POKEMONR                  TEXT('Pokemon')
     A            NUMPOK         4S 0       COLHDG('No' 'Pokedex')
     A            NOM           12A         COLHDG('Nom')
     A            TYPE1         10A         COLHDG('Type')
     A            GEN            1S 0       COLHDG('Gen')
     A          K NUMPOK
     A* Attaques : plusieurs par Pokemon
     A          R ATTAQUER                  TEXT('Attaque')
     A            NUMPOK         4S 0       COLHDG('No' 'Pokedex')
     A            ATTAQUE       15A         COLHDG('Attaque')
     A            PUISS          3S 0       COLHDG('Puissance')
     A          K NUMPOK
     A          K ATTAQUE

Un autre ordre : la clé

POKEMON est trié par numéro de Pokédex. Pour les lire par type, puis par nom, un LF suffit :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* LF : les Pokemon dans lordre du type, puis du nom
     A          R POKEMONR                  PFILE(POKEMON)
     A          K TYPE1
     A          K NOM

PFILE(POKEMON) désigne le PF. Aucune zone n'est listée : le LF reprend alors le format du PF, et IBM impose que son nom soit le même (POKEMONR). Les deux lignes K forment la nouvelle clé. On crée le LF avec CRTLF, comme un PF avec CRTPF :

CRTLF  FILE(JOBIPOK/POKETYPE) SRCFILE(JOBIPOK/QDDSSRC)
CPC7301  Fichier POKETYPE créé dans la bibliothèque JOBIPOK.
CPC7305  Membre POKETYPE ajouté au fichier POKETYPE de JOBIPOK.

Un programme RPG qui lit ce LF par clé reçoit les Pokémon dans l'ordre voulu :

**free
// Lit le LF POKETYPE dans l'ordre de sa cle : type, puis nom.
ctl-opt dftactgrp(*no) actgrp(*new);

dcl-f poketype keyed;

read poketype;
dow not %eof(poketype);
  snd-msg %trim(type1) + ' : ' + %trim(nom);
  read poketype;
enddo;

*inlr = *on;

Électrik : Pichu
Électrik : Pikachu
Eau : Carapuce
Eau : Kaiminus
Feu : Héricendre
Feu : Salamèche
Plante : Bulbizarre
Plante : Germignon
Psy : Lugia
Psy : Mewtwo

« Électrik » passe avant « Eau » : la clé est triée sur les codes EBCDIC des caractères, où les majuscules accentuées comme É viennent avant les lettres sans accent. Un SQL ORDER BY TYPE1, NOM sur notre système rend le même ordre.

Une sélection : seulement le type Feu

Une ligne S (sélection) avec COMP ne garde que certains enregistrements :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* LF avec selection : les Pokemon de type Feu
     A          R POKEMONR                  PFILE(POKEMON)
     A          K NOM
     A          S TYPE1                     COMP(EQ 'Feu')

SELECT * FROM JOBIPOK.POKEFEU

NUMPOK  NOM         TYPE1  GEN
     4  Salamèche   Feu      1
   155  Héricendre  Feu      2

Un programme qui lit POKEFEU ne voit jamais les autres Pokémon : la sélection est faite par le système, pas par le programme.

La jointure : le Pokémon et ses attaques

Le LF de jointure réunit sur une même ligne des zones de plusieurs PF :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* LF de jointure : le nom du Pokemon avec chacune de ses attaques
     A          R POKEJOINR                 JFILE(POKEMON ATTAQUE)
     A          J                           JOIN(POKEMON ATTAQUE)
     A                                      JFLD(NUMPOK NUMPOK)
     A            NUMPOK                    JREF(POKEMON)
     A            NOM
     A            ATTAQUE
     A            PUISS
     A          K NUMPOK

• JFILE(POKEMON ATTAQUE) : les fichiers joints. Le premier est le fichier primaire, les autres sont secondaires.
• La ligne J décrit une jointure : JOIN donne la paire de fichiers, JFLD les zones qui les relient (le numéro dans les deux).
• JREF(POKEMON) : NUMPOK existe dans les deux PF, il faut dire lequel prendre.
• La clé K NUMPOK vient du fichier primaire, comme l'exige IBM.

SELECT * FROM JOBIPOK.POKEJOIN

NUMPOK  NOM         ATTAQUE       PUISS
     1  Bulbizarre  Fouet Lianes     45
     4  Salamèche   Flammèche        40
     7  Carapuce    Pistolet à O     40
    25  Pikachu     Éclair           40
    25  Pikachu     Tonnerre         90
   155  Héricendre  Flammèche        40

Six lignes : Pikachu deux fois, et les Pokémon sans attaque (Mewtwo, Germignon, Kaiminus, Pichu, Lugia) ont disparu. Pour les garder, le mot-clé JDFTVAL, au niveau du fichier, complète les zones absentes par leurs valeurs par défaut, blancs et zéros :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* LF de jointure avec JDFTVAL : aussi les Pokemon sans attaque
     A                                      JDFTVAL
     A          R POKEJDFTR                 JFILE(POKEMON ATTAQUE)
     A          J                           JOIN(POKEMON ATTAQUE)
     A                                      JFLD(NUMPOK NUMPOK)
     A            NUMPOK                    JREF(POKEMON)
     A            NOM
     A            ATTAQUE
     A            PUISS
     A          K NUMPOK

NUMPOK  NOM         ATTAQUE       PUISS
     1  Bulbizarre  Fouet Lianes     45
     …
   150  Mewtwo                         0
   152  Germignon                      0
   155  Héricendre  Flammèche        40
   158  Kaiminus                       0
   172  Pichu                          0
   249  Lugia                          0      (11 lignes)

Les règles du LF de jointure

• On ne peut pas modifier un PF à travers un LF de jointure : il est en lecture seule.
• DFU (donc UPDDTA) ne sait pas afficher un LF de jointure.
• Un seul format, qui ne peut pas être partagé avec un autre fichier.
• Les zones clés viennent du premier fichier de JFILE, le fichier primaire.
• Pas de contrôle de validation (commitment control).

UPDATE JOBIPOK.POKEJOIN SET PUISS = 50 WHERE NUMPOK = 4
SQL0150  Vue, index ou table POKEJOIN de JOBIPOK en lecture seule.

Pour modifier, on passe par les PF eux-mêmes.

Les équivalents SQL : index et vues

Clé, sélection, jointure : SQL fait la même chose avec deux instructions.

-- La clé de POKETYPE
CREATE INDEX JOBIPOK.POKEMON_PAR_TYPE ON JOBIPOK.POKEMON (TYPE1, NOM);

-- La sélection de POKEFEU
CREATE VIEW JOBIPOK.POKEMON_FEU AS
  SELECT NUMPOK, NOM, TYPE1, GEN FROM JOBIPOK.POKEMON WHERE TYPE1 = 'Feu';

-- La jointure avec JDFTVAL : un LEFT JOIN
CREATE VIEW JOBIPOK.POKEMON_ATTAQUES AS
  SELECT P.NUMPOK, P.NOM, A.ATTAQUE, A.PUISS
    FROM JOBIPOK.POKEMON P
    LEFT JOIN JOBIPOK.ATTAQUE A ON A.NUMPOK = P.NUMPOK;

La vue rend les 11 lignes, dont 6 avec une attaque. Et le catalogue montre que ces objets SQL sont des fichiers logiques, avec un nom système de 10 caractères fabriqué par le système :

SELECT TABLE_NAME, SYSTEM_TABLE_NAME, NATIVE_TYPE, SQL_OBJECT_TYPE, NUMBER_BASED_ON_FILES
  FROM QSYS2.SYSFILES WHERE TABLE_SCHEMA = 'JOBIPOK' AND NATIVE_TYPE = 'LOGICAL'

POKEATK           POKEATK     LOGICAL            2
POKEFEU           POKEFEU     LOGICAL            1
POKEJDFT          POKEJDFT    LOGICAL            2
POKEJOIN          POKEJOIN    LOGICAL            2
POKEMON_ATTAQUES  POKEM00003  LOGICAL  VIEW      2
POKEMON_FEU       POKEM00002  LOGICAL  VIEW      1
POKEMON_PAR_TYPE  POKEM00001  LOGICAL  INDEX     1
POKETYPE          POKETYPE    LOGICAL            1

Seul le LF multi-format n'a pas d'équivalent : SQL refuse de le lire (SQL7003).

Un LF a un coût

Un LF à clé tient un chemin d'accès, mis à jour par défaut à chaque modification du PF : le paramètre MAINT de CRTLF vaut *IMMED, et IBM précise que la maintenance immédiate se fait que le fichier soit ouvert ou non. Sur nos huit fichiers logiques, les six qui ont une clé sont en *IMMED : chaque écriture dans POKEMON les tient tous à jour. Les deux vues SQL, elles, n'ont pas de chemin d'accès. Avant d'en créer un nouveau, on regarde ceux qui existent avec DSPDBR (relations base de données) ou la colonne BASED_ON_FILES de QSYS2.SYSFILES.

Questions fréquentes