Discussion :

[Mindiell]

Bonjour à tou(te)s,

Je suis en train de monter une base de données qui peut potentiellement stocker des tas de gens. Se pose donc le problème d'unicité.

Y a-t-il un moyen fiable d'avoir unicité parmi les enregistrements sans utiliser d'id auto incrémenté ? Le but étant de pouvoir "deviner" qu'une même personne est enregistrée plusieurs fois malgré des champs mal rentrés.
Exemple :
- Victor Hugo 26/02/1802 Besançon
- Vitcor Hugo 26/02/1802 Besançon


J'ai regardé :
- nom : non
- prénom + nom : non
- Numéro Sécu : non
- Nom + Numéro Sécu : peut-être, mais il y a un risque que non

Comment faites-vous, vous ? Quelle solution auriez-vous ?

Merci,

[ylarvor]

Le problème du doublon peut être résolu par la mise en place d'une contrainte UNIQUE qui empêche une saisie en double.

Par contre, pour régler le problème des erreurs dans la saisie en double, je n'ai pas de solution miracle.

La seul solution concrète que je vois est un export sur Excel, un tri et une étude manuelle, repérer la clé primaire d'un faux doublon et le supprimer dans la base.

[Mindiell]

Le problème du doublon peut être résolu par la mise en place d'une contrainte UNIQUE qui empêche une saisie en double.

Pas de souci là-dessus, je bosse dans les BDs depuis un petit moment

Par contre, pour régler le problème des erreurs dans la saisie en double, je n'ai pas de solution miracle.

C'est surtout ca qui m'intéresse. Si le Numéro de sécu était unique, on pourrait facilement repérer des doublons (à la condifion que lui-même soit bon bien entendu). C'est pourquoi je cherchais une certaine unicité.
A priori, je vais commencer avec un simple Id. Et je donnerais la possibilité de faire des vérifications en se basant sur différents champs (N°SS, Nom+Prénom, etc...) afin que l'admin puisse trouver et nettoyer les doublons de personnes.

Merci,

[Arnaud F.]

Bonjour,

pourquoi le n° de la sécu ne serait pas unique? Je veux dire, les 8 derniers chiffres sont des clés uniques non? (Le dernier représente le "numéro" du bébé dans le mois)...

Je me trompe peut-être ou bien tu ne disposes pas du n° en entier...


++

[CinePhil]

Comme le dit buchs juste au dessus, le numéro de sécu est unique.
Puisque tu montes une BDD, je suppose qu'elle n'est pas constituée à partir de données existantes ?

Une contrainte UNIQUE sur le numéro de sécu empêchera la saisie en double d'une même personne. Bien sûr, il faut que ce numéro soit enregistré correctement, avec un format préparé (S AA MM DD VVV nnn xx) et contrôlé par l'interface utilisateur ou même dans la BDD (Je crois que SQLPro avait mentionné cette possibilité dans un article mais je ne le retrouve plus).

Si la contrainte d'UNICITE sur un ensemble de colonnes s'avère impossible du fait que les informations à saisir peuvent être incomplètes, il faut que l'interface utilisateur cherche les potentiels doublons et les propose avant de valider l'ajout d'une personne. Par exemple, si on ne connait que le nom, le prénom et la ville, le programme doit interroger la base pour retourner toutes les personnes qui répondent à la saisie afin que l'utilisateur choisisse.
Tout dépend de l'utilisation de la base de données et des contraintes relatives à la saisie des informations personnelles.

[Mindiell]

Désolé, mais le numéro de sécu n'est pas unique. Les chiffres par trois représentent le numéro de commune, et le numéro d'ordre de naissance dans le mois dans cette commune. Le dernier numéro est le complément à 97 et sert de CRC en quelque sorte.

Il se trouve qu'aujourd'hui, les numéros de sécurité sociale sont conservés pour les personnes décédées, et donc on se retrouvera avec des gens qui ont les mêmes numéros après cent ans d'existance (et certains sont en double et encore en vie ).
De plus, les personnes qui n'habitent pas en métropole ont un département sur trois chiffres normalement, ce qui provoque là aussi des doublons puisqu'ils utilisent 97 ou 98 (le numéro est tronqué).

CinePhil> Je pense bien faire une vérification mais sur le n°SS + le nom, mais si le nom est mal tapé, je suis mal (bien que la stricte égalité ne soit pas obligatoire avec un soundex remarque...).

[Chtulus]

Bonsoir,

