| ★ APPLICATIONS ★ DIVERS ★ LES FICHIERS (CPC REVUE) ★ |
| Les Fichiers (CPC Revue n°28) | Les Fichiers (CPC Revue n°29) |
GENERALITES FICHIERS OU DOSSIERS ?Peut-on indifféremment parler de FICHIER ou de DOSSIER ? La question se pose parce que le mot anglais FILE a les deux significations. Or, un fichier est un ensemble de "fiches" de structure généralement identique. Exemple : fichier adresse/téléphone. Toutes les fiches comporteront, par exemple : nom, prénom, adresse, numéro de téléphone. Un dossier est un rassemblement de fiches de types différents, se rattachant au même objet. Exemple : dossier de l'ennemi public n° 1 Méfaits commis à Paris, méfaits commis à Marseille, fiche anthropométrique, auditions des témoins, rapport du gendarme Lefutet Adrien, etc. Le dossier est proche de la notion de base de données. Nous laisserons les dossiers (c'est-à-dire les bases de données) pour l'instant. TYPES DE FICHIERS Outre les listes et les arbres qui sont des structures de données "à pointeurs" et les bases de données qui sont des fichiers reliés entre eux (par des pointeurs), on appelle généralement fichiers ou fichiers CLASSIQUES : les fichiers "séquentiels", les fichiers "à accès direct". Ces appellations sont imprécises et trompeuses. En effet, un fichier à accès direct (que par souci de concision nous appellerons désormais fichier DIRECT) peut parfaitement être lu de façon séquentielle sur le plan logique (lecture directe mais successive des fiches de 1 à N). Conservons néanmoins ces appellations, étant entendu que : SEQUENTIEL = lecture de proche en proche à partir de la première fiche. = écriture de proche en proche à partir de la première fiche. Certains supports (on appelle support ce sur quoi l'information est enregistrée) sont inaptes à l'accès direct : — papier en rouleau Les supports permettant l'accès DIRECT sont en gros : — la mémoire centrale LES FICHES Les fiches sont une suite d'information. En BASIC, chaque information (rubrique) est généralement contenue dans une variable. Les fiches DIRECTES et donc leurs rubriques ont des longueurs rigidement fixées. C'est le condition nécessaire pour que, connaissant l'adresse du début du fichier, on puisse déterminer la piste et le secteur contenant la fiche n° 347 (347e depuis le début du fichier). Une zone NOM$ y sera, par exemple, fixée à 30 caractères. De ce fait, MARTIN y sera la chaîne "MARTIN + 24 espaces". Nous en reparlerons. FICHIERS CLASSIQUES FICHIERS SEQUENTIELS En raison des facilités offertes par le traitement DIRECT, les fichiers séquentiels sont souvent, lorsque la mémoire disponible le permet, transférés dans des tables en mémoire centrale. On effectue alors sur ces tables le traitement adéquat (mise à jour du fichier, par exemple), puis on récrit les tables (lorsqu'elles ont été modifiées) sur un nouveau fichier disque (ou cassette le cas échéant). Ce processus relève, comme nous venons de le dire, de l'accès DIRECT. Nous décrirons, le moment venu, les traitements de base des fichiers séquentiels dans le cas où le fichier ne peut tenir entier en mémoire et donc en suivant les contraintes de la logique séquentielle. CONTENU DES FICHES En séquentiel, si le nombre et le type des rubriques sont rigidement fixes, la taille de chaque rubrique est fonction : — de la longueur de l'information (MARTINET est plus long que DUBOIS), et Exemple :
Avant de voir le nombre exact de caractères d'une fiche et d'un fichier, notons quelques points importants : — jules En ce qui concerne ce dernier point, voir CPC n° 18 "Ecriture et Lecture de fichiers" par Michel Archambault. A) jules Dans un fichier, la plupart des zones peuvent servir à une recherche ou être l'objet d'un TRI. De ce fait, il est conseillé de n'utiliser que les MAJUSCULES. L'usage de UPPER$ est recommandé. B) 0 enfant M. MARTIN n'a-t-il pas d'enfants ou le nombre en est-il inconnu ? Il y a doute si l'information est directement saisie dans une variable numérique, puisqu'ENTER seul donne 0. C'est une raison de plus pour saisir toutes les zones sous forme de CHAINE (par LINE INPUT). La question se pose alors de savoir s'il faut enregistrer sur disque ou cassette la donnée sous la forme CHAINE (sous laquelle elle a été saisie et contrôlée) ou la faire passer au préalable dans une variable numérique. L'une des meilleures solutions est, comme nous le verrons, celle-ci : a) la donnée est entrée au clavier (LINE INPUT "Nbre d'enfants:";n.enf$): L'enregistrement est effectué par PRINT #9,n.enf$ (une seule valeur par PRINT # 9) b) la donnée numérique est calculée par le programme : l'enregistrement est effectué par WRITE#9,n.enf$ (une seule valeur par WRITE#9) Ici, on doit avoir N.ENF$ et SALAIRES. Les valeurs numériques peuvent, à la relecture, être obtenues de deux façons : — LINE INPUT$,n.enf$ puis n.enf = VAL(n.enf$), ou Un autre problème important est celui de la détermination des zones qui ne doivent, en aucun cas, rester VIDES (zones OBLIGATOIRES) lors de la création de la fiche. C'est le cas des zones "numériques" puisque VAL ("") donne un ZERO douteux. La routine du LISTING 1 (voir celle de Michel Archambault dans CPC n° 19) refuse la chaîne dans les cas suivants : — chaîne vide Remarques — Le contrôle de la donnée après saisie complète de la zone (et non par rejet immédiat du caractère erroné lors de la frappe) est tout à fait admissible sur CPC, la touche COPY permettant de recomposer la donnée correcte très rapidement. Généralement, les erreurs sautent aux yeux, sauf les espaces en fin de chaîne, d'où le doublement du CHR$(7). LIGNE1 $:.....................ETAT des STOCKS etc. Les points figurent les blancs à gauche. — Il faudrait penser à bien d'autres choses. Par exemple, certaines zones "chaîne" composées uniquement de chiffres doivent être cadrées de zéros à gauche pour qu'un tri éventuel ait un sens ("21 " est plus grand que "127" mais "00127" est plus grand que "00021". c) 27, RUE VERTE Le problème n'est pas la couleur de la rue, c'est la virgule. Lorsque celle-ci existe, le problème dépend du couple d'instructions écriture/lecture utilisé. Ecriture : PRINT #9 PRINT #9 LINE INPUT #9 NON LONGUEUR DES FICHES ET DES FICHIERS 1ere solution : Si l'on a écrit : PRINT# 9, adresse$ (UNE SEULE valeur avec PRINT# 9 s.v.p), la rubrique sur K7 ou disque fera 13 + 2=15 caractères (les deux caractères de fin sont en Hexa OD et OA (carriage return et line feed) Chaque rubrique devra être relue par LINE INPUT # 9, sauf si la saisie des données a rejeté les virgules (ce qui, à notre avis, est souvent une saine mesure). A ce propos, recevez-vous beaucoup de courrier publicitaire où une virgule figure dans votre adresse ? Dans ce dernier cas, on peut remplacer la série de LINE INPUT#9 par : INPUT#9, nom$, pren$, tels$, n.enf$, salaire$, adresse$, taille$ ou par INPUT#9, nom$, pren$, tel$, n,enf, salaire, adresse$, taille! La longueur de la fiche est obtenue en ajoutant 2 à la longueur de chaque rubrique (présente ou absente, une rubrique vide faisant 0 + 2 = 2 caractères): soit 44 + 14 = 58 caractères. Le nombre de caractères "utilitaires" du fichier est : (N.rubr * 2) * N.fiches + 1 (caractère 1A dit Ctrl-Z de fin de fichier). Soit 20 001 caractères pour 1000 fiches ayant chacune 10 rubriques. La 2e solution, que nous allons voir, est bien pire. Nota : on pourrait être tenté d'économiser quelques caractères en enregistrant de la façon suivante : PRINT#9, nom$: PRINT#9, pren$: PRINT#9, tel$ Le gain serait très exactement d' 1 caractère par fiche, les deux caractères de séparation entre n.enf et salaire (&0D et &0A) étant remplacés par une virgule. Mais cette virgule interdira de se servir de LINE INPUT #9 à la relecture. D'où la suggestion de ne mettre qu'une seule valeur numérique calculée par WRITE #9. Nous pensons d'ailleurs être ainsi fidèles à la pensée du professeur Archambault. 2e solution : Si l'on a écrit : WRITE#9, nom$, pren$, tel$, n.enf$, salaire$, adresse$, taille$ la longueur de la fiche est obtenue en ajoutant à la longueur de chaque rubrique : 2 caractères < " > soit pour 7 rubriques = 14 caractères 1 caractère < , > après 6 rubriques = 6 caractères Le fichier sera lu par : INPUT#9, n$, p$, t$, etc. Le nombre de caractères "utilitaires" du fichier est : (N.rubr* 3 + 1) *N. fiches + 1 Soit 31 001 caractères pour 1000 fiches ayant 10 rubriques. Cette solution est à écarter. 3e solution : Elle est la plus économe en place disque; le nombre de caractères utilitaires étant : (N.rubr + 2) *N. fiches + 1 soit 12 001 caractères pour 1000 fiches ayant 10 rubriques. Le procédé consiste à concaténer en une seule chaîne les différentes rubriques. La longueur maxi de la fiche est de 255 caractères. Pour pouvoir distinguer les rubriques entre elles, celles-ci sont précédées, si on se limite à 54 rubriques (ce qui semble confortable), par le caractère : CHR$(200 + Nr.Rubr.) Dans notre exemple, la chaîne commencerait par : ~ 201 ~ MARTIN ~ 202 ~ JULES......ou ~ 201 ~ représente CHR$(201 ) Le nombre maxi de caractères utiles pour une fiche est donc : 255 - Nbre de rubriques. Il est donc de 254 pour une seule rubrique et de 201 pour 54 rubriques. Ces restrictions n'empêchent pas cette formule d'être intéressante lorsqu'on manque de place. La programmation de cette solution sera donnée par la suite. PERFORMANCES Nous avons enregistré 999 fois la même fiche (MARTIN JULES etc.) faisant 43 octets utiles (la virgule de l'adresse étant supprimée) et pour la 1000® fiche, JULES a été remplacé par JULOT. Chaque programme de lecture devait rechercher cette fiche particulière. On obtient : SOLUTION 1 - Ecr. 56 s. - Lect. 62 s - Taille 56K - Mode Ecr/Lect PRINT#9/LINE INPUT #9 Notas : A) Taille Les calculs auraient donné : Solution 1 -43000 + 14001 = 57001 car./1024 = 55.7 K B) Vitesse Les solutions classiques 1 et 2 mettent à chaque lecture les valeurs à la disposition du programmeur dans les variables. Pour réaliser la même chose avec la solution 3, il faudrait, après chaque lecture par LINE INPUT#9, procéder au "dégroupage" des rubriques. Voir le listing 2. Ce dégroupage prend du temps, mais il n'est nécessaire pour chaque fiche que lorsqu'on traite l'ensemble du fichier (fichier Personnel lors de la paye par exemple). Si l'on fait une simple recherche, seul le dégroupage de la fiche intéressante sera nécessaire.
RECHERCHE SUR CASSETTE OU SUR DISQUE Il résulte des considérations précédentes que la longueur d'une fiche est fonction du nombre de caractères de chaque rubrique et aussi du mode d'enregistrement. Dans ces conditions, il est impossible de connaître, même sur disque, l'adresse d'une fiche à part celle de la première qui correspond à l'adresse de début de fichier. Cette adresse de début est conservée dans le répertoire (DIRectory ou CATalogue). On ne peut donc trouver une fiche qu'en lisant les fiches les unes après les autres et en regardant si la fiche lue contient une valeur repère appelée (de façon détestable) CLE. Par ailleurs, tout fichier se termine par le caractère &1 A (ctrl Z) qui est écrit par CLOSEOUT. Ce caractère &1 A est détecté, à la lecture, par la fonction EOF (End Of File = fin du fichier). La fonction EOF a alors la valeur - 1 (valeur 0 avant la fin de fichier). Nous pouvons représenter la recherche d'une fiche par : a) L'algorithme verbal : 1 - Ouvrir "TOTO" en lecture Il existe au moins 2 autres façons d'exprimer les algorithmes : — par du simili-BASIC Cette dernière méthode ne sera pas utilisée, la connaissance de ce langage n'étant pas encore assez répandue. On peut d'ailleurs penser qu'un BASIC structuré comme TURBO BASIC sera, dans le futur, un excellent moyen de représentation des algorithmes. Le simili-BASIC pourrait donner : WHILE NOT EOF OR zone$<>Cle$ SUITE. '...suite... RECHERCHE EN MEMOIRE CENTRALE Nous vous proposons de chercher une "CLE" de valeur 4567 dans une table de valeurs numériques définie par : DIM nr (2000) Cette méthode très intéressante avec les langages compilés ou en assembleur, ne l'est pas en BASIC interprété où la boucle FOR..NEXT reste la façon la plus rapide de parcourir une table (ceci pour des raisons de programmation de l'interpréteur). FUSION GENERALITES La fusion (MERGE) à distinguer de APPEND (mettre bout à bout), c'est entremêler de façon harmonieuse deux ou plusieurs fichiers ou tables préalablement triés de la même façon. La fusion est souvent utilisée dans le cas suivant : — on se propose de trier en mémoire un fichier enregistré sur disque. Lorsqu'on ne peut ouvrir qu'un seul fichier en entrée (OPE-NIN unique), on peut procéder comme suit : — ayant un morceau, par exemple A, trié en mémoire FUSION DE 2 TABLES OU FICHIERS Point important : nous supposons qu'il y existe des arguments de tri homonymes. Par exemple, plusieurs "MARTIN", si l'on trie sur le nom. Les organigrammes C1 et C2 donnent une solution convenable du problème. Il faut noter : — la nécessité de relire immédiatement le fichier dont on vient d'écrire la fiche sur le fichier en sortie. Bien que la fusion de 2 fichiers puisse, de proche en proche, venir à bout de toutes les situations, il peut être intéressant de se poser le problème suivant : Fusion en une SEULE passe de N (par exemple 5) fichiers en un seul. A la place de "fichiers" il y a lieu, éventuellement, de comprendre "tables". La solution sera proposée ultérieurement. MISE A JOUR Il s'agit là de l'opération fondamentale de ce que l'on appelle la Gestion de Fichiers. Les trois opérations de base de la mise à jour sont les suivantes : — ADDition d'une fiche --> ADD NECESSITE DU TRI Un fichier séquentiel doit toujours être trié sur un (ou plusieurs) critères de recherche pour en permettre l'exploitation. Ainsi dans l'annuaire des abonnés au téléphone, le classement est fait sur : — Localité Ceci ne serait pas nécessaire sur ordinateur si, d'une part, on ne cherchait qu'une seule fiche à la fois et si d'autre part il n'y avait qu'une seule fiche correspondant à la clé de recherche. En effet, fichier trié ou pas, le temps de recherche est EN MOYENNE celui qu'il faut pour lire la moitié de ce dernier. Si le fichier est trié, le premier avantage sera d'avoir les 34 MARTIN qui y figurent, groupés. Le deuxième est que lorsqu'on aura trouvé le MARTIN ROBERT qui nous intéressait et qu'il s'agira alors de trouver le nommé VISTAMBOIR JULES, il suffira de continuer la lecture sans être obligé de la recommencer au tout début. UN PROGRAMME DE MISE A JOUR Remarques préalables : Avant de décrire le fonctionnement du programme, précisons les points suivants : Généralité du programme Un programme de mise à jour doit être valable pour le plus grand nombre possible de fichiers différents. Le premier enregistrement (fiche) du fichier décrit le fichier lui-même (voir les DATA à la fin du programme). En le lisant, le programme MAJSEQ1 sera informé sur la structure des fiches suivantes. Ce premier enregistrement a donc un format différent de celui des autres fiches. Notons qu'ici le fichier n'est pas complètement décrit. On pourrait ainsi ajouter des DATA pour les informations suivantes : — rubrique Obligatoire, Facultative (chaîne vide autorisée). DATA 0, F, 0 (on ne peut pas taper le prénom (cf. programme)). — rubrique numérique avec ZEROS A GAUCHE. Noms des fichiers Le nom du fichier ENTREE est, bien sûr, fixé par l'opérateur. Par exemple, "FICH.CLI". Celui du fichier SORTIE en sera déduit en ajoutant au nom principal le suffixe "OLD". Ainsi, on aura OPENIN "FICH.CLI" et OPENOUT "FICH.OLD". La mise à jour achevée, le programme permutera ces deux noms. Le nom du fichier en entrée sera donc toujours le même ainsi que celui de la version précédente (.OLD). Pourquoi ne pas utiliser le suffixe ".BAK" au lieu de ".OLD" ? Parce que les nettoyages du style |ERA,*.BAK, si pratiques, supprimeraient la version précédente, version qui permet de reconstituer le fichier en cas d'incident. Il faut noter que lorsqu'on fait OPENOUT "FICH.OLD", le système renomme ce fichier qui devient "FICH.BAK". On aurait donc, en fin de Mise A Jour, après échange des noms : — édition n FICH.CLI (écrit sous le nom FICH.OLD) On pourra, de la sorte, avoir des fichiers d'environ 80 K avec une disquette et de 160 K avec deux. Le programme MAJSEQ1 est prévu pour un lecteur (d'où le 1 ). On trouvera en tête de programme ce qu'il faut faire pour travailler avec 2 lecteurs. Dans ce dernier cas, la disquette qui était en 1 sera mise dans le lecteur B à la mise à jour suivante et vice versa. Lorsqu'on a deux lecteurs, travailler ainsi est beaucoup plus sûr que de laisser les deux générations sur la même disquette. CPC |
|  |
|
