Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 5 sur 5
  1. #1
    Membre actif
    Inscrit en
    février 2006
    Messages
    292
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 292
    Points : 174
    Points
    174

    Par défaut Question sur les fichiers indexés

    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.

  2. #2
    Futur Membre du Club
    Inscrit en
    décembre 2010
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : décembre 2010
    Messages : 7
    Points : 19
    Points
    19

    Par défaut

    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

  3. #3
    Expert Confirmé
    Homme Profil pro Hédhili Jaïdane
    Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    juin 2007
    Messages
    1 868
    Détails du profil
    Informations personnelles :
    Nom : Homme Hédhili Jaïdane
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2007
    Messages : 1 868
    Points : 3 254
    Points
    3 254

    Par défaut

    Citation Envoyé par rasti92 Voir le message
    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é.

  4. #4
    Membre actif
    Inscrit en
    février 2006
    Messages
    292
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 292
    Points : 174
    Points
    174

    Par défaut

    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.

  5. #5
    Expert Confirmé
    Homme Profil pro Hédhili Jaïdane
    Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    juin 2007
    Messages
    1 868
    Détails du profil
    Informations personnelles :
    Nom : Homme Hédhili Jaïdane
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2007
    Messages : 1 868
    Points : 3 254
    Points
    3 254

    Par défaut

    Citation Envoyé par Johnny P. Voir le message
    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •