Продолжу рассматривать хранение пользовательской информацией в базе.
В предыдущих статьях описаны мифы по хранению информации из документов и фамилии-имени-отчества.
Для начала давайте договоримся о терминологии.
Основной идентификатор — набор цифр/букв который используется (или должен использоваться) во всех системах для однозначного определения физического лица в масштабах страны. Идентификатор на законодательном уровне должен использоваться во всех государственных базах. Для примера, в Узбекистане в качестве единого идентификатора принят ПИНФЛ, в Азербайджане — ИИН, в Кыргызстане — ПИН, в Казахстане — ИИН. На постсоветском пространстве идентификаторы, как правило, состоят из некоторого набора цифр (ИН в аббревиатурах расшифровывается как Идентификационный Номер).
СНИЛС движется в сторону «основного идентификатора», но пока юридически не подходит под приведённое выше описание.
Вторичный идентификатор — идентификатор, сгенерированной в каком‑либо ведомстве для собственных нужд (идентификатор налогоплательщика, пенсионный идентификатор).
Ещё немного теории: Идентификаторы могут быть сгенерированы на основании пользовательских данных (как правило — пол, дата рождения, место первой персонализации). Основное преимущество такого подхода — возможность «ручной генерации» идентификатора: если отключили свет или интернет, можно в бумажном журнале создать необходимую комбинацию цифр. Также «естественный идентификатор» позволяет меньше допускать «человеческих ошибок» — сотрудник может визуально определить пол и приблизительный возраст посетителя и отказать в случае явного несоответствия.
Идентификатор может быть сгенерирован «синтетически», без привязки к пользовательским данным. В век цифровых технологий он более привлекателен, чем «естественный». Во‑первых, появляется меньше причин для его смены в дальнейшем (см. ниже). Во‑вторых, по понятным причинам, в то же самое количество цифр помещается больше возможных пользователей.
Вопрос с простотой чтения и запоминания «естественных» и «синтетических» идентификаторов остаётся открытым.
На этом вводная часть заканчивается, переходим к основному тексту.
Основной идентификатор есть всегда.
Идентификатор обычно присваивается при первой персонализации гражданина. В идеале, идентификатор должен присваиваться при получении свидетельства о рождении; по факту, в зависимости от законодательства разных стран, персонализация может происходить при получении первого паспорта. При таком подходе несовершеннолетние пользователи отсутствуют в центральной базе. При попытке получить государственные услуги или учесть их в каких‑либо централизованных системах (медицинские, школьные) могут возникать коллизии.
Основной идентификатор не изменяется.
Если исключить человеческий фактор, то возможность изменения идентификатора заложена в законодательство стран. Как минимум, «новая личность» должна возникать при усыновлении/удочерении ребёнка или в ходе работы программ защиты свидетелей (интересно, как в таком случае поступать с записями в медицинских программах).
Если основной идентификатор генерируется на основе биографических данных человека, то при изменении какой‑либо составной части (например даты рождения) может возникать потребность в генерации нового идентификатора.
Соответственно, качественно написанная программа должна грамотно обрабатывать ситуацию «смена основного идентификатора».
Основной идентификатор всегда уникален.
Если всё‑таки не исключать человеческий фактор, то теоретически один идентификатор может повторяться в системах.
Первые попытки создания идентификаторов пользователей на постсоветском пространстве относятся к концу 20 века, когда не то, что единых баз, а компьютеров‑то не всегда хватало. Поэтому, многие идентификаторы предусматривали возможность «генерации» при помощи ручки, бумажки и калькулятора. С последующей записью в журнал и синхронизацией при помощи фельдъегерской почты.
А в такой ситуации достаточно вероятно дублирование или присвоение новому пользователю идентификатора, уже бывшего в употреблении.
Один идентификатор не может быть у двух юзеров.
Частный случай пункта 32. Вероятность коллизии повышается, если разрешено генерировать идентификатор в различных источниках:
Первая персонализация может происходить в разных организациях (ЗАГС и паспортный стол МВД).
филиалы организации, которая проводит персонализацию не связаны единой информационной системой.
В 2023 году такое себе трудно представить, но в центральных базах данных наверняка осталось тяжёлое наследие 20–30 летней давности.
В каждой конкретной организации, у юзера может быть только один вторичный идентификатор.
Приведём гипотетический пример из прекрасных 90-х.
В 16 лет пользователь получил паспорт, устроился на работу и встал на учёт в ФНС с ИНН 123**. Через несколько лет пользователь переехал в другой регион, поменял паспорт (по достижению 25 лет или из‑за смены фамилии) и снова захотел устроиться на работу. О первом опыте работы он забыл, приходит в Налоговую и заново хочет получить ИНН. Сотрудники проверяют его по локальной базе, по глобальной базе и не находят (напоминаю, паспортные данные поменялись). Пользователь не найден, получите новый ИНН 567** и распишитесь.
Через много лет происходит очистка и обогащение базы, система начинает понимать, что это один и тот же пользователь, но на каждом из номеров накопилось много важной информации.
Знакомый знакомого моего знакомого рас��казывал, что один из их знакомых продал квартиру, система определила его ИНН как 123**. Как честный человек он сразу оплатил все требуемые налоги (ага, правильно, с ИНН 567**). И получил штраф за неуплату налогов. Пока разбирался, ещё и пеня набежала.
В данный момент в каждой конкретной организации, у юзера может быть не больше одного вторичного идентификатора.
Пример выше показывает, что у пользователя может быть одновременно два идентификатора в одной системе и удаление одного из них может удалить целый пласт из жизни юзера (например — обнуление трудового стажа или пенсионных начислений).
Другой контрпример: ряд систем государственных органов могут работать с несовершеннолетними, которые не прошли первичную персонализацию (читай, могут отсутствовать в центральных базах). Навскидку, такие ситуации могут возникнуть при получении пенсии (по потере кормильца, по инвалидности), при получении имущества в наследство. После персонализации (читай, присвоения единого идентификатора), такому пользователю может внезапно быть присвоен новый вторичный.
В каждой конкретной организации, связь «основной идентификатор — вторичный идентификатор» это всегда «один к одному».
В идеале нужно проектировать связь «многие ко многим», дополнительно фиксируя временной интервал, когда тот или иной идентификатор был активен.
Если идентификатор состоит из составных частей, части всегда соответ��твуют целому.
Возьмём типичный основной идентификатор пользователя, который состоит из даты рождения, пола и каких‑то порядковых цифр. В соответствии с законодательством большинства стран, дата рождения может быть изменена в судебном порядке. После изменения даты рождения, возможны два варианта:
Изменить основной идентификатор пользователя и открыть ящик Пандоры, перекладывая сопутствующие проблемы по цепочке другим госорганам и информационным системам.
Оставить основной идентификатор неизменным. Вроде бы не страшно, но на выходе получаем «матюки» от особо умных программ, которые валидируют идентификатор и составные части. Вопли «дата рождения не соответствуют идентификатору» — гарантированы.
Для примера — при смене даты рождения, в Казахстане идентификатор остаётся неизменным, в Узбекистане идентификатор генерируется заново. Возможные и возникающие проблемы периодически освещаются в тамошних СМИ: ссылки на dnews.kz и podrobno.uz.
Из вторичного идентификатора всегда можно получить основной.
Госорганы бывают разные, степень цифровизации отличается в разы. Системы бывают разные, с разной реализацией логики и отработкой нестандартных ситуаций. Если не настроено авто‑обновление (актуализация) данных, то после смены основного идентификатора в центральной БД, в ведомственных системах может оставаться старая информация о пользователе, с использованием неактуального основного идентификатора.
И напоследок вопрос
Федя, гражданин Ваканды, был персонализирован и получил основной идентификатор 123***. Федя переехал в Вальверде и отказался от гражданства Ваканды.
Через некоторое время, в связи с «нестабильной политической обстановкой», Федя (гражданин Вальверде) вернулся к семье в Ваканду и получил вид на жительство. Ваааапрос, должен ли к нему вернуться предыдущий основной идентификатор или это уже совершенно другой человек?
Всем мира и добра.
