LES DONNÉES ET L'OS400. le SGBDR DB2/400

Transcription

1 OS LES DONNÉES ET L'OS400 le SGBDR DB2/400 Auteur : Dominique Vignez OS40004.DOC

2 DB2/400 les données et l'os400 2 Cette page est laissée intentionnellement blanche

3 DB2/400 les données et l'os400 3 Table des matières 1 Introduction Traitement des données par l'as Description des fichiers Description au niveau enregistrement Description au niveau champ types de données supportés Organisation de la Base de Données AS Notion de base de données Méthodes de description des données au système Outils d'aide à la gestion des descriptions de données Dictionnaire des données Fichier de références de zones Utilisation d Operation navigator Terminologie OS400 DDS Niveaux informations dans un membre source de description de données Créer un membre PF ou LF Syntaxe d'une ligne de spécification DDS OS400 IDDU SQL/ Description à l'aide de Query Manager Description des fichiers système Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL SYSINDEXES SYSKEYS SYSCOLUMNS SYSTABLES SYSVIEWDEP SYSVIEWS...31

4 DB2/400 les données et l'os Évolutions relatives au support de DB2 en V3R1M Support de IFS (Integrated File System) Réorganisation des tables système QABDCCST QADBFCST QADBIFLD QADBKFLD QADBXRDBD QADBXREF QADBPKG QADBFDEP Support des contraintes d'intégrité référentielle Support des triggers ou déclencheurs Les messages escape du SGBD Procédures cataloguées Validation à deux phases ou two phases commit Les fichiers de l'os Types de fichiers Accès aux fichiers CONTRÔLE DES ACCÈS FICHIERS Open feedback area I/O feedback area Les fichiers de données Structure Description fichiers physiques Structure Mots clé Niveau fichier Niveau format d'enregistrement Niveau zone Niveau clé fichiers logiques Structure Logiques joints Conversions de type de données Mots clé Niveau fichier Niveau enregistrement Niveau joint Niveau champ Niveau clé Niveau sélection/omission Autres fonctions base de données National Language Support...62

5 DB2/400 les données et l'os Predictive Query Governor Amélioration des performances Bases de données distribuées Passerelles vers d'autres SGBDR Data Propagator Opticonnect Bases de données parallèles La base de données SMP (Symetric Multiprocessing Parallel) La base de données faiblement associée Sécurité des données La journalisation La protection des chemins d'accès par le système (SMAPP) Le contrôle de validation DASD de technologie RAID Limitations...67

6 DB2/400 les données et l'os400 6

7 DB2/400 les données et l'os Introduction De par son caractère intégré, situé pour partie au dessus du MI et pour partie à l'intérieur du SLIC, la base de données de l'as400 atteint un niveau d'efficacité plus important qu'une autre base de données qui serait construite au dessus du système d'exploitation. La base de données de l'as400 a été conçu pour le S38 dès 1975 par Perry Taylor. A cette époque E.F. Codd travaillait pour IBM sur un projet appelé System/R et avait décrit un système relationnel de table à deux dimensions, sur laquelle on pouvait réaliser quatre opérations (order, selection, projection, join). Perry Taylor entra en contact avec Codd pour lui faire part de ses propres travaux et lui demander d'unir leurs efforts. Mais Codd le pris de haut annonçant que les bases de données relationnelles ne pouvaient être conçues que pour les gros systèmes et qu'un petit système n'avait besoin que d'un tri et d'une fusion de fichiers. La première base de données relationnelle à être installée sur un ordinateur fut celle du S38 en 1978, mais sans l'opération join. Trois ans plus tard, la base de données du système/r fut commercialisée sous le nom de DB2 et comme elle possédait les quatre opérations, il fut décrété qu'elle était finalement la première base de données relationnelle au monde. Comme il n'existait pas d'interface standard aux bases de données relationnelles à l'époque où la base de données du système 38 a été lancée, il a fallu développer une interface native : les DDS. Les spécifications du langage SQL ne sont venues que plus tard et une décennie a été nécessaire à leur stabilisation. Ceci explique que les DDS sont livrées encore aujourd'hui en standard alors que le kit de développement SQL est fourni en option. Cette nécessité historique fait que longtemps le SQL a été moins performant et quasiment inutilisé sur AS400. La réécriture du SGBD DB2/400 avec la V3.R1. de l'os400 a gommé cette différence. DDS et SQL sont maintenant au même niveau de performances sur l'as Traitement des données par l'as400 L'AS400 est une machine conçue pour s'intégrer dans l'aua d'ibm (Architecture unifiée d'applications) et pouvant assurer la compatibilité avec la gamme 3X ou avec la gamme gros systèmes et même micro sous OS/2 ou AIX pour RS/6000. Sur une même machine il est donc possible de gérer les données de plusieurs façons suivant les finalités recherchées. Ainsi, si l'on utilise des programmes utilisateurs provenant d'un 3X ou des produits sous licence IBM ou si l'on utilise des programmes s'inscrivant dans l'aua comme CICS par CSP/AE (à partir de la version OS/ ), on ne décrira pas les données de la même manière et on ne les traitera pas non plus de la même manière.

