Transfert de données après rétro-conception d'une base de données

[glen1789]

Bonjour,

Dans le cadre de mon projet actuel, il m'est demandé de recoder une application qui utilise une base de données MySQL.
La base de données en question comporte 120 tables et ce nombre va augmenter légèrement dans la nouvelle version de l'application, toutefois la majeure partie des tables seront identiques.
J'ai déjà effectué le modèle Entité-Relation de l'ancienne base sous MySQL Workbench et je suis en train de créer celui de la nouvelle (qui va sans doute évoluer régulièrement au cours du développement).

Les données de l'ancienne application doivent être transférées de l'ancienne application vers la nouvelle, je me suis donc dis que j'allais écrire un script de transfert de données. Après réflexion je me suis dis qu'en procédant de cette manière à chaque modification de la nouvelle base j'aurai deux choses à maintenir (script de transfert + schéma entité-relation).

Donc je viens vers vous pour solliciter votre expertise :
- existe-t-il des outils permettant d'automatiser ce type de transfert?
- sinon, si quelqu'un ayant déjà effectué ce genre de travail pouvait me conseiller sur les bonnes pratiques pour ne pas perdre son temps, je lui en serait très reconnaissant.

Merci d'avance.

Glen.

[CinePhil]

J'ai eu à faire ce travail pour une application de l'INRA.
L'ancien schéma de données n'était pas normalisé et j'ai donc remodélisé complètement les données.

J'ai d'abord fait le nouveau schéma puis j'ai importé les données de l'ancien schéma dans le nouveau à coup de requêtes SQL, mais aussi un peu de PHP car certains transferts étaient impossibles ou trop complexes à faire en SQL.

Après réflexion je me suis dis qu'en procédant de cette manière à chaque modification de la nouvelle base j'aurai deux choses à maintenir (script de transfert + schéma entité-relation).

Oui effectivement mais je pense que tu n'as pas le choix, sinon celui de construire un modèle complet et normalisé en béton avant toute procédure de transfert.

- existe-t-il des outils permettant d'automatiser ce type de transfert?

Je n'en connais pas et ma petite expérience me dit qu'il serait utopique de vouloir en faire un universel tellement les cas sont variés.

Lors du transfert des données, je me suis aperçu que l'ancien modèle a permis la conservation de données mortes, inexploitables, incohérentes que bien sûr je n'ai pas importées dans la nouvelle BDD.

120 tables, ça commence à faire beaucoup !
Commence par vérifier si le schéma actuel est normalisé et, quitte à le modifier, normalise-le. Tu obtiendras peut-être moins de tables mais de meilleures performances.

Ensuite, pour importer les données dans le nouveau schéma, tu commences par les tables sans clé étrangère puis petit à petit tu arrives vers les tables en ayant le plus grand nombre.

Et à chaque fois, avec des requêtes de test, tu vérifies que les données à importer sont les mêmes que les données anciennes et si ce n'est pas le cas, tu en cherches la cause. C'est là que tu peux trouver des données mortes.

Un petit exemple...

Imaginons que tu aies une tables des personnes avec leur adresse, y compris la ville en texte :
personne (id, nom, prenom, rue, code_postal, ville)

Le nouveau schéma donnera par exemple une table de référence des villes et une clé étrangère dans la table des personnes.
personne_prs (prs_id, prs_id_ville, prs_nom, prs_prenom, prs_rue, prs_code_postal)

Tu peux remplir la table des villes à partir d'une source fiable, par exemple l'INSEE qui te donnera les 36000 et quelques communes de France avec leur orthographe et code officiels, leur appartenance à leur canton, leur département et leur région.

Commence par chercher les villes de la table personne actuelle qui n'existent pas dans la table de référence des communes françaises :

Code :

1
2
3
4
SELECT p.id, p.ville
FROM personne p
LEFT OUTER JOIN commune_cmn c ON c.cmn_nom = p.ville
WHERE c.cmn_nom IS NULL

Tu vas peut-être trouver par exemple St. Etienne ou Ste Livrade au lieu de Saint-Étienne et Sainte-Livrade. Tu pourras alors corriger les données en cherchant la bonne orthographe de la ville dans la table de référence.

Une fois les données corrigées, tu peux vérifier que toutes les lignes de la table personne actuelle sont imortables :

Code :

1
2
3
SELECT COUNT(*) AS N
FROM personne p
INNER JOIN commune_cmn c ON c.cmn_nom = p.ville

Si le nombre N est égal au nombre de lignes de la table actuelle, tu peux importer. Sinon, il faut chercher quelles lignes ne sont pas importables et pourquoi avec une nouvelle jointure externe.

Importation des données :

Code :

1
2
3
4
5
INSERT INTO personne_prs (prs_id, prs_id_ville, prs_nom, prs_prenom, prs_rue, prs_code_postal)
SELECT p.id, c.cmn_id, p.nom, p.prenom, p.rue, p.code_postal
FROM personne p
INNER JOIN commune_cmn c ON c.cmn_nom = p.ville
ORDER BY prs_nom, prs_prenom

Bon courage !

[glen1789]

Merci pour cette réponse constructive!

Oui effectivement mais je pense que tu n'as pas le choix, sinon celui de construire un modèle complet et normalisé en béton avant toute procédure de transfert.

C'est bien mon intention mais malheureusement c'est un peu utopiste à mon niveau de croire que j'arriverai à construire une base de plus de 120 tables de manière parfaite la première fois.

Je n'en connais pas et ma petite expérience me dit qu'il serait utopique de vouloir en faire un universel tellement les cas sont variés.

En fait, je travaille aussi avec un outil de Business Intelligence (Business Objects) qui permet de mapper une base de données de manière visuelle (appelé univers de données) en appliquant des règles de mappage (bien sûr un peu limitées) et je me demandais si ce principe existait dans un outil pour base de données car cela est possible. C'est un peu la tare des informaticiens (ou seulement la mienne) de chercher un outil qui permette de faire tout le travail à leur place...

En tout cas merci beaucoup pour l'explication des bonnes pratiques que vous avez mis en place, je vais pouvoir m'en inspirer pour réaliser ce travail.

[CinePhil]

Envoyé par glen1789

C'est bien mon intention mais malheureusement c'est un peu utopiste à mon niveau de croire que j'arriverai à construire une base de plus de 120 tables de manière parfaite la première fois.

Comme dit dans mon précédent message, 120 tables, ça commence à faire beaucoup. Peut-être que le modèle actuel a créé plus de tables que nécessaire.

Par exemple, si tu as des tables par année ou par catégories mais qui ont exactement la même structure, tu réunis tout dans une seule table.

[glen1789]

Bonjour,

Oui mais malheureusement la base est normalisée (120 tables c'est beaucoup mais dans le domaine médical j'ai l'impression que c'est une quantité courante). La refonte totale vient du fait qu'elle a été crée du temps ou InnoDB n'existait pas dans MySQL et que de nouvelles fonctionnalités de la future application nécessitent des changements dans le cœur du modèle.

Merci pour ton implication.