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

[bowhill]

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

Comments

[maksenov]

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

[bowhill]

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

[maksenov]

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

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

[bowhill]

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

[kouzdra]

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

[zimopisec]

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

[kouzdra]

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

[maksenov]

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

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

[ex_juan_gan]

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

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

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

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

Сложно все.

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

[bowhill]

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

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

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

[1master]

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

[kouzdra]

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

[bowhill]

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

[1master]

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

[alamar]

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

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

[bowhill]

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

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

[alamar]

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

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