Внешние данные и схема БД

[bowhill]

Существует известная дилемма, можно ли использовать данные предметной области для построения структуры отношений ( схемы) БД или это должны быть внутренние данные? Например, хорошо ли использовать номер паспорта¹? Некоторые рассуждения могут показаться не очень понятными: внешние данные не контролируются системой, а значит, не контролируется и схема, её качество. Ну и что? Помимо прочего, написал для себя несколько кратких утверждений

1. Данные создаются вне ограничений и контроля.
2. Любые внешние данные могут содержать неустранимые ошибки, это вопрос вероятности.
3. Что означает, для внешних данных нельзя говорить об уникальности и других ограничениях.
4. Использование внешних данных в отображениях схемы означает создание некорректных отображений схемы.

Теперь предлагается практическая задача. Вы — разработчик банковской системы, операционист вводит данные клиента и здесь выясняется, что такой уникальный идентификационный документ в системе уже существует. Как такая ситуация должна обрабатываться в системе?

---
1. http://www.newsru.com/russia/13aug2015/bashpass.html

Comments

[maksenov.livejournal.com]

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

[bowhill.livejournal.com]

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

[maksenov.livejournal.com]

Я сторонник вынесения информации о качестве данных в метаданные - это позволит не меняя существующие модели иметь в распоряжении исчерпывающую информацию для рекомендаций или принятия решений по восстановлению потерь. Собственно, DAMA в своем фреймворке примерно об этом и пишет в разделах Data Governance и Data Quality.

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

[bowhill.livejournal.com]

Ну, Data Governance это уже совсем другой уровень. Если есть такие процессы и политики, то надо смотреть, какие получаются требования. Схема, метаданные или пользовательские данные -- вопросы реализации. По смыслу это метаданные, но если про них никто не знает и не понимает, то может быть проще и в схеме.

[kouzdra.livejournal.com]

Запросить дополнительные идентификационные данные - в данном случае вероятно вполне достаточно ФИО из того же паспорта.

[zimopisec.livejournal.com]

ФИО в принципе может меняться. ( в России вроде не так, а вот в Израиле при этом ID не меняется. Как и должно быть по логике).
Лучше дату и место рождения- эта инфа легально не поменяется, пока не изобрели машину времени

[kouzdra.livejournal.com]

Можно и ее да - даже луяше наверное

[maksenov.livejournal.com]

Интересно имеет ли пересмотр часовых поясов обратную силу в случае с датами :)

Насколько я знаю, единственный документ, который в России не должен меняться - СНИЛС.

[ufm.livejournal.com]

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

[bowhill.livejournal.com]

Вот именно, любые персональные данные волатильны.

[bowhill.livejournal.com]

Всё меняется.

[bowhill.livejournal.com]

А что это даст, если мы всё равно не можем a) проверить b) изменить документы или записи?

[kouzdra.livejournal.com]

Позволит разрешить коллизию, причем опираясь на тот же самый документ, что немаловажно. Подозреваю что с SSN как-то так и делают - бо если верить ID analytics 6% SSN имеют более одного владельца.

[bowhill.livejournal.com]

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

[kouzdra.livejournal.com]

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

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

[juan-gandhi.livejournal.com]

Ох. У нас эта задача, "слияние юзеров", стояла очень остро. Но у нас потому что аккаунт на страховке однозначно идентифицируется - если один аккаунт, то это один аккаунт.

То же самое с емейлом, кстати. Если человек сообщает свой мейл, и у нас такой есть, что остается делать? Посылать ему сообщение на этот мейл.

А вот с SSN туго. Мы просто, не думая, объединяли информацию. Потому что это в этой стране однозначно идентифицирует человека. У нас, правда, это было связано только с аккаунтом. Ну и, главное, Фиделити идентифицирует человека по ССН. Смешно другое, что показывать ССН нигде нельзя.

И еще случай. Документов нет, а есть имя. Дэйв Смит. И у него сын Дэйв Смит. А даты рождения нету. Или еще был случай - один индус своих пятерых детей назвал одинаково. Ну и?

Сложно все.

Возвращаясь к банку - ну откроем еще аккаунт на этого человека. Банку-то не пофиг ли.

[kouzdra.livejournal.com]

Вообще-то теоретически в РФ номер паспорта тоже однозначно идентифицирует человека - но см. ссылку

PS: Впрочем несложное гугление показывает что:

San Diego firm ID Analytics has looked at 290 million social security numbers. They've found 40 million of them have more than one name attached to them.
...
More than 20 million Americans have more than one SSN associated with their name. (http://www.witn.com/home/headlines/Duplicate__111371029.html)

[vitus_wagner]

http://www.idanalytics.com/blog/press-releases/20-million-americans-multiple-social-security-numbers-associated-name/

[bowhill.livejournal.com]

Банку не совсем пофиг, он под регуляторами, но здесь это скорее метафора интерактивного взаимодействия с клиентом в сложных условиях стрельбы в ногу. Скорее иллюстрация более общей проблемы, а не отдельный рецепт. С мейлами, к слову, тоже хороший пример или с телефонами. C SSN как и паспортом, не всё так просто, он может и уникальный, а вот запись о нём – не обязательно, и способы ввода разные. Да и другие варианты возможны.

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

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

[1master.livejournal.com]

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

[kouzdra.livejournal.com]

В российских реквизитах банковского перевода строго говоря тоже два - остальное вообще говоря не обязательно.

[bowhill.livejournal.com]

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

[1master.livejournal.com]

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

[bowhill.livejournal.com]

Продуманные сервисы лучше непродуманных, не думаю, что тут поспорим. Платёжная система в РФ изначально не для участников.

[alamar.livejournal.com]

Создать тикет в службу безопасности банка - провентилировать этот вопрос.

В остальном всё как обычно. Скорее всего это просто опечатка при вводе существующей записи.

[bowhill.livejournal.com]

А что СБ, у неё есть высшие знания или она должна за нас проблемы решать?

Но другой интересный вопрос: чем тем временем будет заниматься клиент банка? Предположу, что написанием поста в соцсетях, о том, что в этом банке не только не сделали необходимые ему операции, например не открыли счёт, но откуда-то знали его персональные данные и уже их с кем-то перепутали. И, наверное, такой пост станет популярным. И это правильно.

[alamar.livejournal.com]

"В остальном всё как обычно."
Учимся читать комментарии.

СБ должна обратиться в органы, чтобы понять, что пошло не так. В фоновом режиме.