Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
TUTORIEL cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Formation > Tutoriels > Bases de données relationnelles > Les échanges de données
        Révision : 03 janvier 2003
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 25 : les échanges de données
 
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 :
Résultat de l'importation
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.
Table importée du web
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.
Importation de données et d'objets dans Access
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.
Chapitre précédent Plan du tutoriel Liste des tutoriels Chapitre suivant
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
Copyright © CERIG/EFPG 1996-2003
Réalisation et mise en page : J.C. Sohm