Quels problèmes sont résolus en divisant les adresses civiles en colonnes individuelles?

Nous avons une équipe qui conçoit les tables et les relations pour les développeurs de logiciels. Dans notre organisation, ils sont assez stricts quant à l'application de la normalisation 3NF - pour être honnête, je suis d'accord avec la taille de notre organisation et la façon dont les besoins ou nos clients changent au fil du temps. Il n'y a qu'un seul domaine pour lequel je ne comprends pas les raisons de leur décision de conception: les adresses.

Bien que cela se concentre principalement sur les adresses aux États-Unis, je pense que cela pourrait s'appliquer à n'importe quel pays qui le fait. Chaque morceau d'une adresse obtient sa propre colonne dans la table des adresses. Par exemple, prenez cette adresse noueuse aux États-Unis:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Il serait divisé dans la base de données comme ceci:

• Numéro de la rue: 485
• Fraction de rue: 1/2
• Rue pré-directionnelle: N (Nord)
• Nom de la rue: Smith
• Type de rue: ST (rue)
• Rue post-directionnelle: SW (sud-ouest)
• Ville: Chicago
• État: IL (Illinois)
• Code postal: 11111
• Code Zip4: 2222
• Pays (supposé être les États-Unis)
• Attention: Jane Doe
• Boîte postale: NULL
• Type de logement: APT (Appartement)
• Numéro du logement: 300B

Et il y aurait quelques autres colonnes liées aux routes rurales et aux routes contractuelles. De plus, notre application spécifique contiendra probablement quelques adresses internationales. Les modélisateurs de données ont déclaré qu'ils ajouteraient des colonnes spécifiques aux adresses internationales, qui seraient les champs normaux de la ligne 1 et de la ligne 2.

Au début, je pensais que c'était bien par dessus bord. La recherche en ligne se réfère à plusieurs reprises à l'utilisation des lignes d'adresse 1, 2, 3 et éventuellement 4, puis à la division de la ville, de la région et du code postal. Nous avons un cas d'utilisation pour notre nouvelle application où cette granularité est bénéfique. Nous devons valider que l'utilisateur ne crée pas d'entreprise en double et vérifier l'adresse est l'une des validations. Nous pouvons le faire fonctionner avec les lignes d'adresse 1 et 2, mais ce serait plus difficile.

Quant à notre application spécifique, nous devons stocker plusieurs types d'adresses pour les entreprises et les personnes (physiques, postales, d'expédition, etc.). Nous pourrions avoir besoin de générer des lettres types imprimables, mais cette exigence n'a pas été discutée jusqu'à présent.

Certaines autres choses que les applications de notre organisation doivent prendre en charge:

