Gestion de Fichiers

1. Gestion de Fichiers GF-9: Construction d’Indexes (Base sur le Chapitre 7 de Folk, Zoellick & Riccardi, File Structures, An Object-Oriented Approach with C++;)

2. Resume du Cours de cette semaine • Vue Generale • Un indexe pour les fichiers a entrees sequentielles • Operations de base sur les fichiers indexes a entrees sequentielles • Indexes trop grands pour tenir en memoire • Indexer un fichier avec plusieures cles  Indexes Secondaires. • Ameliorer la structure des indexes secondaires. • Indexes Selectifs • Attachement des indexes aux locations physiques

3. Vue Generale • Un index est une table contenant une liste de cles associees a un champ de reference pointant vers l’enregistrement dans lequel l’information referenciee par la cle peut etre trouvee. • Un index vous permet d’imposer de l’ordre dans votre fichier sans avoir besoin de le re-arranger. • Un index simple est tout simplement un tableau dont les elements sont les paires (cle, reference). • Il est possible d’avoir plusieurs indexes pour les memes donnees: donnees aux acces multiples. • La construction d’indexes nous donne la possibilite d’acceder a des fichiers d’enregistrements de longueur variablepar cle.

4. Un Indexe Simple pour les Fichiers aux Entrees Sequentielles I • Nous allons travailler avec une collection d’enregistrements de disques (musicaux, cette fois!) et contenant les informations suivantes: • Numero d’identification du disque • Titre • Compositeur(s) • Interprete(s) • Label de la maison d’edition

5. Un Indexe Simple pour les Fichiers aux Entrees Sequentielles II • Nous choisissons d’organiser le fichier en une serie d’enregistrements a longueur variable avec un indicateur de longueur, avant chaque enregistrement. Les champs de chaque enregistrement ont aussi des longueurs variables mais ils sont separes par des delimitateurs. • Nous formons une cle primaire en concatenant le code de label de la maison d’edition avec le numero d’identification du disque. Ceci devrait former un identificateur unique.

6. Un Indexe Simple pour les Fichiers aux Entrees Sequentielles III • De facon a obtenir un acces par cle rapide, nous creons un indexe simple avec un champ cle, associe a un champ reference, qui indique l’addresse du premier octet de l’enregistrement de donnees correspondant. • L’indexe peut etre trie alors que le fichier n’a pas besoin de l’etre. Cela veut dire que le fichier de donnees peut avoir des entrees sequentielles: les enregistrements apparaissent dans l’ordre dans lequel ils ont ete ajoute au fichier de donnees.

7. Un Indexe Simple pour les Fichiers aux Entrees Sequentielles IV • Quelques commentaires sur notre organisation d’indexe: • L’indexe est plus facile a utiliser que le fichier de donnees car 1) il utilise des enregistrements a taille fixe et 2) il est surement plus petit que le fichier de donnees. • En forcant le fichier indexe a avoir des enregistrements a taille fixe, on impose une limite sur la taille duchamp contenant la cle primaire. Ceci peut creer des problemes. • L’indexe pourrait contenir plus d’information que la cle et la reference. (example: on pourrait egalement retenir la longueur de chaque enregistrement dans l’indexe).

8. Operations de Base sur un fichier a entrees sequentielles • Supposition: L’index est assez petit pour etre sauvegarde en memoire. Un peu plus tard, nous verrons ce qui peut etre fait lorsque cela n’est pas le cas. • Creation des fichiers d’indexe et de donnees • Montage de l’indexe en memoire avant son utilisation. • Re-ecriture du fichier indexe sur disque apres son utilisation en memoire. • Ajout d’enregistrements • Effacement d’enregistrements • Mise a jour d’enregistrements

9. Creation, Montage et Re-ecriture • L’indexe est represente par un tableau d’enregistrements. Le montage en memoire peut donc etre fait sequentiellement en lisant un large nombre d’enregistrements d’indexe (qui sont petits) d’un seul coup. • Que se passe-t-il lorsque l’indexe a ete modifie en memoire mais sa re-ecriture sur disque n’a pas encore ete faite? • On peut utiliser un mecanisme pour indiquer si l’indexe est a jour ou non. • On peut avoir une procedure qui reconstruit l’indexe a partir du fichier de donnees au cas ou il n’est pas a jour.