8 DB2/400 les données et l'os Description des fichiers 3.1 Description au niveau enregistrement Elle correspond à l'utilisation traditionnelle sans base de données. Seule la longueur de l'enregistrement est décrite au système. Le système ne connaît rien des champs contenus dans le fichier. La description des champs n'étant donnée qu'à l'intérieur des programmes. Cette façon de procéder est appelée "fichiers à description interne". Dans ce cas les données sont strictement dépendantes des programmes. 3.2 Description au niveau champ Elle correspond à l'utilisation avec base de données déjà utilisée sur le système 38. L'ensemble des éléments à décrire pour un champs comprend : - le nom, - la longueur, - le type, - les domaines de validité, - un texte descriptif. Cette façon de procéder est appelée "fichiers à description externe". Dans ce cas les données sont indépendantes des programmes types de données supportés Le type de données est indiqué en colonne 35 d'une spécification de description de données (A) voir annexes les types possibles sont : - P numérique décimal packé, - S numérique décimal zoné, - B numérique binaire, - F numérique flottant, - A alphabétique, - H hexadécimal, - L date, - T heure, - Z horodatage. Si le type de données n'est pas explicitement indiqué le système attribuera par défaut le type A (alpha) si ne nombre de décimales (colonne 36,37) est blanc, ou packé si le nombre de décimales est de 0 à 31. Indiquer 0 décimale en colonnes désigne un entier pour des zones définies en packé, zoné ou binaire. Si le type est F (virgule flottante) il faut spécifier le mot clé FLTPCN pour indiquer la simple ou la double précision du nombre flottant.

9 DB2/400 les données et l'os400 9 Le type hexadécimal permet d'indiquer au système qu'il ne doit pas interpréter le contenu de ce champ et le restituer tel quel. Dans la plupart des cas un champ défini en hexadécimal sera traité sur les mêmes règles qu'un champ alpha. 4 Organisation de la Base de Données AS400 Sur AS400 il existe 4 méthodes pour décrire les données : - à l'aide de sources DDS suivis d'une compilation (CRTPF, CRTLF), - à l'aide de IDDU, - à l'aide de SQL, - à l'aide de Query Manager. Suivant la méthode utilisée l'environnement système et les possibilités sont différentes mais toujours complémentaires. 4.1 Notion de base de données Sur AS400 une base de données est un ensemble de fichiers physiques et logiques contenus dans une même bibliothèque. Conceptuellement une base de données ne peut pas contenir d'autres bases de données. L'arborescence est donc limitée à sa plus simple expression. Seule la base de données du système (QSYS) qui est la racine, peut contenir d'autres bases de données. Le gestionnaire système de la base données, n'a donc à gérer que deux niveaux hiérarchiques. Au niveau le plus bas (QSYS) le gestionnaire dispose de deux fichiers physiques. QADBXREF (description des fichiers) contenant un enregistrement de 127 octets pour chaque fichier existant collectant les renseignements suivants : - nom du fichier, - nom de la librairie, - nom du dictionnaire, - nom du propriétaire, - texte descriptif, - type de fichier (physique, logique, table, vue, index), - statuts de lien (Externe, Programme, sans), - type du dictionnaire (Iddu, Crtdtadct, Sql, Xmigration, - type fichier (Data, Source), - nombre de champs, - nombre de champs clé, - longueur d'enregistrement, - identificateur interne dans dictionnaire (n record).

10 DB2/400 les données et l'os QADBFDEP (relations entre les fichiers) contenant un enregistrement de 41 octets pour chaque fichier basé sur un autre. - nom du fichier de base, - librairie du fichier, - nom du fichier dépendant, - librairie du fichier dépendant, - type de dépendance (Données, Vue, Index). Deux fichiers logiques sont basés sur QADBXREF se sont QADBXFIL, QADBXDIC et deux fichiers logiques sont basés sur QADBFDEP se sont : QADBLDEP et QADBLDNC pour simplifier les accès. Lorsque l'on décrit les données avec la méthode des DDS, seule cette configuration est en oeuvre associée à la description des champs contenue dans le fichier lui même. 5 Méthodes de description des données au système Si vous désirez décrire un fichier uniquement au niveau enregistrement, vous pouvez utiliser le paramètre de longueur d'enregistrement (RCDLEN) en utilisant la commande de création de fichier physique CRTPF. Si vous désirez décrire un fichier au niveau champs, vous pouvez utiliser plusieurs méthodes : l'utilitaire IDDU (interactive data description utility), les commandes SQL/400, ou les DDS (data description specifications). Les DDS offrant le maximum des possibilités de descriptions offertes au programmeur, c'est souvent cette méthode que vous utiliserez. 5.1 Outils d'aide à la gestion des descriptions de données Afin d'éviter les doubles définitions de données et dans un souci de standardisation, il est possible d'utiliser soit un dictionnaire de données soit un fichier de références de zones Dictionnaire des données Un fichier à description interne peut être décrit dans un dictionnaire de données pour le détail du ou des formats d'enregistrements surtout si ce fichier doit être utilisé par QUERY/400, PCS/400 ou DFU. De même un fichier à description externe peut également être décrit dans un dictionnaire. Le système s'assurant que les deux définitions soient bien identiques Fichier de références de zones L'ensemble des détails de description des champs peut être contenu dans ce fichier, évitant ainsi au programmeur des redéfinitions longues et sources d'erreurs.

11 DB2/400 les données et l'os L'utilisation de ce fichier accroît la productivité du programmeur et garanti l'uniformité des descriptions de données d'un programmeur à l'autre. 5.2 Utilisation d Operation navigator Operation Navigator permet de gérer la base de données par interface graphique. Les requêtes SQL sont générées automatiquement par l interface. A partir de la V4.R4. c est l outil le plus puissant de l AS400 pour gérer les possibilités de DB2 Universal DataBase. 5.3 Terminologie Suivant la méthode employée les notions logiques de mêmes entités peuvent être nommées différemment. La liste suivante donnera les termes pour une organisation traditionnelle puis selon l'os400 puis selon SQL. répertoire librairie collection fichier fichier physique table index secondaire fichier logique vue enregistrement format rangée ou tupple item champs colonne ou attribut

12 DB2/400 les données et l'os Ces termes bien que regroupant des conceptions identiques ne sont pas simplement des homonymes mais bien des entités différentes qui ne peuvent être utilisées l'une pour l'autre. Ces parallèles ne sont faits que pour aider à la compréhension. Pour de plus amples informations sur ce sujet, consultez les brochures IBM programming data base guide, programming data management guide.

13 DB2/400 les données et l'os OS400 DDS Les fichiers à description externe peuvent être décrits en utilisant le langage de description de données. Il s'appelle : DDS : Data Description Spécification en anglais. SDD : Spécification de Description de Données en français. Il sert à décrire les données dans des membres source :. de Base de données : membres source PF et LF.. d'affichage : membres source DSPF.. d'impression : membres source PRTF.. de communications : membres source ICFF.... etc. Chaque ligne d'un membre de donnée = une spécification. Chaque spécification contient la lettre 'A' en colonne 6. L'utilisation des DDS vous permet d'intervenir dans les descriptions au niveau du champs, de l'enregistrement et du fichier. Ce n'est que par l'utilisation des DDS qu'il est possible de décrire les clés du chemin d'accès d'un fichier logique par exemple. Ceci contrairement à SQL qui vous permettra de décrire des vues.

14 DB2/400 les données et l'os La colonne 17 de la spécification A peut contenir : - R pour indiquer la description d'un enregistrement (Record), - K pour indiquer la description d'une zone clé, - J pour indiquer la description d'un joint, - S pour indiquer la description d'une sélection, - O pour indiquer la description d'une omission. Les colonnes 19 à 28 peuvent contenir un nom d'enregistrement ou un nom de champ. La colonne 29 peut contenir un "R" pour indiquer que la description du champ est à rechercher dans un autre fichier soit dans le fichier indiqué au mot clé REF, soit par rapport à une autre zone décrite précédemment au dans un autre fichier Indiqués au mot clé REFFLD. Les colonnes 30 à 34 peuvent contenir la longueur de la zone (cadrée à droite). La colonne 35 indique le type de données (voir ci-dessus types de données). Les colonnes peuvent contenir le nombre de décimales (cadrée à droite) pour la description d'une zone numérique. Un nombre de décimales égal à zéro indique une zone numérique entière. La colonne 38 décrit l'usage de la zone et n'est généralement pas utilisée pour les fichiers base de données. Les valeurs possibles sont : - I (Input) entrée, - O (Output) sortie, - B (Both) entrée sortie, - H (hidden) caché, - M (Message), - P (Program to system), - N (Neither) ni entrée ni sortie. Les colonnes 39 à 41 indiquent le no de ligne alors que les colonnes 42 à 44 indiquent le no de colonne. Ces informations ne sont utilisées que pour les fichiers écrans ou imprimantes et pas pour les fichiers base de données. Les colonnes 45 à 80 sont utilisées pour indiquer les mots clé. Voir ci-dessous les différents mots clé et leur niveau d'usage. Pour de plus amples informations sur les DDS consultez la brochure IBM programming data description specifications reference SC Niveaux informations dans un membre source de description de données

15 DB2/400 les données et l'os Un membre source de description de données contient des informations organisées en niveaux. Ces niveaux ont un ordre à respecter. Certains niveaux peuvent être ignorés s'ils ne sont d'aucune utilité dans un membre source. Un membre PF contient 4 niveaux : - informations de niveau fichier. - informations de niveau format d'enregistrement. - informations de niveau zone. - informations de niveau clé. Un membre LF contient 5 niveaux : - informations de niveau fichier. - informations de niveau format d'enregistrement. - informations de niveau zone. - informations de niveau clé. - informations de niveau sélection.

16 DB2/400 les données et l'os Créer un membre PF ou LF La création d'un membre source PF permet la création d'un fichier de données. 1) Avant de créer un membre PF, il faut connaître les informations suivantes sur le fichier : - le fichier répertoire qui contient la description des zones fichiers, - s'il y a présence de clé : unicité de la clé ou non, - le nom du format d'enregistrement à donner au fichier, - le nom des zones composant l'enregistrement, - le nom de ou des zone (s) composant la clé (optionnel ), - la ou les sélections à faire sur les données ( pour LF uniquement ). 2) Il faut organiser ces informations en niveaux : Au niveau fichier : - donner le nom du répertoire de description des zones, - dire si la clé est unique ou pas ( en cas de présence de clé), - donner autres infos. de niveau fichier. Au niveau format d'enregistrement : - donner le nom du format d'enregistrement, - donner autres infos. de niveau format d'enregistrement. Au niveau zone, pour chaque zone :

