Discussion :

[Johnny P.]

Bonjour ,

Je pratique le Cobol déjà depuis quelque mois et je me lance dans un mini-projet ,
pour cela j'ai conçu le modèle E/A en base de donnée relationnel (schéma conceptuel , logique et physique )

Pour être sûr de bien comprendre :
Je me pose des questions.

J'ai comprit que les clefs primaires sont les record key en Cobol mais ce que j'ai du mal c'est à comprendre les index en base de donnée quand on définit une clé d'index en quoi ça correspond en cobol ?

Par exemple si je demande d'afficher des enregistrements triés sur la date en base de donnée on définit un index sur la date et lors d'un select avec order by il va m'afficher trié par date rapidement grâce à l'index mais en cobol ? ce sont les alternate record key cependant je suppose que lors de l'affichage je dois trier par date avec un sort ?

Merci pour toutes réponses à mes questions.

[rasti92]

Bonjour,

Je ne sais pas si j'ai bien compris votre question mais il faut absolument distinguer deux organisations différentes des données :

- l'organisation en FICHIERS : soit des fichiers séquentiels sans index soit des fichiers indexés auxquels sont associés un index primaire et éventuellement des index secondaires (Alternate index)

- l'organisation en BASES DE DONNEES RELATIONNELLES (ex : DB2 sur grand système) constituées de TABLES sur lesquelles sont définis des Index

Vu du développement Cobol, le premier cas exige de programmer explicitement et précisément les accès aux données avec des ordres de lecture directe (READ avec fourniture explicite de la valeur de la clé recherchée) ou de lecture séquentielle à partir d'une position (READ sur une valeur de clé, suivi de READ NEXT) ; si vous voulez obtenir des résultats triés par Date mais qu'aucun index (primaire ou alterné) ne porte sur cette zone, vous devrez effectivement trier les résultats par un SORT.

Dans le cas des Bases de Données Relationnelles, le programme contient des requêtes SQL (SELECT en particulier) enfermées entre les mots-clés EXEC SQL et END-EXEC. La requête décrit le résultat qu'on veut obtenir (les données recherchées) mais pas le moyen le plus efficace d'y arriver. Ce travail est assuré par un composant ("optimiseur") du SGBD lui-même.

La (fausse) bonne nouvelle est que, si la requête contenue dans le programme est syntaxiquement correcte, le programme s'exécutera bien. La (vraie) mauvaise nouvelle est que si l'optimiseur ne trouve pas de bonne stratégie d'accès, il peut tourner très, très, très longtemps... La seconde mauvaise nouvelle est qu'un programme peut se comporter de manière idéale en phase de tests unitaires sur des tables contenant quelques centaines de lignes et devenir catastrophique lorsqu'on l'exécute en production sur des millions de lignes.

A noter que beaucoup d'éléments d'un SELECT ont un impact sur cette stratégie d'accès : clause WHERE, clause ORDER BY, clause GROUP BY, clauses JOIN, options DISTINCT ...

Les index associés aux tables de la Base de données doivent être "pensés" en fonction des critères de recherche les plus fréquemment utilisés dans les traitements. On n'est pas limité dans le nombre d'index créé sur une même table mais trop d'index a des impacts négatifs sur le volume de données et les performances.

Dans les grandes organisations, la fonction de DBA (Data Base Administrator) est assurée par des spécialistes qui manipulent ces concepts à longueur de journée et qui sont capables : d'optimiser le modèle physique des données Tables et Index), l'architecture des traitements et l'écriture des requêtes. Il faut naturellement les solliciter le plus tôt possible.

Désolé pour ces réponses un peu trop générales, surtout si vous menez un "mini-projet" qui ne doit pas aller jusqu'en Production.

cordialement

[Hédhili Jaïdane]

Bonjour,

Je ne sais pas si j'ai bien compris votre question mais il faut absolument distinguer deux organisations différentes des données :

- l'organisation en FICHIERS : soit des fichiers séquentiels sans index soit des fichiers indexés auxquels sont associés un index primaire et éventuellement des index secondaires (Alternate index)

- l'organisation en BASES DE DONNEES RELATIONNELLES (ex : DB2 sur grand système) constituées de TABLES sur lesquelles sont définis des Index

Bonjour.

En effet, à l'exception de l'AS/400 (et suivants) où DB2 fait partie du micro-code et ne constitue pas un logiciel ou une couche de logiciel indépendante de la machine et où les tables et les index sont en fait basés sur des fichiers physiques (tables) et des fichiers logiques (vues et index) simples ou joints mono ou multi-formats. Cobol/400 les traite comme des fichiers indexés assignés à DATABASE et non DISK. ILE Cobol/400 peut aussi utiliser les alternate index crées à la création du fichier, mais dans ce cas, ils doivent être déclarés comme tels et non comme des fichiers indexés. La description de tous ces types de fichiers peut être interne, externe source ou externe objet. Dans ce dernier cas, la description est extraite de la description du fichier qui doit exister au moment de la compilation.

Ainsi les enregistrements sont lus dans l'ordre du chemin d'accès sans avoir besoin de faire un tri interne ou externe (sauf pour QUERY qui doit trier). Ces tables, vues et index peuvent avoir été crées par des DDS (Data Description Specifications) ou CREATE SQL.

Bien entendu, Cobol peut aussi accéder à DB2/400 via du SQL embarqué.

[Johnny P.]

Plutôt d'ouvrir un nouveau topic , j'ai un petite question sur l'organisation indexée.

Je me suis rendu compte que le open extend ne fonctionnait pas sur l'organisation indexée
Et que donc pour ajouter des enregistrements dans un fichier (indexé) existant ça se compliquait !

D'où ma question , quand on n'a un fichier en access mode dynamic et organization indexed comment ajouter un enregistrement dans un fichier qui en possède déjà ?

C'est sûrement une question stupide mais le open output écrase le fichier , le open i-o n'écrit pas à la fin du fichier ...
Moi qui était content du mode extend...

Merci.

[Hédhili Jaïdane]

Plutôt d'ouvrir un nouveau topic , j'ai un petite question sur l'organisation indexée.

Je me suis rendu compte que le open extend ne fonctionnait pas sur l'organisation indexée
Et que donc pour ajouter des enregistrements dans un fichier (indexé) existant ça se compliquait !

D'où ma question , quand on n'a un fichier en access mode dynamic et organization indexed comment ajouter un enregistrement dans un fichier qui en possède déjà ?

C'est sûrement une question stupide mais le open output écrase le fichier , le open i-o n'écrit pas à la fin du fichier ...
Moi qui était content du mode extend...

Merci.

Bonjour.

- Aucune question n'est stupide à partir du moment qu'il y a un effort avéré.

- L'OPEN EXTEND est réservé aux fichiers séquentiels.

- Pour écrire dans un fichier indexé, ce dernier doit être ouvert en I-O. Il suffit de remplir le buffer, donc la clé à une ou plusieurs zones et de faire un WRITE.
Si l'enregistrement à écrire a la même valeur de clé qu'un enregistrement existant et si les clés doubles ne sont pas autorisées, on sortira par le INVALID. Pour bien faire il faudrait vérifier ce genre de situation par un READ préalable.
L'écriture se fait réellement (physiquement) en fin de fichier, mais dans l'ordre de la clé dans l'index. Cela n'a aucune importance sur les applications traitant de ce fichier même en accès séquentiel.
Certains OS ont des outils pour réorganiser les fichiers indexés selon leur clé et profiter pour récupérer l'espace libéré par les enregistrements supprimés. Une simple copie dans un autre fichier indexé de même clé le fait aussi.