Comments 2
В нашей стране проживает примерно 60 тысяч Ивановых Иванов Ивановичей. Принимая, что где-то гипотетически в средней базе данных хранится 100 таблиц, в каждой таблице по 10 ключевых полей, а каждый ключ может принимать по 60 тысяч значений, получаем, что суммарное количество уникальных состояний ключей внутри базы данных примерно 60 миллионов. Если даже в одной таблице перепутаются два ключа, то они могут породить до 20 уникальных состояний в одной таблице. Всего в базе уникальных состояний может набежать до нескольких тысяч. Согласитесь, что тратить 10% времени разработки и 5-7% времени исполнения ETL для вылавливания таких мелочей — непозволительная роскошь?
Можно поподробнее, пожалуйста? Возможно, другой пример? Спасибо.
1. В статье постулируется несколько неочевидных фактов. Одним из фактов является то, что имена собственные (как и иная личная информация) являются сложным в обработке информационным потоком из-за наличия большой чувствительности любой системы к ошибкам, так и конечных пользователей — к ошибкам в их именах, фамилиях и др.
2. Пример с Ивановыми — классический пример, как одна фамилия может, будучи орфографически правильной, по разному произноситься. Это даже на ТВ обыгрывают в сериале ИвАновы-ИванОвы. Теперь рассмотрим реальную ситуацию.
3. Пусть у вас есть 15-17 сторонних систем, которые пишут ФИО Ивановых в базу.
Допустим, просто имя и фамилию. Проверки кто-то случайно выключил. Что попадет в таблицу? В таблицу попадет Иванов Иван… Что произойдет, если на такой таблице включить обычные связи? У вас будет 60 000 записей, среди которых, я просто уверен, будут полные дубликаты. Итак, представили ситуацию?
4. Включили уникальность на таблице. Могут исчезнуть нужное имя с фамилией, а если включить внешние ключи, то в них может содержаться ошибка на уровне индекса, адреса, др. данных. Сколько раз так бывает, когда приставы, допустим, приходят к полному тезке?
5. Возникает каскад ошибок, каждая из которых решалась бы в рамках одной таблицы, но хранилище подразумевает интегральное состояние объекта. А у нас — каскад ключей не привязанных к нужным ФИО. Поэтому я привел очень оптимистичную оценку, зачастую ситуация много-много хуже.
2. Пример с Ивановыми — классический пример, как одна фамилия может, будучи орфографически правильной, по разному произноситься. Это даже на ТВ обыгрывают в сериале ИвАновы-ИванОвы. Теперь рассмотрим реальную ситуацию.
3. Пусть у вас есть 15-17 сторонних систем, которые пишут ФИО Ивановых в базу.
Допустим, просто имя и фамилию. Проверки кто-то случайно выключил. Что попадет в таблицу? В таблицу попадет Иванов Иван… Что произойдет, если на такой таблице включить обычные связи? У вас будет 60 000 записей, среди которых, я просто уверен, будут полные дубликаты. Итак, представили ситуацию?
4. Включили уникальность на таблице. Могут исчезнуть нужное имя с фамилией, а если включить внешние ключи, то в них может содержаться ошибка на уровне индекса, адреса, др. данных. Сколько раз так бывает, когда приставы, допустим, приходят к полному тезке?
5. Возникает каскад ошибок, каждая из которых решалась бы в рамках одной таблицы, но хранилище подразумевает интегральное состояние объекта. А у нас — каскад ключей не привязанных к нужным ФИО. Поэтому я привел очень оптимистичную оценку, зачастую ситуация много-много хуже.
Sign up to leave a comment.
Случайные базы данных. Oracle Enterprise Data Quality — щит и меч корпоративного хранилища