Outils pour utilisateurs

Outils du site


user:yamina_abdallahi:termino:migration-access-postgresql

De l'art de migrer des bases de données Access vers PostgreSQL

Remarques préliminaires

PostgreSQL reconnait de la même façon les commandes écrites en lettres majuscules ou en minuscules. Cependant, pour des questions de lisibilité, il est préférable de les écrire en lettres majuscules. C'est (sauf oubli) le choix adopté ici.

Les noms de schémas, tables, etc. ne contiennent ni majuscules ni accents. Le choix contraire obligerait en effet à utiliser des guillemets dans les requêtes.

Objectifs

TO DO...

Migration

TO DO...

Fusion des tables

TO DO...

Difficultés rencontrées

TO DO...

Migration des bases

TO DO...

Utilisation de l'outil ODBC

TO DO...

Automation à l'aide de VBA

TO DO...

Difficultés rencontrées

TO DO...

Une des difficultés rencontrées concerne l'encodage des caractères. En effet, les bases de départ (Access) sont encodées en UNICODE. La migration vers une base PostreSQL n'aurait donc pas du poser de problèmes. C'est le cas lorsque l'on passe de Access à PostreSQL sous Windows (à retenir néanmoins : l'existence de la fonction StrConv(chaine, vbUnicode) et StrConv(chaine, vbFromUnicode) pour passer de L'ANSI à l'UNICODE et inversement), mais ce n'est plus le cas, lorsque l'on passe de ce dernier à PostrgresSQL sous NetBSD : les tests ont faits apparaître des problèmes de visualisation des caractères accentués. Par contre, lorsque l'on passe directement d'Access à PostgreSQL sous NetBSD, le problème ne se pose plus. Après vérification de l'encodage des différents terminaux, il semble que le problème vienne du recours à pg-dump(8) pour le passage d'une machine à l'autre et des opérations que cela suppose (sans que cela vienne nécessairement de l'outil en lui-même). Pour l'instant, le mystère reste entier…

Fusion des tables

TO DO...

Révision de la structure des tables

TO DO...

La conversion des types

Migrer et fusionner des bases de données suppose de s'interroger sur la douloureuse question des types de données. D'abord parce que certains types de données Access ne sont pas (ou mal) reconnus par PostgreSQL. Ensuite, parce que la révision de la structure des tables a entrainé le besoin de convertir certains types de données.

Ainsi en est-il des champs se rapportant aux noms de personnes. En effet, dans les bases de départ, il s'agissait de champs de types chaînes de caractères. Or, dans le cadre de la fusion des bases, il a été décidé de créer une table « annuaire » susceptible de regrouper les noms de personnes et leurs coordonnées. De plus, il s'est avéré que les champs concernés (expert et reviseur en particulier) pouvait faire mention de plusieurs personnes. De ce fait, il fallait convertir ces champs en type int4[] (type tableau). Cette conversion n'ayant pas été possible en une seule fois, Les champs ont d'abord été convertis en int4, puis en int4[], à l'aide des commandes suivantes :

ALTER TABLE nomschema.TABLE \
	ALTER COLUMN reviseur TYPE int4 \
	USING CAST(reviseur AS "int4");
ALTER TABLE nomschema.TABLE \
	ALTER COLUMN reviseur TYPE int4[] \
	USING array[reviseur];

De la même façon, lorsque l'on importe les champs numériques à incrémentation automatique d'Access, cette dernière propriété est perdue car le champ est converti par PostgreSQL en type int4 et non en serial (type entier auquel on ajoute une séquence d'incrémentation automatique). Il faut alors ajouter la séquence à l'aide des commandes suivantes (le BEGIN et le COMMIT ne sont pas obligatoires) :

BEGIN;
CREATE SEQUENCE admin.annu_nom_id_seq START 6; 
ALTER TABLE admin.annuaire ALTER nom_id SET DEFAULT NEXTVAL('admin.annu_nom_id_seq'::text);
COMMIT;

Ici, la numerotation commence à 6 car il y avait déjà 5 noms entrées dans la table annuaire.

Procédés de migration

TO DO...

Renumérotation des termes

Déplacement d'une table

Une des possibilités pour déplacer une table consiste à utiliser la commande suivante :

ALTER TABLE nomschema.tablearrivee AS SELECT * FROM nomschema.tableorigine;

Cette commande insère les données de la table tableorigine dans la table tablearrivee, à l'aide d'un SELECT. On peut, ensuite, supprimer la table tableorigine à l'aide de la commande suivante :

DROP TABLE nomschema.tableorigine;

De la même façon, il est possible de déplacer une table d'un schéma à un autre :

ALTER TABLE schemaarrivee.tabletruc AS SELECT * FROM schemaorigine.tabletruc;

Il s'agit ici aussi d'insérer les données de la table tabletruc à l'aide d'un SELECT.

Enfin, les données peuvent être copiées dans une table nouvelle :

CREATE TABLE schemaarrivee.tabletruc AS SELECT * FROM schemaorigine.tabletruc;

Il suffit de remplacer ALTER par CREATE (sous réserve que la table n'existe pas déjà).

Copies et sauvegardes

Il est possible d'enregistrer une copie d'une table à l'aide de la commande suivante :

COPY nomschema.nomtable TO 'D:\Docs\PostgreSQL\base.txt' WITH OIDS NULL AS '';

Cette commande copie la table nomtable sous la forme d'un fichier texte base.txt, en incluant les OIDS et en remplaçant les valeurs NULL par des chaînes vides.

Difficultés rencontrées

TO DO...

Liens

user/yamina_abdallahi/termino/migration-access-postgresql.txt · Dernière modification: 2009/04/03 21:06 par Yamina Abdallahi