|
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é. |
|
|
|
Comme pour les autres chapitres de ce tutoriel (ou tutorial, ou cours en ligne), nous utiliserons le SGBD Access comme
support pratique. |
|
|
|
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 20 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. |
|
|
