アドレスを正規化しようとしています。
下の図は、私が信じるこの質問に関連する表を示しています。ZipCodesをモデルに統合する方法を知りたいです。これは国際住所用であるため、Zip/PostalCodeがどこでも使用されているわけではないことを私は知っています。City ::ZipCodeは1::0-nだと思います（他の人がこれが常に当てはまるとは限らないと言っているのを読んだことがありますが、証拠を提供したことはありません）。それらが正しければ、これは多対多の関係になると思います。各住所には最大で1つの郵便番号しか含めることができませんが、郵便番号には多くの住所を含めることができるため、このモデルを正規化する方法がわかりません。
アドレスには郵便番号が含まれる場合と含まれない場合があるため、アドレステーブルにnull許容FKとして含めることは控える必要があります。
編集：提供されたエンティティと属性が実際のDBから大幅に縮小されている ことを強調したいだけです。これは参照としてのみ使用され、モデルのどこに郵便番号を含めるかについての私の懸念に対処するために使用されます。
使用しているスキーマを正規化するには、外部キーアドレスIDと郵便番号を含むテーブルAddress-ZipCodeテーブルを追加します。主キーのアドレスID-アドレステーブルのアドレスIDと同じです。次に、住所と新しいテーブルの間の左結合を使用して、郵便番号を含めます。新しいテーブルは、住所に郵便番号がある場合にのみ入力されます。
ただし、国際アドレスに対応しようとしている場合は、スキーマが不十分である可能性が高いことをお勧めします。図に示されているよりも多くのアドレス行とより多くのレベルのカテゴリが必要になります。見逃されたカテゴリには、国、サブリージョン、町、および場合によってはその他が含まれます。
ここでの私の答え（非常に長い）は、国際アドレス（およびその他のもの）を包括的に処理するために何が必要かを示しています。複数の国のそれぞれで数百万のアドレスを扱っている場合を除いて、これは大規模なやり過ぎです。
私は何年にもわたっていくつかの異なるアプリでこれに苦労してきました。これをどのように設定するかは、ニーズによって異なります。私は手頃な価格の住宅で働いています。私たちがしなければならないことの1つは、さまざまな地理的要素（市、郡、州など）をHU（米国の住宅と都市開発）によって定義されたさまざまな地域に関連付けることです。
私が最終的に得たものは、これに少し似ています：
tblState:
StateID
StateCode (AL, AK, AR . . . etc)
StateName (Alabama, Alaska, Arkansas, . . . etc)
tblCounty
CountyID
HUDRegionID FK to tblHUDRegion
StateID FK to tbleState
CountyName (Pierce County, WA; Lane County, OR)
NOTE: I recognize I could normalize even further and create a table of count names, many-to-many related to States ON stateID, but there's a limit, man!)
tblCity
CityID
CountyID
CityName
tblZIPCOde
ZIPCodeID
CityID
tblHUDRegion
HUDRegionID
HUDRegionCode
HUDRegionName
私の場合、HUDリージョンは郡レベルで定義されます（1つのHUDリージョンには1つ以上の郡（または場合によっては「County-Towns」）が含まれます）。各HUDリージョンには、実際には任意のHUD（HUD CBSA_Sub）で定義された一意の識別子があります。これを「HUD-region_code」として使用します。また、HUDリージョンには、1つ以上の州の郡を含めることができることに注意してください。したがって、HUDリージョン識別子は郡に関連付けられていますが、各郡を通じて間接的にのみ州に関連付けられています。たとえば、HUD "Portland / Vancouver / Beaverton" HUD MSAには、オレゴン州とワシントン州の両方の郡（および市）が含まれます。
あなたの場合、もう1つのトップレイヤーtblCountryを定義する必要があります。さらに、他の国に対応するために、「郡」と「州」の概念を少し調整する必要がある場合があります（「州」およびそれらが市より大きく、州よりも小さい細分化に使用するものはすべて。この場合、「地域」が機能する可能性があります。同様に-私は多くのヨーロッパの国々が「地域」を使用していると信じています）。
国には1つ以上の州（または同等のもの）があります。州には1つ以上の郡（または同等の郡）があります。郡には1つ以上の都市があります。また、都市には少なくとも1つの郵便番号がある傾向があります。
私の場合、HUDリージョンなどのリージョンは、これらのレベルの1つで集約として定義される傾向があります。
多くの場合、このHUD駆動モデル以外で開発する必要がありました（ZIPまたは郡ごとにどのHUD MSAが機能しているかを確認する必要がある場合がよくあります。すべての場合において、HUDを想定するのは安全ではありません。地域は特定の州に含まれています。
また、USPSが特定の地域の郵便番号を定期的に変更することにも注意してください。
郵便番号の規則に準拠している国によっては、かなり危険にさらされる可能性があります。郵便番号に1つの正式な都市名があると想定するのはかなり安全ですが、米国とカナダの両方で、郵便番号の代替都市名が許可されています。私は北米向けの住所検証ソフトウェアを開発しているので、これを事実として知っています。非公式の名前は郵便当局によって認識されることが多く、通常はそれらの使用を許可する必要があります。
したがって、非公式の名前を使用できるようにする場合は、市区町村と郵便番号の間にm：nが必要です。とにかく、なぜ郵便番号のコードテーブルが必要なのか疑問に思います。アドレスストレージでは、これらを正規化するのではなく、独立した属性として扱う方が適切です。
データベース内の一部のデータを使用して、郵便番号から都市名に逆方向に移動したり、都市名から郵便番号に転送したりできると思われる場合は、失望の準備をしていることになります。USPSとCanadaPostが認めた住所検証を行うためのソフトウェアソリューションがあり、実際に調査することに時間を費やすと、住所検証の問題領域が思ったよりもはるかに複雑であることがわかります。住所の正確性がアプリにとって重要である場合（ほとんどの場合、それが重要であるはずです）、サードパーティのツールを購入して住所の検証を行い、意味のある数の列を持つ単一のテーブルに住所を保存します。
アドレスの正規化または標準化は、正確で定期的にフォーマットされたアドレスを必要とするほとんどのエンティティにとって大きな問題です。（私は住所検証業界で働いています-SmartyStreetsのために-これをたくさん扱ってきました。）さまざまな配信エンドポイントの複雑さ、住所の変更、住所のコンポーネントの更新、および他の多くのことのために、それは最高ですあなたのためにそれを世話するために認定されたサービスを募集します。
米国の住所を使用していると仮定すると、必要なデータを取得するために非常に簡単にフックできるAPIまたはリスト処理サービスがあります。たとえば、NULL可能なZipCode FKで問題が発生した場合は、すべての住所に郵便番号を追加することをお勧めします（住所が見つからない場合は、とにかく悪い住所であるため、そのままにしておく必要があります）。
そのようなサービスの1つは、APIリクエストを処理するSmartyStreetsのアドレス検証APIです。または、バルクアドレス検証ツールを使用して既存のアドレスのリスト/テーブルを処理することもできます。
郵便番号has_manyアドレス/アドレスbelongs_tozip_code。正規化する必要がありますか？ほとんどのアプリでは、アドレステーブルにzip_code列を含めるのが最適です。国際住所のすべての郵便番号を維持することは困難な戦いです。
また、addressとcityでregion_idを複製しています。アプリ内の地域を説明する必要があるかもしれませんが、これは都市にある必要があるだけのようです。
世界中で、190か国のうち119か国が郵便番号を使用しています。それらを使用しない注目すべき国には、アイルランドとパナマが含まれます。[1]
その事実を支持することに加えて、それは郵便番号を持つことを主張した非常に迷惑なシステムになるでしょう。また、不明な郵便番号を許可する必要があります。
米国では、各「都市」に少なくとも1つの郵便番号があるため、関係は正しいです。私はこれを約1年間の郵便番号データベースの開発から知っています。