Показать сообщение отдельно
Старый 13.07.2015, 10:47   #17  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5813 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Возвращаясь к теме целостности данных, хочется еще раз вспомнить замечательную книгу Тома Демарко, Тимоти Листера и Ко Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд, а именно - паттерн №57 "КачИство данных"
Цитата:
Качество данных часто омерзительно. Печально распространенный подход к этой проблеме – поиск более совершенного программного обеспечения для обработки таких данных.

Качество программного обеспечения баз данных обычно превосходит качество самих обрабатываемых данных, однако с точки зрения конечного пользователя качество системы в целом определяется менее качественной составляющей. Компании повсеместно сталкиваются с базами данных, которые битком набиты неточными, устаревшими или неполными сведениями.
Эта проблема ясна как божий день, но, как любую очевидную вещь, ее бывает сложно разглядеть. Компаниям тяжело сразу примириться с собственными проблемами в области качества данных, хотя в чужом глазу все замечают соринку с легкостью. Поэтому они склонны видеть проблему в совокупности программного обеспечения и данных. А так как программное обеспечение всегда легче исправить, чем данные (ведь данных просто ужас как много!), компании занимаются исправлением программ или поисками заменителей.
Поскольку в этих действиях заведомо нет особого смысла, нам важно обсудить здесь не то, почему не следует заниматься исправлениями и поиском заменителей, а то, почему мы все же делаем это, хотя и не следовало бы. Отчасти причиной является разновидность улучшения новостей (см. паттерн 45): плохая новость о том, что 2,4 процента счетов в этом месяце были завернуты из-за ошибок в адресах, распространяется вверх по иерархии, на каждом уровне встречаясь с вопросом: «Блин, ну и что вы собираетесь с этим делать, причем побыстрее?»
Уточнение «причем побыстрее» немедленно исключает обширные исправления вручную. Расплывчатый ответ на этот вопрос: серьезные мероприятия по «чистке данных» начнутся как можно скорее. Эта прелестная фразочка проходит путь снизу до уровня директоров компании, на разных этажах означая разные вещи. У основания иерархии чистка данных означает, что кто-то сядет на телефон, зависнет в Интернете и перероет архивы переписки, чтобы изучить и исправить каждую некорректную порцию данных. Наверху это означает «работать умнее, чтобы каким-то образом породить правильные данные путем хитроумной обработки плохих данных». Поскольку финансирование поступает сверху, выделяемые бюджеты обычно предусматривают подход «работать умнее», а не оплату маленькой армии клерков, выполняющих реальную работу.
Стоит заметить, что данные могут быть просто попорчены (к примеру, в результате некорректных вычислений), и в этом случае существуют некоторые, по меньшей мере, частично автоматизированны способы откатить повреждения, обратившись к более ранним резервным копиям. Аналогичным образом, если одни и те же данные независимо записаны в нескольких системах, автоматизированная чистка данных может способствовать выбору правильных вариантов. В обоих случаях автоматизация опирается на возможность использовать избыточные данные. И хотя легко придумать пример, когда избыточность спасает (в системе А записан старый адрес, но – ура! – в системе Б записан новый), реальные случаи, когда низкое качество данных можно исправить автоматически, встречаются крайне редко.
Основная причина снижения качества данных со временем – это изменения. Такую порчу активов мы называем «корпоративностью данных», и лечится это только вручную. Думать иначе означает просто откладывать судный день.