17 DB2/400 les données et l'os donner le nom de la zone, - si la zone est référencée : - dire si elle fait référence au répertoire cité au niveau fichier ou si elle fait référence à une autre zone, - si la zone n'est pas référencée : - donner sa longueur et son type; - donner infos complémentaires. au niveau zone. Au niveau clé : - donner la ou les zones composant la clé (cette ou ces zones doivent faire partie de l'enregistrement ), - donner autres infos. au niveau clé. Au niveau sélection omission : - décrire la/les sélections et/ou omissions de données. 3) Créer le membre PF ou LF sous PDM : Créer un nouveau membre de type PF ou LF. Pour saisir une ligne : insérer une ligne avec l'invite DP : IPDP (voir pages suivantes pour la syntaxe DDS) 4) Compiler le membre PF ou LF pour créer le fichier BD : utilisez l'option 14 de PDM (si besoin F4 pour les options et optimisations). Attention : il y a un ordre de création des différents fichiers de la BD. - créer d'abord le répertoire de données, - créer ensuite les fichiers Physiques, - créer enfin les fichiers Logiques Syntaxe d'une ligne de spécification DDS

18 DB2/400 les données et l'os400 18

19 DB2/400 les données et l'os400 19

20 DB2/400 les données et l'os OS400 IDDU Les fichiers physiques peuvent être décrits en utilisant IDDU. L'avantage d'utiliser IDDU est que c'est une méthode interactive avec accès par menus pour décrire les données. Il se peut également que des utilisateurs connaissant le système 36 en aient l'habitude et préfèrent cette méthode. De plus IDDU autorise la description de formats multiples en relation avec QUERY/400, PCS/AS/400 (PC Support) et DFU (data file utility). Si vous utilisez IDDU pour décrire vos fichiers, les définitions de fichiers deviennent des éléments d'un dictionnaire de données OS/400. Si vous désirez de plus amples informations à ce sujet consultez la brochure IBM IDDU user's guide. Lorsque l'on utilise la méthode IDDU, une base de données utilisateur, donc une librairie contient en plus des fichiers de données les objets suivants : - un dictionnaire de données (DTADCT) portant le nom de la base de données fichiers physiques qui sont : QIDCTP02 commentaires longs des fichiers, enregistrements et champs, QIDCTP10 descriptions des champs, QIDCTP20 descriptions des enregistrements, QIDCTP21 relations des champs et des enregistrements séquence des champs et mode de traitement, QIDCTP25 séquence et mode de traitement des enregistrements, QIDCTP30 descriptions des fichiers, QIDCTP31 relations des enregistrements et fichiers, QIDCTP51 zones clé d' un enregistrement, QIDCTP52 texte de la commande SQL ayant créée un enregistrement, QIDCTP53 relations entre un enregistrement et les fichiers physiques sur lesquels il est basé. - 7 fichiers logiques basés sur les précédents : QIDCTL76 liste des champs par alias basé sur P10, QIDCTL80 liste des champs par nom et par id interne de dictionnaire basé sur P10, QIDCTL81 liste des enr. basé sur P20, QIDCTL82 liste des fichiers basé sur P30, QIDCTL84 liste des enr. utilisant un champ basé sur P20, P21, QIDCTL86 liste des fichiers utilisant un enr. basé sur P30, P31, QIDCTL88 liste des fichiers utilisant un champ basé sur P20, P21, P30, P31. Ces objets sont nécessaires à l'utilitaire IDDU pour assurer sa fonction de description de données interactive. Mais IDDU n'est capable de créer que des fichiers physiques. Par contre il peut gérer les définitions de fichiers logiques. Un fichier créé par la méthode des DDS peut voir ses définitions gérées par IDDU à la condition que celles ci soient entrées dans le dictionnaire par la commande ADDDTADFN.