10. Addition d’Enregistrements • Lorsqu’on ajoute un enregistrement, aussi bien le fichier de donnees que le fichier contenant l’indexe doivent etre mis a jour. • Dans le fichier de donnees, l’enregistrement peut etre ajoute n’importe ou. Cependant, la position relative (byte offset) du nouvel enregistrement dans le fichier doit etre retenue. • Puisque l’indexe est trie, la location du nouvel enregistrement est importante dans l’indexe: il faut decaler tous les enregistrements apparaissant apres celui que l’on insere afin de donner de la place au nouvel enregistrement. Cependant, cette operation n’est pas trop couteuse puisqu’elle prend place en memoire.

11. Effacement d’Enregistrements • L’effacement d’enregistrements peut etre fait en utilisant les techniques discutees dans les notes gf-8. • De plus, cependant, l’enregistrement d’indexe correspondant a l’enregistrement de donnees efface doit aussi etre efface. Encore une fois, puisque cet effacement prend place en memoire, le decalage d’enregistrement n’est pas trop couteux.

12. Mise a Jour d’Enregistrements • Il y a 2 categories de mises a jour: • La mise a jour change la valeur du champ cle. • La mise a jour n’affecte pas le champ cle. • Dans le premier cas, aussi bien le fichier d’indexe que le fichier de donnees peut necessiter le re-tri. Note: La mise a jour est facile a conceptualiser si elle est concue en un effacement suivi d’une insertion (mais l’utilisateur n’a pas besoin de le savoir). • Dans le second cas, l’indexe n’a pas besoin d’etre re-trie, mais le fichier peut en avoir besoin. Si l’enregistrement mis a jour est plus petit que l’enregistrement original, il peut-etre re-ecrit au meme endroit. Si, par contre, il est plus grand un nouvel endroit doit etre trouve (encore une fois, une solution effacement/insertion peut etre utilisee.

13. Indexes trop grands pour Tenir en Memoire I • Problemes: • La recherche binaire demande plusieurs seeks plutot que d’etre performee a la vitesse de la memoire. • Le re-arrangement de l’indexe demande le decallage ou le triage de donnees sur l’unite de storage secondaire  Ceci est tres couteux (vis a vis du temps requis). • Solutions: • Utilisation d’une organisation en Hashcoding • Utilisation d’un indexe organise dans une structure d’arbre (example: un Arbre-B)

14. Indexes trop grands pour Tenir en Memoire II • Les indexes simples, cependant, ne doivent pas etre completement abandonnes meme s’ils sont trop grand pour tenir en memoire: • Ils permettent l’acces multiple aux donnees.

15. Les Indexes a Cles Multiples • Les indexes construits precedemment nous permettent seulement l’acces par cle: ils nous permettent de retrouver le disque DG188807, mais on n’a pas la possibilite de trouver la 9eme Symhonie de Beethoven  Les indexes a cle simple ne sont pas tres utiles! • Il faudrait avoir d’autres cles secondaires telles que: le titre du disque, le composeur, l’interprete. • Bien qu’il serait possible de lier ces cles secndaires a une position relative (byte offset) dans le fichier de donnees, ceci n’est habituellement pas la solution choisie (nous verrons pourquoi dans un moment). On choisit plutot de lier la cle secondaire a une cle primaire qui, elle, pointera directement a la position relative dans le fichier des donnees.

16. Addition s’Enregistrement dans un Indexe a cles multiples • Lorsqu’une cle secondaire est utilisee, ajouter un enregistrement demande la mise a jour du fichier de donnees, de l’indexe primaire et de l’indexe secondaire. La mise a jour de l’indexe secondaire est similaire a celle de l’indexe primaire. • Les cles secondaires sont exprimees en lettres majuscules. La forme minuscule/majuscule doit etre obtenue du fichier des donnees. De plus, a cause de restrictions sur la longueur des cles, les cles secondaires peuvent parfois etre tronquees. • L’indexe secondaire peut contenir des enregistrements dupliques (l’indexe primaire ne le peut pas!

17. Effacement d’Enregistrements dans un indexe a cles multiples • Effacer un enregistrement du fichier de donnees correspond a effacer sa cle dans l’indexe primaire et peut vouloir dire effacer toutes les cles pointant a la cle primaire dans les indexes secondaires. • Cependant, il est aussi possible de ne pas s’inquieter des indexes secondaire  Cette solution est moins couteuse car on n’a pas besoin de re-arranger les indexes secondaires. • Neanmoins, il y a d’autre couts associes a cette solution.

18. Mise a Jour d’Enregistrements dans un Indexe a cles multiples Trois situations sont possibles. • La mise a jour concerne les cles secondaire: il se peut qu’il fasse re-arranger l’index secondaire. • La mise a jour concerne les cles primaires: des changements sont requis de l’indexe primaire, mais tres peu de l’indexe secondaire. • La mise a jour concerne d’autres champs: aucun changement n’est requis de l’indexe primaire ou secondaire.

19. Recherche en utilisant une combinaison de cles secondaires • Avec des cles secondaires, on peut chercher tous les disques de Beethoven ou tous les disques intitules “Concerto pour Violon”. • Encore plus important, on peut utiliser des combinaisons de cles secondaires (example: cherche tous les disques interpretant la 9eme Symphonie de Beethoven). • Si nous n’avions pas de cles secondaires, une telle requete serait tres couteuse car elle demanderait une recherche sequentielle de tout le fichier de donnees. Avec des cles secondaires, cette requete et facile et rapide a executer.

20. Ameliorer la structure de l’indexe secondaire I: le Probleme Les indexes secondaires amenent deux diffixultes: • Le ficher contenant l’indexe doit etre re-arrange a chaque fois qu’un nouvel enregistrement est ajoute au fichier • S’il y a des cles secondaires dupliquees, le champ de la cle secondaire est repete pour chaque enregistrement  De l’espace est gaspille.

21. Ameliorer la structure de l’indexe secondaire II: Solution 1 • Solution 1: On peut changer la structure secondaire de facon a ce qu’elle associe un tableau de references a chaque cle secondaire. • Avantage: Ceci permet d’eviter la necessite de re-arranger le fichier contennant l’indexe trop souvent. • Desavantages: • Cela peut restreindre le nombre de references associees a chaque cle secondaire. • Cela peut coser de la fragmentation interne, et donc, gaspiller de l’espace

22. Ameliorer la structure de l’indexe secondaire III: Solution 2 • Methode: Chaque cle secondaire pointe vers une liste differente de cles primaires. Chacunes de ces listes peut s’aggrandir autant que necessaire et aucun espace n’est perdu a la fragmentation interne. • Avantages: • L’indexe secondaire n’a besoin d’etre re-arange qu’au moment d’une addition d’enregistrement. • Le re-arrangement est plus rapide. • Il n‘est pas tres couteux de sauvegarder l’indexe secondaire sur le disque. • L’indexe primaire n’a jamais besoin d’etre trie. • L’espace d’une cle primaire effacee peut etre facilement re-utilise. • Desavantage: • La localite (dans l’indexe secondaire) a ete perdue  Il faudra peut-etre faire plus de seeking.

23. Indexes Selectifs • Lorsque vous utilisez des cles secondaires, vous pouvez diviser le fichier en plusieures parties et, ce faisant, fournir des vues selectives des donnees. • Par example, vous pouvez construire un indexe selectif qui ne contient que les titres de disques de musique classique, ou de disques apparus avant 1970 ou apres 1970. • Une demande possible pourrait ainsi etre:“Donner une liste de tous les disques de la 9eme Symphonie de Beethoven apparus apres 1970.

24. Attachement I • Question: A quel moment une cle est-elle attachee a l’addresse physique de l’enregistrement duquel elle correspond? • Reponse jusqu’a maintenant: L’attachement de nos cles primaires prend place au moment de la construction. L’attachement de nos cles secondaires prend place au moment ou elles sont utilisees. • Avantage de l’attachement au moment de la construction: Un acces plus rapide. • Desavantage de l’attachement au moment de la construction: la reorganisation du fichier de donnees doit resulter en une modification de tous les indexes deja attaches. • Avantages de l’attachement au moment de l’utilisation: moins risque

25. Attachement II Choix dans les decisions sur l’attachement • Un attachement rigoureux au moment de la construction est preferable lorsque: • le fichier de donnees est statique ou presque statique, ne demandant que peu ou pas d’ajouts d’effacements et de mises a jour. • Une performance rapide pendant la recherche est une grande priorite. • Retarder l’attachement aussi longtemps que possible est plus simple et moins risque lorsque le fichier de donnees demande beaucoup d’ajouts, d’effacements et de mises a jour.