住所を個々の列に分割することでどのような問題が解決しますか？
ソフトウェア開発者向けのテーブルと関係を設計するチームがあります。私たちの組織では、彼らは3NF正規化の実施についてかなり厳格です-正直なところ、私たちの組織の規模と、時間の経過に伴うニーズまたはクライアントの変化を考えると、私は同意します。彼らの設計決定の背後にある理由について私が明確にしていない唯一の領域があります：アドレスです。
これは主に米国の住所に焦点を当てていますが、これを行うすべての国に適用できると思います。住所の各部分は、住所テーブルで独自の列を取得します。たとえば、次の危険な米国の住所を見てみましょう。
Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
次のようにデータベースに分割されます。
- 番地：485
- ストリートフラクション：1/2
- ストリート方向指示器：N（北）
- ストリート名：Smith
- ストリートタイプ：ST（ストリート）
- ストリートポスト方向指示器：SW（南西）
- 都市：シカゴ
- 州：IL（イリノイ州）
- 郵便番号：11111
- 郵便番号：2222
- 国（米国を想定）
- 注意：Jane Doe
- P.O.ボックス：NULL
- 住居タイプ：APT（アパート）
- 住居番号：300B
そして、地方のルートと契約ルートに関連する他のいくつかの列があります。さらに、特定のアプリケーションには、いくつかの国際アドレスが含まれている可能性があります。データモデル作成者は、通常の1行目、2行目フィールドである国際住所に固有の列を追加すると述べました。
最初はこれは船外にあると思いました。オンラインで繰り返し調査することは、住所行1、2、3、および場合によっては4を使用して、都市、地域、郵便番号を分割することを指します。この細分性が有益である新しいアプリケーションには1つの使用例があります。ユーザーが重複するビジネスを作成していないことを検証する必要があり、住所のチェックも検証の1つです。住所行1と2で動作するようにできますが、より困難になります。
私たちの特定のアプリケーションに関しては、ビジネスと人のために複数の種類の住所を保存する必要があります（物理、郵送、発送など）。 mightは印刷可能な定型書簡を生成する必要がありますが、その要件についてはこれまで説明していません。
組織内の他のアプリケーションがサポートする必要があるもの：
- 監査（完全な履歴テーブルを使用）
- 宛名ラベルの印刷
- 印刷されたフォームの生成
- 報告（国および地方政府向け）
私たちのアプリケーションは他のすべてのアプリケーションが行っていることをすべて実行しているわけではないかもしれませんが、アドレスを複数のコンポーネントに分割することは私が作業するエンタープライズ標準です。私たちのアプリケーションがそれから利益を得るかどうかに関係なく、私たちはこれを行わなければなりません。
半関連のStackOverflow質問： Where is a good Address Parser これはクローズされましたが、アドレスの解析がいかに難しいかを示しています。
私が彼らのデザイン決定をよりよく理解し、そのアイデアでクライアントを販売するために...
住所を個々の列に分割することでどのような問題が解決されますか？
問題が発生したため、このようなシステムを実装したすべての人にボーナスポイント。
分割によって解決できる問題には、
検証名前の一部をマスターリストと比較できます。一致しないものは拒否できます。郵便番号/郵便番号は明白な例です。これらは、独立した機関によって発行および管理されます。唯一の有効なものは、その当局によって発行されたものです。
振り分け・選別ある程度整理済みの宅配便にメールを渡すと郵便料金が安くなる場合があります。対応する列があると、具体的なビジネス価値が生まれます。
分析注文がどこに行くのかを地理的に階層的に把握しておくと便利です。これにより、販売活動、製品開発、手数料の支払いなどが促進される可能性があります。
コードの複製組織内のすべてのアプリケーションに同じデータモデル（最も複雑なコンシューマのデータモデル）を採用させることで、単一のコードベースを全社規模で採用し、一貫して維持できます。際限なく複製された髪の毛の分割は避けられるか、少なくともプロペラヘッドに委任されます。組織のさまざまな部分が保持するアドレスは、一貫して更新できます。カスタマーサービスと満足度を高めることができます。開発努力は、システムのユニークで価値の高い部分に集中できます。
法的問題法律と税は管轄によって異なります。詳細な住所値を個別に取得することで、トランザクションデータをコンプライアンス要件と相互参照することが容易になります。
複製 1つの要素を次の行に移動するか、一部を並べ替えることで、テキストとして保持されているアドレスを偽装するのは簡単です。完全に解析されたアドレスは比較が容易です。これは単純なデータ品質の問題である可能性があります。たとえば、複数のシェル会社が同じ配送先住所に大量の注文をした場合や、クレジットカードを使用して短期間に多数の分散した場所に配送する場合は、コンプライアンスや信用に影響を与える可能性があります。
フォーマット個別に保持されているパーツは、現在のニーズに適した方法で組み合わせることができます。たとえば、長く薄い印刷ラベルが安価になった場合は、再フォーマットして使用できます。
もちろん、これらのどれも特定のアプリケーションに適用できない場合があります。このタイプのデータは、収集後、ソースで解析および検証することが、ポスト分析よりもはるかに簡単になります。したがって、たとえYAGNIであっても、少しのコストと将来の大幅な節約のために、追加の労力を前に置く方がよい場合があります。
最後に、私は人的要因を否定しません。データモデルはデータモデラーによって作成されます。それは彼らがすることです。それが彼らの職業です。 BLOBにダンプするように指示するつもりはありませんか？
私は出版社向けのソフトウェアの開発に7年間費やしましたが、これまで取り組んだ最も困難な問題の1つは、サブスクリプションリストの住所を解析することでした。アドレスを個別のフィールドに分割することは便利ですが、[〜＃〜] ever [〜＃〜]アドレス形式とコンポーネントの可能なすべての病理学的異常のために設計することはできません人間の脳は工夫することができます。
すべての地域には奇妙なことがあり、それは米国だけです。他の国に投げると、すべてのアドレスを解析する必要のあるアプローチでは、事態が非常に速く管理できなくなります。ほんの2つの例：
スペインでは、通り番号は常に通りの名前とコンマの後に続きます。多くの住所には、1°や3ªなどの序数のフロア番号と、「左」の略語（「Izda」は、後に左側のドアを意味します）が含まれています。階段を上がる）、「右」（「Dcha」）、またはその他の可能性。次に、その奇妙さを、住所の歴史的な習慣が異なるさまざまな国や地域の数で乗算します...（日本？イギリスの地方？韓国？中国？）
オレゴン州ポートランドには、都市をNW、NE、SW、およびSE象限に分割するN-SおよびE-W軸があります（N象限も同様ですが、余談です）。 NSストリートには、この軸から東と西に増分番号が付けられ、EWストリートの住所は、NSストリート番号が番号の「百ブロック」であることによって決まります（つまり、11〜12番通りのEWストリートの家には番号が付けられます） 1123のように）。米国の住所のかなり標準的なもの。
0205 SW Nebraska Stのようなポートランドアドレスに遭遇することがよくあります。先行ゼロ？ WTF？家「番号」のinteger列が表示されます。
グリッドが設定されたとき、N-S軸はウィラメット川によって定義されました。川の東側はすべてNEまたはSE、川の西側はNWまたはSWでした。都市が南に成長するにつれて、川が東に蛇行するという不都合な事実に遭遇したため、軸を南に投影すると、この問題のある領域は川の「西」側にありますが、軸の東側にあります。解決策は、先行ゼロを追加することであり、実際にはマイナス記号で、数値は軸線から東に向かって増加します。
もし私があなただったら、私は究極のシステムを設計する希望をあきらめるでしょう。あなたはすべての可能性をカバーすることはできません、そして人類が以前に未開発の土地に押し込むにつれて新しいものが作成されます。
米国の住所の場合は、USPSが住所の標準化ですでに行ったことを確認し、house_number列a varchar。その間、1634 E N Fort Lane Aveを解析する方法を理解します。
残りの世界については、おそらく追加のフィールドを抽象化して、起こりそうなものの80〜90％をカバーし、必要に応じて他のすべてを処理できる解釈されないフィールドのセットを提供しようと思います。つまりパーサーがアドレスを処理できない場合は、解析せずにフラグを付けて保存します。住所の解析に成功した場合は、さまざまなフィールドを見つけた順序を覚えておいて、成果物に再構成できるようにしてください。
最も重要なフィールドはポストコードになると言っていましたが、多くの場所で それが与えられていなくても です。
幸運を。これは楽しくて非常に苛立たしい試みとなる可能性がありますが、健全性の鍵は、試行を中止して、入力を解析せずに保存するか、元の入力を部分的に解析してバックアップとして保存するタイミングを知ることです。
すべての設計の質問と同様に、非常に適格な「それは依存します」があります。それはあなたのデータストーリーに依存します-データの収集方法、使用方法、更新方法など。私のすべてのコメントは、ハウツーの回答ではなく、ディスカッションポイントとして解釈する必要があります。
自分でアドレス検証サービスを構築するよりも、アドレス検証サービスを利用する方がメリットがあると思われます*。それらは高価ですが、そのようなサービスの多くは大幅な郵送割引が付いています。
もちろん、特定のデータストーリーについては、妥協点があります。解析されたアドレス部分を永続化し、結合されたアドレスの計算された列（おそらく列のセット）を作成できます。これは実装の回答であり、通常のすべての警告が暗示されています。
解析済みのアドレス設計を実装しました。これは、データ品質とデータ処理のニーズのために絶対に必要でした。しかし、それは物理的な住所、郵便の住所、仮想の住所などがあったビジネスでした。
発生する可能性があるもう1つの問題は、異なる郵便サービスでは、同じ情報を異なる形式/順序などで提示する必要があることです。そのため、パーツをモデル化することで、さまざまな形式とレイアウトで同じ情報を提示できます。
最後に、国際的なデータをサポートするために国際的な事業活動を行う必要はありません。米国を拠点とする企業でさえ、国際住所をサポートする必要があります。あなたがそれを持つことは決してないだろうと仮定することは、大きなデータの間違いです。顧客は移動し、ベンダーはHQを変更します。ベンダーの連絡先情報は、米国のHQがある場合でも国際的なものにすることができます。あなたの現在のシステムがその間違いをしたとしても、あなたはこれを先に進めたくないでしょう。
Graham Rhindによる執筆とブログを強くお勧めします。彼はあらゆる種類の住所とそれらに関連するトレードオフについてのデータ分野の専門家です。
*ここで私が述べたことは全体的な一般化です。設計ソリューションを実現するために私が手助けしなければならない質問がたくさんあるので、チャットには数時間かかる場合があります。おそらくいくつかの写真といくつかのデータプロファイリングも。そして、住所に関する非常に風変わりなデータストーリーがたくさんあります。
人々が提供する予測不能な意味不明なものを正しく解析するという大きな課題を完全に無視して、解析のbenefitは、グループ化と並べ替えのディメンションを提供します。たとえば郵便番号。ただし、特定のディメンションの解析から、そのディメンションでのグループ化または並べ替えが必要になるまで、payoffはありません。
とにかくisアドレスとは？あなたはそれが場所の識別子であるという良い例を作ることができますが、配達指示である「セメント工場から通りを下る」という同じくらい良い例を作ることができます。オーストラリアでは、郵便番号はロケーション識別子であると人々は考えていますが、そうではなく、ルーティングコード-配達指示です。 4702はロックハンプトンメールセンターで、海から300 kmの内陸にある鉱山の町であるエメラルドまで広がる地域にサービスを提供する主要な流通ノードです。
場所を特定する場合、BingとGoogleは、解析されていない文字列からGPS座標に直接ジオコーディングできます。GPS座標は、解析されていない文字列とともに小さなシンプルなテーブルに格納できます。彼らは一貫して良い結果の可能性がある唯一の一般的なアプローチを使用します：検証された結果の巨大なデータベースとのランク付けされた加重部分マッチング。
anythingを含む可能性があるため、配信指示が必要な場合でも、解析されていない文字列を保持することをお勧めします。
どちらの場合も、解析されていない文字列を保持することをお勧めします。それは
- それ自体で便利です
- いつかあなたはそれを解析する方法を理解するでしょう
- その数日後、あなたはそれを解析する方法を理解します正しく
- これは終わらない
おそらくアドレスは常に配信指示であり、少なくとも 1つのロケーションIDを含みます。 「123 Main st、Emerald 4702」宛ての手紙は、3つの場所をエンコードしています。ロックハンプトン、エメラルドの北部にあるRMC、および番地。ロックハンプトン郵便局は、それをRMCに送るだけです。 RMCはそれをエメラルド郵便局に送ります、そしてエメラルド郵便局はうまくいけば123メインストリートを見つける場所を知っています。
郵便番号/郵便番号、建物名、道路名を区別することは意味があります。しかし、「町」、「エリア」などを追加し始めると、line1、line2などだけに比べて疑問が生じます。問題は、私と妻でさえ、私たちが住んでいる町の名前に同意できないことです！ 「村」の名前は町のフィールドに入れますか、それとも道路の名前の下の行に、地方の都市を町のフィールドに入れますか？ （町ではなく村に住んでいると電話をかけると怒る人もいれば、同じ場所に住んでいる人が村ではなく町に電話をかけると怒る人もいます！）
したがって、空想的なことを何でもしようとすることは、使用するアドレス検証システムに勝るものではありません。しかし、それはさらに悪化します。英国では、すべての住所に郵便番号を設定する必要がありますが、郵便番号は家が建てられるまで割り当てられません……したがって、住所に関するすべての規則を破ることをシステムが許可する必要があります。
以前はオランダでしたが、このようなシステムを以前に実装しました。実は、この種の情報は、あなたが思っているよりも多くの点で変化する可能性があります。通りの名前が変更され、都市がマージされます。アドレスを単一の文字列として解析することなく、この種の情報を更新できるのは素晴らしいことです。
他の回答で既に言及されている問題に加えて、一部の言語、特にゲルマン語では、通りの名前が複雑になる傾向があります。たとえば、多くのドイツの町や都市では、鉄道駅に通じる通り "Bahnhofstrasse"（ "Bahnhof"は鉄道/鉄道駅を意味し、 "Strasse"は通りを意味します）を持っています。確かにこれらの2つのコンポーネントを分離することはできますが、それらを（プログラムで）元に戻したい場合は、傾斜の問題に直面しています。
または、「ロマンス」またはラテン語の言語では、「Rue de la Pais」または「Boulevard desChamps-Élysées」という形式のストリート名がよくあります。これで、前置詞（ "de"）と明確な冠詞（ "le"または "la"）が混在し、それらを組み合わせることができます。それらは、ストリートタイプまたはストリート名の一部を表していますか？ （おそらくそれらをどこかに保存する必要があります。そうしないと、再び衰弱してしまいます。）
私はかつてこのようなものをモデル化しました。しかし、それは非常に小さなアプリケーションであり、中規模の大学（米国）の住宅物件の保守管理オフィスにとっては。次の理由から、アドレスを非常に細かくしました。
- 同じ名前で通りの「タイプ」が異なる通りがエリアにありました（例：「ウッズアベニュー」と「ウッズコート」）。
- ユーザーは、メンテナンス作業を最適化できることを望んでいました。同じブロックに2つ以上のサービス要求があった場合、それらは同時に処理できます。
- ユーザーは、同じ建物内の異なるユニット（アパートメント）間で問題を相互に関連付けられるようにしたいと考えていました。複数のアパートが冷たい温度または不十分な温水を報告した場合。
...そして、もう覚えていないその他の理由。 （これは1980年代後半のものでした。）
繰り返しになりますが、これは、処理するアドレス（およびアドレスのフォーマット規則）がかなり少ないため、理にかなっています。米国の住所に限定されているとしても、他の回答ですでに述べられている理由により、このアプローチが拡大することはないと思います。