21 DB2/400 les données et l'os Néanmoins les fichiers partageants un chemin d'accès, ayant une séquence de classement alternée ou étant en union, les fichiers joints et les fichiers logiques en select ou en project ne sont pas gérables par IDDU.

22 DB2/400 les données et l'os SQL/400 Le langage de requête structuré SQL/400 peut être utilisé pour pour décrire une base de données AS/400. SQL/400 supporte les instructions pour décrire les champs d'une base de données, et pour créer les fichiers. Si l'application que vous développez doit s'inscrire dans un contexte de portabilité entre systèmes, il sera préférable de décrire vos données par SQL. Pour de plus amples informations à ce sujet, consultez la brochure IBM SQL/400 programmer's guide. Lorsque l'on utilise la méthode SQL, l'environnement s'enrichi encore et la base de données devient une collection par adjonction des éléments suivants : - QSQJRN journal associé au contrôle de validation SQL, - QSQJRN0001 récepteur de journal, - 8 fichiers logiques assurants la comptatibilité avec la norme SQL et dont les fonctions et contenus sont redondants avec ceux de IDDU, QSQTABLES basé sur P02 et P30; QSQCOLUMNS basé sur P10, P02, P20, P30, P31, QADBXREF; SYSCOLUMNS mêmes bases que le précédent; SYSINDEXES basé sur P30, QADBXREF, QADBFDEP; SYSKEYS basé sur P02, P10, P20, P51, QADBXREF; SYSTABLES basé sur P30, QADBXREF; SYSVIEWDEP basé sur P30, QADBXREF, QADBFDEP; SYSVIEW basé sur P30, P52, QADBXREF. Cette configuration est nécessaire pour créer des tables, des vues, des enregistrements par SQL. Mais pour gérer les données en lecture, en mise à jour ou en ajout à l'aide de SQL, il n'est pas indispensable que ces dernières soient incluses dans une collection. SQL400 est capable de gérer les données de l'as400 quelque soit leur mode de définition. 9 Description à l'aide de Query Manager Query Manager est un outil offrant une interface utilisateur pour utiliser le langage SQL. Il offre les mêmes possibilités que IDDU et SQL réunis, sans avoir recours aux fichiers systèmes. Par contre et s'en est la contrepartie, il est un peu plus lent d'exécution car chaque information doit faire l'objet d'un traitement pour être accessible au lieu d'avoir à effectuer une simple lecture de fichier. L'accès à Query Manager se fait grâce à la commande STRQM (démarrer Query Manager). En choisissant le choix 3 (gestion des tables QM) du menu qui s'affiche, une fenêtre permet d'indiquer la collection ou la bibliothèque sur laquelle on désire travailler.

