Нормализация/валидация для международных наборов данных в базе данных?

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

Глядя на систему номеров телефонов,, вы считаете это простым, но это действительно не так. В Северной Америке мы обычно имеем формат 1-222-333-4444 для вызова людей. Разумеется, это отклоняется в ваш международный код, код города, префикс обмена и номер строки. Проблема: реальные номера телефонов ограничены, в США около 220 кодов областей из потенциального 1000, каждый код зоны имеет ограниченное количество обменов, а номера строк ограничены конкретным использованием в этой стране (например, шаблоны с 911 ограничены, используются только около 3/4 из 10 000). Возьмите это в Великобританию, у них есть свой собственный набор правил для номеров строк, например, резервирование большей части блока 0300-0399 для конкретного использования и другие ограничения. Международные коды также ограничены. Нормализация кодов областей, обмены и проверка достоверности данных на номера телефонов просто усложнилась. Я не буду вдаваться в подробности о том, когда мы входим в места, которые не входят в схему NPA но позволяют просто определить, что мы не можем действительно доверяйте шаблону в Северной Америке, отбросьте назад и назовите это днем.

Как мы нормализуем такие вещи? Как мы проверяем данные? Как мы имеем дело с этими, казалось бы, ad-hoc дополнительными кодами или инструкциями для внутреннего набора?

Международные адреса не намного лучше, различия между не только сохраненными данными, но и выходными форматами aren ' t одинаково по всей доске. Как мы имеем дело с международными почтовыми кодами, когда в Канаде формат A1A1A1, а в США есть такая система, как 55555 [-4444]?

У меня возникает соблазн просто писать классы для каждой из этих ситуаций, когда я их встречаю, храня их в базе данных как XML/JSON/подобный, но как же я могу связать поля и легко искать свой контент? Я не хочу создавать таблицу, содержащую тысячи таблиц для каждой страны. Я хочу легко масштабируемое решение, где я могу нормализовать свои адреса и проверить содержание. Это слишком много, чтобы спросить?

Ответ 1

Способ приближения к этой проблеме может быть следующим:

принять три вида адресов/телефонных номеров/почтовых кодов и т.д.

Первое представление относится к адресам (скажем) как к нескольким строкам текста.
Второе представление - это теги адресов (подробнее об этом ниже).
Третье представление - это правила проверки адресов для адресов

Другими компонентами, которые необходимы для этого подхода, являются общая процедура (класс/триггер) для проверки; процедура форматирования для целей печати; и базу правил вместе с механизмом администраторов для обновления правил проверки. Правило "catchall", которое говорит об этом, является допустимым адресом - оно проверено вручную - даже если оно не отвечает ни одному из правил вашей базы правил.

Компоненты: 1 Адрес состоит из нескольких строк, каждый из которых имеет связанный порядковый номер и несколько тегов (обычно один). Можно также связать с адресной строкой, набором правил и версиями правил, с которыми они были проверены, но это уточнение, которое зависит от ваших скоростей обновления/вставки/расчета.

2 Тегами адресов являются такие вещи, как город; город; номер дома; и идентифицировать разные строки адреса. Возможно иметь адресную строку, которая не имеет никаких тегов, но в этом случае возможны только общие поисковые запросы (например, для Нью-Йорка) на полном наборе строк. Поиски "City = New York" ) невозможны.

