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 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
- P.O. Boîte: 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 peut-être devons 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 un standard d'entreprise où je travaille. Peu importe si notre application en bénéficierait, nous sommes obligés de le faire.
Question StackOverflow semi-liée: Où est 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?
Des 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 N'importe quelle 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, d'une manière géographiquement hiérarchique. 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 les valeurs d'adresse détaillées séparément, il est plus facile de comparer 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équençant 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 Shell effectuent des commandes importantes à 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.
Formatage Les pièces détenues séparément peuvent être combinées de la manière qui convient aux besoins actuels. Si, par exemple, 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 vider 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é l'analyse des adresses dans les listes d'abonnement. Il est utile de diviser les adresses en champs distincts, mais vous ne pouvez jamais, [~ # ~] jamais [~ # ~] concevoir pour chaque aberration pathologique possible des formats d'adresse et des composants du 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 d'autres possibilités. Multipliez maintenant cette excentricité par le nombre de pays et de régions différents avec des coutumes historiques différentes pour les adresses ... (Japon? Angleterre rurale? Corée? Chine?)
À Portland, OR, il existe des axes N-S et E-W 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 est et ouest à partir 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.
De temps en temps, vous rencontrez une adresse Portland comme 0205 SW Nebraska St. Un zéro en tête? WTF? Il va ma colonne integer pour la maison "numéro".
Lors de la mise en place du maillage, l'axe N-S é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 le house_number colonne a varchar. Pendant que vous y êtes, découvrez comment vous allez analyser 1634 E N 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. C'est à dire. si votre analyseur ne parvient pas à gérer une adresse, enregistrez-la non analysée 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 champ le plus important va être le code postal, mais même ce n'est pas une donnée dans 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 à discuter. Probablement quelques images 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, le avantage de l'analyse est qu'il vous donne des dimensions pour le regroupement et le tri. Code postal, par exemple. Cependant, il n'y a pas payoff à partir de l'analyse d'une dimension spécifique jusqu'à ce que vous deviez grouper ou trier sur cette dimension.
Quoi est une adresse, de toute façon? Vous pourriez faire valoir que c'est un identifiant de lieu, mais vous pouvez également faire valoir qu'il s'agit d'instructions de livraison - "En bas de la rue de 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 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.
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é aux lignes 1, 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 l'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!
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.
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 remonter (par programme), vous vous posez des questions de déclinaison.
Ou, dans les langues romanes ou latines, vous avez fréquemment des noms de rues 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 de maintenance 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 voulaient pouvoir optimiser les travaux de maintenance, par ex. s'il y avait deux demandes de service ou plus sur le même bloc, celles-ci pourraient être traitées en même temps.
- Les utilisateurs voulaient pouvoir corréler les problèmes entre différentes unités (appartements) dans le même bâtiment - par exemple si plus d'un appartement a 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.