Нормализовать адрес - PullRequest
       71

Нормализовать адрес

3 голосов
/ 03 апреля 2011

Я пытаюсь нормализовать адрес.

Диаграмма ниже показывает соответствующие таблицы для этого вопроса, я полагаю. Я хочу знать, как ZipCodes должны быть интегрированы в модель. Это было бы для международных адресов, поэтому я знаю, что Zip / PostalCode не везде используется. Я думаю, что City :: ZipCode равен 1 :: 0-n (я читал, что другие говорят, что это не всегда так, но они никогда не предоставляли доказательств). Если они верны, то я думаю, что это были бы отношения многие ко многим. Поскольку у каждого адреса может быть только один ZipCode, в то время как ZipCode может содержать много адресов, я теряюсь при нормализации этой модели.

Поскольку Адрес может содержать или не содержать ZipCode, я должен воздерживаться от использования его в качестве обнуляемого FK в таблице адресов.

РЕДАКТИРОВАТЬ: Просто хочу подчеркнуть, что предоставленные сущности и атрибуты значительно уменьшены по сравнению с фактической БД . Он используется только в качестве справочного материала и позволяет решить, куда включать почтовые индексы в модель.

enter image description here

Ответы [ 6 ]

6 голосов
/ 03 апреля 2011

Для нормализации схемы у вас есть; добавить таблицу Address-ZipCode таблицы с внешними ключами Address ID и Zip Code; и первичный ключ Address Id - такой же, как в таблице Address. Затем включите почтовые индексы, используя левое соединение между адресом и новой таблицей. Новая таблица будет заполнена только тогда, когда адрес имеет почтовый индекс.

Однако я хотел бы предложить, что если вы пытаетесь приспособить международные адреса, ваша схема, вероятно, будет неадекватной - вам понадобится несколько строк адреса и больше уровней категории, чем показано на диаграмме. Пропущенные категории включают страну, субрегион, город и, возможно, другие.

Мой ответ здесь (который очень длинный) показывает, что необходимо для комплексной работы с международными адресами (и другими вещами). Это огромное излишество, если вы не имеете дело с миллионами адресов в каждой из нескольких стран.

2 голосов
/ 26 января 2012

Нормализация или стандартизация адресов - огромная проблема для большинства организаций, которым нужны точные, регулярно отформатированные адреса. (Я работаю в отрасли проверки адресов - для SmartyStreets - поэтому я много с этим справлялся.) Из-за сложности различных конечных точек доставки, изменений адреса, обновлений компонентов адреса и многое другое, лучше всего нанять сертифицированную услугу, чтобы позаботиться об этом за вас.

Предполагая, что вы работаете с адресами в США, есть API или службы обработки списков, которые вы можете довольно легко подключить для получения необходимых данных. Например, если у вас есть проблемы с NULLable ZipCode FK, вы можете также добавить почтовый индекс к каждому адресу (если он не может его найти, то зачем его сохранять, потому что он в любом случае является плохим).

Одним из таких сервисов является LiveAddress , который обрабатывает запросы API, или вы можете обработать существующий список / таблицу адресов с помощью нашей CASS-Certified Scrubbing . В любом случае, я буду рад лично помочь вам создать рабочее решение ...

2 голосов
/ 03 апреля 2011

Я боролся с этим для нескольких разных приложений на протяжении многих лет. Как вы это настроите, зависит от ваших потребностей. Я работаю в сфере доступного жилья, и одна из вещей, которые нам нужно сделать, это связать различные географические компоненты (город, округ, штат и т. Д.) С различными РЕГИОНАМИ, как это определено 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 определяются на уровне округа (один регион HUD включает в себя один или несколько округов (или в некоторых случаях «графства-города»). Каждый регион HUD фактически имеет уникальный идентификатор, определенный в HUD (HUD CBSA_Sub), который я использую как «HUD-region_code». Также важно отметить, что регионы HUD могут включать округа в одном или нескольких штатах. Следовательно, идентификатор региона HUD связан с округом, но только косвенно с состоянием, ЧЕРЕЗ каждый Например, HUD MSA HUD "Портленд / Ванкувер / Бивертон" включает округа (и города) в штатах Орегон и Вашингтон.

В ВАШЕМ случае вам необходимо определить еще один верхний слой, tblCountry. Кроме того, вам может потребоваться немного изменить концепцию «графства» и «штата», чтобы приспособить их к другим странам («провинция» и все, что они используют для подразделений больше, чем город, но меньше, чем штат. В этом случае может работать «регион»). также - я полагаю, что многие европейские страны используют "регионы").

Страна имеет одно или несколько государств (или равнозначных). Штат имеет один или несколько округов (или равнозначных). В округе есть один или несколько городов. И города, как правило, имеют по крайней мере один почтовый индекс.

Такие области, как область HUD, в моем случае, как правило, определяются как агрегации на одном из этих уровней.

Во многих случаях за пределами этой модели, управляемой HUD, которую мне приходилось разрабатывать (часто бывает необходимо выяснить, какой HUD MSA работает по ZIP или округу. Во всех случаях небезопасно Предположим, что области HUD содержатся в определенном состоянии.

Также важно отметить, что USPS периодически меняет почтовые индексы для определенных областей.

1 голос
/ 03 апреля 2011

В зависимости от того, в какой стране вы применяете правила, почтовые индексы могут быть довольно рискованными.Вы можете с уверенностью предположить, что почтовый индекс имеет одно официальное название города, но и США, и Канада допускают альтернативные названия городов для почтового индекса.Я знаю это наверняка, потому что я разрабатываю программное обеспечение для проверки почтовых адресов в Северной Америке.Неофициальные имена часто распознаются почтовыми службами, и вам, как правило, приходится разрешать их использование.

Поэтому, если вы хотите использовать неофициальные имена, вам нужно m: n между городом и почтой.код.Я хотел бы спросить, почему вы хотите таблицу кодов почтовых индексов в любом случае.Для хранилища адресов лучше рассматривать их как независимые атрибуты, а не пытаться их нормализовать.

Если вы каким-то образом думаете, что сможете использовать некоторые данные в своей базе данных для перехода назад от почтового кода к названию города или к переходу от названия города к почтовому индексу, то вы настраиваетесь на разочарование!Существуют признанные программные решения USPS и Canada Post для проверки адресов, и если вы потратите какое-то время на его изучение, вы обнаружите, что проблемная область проверки адресов на намного сложнее, чем вы думаете.,Если точность адреса важна для вашего приложения (и так должно быть в большинстве случаев), тогда купите сторонние инструменты для проверки вашего адреса и сохраните ваши адреса в одной таблице с таким количеством столбцов, которое имеет для вас смысл.

0 голосов
/ 03 апреля 2011

Во всем мире 119 из 190 стран используют почтовые индексы.Известные страны, которые не используют их, включают Ирландию и Панаму. [1]

Помимо поддержки этого факта, это была бы очень раздражающая система, которая настаивала на том, чтобы иметьПочтовый индекс.Также следует разрешить почтовый индекс неизвестен .

В США каждый "город" имеет по крайней мере один почтовый индекс, поэтому связь правильная.Я знаю это по разработке базы данных почтовых индексов в течение года.

0 голосов
/ 03 апреля 2011

почтовые индексы has_many адреса / адрес принадлежит к zip_code.Вам нужно нормализовать?В большинстве приложений лучше всего иметь столбец zip_code в таблице адресов.Сохранение всех почтовых индексов для международных адресов - тяжелая битва.

Также вы дублируете region_id в адресе и городе.Возможно, вам придется объяснить, какой регион находится в вашем приложении, но похоже, что он должен быть только в городе.

...