La base de données pédagogiques « ddt » du SEM est utilisée pour créer les adresses électroniques dont tous les enseignants genevois seront progressivement dotés, conformément à la décision du département de l’instruction publique du 11 mai 2006. Cette base reçoit les informations nécessaires à cette opération par import de fichiers. Cet article décrit le développement informatique réalisé et la marche à suivre pour importer ces fichiers dans la base de données « ddt ».

Introduction

La base de données « ddt » reçoit périodiquement des informations sur les personnes travaillant au DIP par import de fichiers de type « txt ». Ces informations, qui sont utilisées pour créer les adresses électroniques, doivent être importées dans la table « MISES A JOUR » de « ddt ».

Pourquoi un développement informatique a-t-il été nécessaire ?

Les possibilités d’import font partie des outils existants dans toutes les bases de données. Mais l’import de données nécessite l’existence d’une structure dans les fichiers à importer, structure généralement définie par des séparateurs de champs et d’enregistrements qui peuvent être de taille fixe ou variable. Or les fichiers que nous recevons ne comportent ni séparateur d’enregistrements, ni séparateur de champs. Ils sont composés de lignes de 80 caractères, les premiers caractères de la ligne donnant une information sur son contenu, et les champs sont de taille fixe. Le nombre de lignes par enregistrement n’est pas constant (certains champs peuvent être absents comme « n° de téléphone », ou « adresse » par exemple. Les outils d’import existants ne permettent pas d’importer ces fichiers et ils devaient être « traités » par des scripts Pearl pour être importés.

Qu’apporte ce développement et comment l’import s’effectue-t-il ?

Les fichiers peuvent désormais être importés dans « ddt » sans traitement préalable. Lors d’un import, les informations correspondant à chaque enregistrement figurant dans le fichier sont lues puis recherchées dans la table « MISES A JOUR » de « ddt ». Si elles ne s’y trouvent pas, un nouvel enregistrement est créé, sinon, le contenu de chaque champ est comparé aux informations lues, et au besoin mis à jour. Au terme de l’import, un message fournit plusieurs informations :

– type du fichier importé (élèves ou enseignants)
– durée du traitement
– nombre d’enregistrements importés
– nombre d’enregistrements modifiés.

L’utilisateur voit ensuite apparaître à l’écran la liste des enregistrements créés et modifiés. Une recherche parmi cette sélection permet d’isoler les enregistrements nouvellement créés ou ceux qui ont été modifiés.

Risques d’erreur et inconvénients

Si l’utilisateur se trompe de fichier (en sélectionnant par exemple un fichier « élèves » alors qu’il a demandé à importer des enseignants) ou si le fichier n’a pas la bonne structure, une alerte l’avertit. Les méthodes d’import ont été optimisées pour réduire le temps de traitement (il faut bien sûr exécuter le programme dans sa version compilée pour tirer profit de cette optimisation). Ces méthodes supposent que toutes les structures possibles sont présentes dans les fichiers que nous avons reçu depuis janvier 2005. Si de nouvelles structures devaient apparaître (champs ou lignes supplémentaires pour certains enregistrements), ces méthodes devraient être modifiées. Il serait possible d’éviter ces désagréments et de rendre les méthodes capables d’importer des fichiers structurés différemment si ces derniers comportaient des séparateurs d’enregistrements et de champs.

N. B. L’import sans séparateur de champ reste possible avec des champs de longueur fixe, mais l’information importée doit alors être débarrassée des blancs finals. C’est la fonction eliminerBlancs qui se charge de ce travail.

Tests effectués

Les méthodes d’import des fichiers « élèves » et « enseignants » ont été testées avec la totalité des fichiers reçus pour l’année 2005 et avec quelques fichiers de l’année 2006. Le code source d’une de ces méthodes est donné dans le cadre ci-dessous.

Code source
– Import d’élèves