Discussion :

[Jean-Marc68]

Salut,

J'ai récupéré une base de données dont la cohérence n'était pas assurée (absence de liens entre les tables, absence de clés d'unicité, ...).
Et j'ai un problème avec les clients (pas qu'eux, mais actuellement c'est le problème que je tente de résoudre).
La table client contient entre autre un id, un prénom et un nom. Wow, cool. Tout devrait bien aller. Eh bien non. Comme il n'y a pas de clé d'unicité, il y a plein de fois la même personne. Et comme c'est lié au dossier via une table intermédiaire pour permettre du many to many, ça me complique l'exercice pour corriger les incohérences.

Donc le picture est :
Une table dossier qui contient une clé primaire no_dossier,
une table personnes qui contient un id_personne,
et une table intermédiaire qui contient no_dossier et id_personne.
Mais vu l'absence de clé d'unicité, je me retrouve parfois à voir la même personne pour plusieurs dossiers (ce qui est correct), mais parfois à avoir autant de fois la même personne qu'elle a de dossiers (et c'est parfois beaucoup).

Je me retrouve donc à avoir

dossier	dossier_personne	personne
1	1/1	1/Albert/Anselme
2	2/1
...
82	82/117	117/Albert/Anselme
118	118/185	185/Albert/Anselme

le résultat recherché étant évidemment quelque chose qui ressemblera à

dossier	dossier_personne	personne
1	1/4	4/Albert/Anselme
2	2/4
...
82	82/4
118	118/4

J'imagine que je ne pourrais pas ramener ma table de client à une table cohérente qui n'a qu'une seule fois chaque personne.
Je devrai sans doute faire une nouvelle table avec un nouvel ID et qui sera alimentée par un select distinct de l'ancienne table de clients.
Ensuite je suppose qu'il va falloir lier les anciens ID de clients avec les nouveaux pour les clients qui avaient plusieurs ID et qui n'en ont maintenant plus qu'un seul (ce qui est plus logique).
Mais c'est ici que ça coince. Comment dois-je créer ce qui sera, je suppose, une table temporaire contenant les nouveaux et les anciens ID de clients. Puis comment faire pour faire l'update de la table dossier_personne pour qu'elle soit correcte avec les nouveaux ID ?

Je cherche mais je ne trouve pas. Aussi je fais appel à vos connaissances pour apprendre et me démêler de ce problème.

Merci.

[tatayo]

Bonjour,
Visiblement tu veux dédoublonner les clients sur le couple non/prénom.
Quid des homonymes ?

Tatayo.

[escartefigue]

bonjour,

Déjà, tous les clients sont ils des personnes physiques ou y a -t-il aussi des personnes morales ?
Selon le cas, les critères de dédoublonnage ne peuvent pas être les mêmes.
ensuite, il faut déterminer les critères qui permettent de détecter les vrais doublons

Pour des personnes physiques, le NNI (numéro national d'identité) est souvent fiable mais pas toujours, ça dépend de la façon dont il est enregistré et contrôlé.
Des noms peuvent être distincts mais concerner la même personne (erreur de saisie sur consonne double, accent et autre fantaisie, comparaison nom de naissance et nom marital...)
Dans les traitements de convergence de S.I. le rapprochement des personnes sur NNI+6premières lettres du nom de naissance + 4 premières lettres du prénom est une méthode souvent très fiable (plus que les noms et prénoms complets à cause justement des erreurs de saisie)

Pour les personnes morales, s'il s'agit d'entreprises françaises, le SIRET est un bon critère, sinon il existe des identifiants équivalents dans les autres pays.

Dans tous les cas, il faudra faire des essais itératifs pour affiner les critères de rapprochement avant de tirer à balles réelles


@Jean-Marc68 : merci de corriger le titre du sujet pour que tout le monde comprenne de quoi il s'agit. Ce n'est pas un problème de "boulons" mais de "doublons"

[Jean-Marc68]

Merci de tes propositions escartefigue (PS. Le titre est corrigé .).
Mais actuellement ma difficulté réside plus dans la "migration".
Je cherche tjrs la meilleure façon pour que les nouveaux id soient répercutés dans la table intermédiaire ?

[escartefigue]

L'affectation des nouveaux identifiants c'est ce qui est le plus simple, il suffit de définir une colonne IDENTITY, le SGBD attribuera les nouvelles valeurs automatiquement pour chaque nouvelle entrée.
Il est très fortement recommandé de conserver une colonne avec l'ancien identifiant, ce qui permettra de s'y retrouver pour effectuer des rapprochements avec d'anciennes sauvegardes, d'anciens documents imprimés ou autres supports contenant cet ancien identifiant

[SQLpro]

Rajoutez une colonne dans la table des clients de même type que l'id et appelez la ID_UNIQUE

Mettez à jour cette colonne avec le MIN(id) groupé sur les autres colonnes

Mettez à jour la table fille pour modifer les anciens id avec le ID_UNIQUE

Rendez la colonne ID PRIMARY KEY

Rajouter la contrainte FK dans la table fille.

Entourez tout ce code d'une transaction explicite et ne validez que si tout a marché

Supprimez la colonne ID_UNIQUE

A +

[Jean-Marc68]

Merci SQLpro
J'ai fais des test et ma méthode de migration (en fait la vôtre adaptée à mes tables et colonnes) est établie et enregistrée.
Maintenant il me reste à trouver un maximum de faux amis comme l'expliquait escartefigue puis à passer la moulinette pour de bon.

[SQLpro]

...
Maintenant il me reste à trouver un maximum de faux amis comme l'expliquait escartefigue puis à passer la moulinette pour de bon.

Vous pouvez vous aider, pour comparer des informations similaires, à l'algo que j'ai mis au point pour se faire (inférence basique) :
https://sqlpro.developpez.com/cours/...ns-motifs/#LVI

A +