Migration de lecteurs – Transfert de dates-clés

15 avril 2012 Anne-Marie Import de données

 

Un "simple import" ou une véritable migration ?

 

Lors de la migration d'une base vers une autre, on souhaite parfois préserver certaines données du "passé" de ces lecteurs, par exemple des dates-clés (inscription, début et fin d'abonnement).
Dans ce cas, il faut importer par la méthode standard, et employer ensuite les paniers de lecteurs et des requêtes SQL afin de récupérer les dates telles qu'elles étaient à l'origine.

• C’est le cas si vous changez de logiciel et que vous passez à PMB.
• La situation est la même si deux bibliothèques qui emploient déjà PMB ont décidé de s’associer. Vous allez fusionner les 2 bases PMB : créer un catalogue commun et une liste globale de lecteurs.

 

Il y a trois dates-clés liées aux lecteurs :

• la date de création, autrement dit, la première inscription du lecteur dans la base
• le début d’adhésion correspond soit à la date de création, soit à la date du dernier renouvellement de l’abonnement
• la fin d’adhésion, c’est le moment où l’abonnement arrivera ou est arrivé à échéance

 

Lorsqu’on crée des lecteurs manuellement dans PMB, ou lorsqu’on importe des lecteurs (que ce soit par la méthode standard ou avec un script comme import Bretagne ou import Belgique), ces trois dates-clés ne sont pas modifiables.

• Les dates de création et de début d’adhésion sont identiques : c’est le jour de l’import ou de la saisie manuelle
• Quant à la date de fin d’adhésion, elle est calculée automatiquement par PMB, sur base de la durée d’adhésion de la catégorie de lecteurs concernée.
• Dans un cas comme dans l’autre, le calcul automatique de la fin d’adhésion par PMB donne un résultat cohérent.

 

Dans la majorité des cas, ce système ne pose pas de problème, car les emprunteurs sont

• soit des nouveaux lecteurs qui ne figuraient pas dans la base ; dans ce cas, il est logique que les dates de création et de début d’adhésion soient celles du jour où l’import a été réalisé
• soit d’anciens lecteurs dont on renouvelle l’abonnement ; dans cette hypothèse, la date de création ne change pas, mais la date de début d’adhésion est modifiée, elle correspond désormais au jour de l’import.
• Dans un cas comme dans l’autre, le calcul automatique de la fin d’adhésion par PMB donne un résultat cohérent.

 

Comment PMB distingue-t-il les anciens lecteurs des nouveaux ?

Il est impossible d’opérer une distinction sur base du nom et du prénom des lecteurs, car vous pouvez avoir plusieurs homonymes dans votre base. La seule solution pour identifier un emprunteur sans la moindre ambiguïté, c’est de tenir compte du numéro identifiant du lecteur (son « code-barres »), comme PMB le fait d’ailleurs pour l’exemplaire.

• Si ce numéro existe déjà dans la base, il s’agit d’un ancien lecteur dont on renouvelle l’abonnement.
• Si ce numéro est inconnu dans la base, c’est un nouveau lecteur.

C’est pourquoi il est important de bien choisir les numéros de lecteurs, des numéros qui assurent une certaine « pérennité ». Sinon, vous risquez des problèmes, le même lecteur pourrait avoir deux numéros différents, et donc deux identités distinctes et deux listes de prêts en cours ou en retard.
Voir Conseils afin de bien choisir les numéros d'exemplaires ou de lecteurs

 

Dans certaines circonstances, ce n’est pas un « simple import », c’est une véritable migration d’une base vers une autre, parce que les « nouveaux lecteurs » ont un passé, et qu’on aimerait en garder des traces ! Il se peut que vous vouliez conserver les « vraies » dates d’inscription et de début d’adhésion, afin de savoir à quel moment il faut demander aux lecteurs de renouveler leur abonnement – surtout s’il est payant !

 

Il y a encore 3 autres dates à mentionner dans ce contexte de migration :

• la date du dernier emprunt effectué par le lecteur (le champ last_loan_date)
• la date de fin de blocage – si un lecteur a rendu des livres en retard, on peut bloquer son compte et lui interdire tout emprunt pendant une durée équivalente au retard (le champ date_fin_blocage)
• la date de dernière modification de la fiche du lecteur (cela peut correspondre à un renouvellement d’abonnement, mais c’est peut-être tout simplement la date où on a modifié l’adresse du lecteur ou ajouté un numéro de téléphone)

N.B. En soi, les dates du dernier emprunt et de fin de blocage n’ont guère d’importance, il n’est pas nécessaire de les préserver lors de la migration. Toutefois, vous verrez qu’elles nous serviront à mémoriser temporairement certaines infos.

 

Principes de base du processus

