1 - Introduction
De
plus en plus, les applications échangent des données, et les SGBD n'y font pas
exception.
Il y a bien sûr le fameux "copier-coller", qui marche en
de nombreuses occasions.
Mais dans des cas plus difficiles ou plus spécifiques,
il faut recourir à des opérations d'importation ou d'exportation.
C'est pourquoi,
dans les menus des applications, à la rubrique "Fichier", on constate
de plus en plus souvent la présence des fonctions "Importer..." et/ou
"Exporter...".
Les BDD sont des réservoirs à données. Ces données ont
peut-être été saisies au clavier, mais la saisie manuelle est coûteuse, et le
risque d'erreur est toujours présent.
Chaque fois que cela est possible, on
saisit les données à l'aide de capteurs reliées à des ordinateurs (appareils de
mesure, lecteurs de codes barres, scanners, etc.), avant de les importer dans
une base.
De plus, on constate une dématérialisation croissante des
données échangées entre les entreprises. Pour les opérations commerciales
récurrentes, les bons de commande et les factures imprimés vont peu à peu
disparaître au profit de transmissions directes via Internet (cela s'appelle le
"e-procurement").
Toutes les données résultant de ces transactions
aboutiront dans des BDD par importation.
Il est bien rare que, dans une entreprise d'une certaine
taille, toutes les données soient stockées dans une seule et même BDD (et ce ne
serait peut-être pas judicieux de le faire -- il y a des discussions
passionnées sur ce sujet).
On est donc fatalement amené à transférer des
données d'une base à une autre.
Le cas échéant, il peut être intéressant de
transférer des objets (requêtes, formulaires, états, macros, etc.), c'est à
dire des structures et non plus des données.
Enfin, en cas de changement de
matériel et/ou de logiciel, on peut être amené à transférer une base entière d'un
système informatique à un autre.
Certains échanges, bien sûr, peuvent être très difficiles à
réaliser (entre des systèmes informatiques n'utilisant pas le même système
d'exploitation, par exemple), voire même impossibles.
Les divers SGBD que l'on
trouve sur le marché sont plus ou moins ouverts, et l'étude de l'import/export
est donc très spécifique du système utilisé.
2 - L'importation de données de type texte
Les
données que l'on veut importer dans une BDD se trouvent souvent dans de simples
fichiers texte. Ces derniers présentent en effet trois avantages déterminants :
- on les génère très facilement ;
- leur poids est modeste, parce que les balises de mise en forme sont absentes ;
- les ordinateurs peuvent les lire aisément, par suite de l'absence d'un format propriétaire.
Les tableaux n'existant pas dans les fichiers texte, les données
d'un même enregistrement sont rassemblées sur une même ligne (nous supposerons
ici que c'est toujours possible).
Le passage d'un champ à l'autre est repéré
par un caractère particulier réservé à cet effet (espace, point virgule, etc.)
et appelé caractère de séparation, ou par une tabulation.
La figure ci-dessous
représente un exemple d'une telle disposition, où l'espace sert de caractère de
séparation.
| Groupe X - Magasin Y Date : 28/12/2002 Date Heure Caisse Produit Quant. Prix Total 28/12/2002 9:02:31 03 C-168324 1 24,95 24,95 28/12/2002 9:02:35 02 P-2896 3 13,55 40,65 28/12/2002 9:02:41 02 X-12709 1 6,90 6,90 etc...... |
A la fermeture du magasin, le fichier texte contenant le
détail des ventes de la journée est envoyé (via un réseau de transmission de
données ) au centre de traitement informatique du groupe, où il est importé
dans une base de données.
Le lendemain matin, le patron trouvera sur son bureau
une synthèse des résultats de la veille, générée de manière entièrement
automatique...
Commençons, plus modestement, par importer manuellement un
tel fichier dans Access.
Mais avant de commencer, il faut que nous décidions si
nous importons dans une table existante, ou si nous laissons au système le soin
d'en créer une.
Nous conseillons vivement la première solution, et ce pour deux
raisons :
- on règle mieux les propriétés des champs dans la grille de création d'une table que dans l'assistant d'importation ;
- importer dans une table existante revient à réaliser une requête Ajout (les nouvelles données viennent s'inscrire à la suite des précédentes), et c'est généralement le résultat que l'on recherche.
Donc, avant d'importer, nous créons une table comportant
sept champs (Date, Heure, N°_caisse, Code_produit, Quantité, Prix_unitaire,
Prix_total), dotés des types de données et des propriétés adéquats, et en
évitant les espaces dans leurs noms.
Nous lançons ensuite l'assistant "Importation de
Texte" via "Fichier > Données externes > Importer...".
Il
faut d'abord préciser l'extension du fichier à importer et son chemin.
On
notera au passage la liste des formats qu'Access peut importer (outre le sien
propre) : dBase, Excel, HTML, Outlook, Lotus, Paradox, texte, XML et les
formats des SGBD respectant l'interface ODBC (Open DataBase Connectivity).
Cette interface, créée par Microsoft en 1993, permet à presque tous les SGBD de
communiquer lorsqu'ils sont installés sous Windows (il faut cependant que le
pilote ODBC correspondant existe).
L'assistant démarre et nous conseillons de cliquer tout de
suite sur le bouton "Avancé...".
La fenêtre "[Nom du fichier]
Spécification d'importation" s'ouvre, qui nous permet de régler tous les
détails de l'importation :
- Format du fichier : le fichier est-il "délimité" ou de "longueur fixe" ? Le premier cas correspond à l'usage d'un caractère de séparation, le second à une tabulation. Dans le cas présent, la réponse est "délimité" ;
- Séparateur de champ : il faut indiquer au système quel est le caractère séparateur. Dans le cas présent, la réponse est "space" ;
- Délimiteur de texte : pour différencier les champs de texte des champs numérique, on place parfois le texte entre des guillemets simples ou doubles. Dans le cas présent, la réponse est "aucun" ;
- Dates, heures et nombres : dans le cas présent, nous laissons les valeurs par défaut ;
- Informations sur le champ : ces informations (nom, type de données, indexation) doivent correspondre avec celles de la table dans laquelle nous allons importer. Le système propose de ne pas importer le contenu de certains champs ("sauter"), ce qui rend service dans certains cas.
Avant de quitter cette fenêtre, nous devons enregistrer
toutes les informations qu'elle contient en cliquant sur le bouton
"Enregistrer sous..." et donner un nom au format d'importation
personnalisé que nous venons de créer.
Nous poursuivons avec l'assistant. Nous ne cochons pas
"Première ligne contient les noms des champs" pour deux bonnes
raisons : ce n'est pas vrai, et les noms des champs sont déjà déterminés
puisque nous importons dans une table existante -- ce que nous indiquons à
l'étape suivant, en précisant le nom de la table (liste déroulante).
Nous
cliquons sur "Terminer", et le système nous prévient que toutes les
données n'ont pas été importées avec succès. La table que nous avions préparée
se trouve ainsi remplie :
Les données des trois premières lignes du fichier texte
n'ont pas pu être importées, parce que leur type de données était incompatible
(seul "Produit" est passé entre les mailles).
Une table contenant les
erreurs d'importation a d'ailleurs été créée, dont voici le contenu :
Ces erreurs ne se seraient pas produites si nous avions
éliminé les trois premières lignes du fichier avant de l'importer. Il faut
cependant bien voir que si l'on importe un fichier texte de plusieurs centaines
de milliers de lignes, la probabilité de rencontrer quelques lignes erronées
n'est pas tout à fait nulle.
Une coupure de courant, un incident nécessitant le
redémarrage de l'ordinateur, une machine débordée qui écrit comme elle peut
dans son fichier journal, un petit bug dans le logiciel... et voici créée une
ligne qui ne s'importera pas correctement.
Mais la présence d'une à quelques
lignes dans la table des erreurs d'importation ne constitue pas un drame.
On
peut éliminer facilement les enregistrements déficients de la table (dans
laquelle s'est faite l'importation) à l'aide d'une requête suppression, le
critère étant que l'un des champs au moins n'est pas renseigné (Est Null),
alors qu'il devrait normalement l'être.
Lorsqu'on importe régulièrement des données possédant la
même structure, on accélère considérablement la procédure en réutilisant le
format d'importation.
Pour ce faire, il faut se rendre tout de suite dans la
fenêtre des spécifications d'importation, cliquer sur le bouton
"Paramètres...", et choisir le bon format.
Toutes les données
correspondantes s'inscrivent d'elles mêmes dans la fenêtre.
On peut encore aller plus vite en automatisant l'importation
à l'aide d'une macro, comme nous le verrons au chapitre suivant.
3 - L'importation de données du web
On
trouve de tout sur le web, y compris des tableaux de données sur les sujets les
plus divers. Il peut être utile de récupérer ces données dans un SGBD, ne
serait-ce que pour effectuer des requêtes. L'assistant d'importation d'Access
reconnaît les tableaux dans une page web, et en dresse la liste.
La plupart de
ces tableaux servent uniquement à la mise en page, et il faut trouver dans la
liste quel est le tableau qui contient les informations à importer.
A titre d'exemple, nous allons importer une liste
d'imprimeries dont le nom commence par un A, et qui se trouve dans les pages de
liens imprimerie du CERIG (variante sans cadres).
Le première opération
consiste à télécharger la page en question et à l'enregistrer sur le bureau de
l'ordinateur, grâce à la fonction "Enregistrer sous..." du
navigateur.
La seconde opération consiste à lancer l'assistant
d'importation, en lui indiquant la page HTML. L'assistant dresse une liste de
11 tableaux, dont seul le huitième contient l'information désirée.
La suite des
opérations se poursuit comme précédemment, mais nous laissons cette fois au
système le soin de créer la table correspondante.
La figure ci-dessous en
représente les premières lignes.
Si l'on examine les propriétés de la table ainsi créée, on
s'aperçoit que, pour les champs de type texte (Ville, Activité) le système
réserve automatiquement la place maximale (255 caractères), même si aucune des
chaînes de caractères importées n'atteint cette taille.
On peut toujours
corriger après coup, mais on court le risque de tronquer certaines
informations. Si l'on importe dans une table existante, et qu'une chaîne est
trop longue pour le champ, elle sera là encore tronquée, mais le fait sera
signalé dans le fichier des erreurs d'importation.
4 - L'importation d'objets
Tous
les objets d'une BDD gérée par Access peuvent être importés dans une autre base
gérée par le même SGBD : tables, requêtes, formulaires, états, macros, modules.
Mais cela ne veut pas dire qu'ils fonctionneront à coup sûr après importation.
Une requête, par exemple, est basée sur une ou plusieurs tables ou feuilles de
données.
Si nous importons la requête, mais que l'une des tables manque, la
requête ne peut pas fonctionner, et le système nous en avertira.
Il arrive souvent que l'on ne s'intéresse qu'à une petite
partie d'une grande base de donnée, par exemple une semaine dans les opérations
d'une année.
On a alors intérêt à créer des tables réduites à la semaine en
question, puis à les importer dans une nouvelle base avec tous les autres
objets.
On pourra effectuer les mêmes opérations que sur la base de départ,
mais avec 52 fois moins de données, ce qui va bien accélérer les opérations.
Pour voir fonctionner l'importation d'objets, nous suivons
de nouveau le chemin "Fichier > Données externes >
Importer...".
Nous indiquons au système un fichier Access (.mdb), et la
boite de dialogue suivante s'ouvre.
L'examen détaillé de cette boite révèle que :
- tous les objets sont importables (voir les onglets) ;
- en ce qui concerne les tables, on peut importer la structure seule ("Définition uniquement"), ce qui correspond à une table vide, ou la structure et les données ("Définition et données"). Nous retrouvons là le double aspect de l'objet table, sur lequel nous avons déjà insisté ;
- le même choix s'applique aux requêtes. Nous pouvons importer la structure seule ("Comme des requêtes"), ou la structure et le résultat ("Comme des tables").
Lorsque tous les objets désirés ont été sélectionnés (en
cliquant dessus -- un nouveau clic désélectionne), on valide par
"OK", et l'importation s'effectue.
5 - L'exportation
Dès
qu'un objet de la base (ex : table) est sélectionné, la fonction "Fichier
> Exporter..." devient active, et l'on peut se livrer aux opérations
inverses de celles décrites ci-dessus.
L'exportation d'une table sous forme d'un fichier texte
délimité peut servir de dernier recours pour transférer des données d'une base
à une autre, lorsque tous les autres moyens ont échoué. L'opération
d'exportation est sans douleur, il suffit d'indiquer au système le caractère de
séparation que l'on veut utiliser.
L'exportation d'un objet d'une base Access vers une autre
base Access ne pose pas de problème particulier. Si l'objet est une table, le
SGBD demande si l'on veut exporter la structure seule, ou la structure et les
données ensemble.
L'échange de données entre Access et Excel est très aisé, et
souvent pratiqué. Certains utilisateurs trouvent commode de commencer une
recherche d'information dans Access, et de la terminer dans Excel. Il faut dire
que la plupart des utilisateurs sont plus à l'aise dans le second logiciel que
dans le premier.
Mais faut également reconnaître que la mise en forme finale
des données avant impression est plus facile à réaliser dans une feuille de
calcul d'Excel que dans un état d'Access.
L'exportation des données des BDD vers le web prend de plus
en plus d'importance.
On distingue :
- les pages web statiques, c'est à dire générées d'abord depuis une base de données, puis mises en ligne sur un serveur web ;
- les pages web dynamiques. Elles sont générées à la volée par un script côté serveur à partir de données résidant dans une base de données, juste avant d'être envoyées au client internaute.
Les deux types de pages ont leurs mérites et leurs
inconvénients, et leurs applications sont distinctes ; nous n'entrerons pas
dans une discussion à ce sujet.
Précisons qu'Access ne permet pas de créer des
pages dynamiques, et que son mode de création de pages statiques est fort
médiocre. L'opération n'est pas paramétrable, et le code HTML obtenu n'est pas
fameux.
Pour faire communiquer une BDD (gérée sous Access) et le web, on
utilise généralement du logiciel tierce partie.
6 - Conclusion
Les
échanges d'information (données et objets) entre BDD sont plus ou moins faciles
suivant les cas envisagés. De ce point de vue, Access est un SGBD relativement
ouvert, qui reconnaît plusieurs formats.
Les échanges de données et d'objets entre bases gérées par
Access sont très aisés. L'importation de données en provenance de fichiers
texte ou HTML est bien gérée par Access. L'exportation -- en particulier vers
le web -- est médiocre, c'est un point faible de ce SGBD.
Aucun commentaire:
Enregistrer un commentaire