3 Правила, написанные на определенном домене. Это может быть регулярное выражение; язык, специфичный для вас; ваш нормальный язык разработки (хотя это, вероятно, будет наименее полезным подходом, поскольку языкам программирования может быть сложно понять и точно представить правила, о которых я говорю. Пример типичных правил может быть (касающийся вашего описания US Zip Codes) - первые пять символов должны быть цифрами.

первые пять символов представляют собой "код зоны".

почтовый индекс должен быть последней строкой адреса.

Правила будут разделены на группы и наборы (например, адреса США). Правила должны иметь возможность ссылаться на другие правила, а также на адресные данные.

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

Я надеюсь, что другие компоненты будут очевидны из общего подхода.

Этот подход предназначен для решения этих проблем, определенных в вашем вопросе:

Разделение телефонных кодов.
Ограниченное количество возможных кодов областей.
Блоки телефонных номеров, зарезервированные для определенных целей.
Нормализация данных - данные нормализованы. Однако этот тип нормализации (обратная индексация) обычно не используется, за исключением программного обеспечения хранилища данных и баз данных, содержащих массивные данные датчика в реальном времени. Возможно, что при внедрении этого решения вы можете выбрать дублирующиеся данные (контролируемые). Это не является неотъемлемой частью решения, но может быть удобным.
Я бы настоятельно рекомендовал НЕ добавлять классы для каждого варианта - это не масштабируемо и не поддерживается.
Поиск подробно описан ниже.
Таблицы монстров избегаются: база правил, вероятно, будет или порядок от сотен до нескольких тысяч правил, дополняющих фактические данные.
Решение является масштабируемым - одно просто добавляет или изменяет правила.

а также справиться с некоторыми связанными проблемами.

Даже если вы можете применять правила валидации к национальным форматам адресов, всегда будут исключения из стандартов для конкретной страны. Мой собственный адрес - пример - я живу на лодке и нуждаюсь в дополнительной информации, включенной в мой адрес, помимо стандартного адреса почтового ветки. Аномалии такого рода всегда, вероятно, нуждаются в ручном вмешательстве - отсюда правило, принятое ручным вмешательством.
В разных странах разные адреса для адресов - адреса в Китае, например, написаны: Страна; Почтовый индекс; Город; Городская зона; Название улицы; Номер дома; Имя человека.
Принятие первого адреса из области, где у вас нет правил, а правила страны отличаются от всех, которые вы записали.
Люди, которые хотят использовать (например, офис) адрес, отличный от "своего" адреса.
Конкретные проблемы с индивидуальной адресацией - кто-то, кто хочет скрыть свою переписку от ближайших и самых близких.
Решение может быть распространено на подобные проблемы - например, обращение к человеку. Это может включать заголовки - Dr, Rev и т.д.; умножать переносимые имена (ffoulkes-symthe); (CPA, BSc и т.д.), а также семейные квалификации (третий и т.д.), а также различные способы именования в зависимости от культуры лиц (люди из индийского субконтинента часто не имеют фамилии, и каждая из них, по-видимому, имеет другую фамилию).
Изменения правил адресации (например, добавление нового почтового индекса для новой разработки) могут быть сделаны легко и быстро.

По-прежнему возникают проблемы:

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

EDIT:

Я не знал о BigTable, когда писал свой ответ. Очень быстро взглянув на это, похоже, это очень похожее понятие. Что касается реализации его в разработке ACID, я думаю, что это возможно для набора данных контактов и для базы данных правил. По опыту я знаю, что он легко масштабируется до 5 * 10 ^ 7 наборов контактных данных в такой среде (хотя с фоновой, несрочной критичной проверкой контактных данных).

При рассмотрении случая ACID/SQL мое использование слова "вид", возможно, заставило зайца уходить в том направлении, которое я не собирался. Более подходящим словом может быть обзор или прогноз (что-то без привязки реляционной модели или СУБД). На самом деле я бы рассмотрел каждую из вещей, которые я назвал представлением, в качестве таблицы-кандидата.

Я изложил схему схемы для моего подхода, чтобы помочь обсуждению. В этой схеме используются некоторые соединения M: N, которые, очевидно, будут нормализованы в реализации как ассоциативные таблицы. Это остается как упражнение для читателя:-). Я поместил несколько примерных атрибутов и данных в некоторые из таблиц.

В эскизе редактирование набора правил; Правило; и правила, относящиеся к другим правилам (административное приложение), очевидно, могут выполняться с помощью свойств ACID с помощью операций SQL Normal CRUD на адресном пользователе; Адрес; и адресная строка в равной степени может выполняться по методу ACID/SQL, принимая адресные строки в качестве входных данных пользователя. Возможно, вы захотите сделать некоторую предварительную обработку транзакции, чтобы отделить (в моем примере) номер дома от имени дороги и, соответственно, потерять правило "Дорожное имя". Другая предварительная обработка, которая, вероятно, будет полезна, - это стандартизация капитализации, хотя это также может быть частью шага валидации. Также можно просто принять полную строку "9 Richmond Road" в качестве входных данных и пометить ее как "Требует проверки". В любом случае нет проблемы (что я знаю) о выполнении этой транзакции ACID.

Где я менее ясен, так это то, как валидация и последующая маркировка могут быть включены в транзакцию ACID/SQL. Кажется, что для выполнения шага валидации ACID может потребоваться заказать приложение тестирования против наборов правил (с наиболее распространенными проверенными ранее случаями и прекращением успешной проверки). Также может потребоваться, чтобы сделать ACID транзакции, чтобы проверить только против вашего наиболее распространенного случая, оставив остальных с тегами "Необходимость проверки", которые затем будут выполняться в качестве фоновой задачи.

Фактическая задача проверки включает проверку всей базы правил, заданной множеством, до тех пор, пока не будет найден набор правил, который проверяет все входные строки. Разумеется, существуют потенциальные рекомендации самих данных - если вы зарегистрировали страну, то это позволяет сразу же пометить линию страной и предоставить фильтр для наборов правил, с которыми вы должны протестировать. Я сожалею, но это насколько я могу принять этот аспект.

Кстати, эта схема эскиза идет только частично к полной нормализации. Как показано на рисунке, каждый адрес имеет свою собственную последовательность адресных строк, и нет нормализации данных за пределами отдельных строк в качестве входных данных (плюс или минус любая предварительная обработка, которую вы выбираете). Этот подход можно использовать еще дальше - путем установления связи между Адресной и адресной линией M: N и гарантией того, что поле Line в таблице адресной строки является его первичным ключом.

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

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