• En théorie, 3 dates-clés doivent être transférées, mais concrètement parlant, il suffit d’importer les deux premières : la date de création (ou inscription) et la date de début d’adhésion
• En effet, la date de fin d’adhésion peut être recalculée automatiquement à tout moment, il suffit d’ajouter à la date de début d’abonnement une durée égale à celle de l’adhésion (cette durée peut varier selon la catégorie de lecteur).
• Première étape : exporter de la base de départ toutes les données du lecteur, entre autres les « vraies » dates de création et de début d’adhésion.
• Puisque l’import « standard » ne permet pas d’importer les dates-clés, on va importer les lecteurs « normalement » dans PMB, les dates de création et de début d’adhésion seront donc celles du jour de l’import, et la fin d’adhésion sera calculée par PMB.
• Outre les données habituelles (numéro identifiant, nom et prénom de lecteur, adresse, etc), trois champs doivent figurer dans le fichier d’import :
  • deux dates : les dates du dernier emprunt et de fin de blocage, mais pas dans le but de préserver ces valeurs. En fait, l’intitulé est trompeur, on aura stocké d’autres dates dans ces champs.
  • le champ « message » doit contenir un message significatif, qui permet de repérer aisément tous les lecteurs qui ont été importés en même temps
• Lorsque l’import sera terminé, on va employer une série de requêtes SQL afin d’effectuer un petit « tour de passe-passe »
  • Sélectionner des lecteurs, regrouper dans un même panier ceux dont le message est identique
  • Ceci permet d’employer des procédures SQL d’action, qui auront un effet seulement sur les lecteurs qui figurent dans ce panier
  • La date de dernier emprunt deviendra la date de création du lecteur
  • La date de fin de blocage deviendra la date de début d’adhésion
  • La date de fin d’adhésion sera à nouveau calculée sur base de la « vraie » date de début d’adhésion
  • Lorsque les 3 dates sont correctes, on peut réinitialiser les dates du dernier emprunt et de fin de blocage, et leur donner la valeur par défaut qu’elles devraient avoir. En effet, on n’a désormais plus besoin des valeurs qui y avaient été temporairement stockées.
  • Après une ultime vérification, si tout est exact, on peut supprimer le contenu du champ message et vider le panier de lecteurs

 

Réflexions complémentaires

Tout dépend en effet de ce que vous pouvez exporter à partir de l’ancien logiciel. Si vous n’avez qu’une seule info, le début d’abonnement, il faudra mettre cette date non seulement dans la colonne « début d’adhésion », mais aussi dans la colonne « date d’inscription ». Il n’y aura donc aucune différence entre ces deux colonnes du fichier d’import.

Il est fort possible que votre ancien logiciel ne prévoyait pas de message lié au lecteur, mais il en faut un dans le fichier d’import.  En effet, sauf dans le cas exceptionnel où tous les lecteurs à importer seraient dans la même catégorie et auraient le même code statistique, on importe nécessairement en plusieurs fois.

La raison est simple. Ce n’est qu’au moment de l’import qu’on choisit la future catégorie et le futur code statistique, donc vous devrez préalablement scinder le fichier d’import en plusieurs « blocs », afin d’attribuer à chaque sous-ensemble de lecteurs la catégorie et le code statistique souhaités.

On importe donc rarement dans une base vide, il y a en général déjà des lecteurs. Or, les requêtes que j’ai prévues pour modifier les dates ne peuvent pas s’appliquer à l’ensemble des emprunteurs de la base, mais seulement à ceux que vous venez d’importer. La seule manière de changer les dates pour certains lecteurs, mais pas pour d’autres, c’est de mettre ces emprunteurs dans le même panier et d’employer des requêtes d’action sur paniers de lecteurs. Et la meilleure manière de repérer qui sont les emprunteurs à regrouper de la sorte, c’est de les associer au même message dans le fichier d’import.
Exemples de message : « avril 2012 adultes », « avril 2012 enfants »

• Il faut, en théorie, importer 2 dates, celle d’inscription (ou création) et celle de début d’adhésion des lecteurs. Que faire si on ne dispose que d’une seule de ces valeurs, le début d’abonnement ?
• Pourquoi faut-il prévoir un contenu pour le champ « message du lecteur » ?

 

Création du login et du mot de passe

 

Le login permet au lecteur de s’identifier dans l’OPAC, et d’accéder à son compte. Ce qui entraîne une contrainte importante : il ne peut pas y avoir 2 logins identiques dans la base.

Si on n’a pas complété les champs login et mot de passe, PMB les crée automatiquement.

Login par défaut : la première lettre du prénom + le nom en entier – le tout en un mot et en minuscules.
S’il y a risque d’homonymie dans les logins, PMB ajoute automatiquement un chiffre afin de les distinguer.
Ex. Schtroumpf Paresseux, Schtroumpf Paysan et Schtroumpf Poète
on aura – dans l’ordre – pschtroumpf, pschtroumpf1 et pschtroumpf2.

Mot de passe par défaut : l’année de naissance.

 

Si vous n’avez pas prévu de login et de mot de passe dans le fichier d’import, et que le secrétariat ne vous en a pas fourni, les lecteurs n’en auront pas !

C’est gênant, vous devriez créer manuellement le login et le mot de passe, ce qui risque de vous prendre du temps.

