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