Более важная причина заключается в том, что некоторые источники этой идеи являются конфиденциальными или секретными. В моей рабочей карьере часть моей работы заключалась в том, чтобы следить за развитием технологий и прогнозировать влияние технологий на бизнес через десять лет. Это включало посещение исследовательских лабораторий и обсуждение с ведущими исследователями по различным темам. В то время как я, я, исследователь первого класса, я, кажется, очень хорошо разбираю усилия других исследователей. Однако, делая это, я всегда работал в условиях коммерческой конфиденциальности и/или военной тайны. Ни один из моих ответов не нарушил эти условия. В результате этого я могу лишь дать неопределенные указания относительно того, как была получена информация.

Мои источники:

семинар, проведенный C J Date в IBM, исследующий дальнейшие пути нормализации и реляционную модель (НЕ Реляционная модель, реализованная в SQL). Это связано с исследованием пятых (?) И шестой (?) Нормальных форм.
серию обсуждений с техническим персоналом Oracle в течение определенного периода времени, обсуждение метаданных; мета метаданные; и другие подобные обобщения.
обсуждения с британским военным исследовательским учреждением. Хотя это было несколько лет назад, я не уверен, что когда-либо было опубликовано то, о чем мы говорили.
работала в крупном финансовом учреждении, система контактных данных которого была похожа на мое предложение, но возникла из нереляционных корней; и для которого первоначальный технический импульс был экономит место в эпоху, когда память, постоянная память и резервная емкость были главной проблемой.

EDIT:

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

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

Start read transaction
  Read set of address lines where one or more lines are "Needs Validation"
  Read all rule set names
  Read all rule lines which belong to the first rule set
  If read is not successful then abandon and start process again
End read transaction
Do while address not validated and not end of rule sets
  If set of address lines validates against first rule set then 
    prepare transaction by allocating the tags to be applied to each line of the 
    address and temporarily recording the rule set that has validated the address
    Start validation transaction
      Read same set of address lines and rule set (all fields)
      Is the address and the rule set identical to what was obtained in the read
      transaction?
      If identical then
        create appropriate set of Tag Usage records
        if successful then 
          commit validation transaction
          end overall process
        if not successful or 
        if not identical then
          rollback validation Tag and Tag Usage 
            ** This is the point where there might be problems if the rule set has 
            changed since reading it. The ordering may have changed due to amendment 
            deletion or creation of rule sets. This is the reason for the read of all 
            the read set names initially. However if there is such a change one can 
            afford to fail to validate and move on, aiming to come back to this address 
            later.
    End of validation transaction
    Start read transaction
      Read rule lines which belong to the next rule set
    End read transaction
End while loop
If end of rule sets reached and address not validated
  begin create Tag Usage transaction
    create tag usage pointing to Tag "Manual Intervention needed"
  end create Tag Usage transaction

Все три типа транзакций (адрес, адресная строка, набор правил, обновления правил и тег, обновления использования тегов) соответствуют условиям ACID. Я твердо верю (но не доказал), что любое перемежение, комбинация или пересекающийся набор этих трех типов транзакций также будет выполнять условия ACID.

Ответ 2

Возможно, уже ответил для номера телефона, по крайней мере. Вы можете сделать что-то подобное для почтовых кодов.

Ответ 3

Если бы я реализовал это, я бы сохранил номера телефонов, почтовые индексы и т.д. как обычные строки. В частности, данные должны храниться в том формате, который ему нужен конечный пользователь. (Предполагая, что у каждого конечного пользователя одинаковые потребности.) Например. с немецким адресом: "Roadname 123", адрес США? "123 Roadname". Выполняя то же самое для почтовых индексов, объедините их с именем города. Вы можете сохранить адреса как address_line_1 (название улицы, номер дома в определенном конкретном заказе пользователя), address_line_2 (почтовый индекс, название города...).

Если вам по-прежнему нужно искать свою базу данных для определенных почтовых кодов, вы можете написать регулярное выражение или даже функцию для этого. Учитывая названия городов, вы можете стереть их из address_line_2, и с большой вероятностью вы получите почтовый индекс.

Я думаю, что написание валидации для каждой страны должно быть огромной работой, что 200 стран... Как вы можете быть уверены, что не пропустили некоторые локальные соглашения? Вы можете написать функцию eq, которая, например, вычисляет eq ( "ABCDE-34", "ABCDE.34" ) == true.

Хотя я действительно не вижу смысла в написании отзывов на стороне клиента и на стороне сервера. Даже если клиент является веб-браузером, вы можете использовать проверки сервера через AJAX.

В конце концов, это зависит от используемой СУБД (поддержка хранимых процедур Java?), вашего языка на стороне клиента... Также как ввод данных (вводится ли он очень неточно? в веб-браузере?) и что вы хотите с этим делать. (Планируете ли вы отправлять Skype с помощью телефонных номеров из своей базы данных или читаете ли они людей, которые набирают их на своем телефоне?) Нужно ли вам выполнять некоторые конкретные операции соединения? И, конечно, это зависит от того, сколько человеко-часов вы сможете потратить на решение этой проблемы...