Le cœur du problème, c’est que vous devez être sûr de l’unicité du login, mais c’est plus difficile à vérifier si vous importez en plusieurs étapes. Vous risquez d’avoir « oublié » quels étaient les logins employés jusqu’à présent.
En outre, entre deux imports, vous avez peut-être aussi créé quelques lecteurs manuellement (Circulation > Nouveau lecteur), donc les risques de doublons augmentent au fil du temps.

 

• Mode de création lors de la saisie « manuelle » (Circulation > Nouveau lecteur)
• Import de lecteurs par la méthode « standard » – ce qui est le cas lors d'une migration de lecteurs
• Si le secrétariat n’a pu vous fournir ni un login ni un mot de passe, voici une solution facile à mettre en œuvre.

  Login = numéro de lecteur – Mot de passe = année de naissance

  – un login unique assez facile à mémoriser – si du moins les lecteurs connaissent leur numéro par cœur … ou ont leur carte de lecteur sous la main … Et s’ils vous posent la question, vous pouvez aisément trouver la réponse.
  – un mot de passe qu’on ne risque pas d’oublier – on peut supposer que les lecteurs se souviennent de leur année de naissance … et espérer que les données du fichier d’import étaient correctes 😉

  – vous demander de remplacer leur login par quelque chose de plus mnémotechnique
  – changer eux-mêmes leur mot de passe s’ils le souhaitent
  – et s’ils ont oublié leur nouveau mot de passe, vous demander de le réinitialiser en lui rendant sa valeur par défaut.
  – C’est simple à faire : vous recherchez le lecteur « distrait » dans votre base, vous ouvrez sa fiche en mode modification, il vous suffit d’introduire son année de naissance dans la zone de saisie prévue pour le mot de passe, et le tour est joué.

  J’ai prévu 2 requêtes d’action sur panier de lecteurs, afin de créer ce login et ce mot de passe pour tous ceux qui en seraient dépourvus.

  • Dans le fichier d’import, des valeurs sont répétées
  • Avec ce système tout simple, vous créez
  • De toute façon, par la suite, les lecteurs peuvent
  • Roue de secours : même si vous avez déjà importé des lecteurs sans login ni mot de passe, il n’est pas trop tard !

 

Le format des dates dans le fichier d'import

 

Ces dates doivent pouvoir être interprétées correctement en Php – MYSQL, donc le seul format possible est ‘0000-00-00’ : « année – mois – jour »
4 chiffres pour l’année, 2 chiffres pour les jours et les mois, même ceux < 10
C’est d’ailleurs le seul format qui permet un tri chronologique « naturel » (par ordre normal ou inversé).

 

Obtenir une date dans ce format-là est parfois plus compliqué qu’on ne le croirait :

• Vous n’allez pas nécessairement pouvoir extraire les dates dans le bon format, à partir de votre ancien logiciel
• Excel risque de vous jouer de mauvais tours, et de convertir les dates dans un format inapproprié, car il a une "vision très particulière des dates".

 

En effet, Excel mémorise les dates sous la forme d'une série de numéros séquentiels, des nombres entiers donc. On pourrait même parler de numéros "cachés".

A titre d'exemple, le 1er janvier 2012 était le jour 40909, le 2 janvier 2012, le jour 40910 …
D'où viennent ces valeurs ?
Le point de départ, le jour n° 1, c'est le 1er janvier 1900 (sous Windows), le 1er janvier 1904 (sous Mac). Dans un cas comme dans l'autre, ce type de calendrier s'arrêtera le 31 décembre 9999.
Il est donc impossible de mémoriser dans un format date des dates antérieures au 1er janvier 1900.

 

Le coeur du problème, c'est la manière dont votre ancien logiciel a exporté les dates.

N.B. Dans le zip, il y a un fichier qui vous montre en détail comment procéder (excel-format-dates-explications.xls).

• Si c’est sous la forme ‘0000-00-00’, aucun souci à se faire.
• Si c'est un format texte avec un affichage différent, il faut
  • d'abord convertir ce texte en une date aux yeux du tableur (donc un numéro caché)
  • ensuite adapter le format d’affichage afin que cette date puisse être importée comme PMB le requiert.

 

Ne vous contentez pas de ce résumé !
La version imprimable contient beaucoup d'autres infos complémentaires et des captures d'écran :
Migration de lecteurs – Transfert de certaines dates-clés (pdf)

 

Ce tutoriel est accompagné d’un zip à décompresser :
Test – Migration de lecteurs – Avec certaines dates-clés

 

Contenu du zip

• le fichier test avec les données des lecteurs – en deux formats
  • pmb-excel-import-lecteurs-avec-dates.xls
  • pmb-excel-import-lecteurs-avec-dates.csv
• les explications sur le format « dates » dans le tableur et sur la manière de les convertir
  • excel-format-dates-explications.xls
• les requêtes SQL mentionnées dans ce tutoriel (14 au total) – voir page 5, au bas de la page 7 et page 10
  • 2 dans l’onglet Administration
  • 12 dans l’onglet Circulation (1 procédure de sélection et 11 procédures d’action)

 

Voir aussi

Notes techniques sur l'import des données et sur le format csv

 

données à importer, lecteurs

Astuce des fichiers _subst (substitution) Utilitaires – Gestion de la base – Commentaires