[\Mode aparté]
Bon pour retirer toute polémique autour du numéro de sécurité social, en effet il n'est pas unique. Certes les chances de rencontrer des doublons je pense est faible mais par exemple, l'année de naissance est sur 2 chiffres. Donc tout les 100 ans, les personnes nés au même endroit, avec un même numéro d'ordre... Je vous laisse deviner. Sans compter les personnes nées hors métropole et le dernier un peu plus compliqué avec les ayant droits. Bref.

Bon certes ayant été proposé en 1940 puis définitivement en 1945 avec 13 chiffres on a encore un peu de temps.

Donc il y a bien risque de doublons.

Fin.
[\Fin du mode aparté]

Bonne soirée.

[Monstros Velu]

Il y a aussi ceux qui n'ont pas de numéro de sécurité sociale :
L'exemple du 1er post parle de Victor Hugo... Je doute aussi que Caligula ou Hillary Clinton aient un numéro de sécurité sociale ^^

[Mindiell]

Oui, par contre là, c'est ok. Mon application peut potentiellement enregistrer n'importe quel humain vivant uniquement et c'est tout (suivant à qui cela se vendrait ou serait distribué hein ).
Donc le problème c'esst pour le moment la France, et puis c'est tout, c'est déjà pas mal

[SQLpro]

Attention aussi dans la partie MOIS, vous pouvez avoir > 12 du fait des dates de naissance inconnues....

Pour trouver les doublons, vous pouvez faire cela par des rapprochements en SQL. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/doublons/

A +

[soazig]

Toujours en aparté sur le contrôle du numéro de sécurité sociale.
Le sexe peut être différent de 1 ou 2, si! si!. J'ai été obligé d'enlever ce contrôle dans une application en revanche il est toujours numérique!
A+
Soazig

[pacmann]

Salut !

je crois qu'il ne te reste plus que la biométrie...

"Pour créer votre profil sur notre site, veuillez préalablement nous faire parvenir un prévèlement de votre ADN..."

[Mindiell]

Bon, pour calmer le jeu des excités ci-dessus :
"Les numéros de sécu commencant par 3, 4, 7 ou 8 sont des numéros provisoires (changement de régime tout ca) qui ne sont pas valides pour la déclaration des données sociales."



Plus d'infos :
- Les corses ont 2A et 2B pour leur département. Il y a donc un traitement spécial pour le calcul de leur clef.
- Les "nés à l'étranger" ont 99 comme département

Maintenant :
- Quid de tout ca si les départements disparaissent ?

[CinePhil]

Maintenant :
- Quid de tout ca si les départements disparaissent ?

Même si l'administration départementale disparaît, rien n'empêche d'en garder le découpage existant et de continuer à coder des données sur ce découpage.

Les grandes entreprises sont découpées souvent en régions qui n'ont souvent rien à voir avec les régions administratives.

Ma dernière entreprise situait l'agence de Perpignan dans la région sud-ouest parce que dépendant de la région pilotée par Toulouse alors que dans une autre entreprise elle serait peut-être dans la région sud-est regroupant les régions administratives 'Languedoc-Roussillon' et 'PACA'.

[UVB_PC]

Le but étant de pouvoir "deviner" qu'une même personne est enregistrée plusieurs fois malgré des champs mal rentrés.
Exemple :
- Victor Hugo 26/02/1802 Besançon
- Vitcor Hugo 26/02/1802 Besançon

Je pense que ton problème n'est pas un problème informatique réglable par l'informatique : est-ce que Karine Martin et Carine Martin sont la même personne ? Elles n'ont pas le même numéro de sécurité social ? c'est peut-être une autre erreur de frappe.
Impossible à dire avec seulement les informations présentent dans la base.

Ce dont je suis sûr c'est qu'en prenant Nom/prénom+date de naissance tu auras des personnes physiques différente répondant aux mêmes critères, il est donc impossible de savoir de façon automatique si c'est un doublon ou pas.
C'est donc bien l'action d'un utilisateur qui pourra corriger ce genre d'erreur (suite à une réclamation d'un client qui reçoit un courrier mal orthographié par exemple)

Si vraiment tu veux aider l'utilisateur à repérer ce genre d'erreurs, tu dois mettre en place un système proche de ce que font les correcteurs orthographiques (il repèrent qu'un mot ressemble à d'autres mots contenu dans leur dictionnaire et propose la liste de bonnes orthographes possibles) en n'oubliant pas d'implémenter la fonctionnalité "ignorer toujours" car si tu as deux personnes qui se ressemblent dans la base, ton outil les détectera systématiquement comme doublons potentiels.

[Mindiell]

UVB_PC> C'est bien ce que je compte faire au final : un module permettant d'identifier les doublons réels et les doublons "à priori".
Après, à l'utilisateur de gérer ces cas là tout seul