23 DB2/400 les données et l'os L'affichage d'un choix de bibliothèque dans une liste est possible par l'intermédiaire de la touche F4. Il est possible ensuite de créer un fichier physique par l'option 1 (création de table).

24 DB2/400 les données et l'os Description des fichiers système 10.1 Fichier QIDCTP10 Longueur d'enregistrement : 535 octets nom externe du champ id interne du champ flag interne de delete fonction de création date de création heure de création id créateur date dernière modification heure dernière modification id dernier modifieur type général de donnée (1=char, 2=numérique) type détail de donnée majuscule par défaut longueur externe longueur interne nbre de décimales type de donnée SQL longueur SQL précision SQL valeur nulle possible (Y=oui, N=non) code d' édition séparateur de date et heure symbole de point décimal séparateur de milliers apparition du signe négatif signe négatif gauche signe négatif droit impression de la valeur zéro remplacement des zéros non significatifs remplacement de la valeur zéro option d' affichage des zéros négatifs affichage du symbole monétaire symbole monétaire gauche symbole monétaire droit mot d' édition longueur entête 1 de champ entête 1 de champ longueur entête 2 de champ entête 2 de champ longueur entête 3 de champ entête 3 de champ nom alias 10.2 Fichier QIDCTP20 Longueur d' enregistrement 123 octets

25 DB2/400 les données et l'os nom externe de l'enregistrement id interne de l' enregistrement flag interne de delete texte descriptif fonction de création date de création heure de création id du créateur date de dernière modif heure de dernière modif id du dernier modificateur code de révision du fichier physique 21 code de révision du fichier physique 25 réserve reserve 10.3 Fichier QIDCTP21 Longueur d' enregistrement 36 octets id interne d' enregistrement code de révision interne id interne de champ type de fichier (D=dbase) séquence relative de sortie séquence relative d' entrée usage du champ modifiable par SQL (Y=oui, N=non) n de référence de joint 10.4 Fichier QIDCTP25 Longueur d' enregistrement 36 octets id interne d' enregistrement code de révision interne id interne de champ n relatif de séquence type de fichier (D=dbase) position relative dans le champ opérateur de comparaison (EQ, NE, ZN, NZ, DG, ND) valeur test id enregistrement continuation et/ou (1=and, 2=or) 10.5 Fichier QIDCTP30 Longueur d' enregistrement 134 octets nom externe du fichier id interne du fichier flag interne de delete texte descriptif date de création heure de création id du créateur

