Discussion:accès aléatoire

Une définition du Jargon Français.
Aller à : Navigation, rechercher

Sens

Bonsoir,

A ma connaissance, les différences sont les suivantes :

Accès "direct ?", organisation séquentielle indexée (KSDS VSAM) : les "enregistrements" sont accessibles par une clé via un index primaire : C'est un faux accès direct car il y a une recherche séquentielle non négligeable (séquentielle indexée). KSDS : clé + index primaire = cluster=grappe. L'index est un fichier à part entière qui contient des clés, chacune associée à un pointeur (le RBA Relative Byte Address) qui pointe vers les enregistrements (en fait les CI : Control Intervalsize = 1 ou plusieurs enregistrements) d'un autre fichier (d'où la grappe), la partie data contenant les enregistrements triés (et qui doivent le rester) sur la valeur de la clé.

Accès direct (RRDS VSAM) : les "enregistrements" sont accessibles par un n° d'ordre : Numéro d'ordre de 1 à n, les "enregistrement(s)" sont accédés par le RBA : Relative Byte Address qui n'est autre qu'un comptage d'octets (de 0 à n = dernier octets référençant un enregistrement) indiquant l'adresse de début de chaque enregistrement. Il se calcule de la manière suivante : RBA = (n° ordre - 1) x longueur d'enregistrement, lesquels doivent être de longueurs fixes pour ce type d'organisation.

Accès aléatoire (RANDOM) par exemple DL/I lequel utilise des fichiers VSAM: les "enregistrements" (les occurences racine d'une base de données DL/I) sont accessibles par une adresse CALCULEE à l'aide d'une routine, dite de randomisation, qui utilise la valeur de clé "applicative" (un n° de client .......). Exemple : base de données hiérarchique HDAM en DL/I (IMS/DB de IMS).

Ces routines font "ce qu'elle peuvent" pour calculer une adresse uique tout en essayant d'optimiser l'espace disque, mais on comprend bien qu'à partir de valeurs aléatoires les adresses sur disque, calculées par la routine, sans être fantaisistes, ne peuvent pas être rigoureusement contigües, de plus il peut y avoir des identités d'adresses pour deux clés de valeurs différentes. Il s'ensuit une perte sensible de mémoire externe (disque), par contre le temps d'accès à un "enregistrement" est optimal. Cette organisation est retenue pour construire des fichiers privilégiant les accès directs pour lesquels le temps d'accès est prioritaire et qui ont un faible taux de mise à jour (peu de créations, annulations). Leur organiqation est dite aléatoire (et par extension l'accès) dans le sens où les enregistrements sont "disséminés" sur l'espace disque de manière non prévisible et par le fait, ne peuvent être accédés (en BROWSING) de manière séquentielle en progression logique sur la valeur de la clé "applicative" (le n°de client dans mon scénario).

Voilà ce dont je me souviens, je ne pense pas trop me tromper mais c'est "de mémoire² que je vous raconte tout ça, et à mon âge la mémoire .............


christian 30 janvier 2007 à 03:01 (CET)

Pour ce que j'en saisis il s'agit ici des acceptions dans le monde mainframe (IBM). Je tente des parallèles:
Accès direct séquentiel indexé: une recherche par dichotomie pratiquée sur l'index rend possible d'accéder à un enregistrement d'ordre donné. Inconvénient: lors d'une recherche et dans le pire des cas ( très variables dispersions dans les sous-ensembles) la dichoto peut "coûter cher"
accès direct: de l'adressage indirect, donc le sizeof des enregistrements et le numéro d'ordre de l'un d'eux suffisent pour calculer son déplacement. Contrainte: tous les enregistrements sont de même taille. Avantage: pas de fichier d'index requis, temps d'accès à tous les "rangs" (numéros d'ordre) identique
accès aléatoire: la "randomisation" est ce que l'on appelle maintenant un hachage. Une table doit quelque part associer un hash donné (pouvant correspondre à plusieurs enregistrements) au déplacement du premier enregistrement correspondant (les autres sont stockés immédiatement après). Avantage: taille variable possible, l'écart-type des temps d'accès à tous les "rangs" (numéros d'ordre) est proportionnel à l'inadéquation de l'algo de hachage (autrement dit: plus le nombre de "collisions" (même hashes pour des enregistrements différents) augmentent, plus l'algo de hachage est inadéquat, plus çà rame. En pratique (hors cas limites de données bizarres ou d'algo géniaux ou pourris) cela implique une relation fine entre, d'une part, le gabarit moyen et la dispersion des enregistrements, et, d'autre part, la taille de chaque condensat (hash) Natmaka 31 janvier 2007 à 22:37 (CET)

Bonsoir,

Il s'agit bien en effet d'une vision mainframe IBM. Je constate à la lecture de votre réponse qu'il n'y a pas, semble-t-il de différences majeures, à propos des principes généraux de "fonctionnement" de ces organisations de fichiers et de leur(s) mode(s) d'accès associé(s). En ce qui concerne le séquentiel indexé (KSDS VSAM) les problèmes de dispersions sont anticipés, au mieux, en calculant un FREESPACE (espace laissé libre par CI = un ensemble de 1 à n enregistrement(s) = unité d'adressage vue de l'index) cet espace libre sert à contenir les éventuels et futurs ajouts (création). De même, en cas d'annulation la place correspondante est récupérée par VSAM. Même organisation et même principe pour la partie index qui est un fichier à part entière. Mais il est clair que ce que l'on gagne d'un côté, on le perd de l'autre. Ici c'est de la mémoire sur disque qui est "temporairement" perdue. Second moyen complémentaire, le dossier d'exploitation de l'application utilisant ces fichiers en mise à jour, précise la périodicité à laquelle ils doivent être réorganisés (sauvegarde ==> restauration dans la foulée). Ce qui a pour effet de remédier radicalement aux inconvénients liés à la désorganisation des clusters. Là c'est de côut d'exploitation dont il est question.

En ce qui concerne l'accès aléatoire il existe un "point d'ancrage", adresse renvoyée par la routine pour le 1er enregistrement, suivi d'un (procédé) de chaînage des enregistrements dont les valeur des clés se traduisent par une adresse identique. Ce qui a pour conséquence la dégradation des performances.

christian 31 janvier 2007 à 23:44 (CET)