• Audit (avec tableaux d'historique complets)
• Impression d'étiquettes de publipostage
• Génération de formulaires imprimés
• Rapports (pour les gouvernements nationaux et régionaux)

Bien que notre application ne fasse pas tout ce que font toutes les autres applications, la division des adresses en plusieurs composants est une norme d'entreprise dans laquelle je travaille. Peu importe si notre application en bénéficierait, nous sommes obligés de le faire.

Question StackOverflow semi-connexe: où se trouve un bon analyseur d'adresses qui a été fermé, mais illustre à quel point l'analyse des adresses peut être difficile.

Afin de mieux comprendre leur décision de conception, et de vendre notre client sur l'idée ...

Quels problèmes sont résolus en divisant l'adresse municipale en colonnes individuelles?

Points bonus pour quiconque a mis en place un système comme celui-ci, car il a rencontré des problèmes.

Les problèmes qui peuvent être résolus par fractionnement incluent

Validation Toute partie du nom peut être comparée à une liste principale. Celles qui ne correspondent pas peuvent être rejetées. Le code postal / code postal est un exemple évident. Ils sont délivrés et maintenus par une autorité indépendante. Les seuls valables sont ceux délivrés par cette autorité.

Tri et sélection J'ai vu des cas où les frais postaux sont réduits si le courrier est remis au service de livraison déjà organisé dans une certaine mesure. Le fait d'avoir les colonnes correspondantes produit une valeur commerciale tangible.

Analyse Il peut être utile de savoir où vont vos commandes, de manière hiérarchique géographiquement. Cela peut conduire à des initiatives de vente, au développement de produits ou au paiement de commissions, etc.

Duplication de code En faisant en sorte que toutes les applications d'une organisation adoptent le même modèle de données (celui du consommateur le plus complexe), une base de code unique peut être adoptée à l'échelle de l'entreprise et maintenue de manière cohérente. Le dédoublement indéfini des cheveux peut être évité, ou du moins délégué aux têtes d'hélices. Les adresses détenues par différentes parties de l'organisation peuvent être mises à jour de manière cohérente. Le service client et la satisfaction peuvent être augmentés. L'effort de développement peut se concentrer sur les parties uniques et de grande valeur d'un système.

Questions juridiques Les lois et les taxes varient selon la juridiction. En capturant séparément les valeurs d'adresse détaillées, il est plus facile de renvoyer les données transactionnelles aux exigences de conformité.

Duplication Il est simple d'usurper des adresses détenues sous forme de texte en déplaçant un élément vers la ligne suivante ou en reséquencant certaines parties. Les adresses entièrement analysées sont plus faciles à comparer. Cela peut être un simple problème de qualité des données, ou peut avoir des implications en termes de conformité ou de crédit si, par exemple, plusieurs sociétés écrans effectuent de grosses commandes à la même adresse de livraison, ou si une carte de crédit est utilisée pour livrer dans de nombreux endroits dispersés en peu de temps.

Le formatage des pièces détenues séparément peut être combiné de la manière qui convient aux besoins actuels. Par exemple, si les étiquettes longues et minces deviennent bon marché, vous pouvez les reformater pour les utiliser.

Bien sûr, aucun de ces éléments ne peut s'appliquer à une application spécifique. Les données de ce type sont beaucoup plus faciles à analyser et à valider à la source, une fois collectées, qu'elles ne le seront jamais en post-analyse. Donc, même si YAGNI, il peut être préférable de mettre l'effort supplémentaire en avant pour un faible coût et une économie future potentielle importante.

Enfin, je ne rejetterais pas le facteur humain. Le modèle de données est produit par des modélisateurs de données. C'est ce qu'ils font. Voilà leur profession. Ils ne vous diront pas de le jeter dans un BLOB, n'est-ce pas?

J'ai passé 7 ans à développer des logiciels pour une société d'édition et l'un des problèmes les plus difficiles que nous ayons jamais abordés a été d'analyser les adresses dans les listes d'abonnement. Il est utile de diviser les adresses en champs distincts, mais vous ne pouvez jamais concevoir JAMAIS pour chaque aberration pathologique possible des formats d'adresse et des composants que le cerveau humain peut concevoir.

Chaque localité peut avoir ses caprices, et c'est juste aux États-Unis. Jetez dans d'autres pays et les choses deviennent ingérables très rapidement pour toute approche qui veut analyser chaque adresse. Juste deux exemples:

En Espagne, le numéro de rue vient toujours après le nom de la rue et une virgule, et de nombreuses adresses contiennent un numéro d'étage ordinal, tel que 1 ° ou 3ª, ainsi que des abréviations pour «gauche» («Izda» signifiant porte de gauche après vous montez les escaliers), "à droite" ("Dcha") ou autres possibilités. Multipliez maintenant cette excentricité par le nombre de pays et de régions avec des coutumes historiques différentes pour les adresses ... (Japon? Angleterre rurale? Corée? Chine?)

À Portland, OR, il existe des axes NS et EW qui divisent la ville en quadrants NW, NE, SW et SE (ainsi qu'un N "quadrant", mais je m'éloigne du sujet). Les rues NS sont numérotées de façon incrémentielle à l'est et à l'ouest de cet axe, et les adresses sur les rues EW sont dictées par le numéro de rue NS étant le "bloc de cent" du nombre (c'est-à-dire qu'une maison sur une rue EW entre les 11e et 12e avenues aurait un numéro comme 1123). Assez standard pour les adresses américaines.

Chaque si souvent vous rencontrez une adresse Portland comme 0205 SW Nebraska St . Un zéro en tête? WTF? Voilà ma integercolonne pour le numéro de maison.

Lors de la mise en place du maillage, l'axe NS était défini par la rivière Willamette. Tout à l'est de la rivière était NE ou SE, et à l'ouest de la rivière NW ou SW. Au fur et à mesure que la ville grandissait vers le sud, ils rencontraient le fait gênant que la rivière serpente à l'est, donc en projetant l'axe sud, vous avez cette zone problématique qui est du côté "ouest" de la rivière mais à l'est de l'axe. La solution consistait à ajouter un zéro de tête, en fait un signe moins , les nombres augmentant vers l'est à partir de la ligne d'axe.

Si j'étais vous, j'abandonnerais tout espoir de concevoir le système ultime. Vous ne pouvez pas couvrir toutes les possibilités, et de nouvelles seront créées au fur et à mesure que l'humanité pénètrera dans des terres auparavant non développées.

Pour les adresses américaines, jetez un œil à ce que l'USPS a déjà fait en matière de normalisation des adresses et n'oubliez pas de faire la house_numbercolonne a varchar. Pendant que vous y êtes comprendre comment vous allez analyser 1634 FR Fort Lane Ave .

Pour le reste du monde, j'essaierais probablement d'abstraire des champs supplémentaires pour couvrir 80 à 90% de ce qui est susceptible de se produire, et de fournir un ensemble de champs non interprétés qui peuvent gérer tout le reste si nécessaire. Autrement dit, si votre analyseur ne parvient pas à gérer une adresse, enregistrez-la sans analyse et signalée comme telle. Si vous parvenez à analyser une adresse, assurez-vous de vous souvenir de l'ordre dans lequel vous avez trouvé les différents champs afin de pouvoir la réassembler en quelque chose de livrable.

J'allais dire que le domaine le plus important sera le code postal, mais même cela n'est pas donné à de nombreux endroits.

Bonne chance. Cela peut être une entreprise amusante et extrêmement frustrante, mais la clé de la raison est de savoir quand arrêter d'essayer et de simplement stocker l'entrée non analysée, ou partiellement analysée avec l'entrée d'origine en tant que sauvegarde.

Comme toutes les questions de conception, il existe un "ça dépend" extrêmement qualifié. Cela dépend de votre histoire de données - comment les données sont collectées, comment elles sont utilisées, comment elles sont mises à jour, etc.

Il semble que * vous pourriez bénéficier davantage de l'utilisation d'un service de validation d'adresse que d'essayer d'en créer un par vous-même. Bien qu'ils soient coûteux, de nombreux services de ce type sont accompagnés de remises postales importantes.

Bien sûr, il y a un compromis ici, pour certaines histoires de données. Vous pouvez conserver les éléments d'adresse analysés et créer une colonne calculée (ensemble de colonnes, probablement) pour l'adresse combinée. Il s'agit d'une réponse de mise en œuvre, avec toutes les mises en garde normales impliquées.

J'ai implémenté la conception d'adresse analysée. Nous en avions absolument besoin pour la qualité des données ET les besoins de traitement des données. Mais c'était une entreprise qui avait des adresses physiques, des adresses postales, des adresses virtuelles, etc.

L'autre problème qui peut se poser est que différents services postaux nécessitent que les mêmes informations soient présentées dans différents formats / commandes / etc. Ainsi, la modélisation des pièces permet de présenter les mêmes informations dans une variété de formats et de dispositions.

Enfin, vous n'avez pas besoin d'avoir des opérations commerciales internationales pour prendre en charge les données internationales. Même les entreprises basées aux États-Unis doivent prendre en charge les adresses internationales. C'est une énorme erreur de données de supposer que vous n'aurez jamais cela. Les clients déménagent, les fournisseurs changent de siège social, les coordonnées des fournisseurs peuvent être internationales même s'ils ont un siège social américain. Même si vos systèmes actuels ont fait cette erreur, vous ne voulez pas poursuivre celle-ci.

Je recommande fortement les écrits et les blogs de Graham Rhind. Il est l'expert dans le domaine des données sur les adresses de toutes sortes et les compromis qui leur sont associés.

_{* Tout ce que j'ai dit ici est une généralisation grossière. Il y a tellement de questions que je devrais aider à trouver une solution de conception que cela pourrait prendre quelques heures de discussion. Probablement quelques photos et quelques profils de données aussi. Et puis beaucoup d'histoires de données vraiment originales sur les adresses.}

Laissant de côté l'énorme défi de l'analyse correcte du charabia imprévisible que les gens fournissent, l' avantage de l'analyse est qu'elle vous donne des dimensions pour le regroupement et le tri. Code postal, par exemple. Cependant, il n'y a aucun avantage à analyser une dimension spécifique jusqu'à ce que vous deviez grouper ou trier sur cette dimension.

Qu'est - ce qu'une adresse, de toute façon? Vous pourriez faire valoir qu'il s'agit d'un identifiant de lieu, mais vous pouvez également faire valoir qu'il s'agit d'instructions de livraison - «En bas de la rue depuis la cimenterie». En Australie, les gens pensent que les codes postaux sont des identifiants de localisation, mais ils ne le sont pas, ce sont des codes de routage - des instructions de livraison. 4702 est le Rockhampton Mail Centre, un nœud de distribution majeur desservant une région s'étendant de la mer à Emerald, une ville minière située à 300 km à l'intérieur des terres.

Si vous souhaitez identifier des emplacements, Bing et Google peuvent géocoder directement à partir de la chaîne non analysée en coordonnées GPS, qui peuvent être stockées dans un petit tableau simple avec la chaîne non analysée. Ils utilisent la seule approche générale ayant une chance d'obtenir de bons résultats constants: l'appariement partiel pondéré avec une base de données colossale de résultats validés.

Si vous voulez des instructions de livraison, vous êtes toujours bien avisé de conserver la chaîne non analysée car elle pourrait contenir n'importe quoi .

Notez que dans les deux cas, j'ai recommandé de conserver la chaîne non analysée. C'est parce que

• c'est utile en soi
• un jour vous découvrirez comment l'analyser
• quelques jours après cela, vous découvrirez comment l'analyser correctement
• cela ne finit jamais

On peut dire qu'une adresse est toujours des instructions de livraison, contenant au moins un identifiant d'emplacement. Une lettre adressée au "123 Main st, Emerald 4702" code trois emplacements: RMC dans la partie nord de Rockhampton, Emerald, et une adresse. Le bureau de poste de Rockhampton l'enverra simplement au CMR. Le CMR l'enverra au bureau de poste d'Emerald, et le bureau de poste d'Emerald sait, espérons-le, où trouver 123 rue Main.

J'ai déjà mis en place un système comme celui-ci, bien qu'aux Pays-Bas. Le fait est que ce type d'informations peut changer de plus de façons que vous ne le pensez. Les rues sont renommées, les villes sont fusionnées, etc. C'est agréable de pouvoir mettre à jour ce type d'informations sans analyser les adresses comme une seule chaîne.

Séparer le code postal / code postal, le nom du bâtiment et le nom de la route peut être logique. Mais quand vous commencez à ajouter «ville», «zone», etc., cela devient discutable, comparé à seulement la ligne 1, la ligne 2, etc. Le problème est que même moi et ma femme ne pouvons pas nous entendre sur le nom de la ville dans laquelle nous vivons! Le nom du «village» doit-il être mis dans le champ de la ville, ou va-t-il dans la ligne en dessous du nom de la route, la ville locale étant mise dans les champs de la ville? (Certaines personnes sont offensées si vous appelez où elles habitent un village au lieu d'une ville, d'autres personnes vivant au même endroit sont offensées si vous appelez une ville au lieu d'un village!)

Par conséquent, essayer de faire quelque chose de fantaisiste n'est pas mieux que le système de vérification d'adresse que vous utilisez. Mais c'est encore pire. Au Royaume-Uni, TOUTES les adresses doivent avoir un code postal, mais pourtant, le code postal n'est attribué qu'après la construction d'une maison …… Donc, un système doit permettre de briser toutes les règles concernant l'adresse!

En plus des problèmes déjà mentionnés dans d'autres réponses, dans certaines langues - germaniques en particulier - les noms de rue ont tendance à être composés. Par exemple, il est courant dans de nombreuses villes allemandes d'avoir une "Bahnhofstrasse", la rue qui mène à la gare ("Bahnhof" signifiant gare / gare, "Strasse" signifiant rue). Certes, vous pouvez séparer ces deux composants, mais maintenant, si vous voulez les remettre ensemble (par programme), vous vous posez des questions de déclinaison.

Ou, dans les langues "romance" ou latinate, vous avez fréquemment des noms de rue de la forme "Rue de la Pais" ou "Boulevard des Champs-Élysées". Vous avez maintenant une préposition ("de") et un article défini ("le" ou "la") dans le mix - et ils peuvent être combinés. Représentent-ils une partie du type ou du nom de la rue? (Vous devez probablement les stocker quelque part, sinon vous vous retrouvez à nouveau dans la déclinaison.)

J'ai déjà modelé quelque chose comme ça. Mais c'était une très petite application, pour le bureau d'entretien des propriétés résidentielles d'une université de taille moyenne (aux États-Unis). J'ai rendu les adresses très précises pour les raisons suivantes:

• Il y avait des rues dans le quartier avec le même nom mais un "type" de rue différent (par exemple "Woods Avenue" vs "Woods Court").
• Les utilisateurs souhaitaient pouvoir optimiser les travaux de maintenance, par exemple, s'il y avait deux demandes de service ou plus sur le même bloc, celles-ci pouvaient être traitées en même temps.
• Les utilisateurs souhaitaient pouvoir corréler les problèmes entre différentes unités (appartements) dans le même bâtiment - par exemple, si plusieurs appartements ont signalé des températures froides ou une eau insuffisamment chaude.

... et d'autres raisons dont je ne me souviens plus. (C'était à la fin des années 1980.)

Et encore une fois, cela n'avait de sens que parce qu'il y avait un nombre raisonnablement petit d'adresses (et de règles de formatage d'adresse) à traiter. Je ne pense pas que cette approche pourrait évoluer, même si elle était limitée aux adresses américaines, pour des raisons déjà données dans d'autres réponses.