26 DB2/400 les données et l'os date dernière modif heure dernière modif id du dernier modificateur type de fichier (1=physique, 2=logique) accès base de données (1=séquentiel, 2=par clés) type de joint (1=inner join, 2=left outer join) vérification SQL (Y=oui, N=non) clés en double (D=oui, U=non) séquence des clés en double (F=fifo, L=lifo) code de révision fichier physique 31 code de révision fichier physique 51 code de révision fichier physique 52 code de révision fichier physique 53 réserve réserve réserve définition fichier SQL 10.6 Fichier QIDCTP31 Longueur d'enregistrement 27 octets id interne fichier code révision interne id interne d' enregistrement N de séquence relatif 10.7 Fichier QIDCTP51 longueur d' enregistrement 40 octets id interne fichier code de révision interne id interne d' enregistrement id interne de champ n de séquence relatif ordre de tri de la clé (A=ascendant, D=descendant) attribut de clé (S=signée, U=non signée, A=alpha, D, Z) 10.8 Fichier QIDCTP52 Longueur d' enregistrement 86 octets id interne de fichier code de révision interne n de séquence relatif texte de la commande SQL de création 10.9 Fichier QIDCTP53 Longueur d' enregistrement 60 octets id interne fichier code de révision interne id interne d' enregistrement nom du fichier de base nom de la librairie du fichier de base

27 DB2/400 les données et l'os id interne du fichier physique de base n de séquence relatif séquence de référence de joint (0=logique) Fichier QIDCTL76 Vue logique de QIDCTP10 longueur enr. 30 octets, longueur clé 30 octets clé : Q76GUA Fichier QIDCTL80 Index de QIDCTP10 longueur enr. 535 octets, longueur clé 21 octets clé : Q10DEN,Q10IDI nom externe zone, id interne Fichier QIDCTL81 Index de QIDCTP20 longueur enr. 123 octets, longueur clé 21 octets clé : Q20REN,Q20IRI nom externe enr., id interne Fichier QIDCTL82 Index de QIDCTP30 longueur enr. 134 octets, longueur clé 21 octets clé : Q30FEN,Q30IFI nom externe fichier, id interne Fichier QIDCTL84 Vue jointe sur QIDCTP21/QIDCTP20 longueur enr. 101 octets longueur clé 11 octets clé : Q84IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI id champ interne id enr. interne code révision interne code révision P25 séquence de sortie relative nom enr. externe date création heure création Fichier QIDCTL86 Vue jointe de QIDCTP31/QIDCTP30 longueur enr. 105 octets longueur clé 11 octets clé : Q86IRI joint : QIDCTP31/Q31IFI -> QIDCTP30/Q30IFI id enr. interne id fichier interne code révision interne

28 DB2/400 les données et l'os code révision P51 code révision P52 code révision P53 n séquence relatif Type fichier nom fichier externe texte descriptif date création heure création Fichier QIDCTL88 Vue jointe de QIDCTP21/QIDCTP20/QIDCTP31/QIDCTP30 longueur enr. 98 octets longueur clé 11 octets clé : Q88IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI QIDCTP31/Q31IRI QIDCTP31/Q31IFI QIDCTP30/Q30IFI QIDCTP31/Q31R31 QIDCTP30/Q30R31 id champ interne id fichier interne code révision interne type fichier type de fichier base de données nom fichier externe texte descriptif date création heure création SYSINDEXES Cette vue logique contient un enregistrement pour chaque index de la base de données. NAME char(10) nom de l'index CREATOR char(10) propriétaire de l' index TBNAME char(10) nom du fichier physique TBCREATOR char(10) propriétaire du fichier physique TBDBNAME char(10) nom de la librairie du fichier physique UNIQUERULE char(1) clés en double autorisées D=oui (duplicates) U=non (unallowed) COLCOUNT integer nombre de champs dans la clé DBNAME char(10) nom de la lbrairie contenant l'index SYSKEYS Cette vue logique contient un enregistrement pour chaque champs contenu dans un index. IXNAME char(10) nom de l'index IXCREATOR char(10) propriétaire de l' index COLNAME char(10) nom du champs contenu dans l' index COLNO integer n d'ordre du champs dans l'enregistrement COLSEQ integer n d'ordre du champs dans la clé