|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Ilya Brikker 2:5020/400 14 Nov 2002 13:44:14 To : Gregory Kudinov Subject : Re: А вы сталкивались с проблемами с качеством данных? -------------------------------------------------------------------------------- Привет, Григорий! "Gregory Kudinov" <gr_kudinov@mtu-net.ru> wrote in message news:aquo2m$13ck$1@gavrilo.mtu.ru... > Интересно вглубь - какие они проблемы с КД? > Что должно быть прописано? Понятно, что смешно говорить о КД в > БД отдела кадров ;-) Почему смешно? Hа основании этих данных деньги ведь считаются > Живой пример: > Если маркетинговая БД по клиентам супермаркета - она по определению > неполна количественно и недостоверна. > > Обычно пополняется во время маркетинговых кампаний вида: > "мы вам дисконтную карточку именную дадим", > или "скидка владельцам кредитных карточек". > Или "а не доставить ли вам ТВ на дом?" > Hе каждый клиент "засветит" свои личные данные, плюс > потоки данных неравномерны и каждый раз дают непредсказуемую > выборку из генеральной совокупности. > > Типичные вопросы на которые надо ответить на основе этой БД: > В среднем сколько и какой клиент тратит, что покупает, > сколько всего клиентов + спрогнозировать то же самое на будущее. > Отчеты должны выдаватьс укрупненные и по всему множеству > клиентов с указанием погрешности. > > Проблемы: поиск дублей (записи по сущностям-дублям объединяются > записи по схожим разводятся), разделение домохозяйств > (каждый член семьи может отовариться по-отдельности, но покупательная > способность одна на всю семью), отсев "случайных" покупателей. > > Тут явно нужен пользователь по имени "специалист по КД", который > будет чистить данные и используя статистические методы дополнять > отсутствующую информацию. Слишком расплывчатое понятие получается - "качество данных" :-) Сейчас поясню. Приведенный пример - решение типичной задачи, точное название которой я не помню, что-то из области социологии. Суть в том, что есть специальные метрики и методы, чтобы составить репрезентативную выборку, и на основании нее получить интересующую цифру с наперед заданной погрешностью. Или наоборот, рассчитать эту погрешность. Человек, который владеет этой методикой (профессия его называется маркетолог, наверное, или социолог) и должен заниматься такой работой - это ж наука целая. Hе админа же грузить подобной байдой. Если максимально упростить задачу, остается - напечатать анкеты, проанкетировать, ввести анкеты в компьютер, проанализировать данные (получить требуемый отчет) Что я лично понимаю под качеством данных в этой задаче - это правильно ввести в базу данных анкеты. Простейший метод обеспечить хорошее качество этих данных - ввести анкеты вручную, два раза, разными людьми, потом 'пользователь по имени "специалист по КД"' сравнивает результаты ввода, и по тем анкетам, по которым есть расхождение, принимает решение "как правильно". Организовать такой механизм и есть чисто ИТ-шная задача обеспечения "качества данных", т.е. минимизировать ошибку на том участке, где она может возникнуть (ошибки ручного ввода данных или модуля распознавания). Другой вопрос, насколько оправданы такие издержки, ведь данные вводятся чисто для статистики. Более дешевый способ - удалять "подозрительные" анкеты (возраст: 111 лет, единичка, быть может :-) запала) - фильтры придумывать на основании здравого смысла. Алгоритмы и методики, которые работают дальше (анализ данных) - нельзя, имхо, относить к проблеме "качества данных". Это чисто прикладная проблема. Ведь задача не состоит в скрупулезном ведении базы данных постоянных покупателей. > Hе озабочен внедренец-программист КД. Он озабочен тем, чтобы > его БД нормально работала с _чистыми данными_ согласно > функциональным требованиям. Это его зона ответственности. > Зона ответственности КД - работа с живыми данными. > И жестоко мучить программиста вопросами достоверности данных. > Только заказчик знает и может сформулировать требования к КД. > Если сможет их сформулировать. Т.е. нужен специалист по КД > на этапе проектирования системы (он может быть со стороны > исполнителя) и возможно на этапе использования (штатный). тут я полностью с Вами согласен Система должна быть устойчивой - контроль оно хорошо, но ошибочные данные рано или поздно попадут в базу данных, какой бы ни был мощный контроль. Значит, обязательно должны быть заранее продуманы и отработаны механизмы внесения исправлений. > Думаю, иногда часть вопросов КД не нужно делегировать внедренцам в > принципе. Hапример, в том случае, если дефекты в данных предопределены > самой предметной областью и являются нормой - нужен штатный специалист. > Это как доверить администрирование БД внедренцам. > В MS Access можно, а там где на администрирование завязано > функционирование системы (разделение полномочий и > назначение прав доступа и т.п.) - там должен быть свой человек. > > SV> Хотя пpоблема может (и должна) быть сведена системой к минимуму, > SV> однако полностью гаpантиpовать качество данных можно лишь > SV> администpативными меpами. > Hельзя сделать БД по жителям Москвы актуальной (и соответственно > качественной на 100%) в принципе - даже перепись многие сознательно > избежали ;-) > Даже если Лужков лично прикажет - ему только ответят, что она полна > на столько-то процентов с такой-то погрешностью. > И это будет даже не %95. > Hе говоря про то, что в Москве недавно нашли не один десяток строений > вообще _без адреса_. И несколько с большим количеством _официальных_ > адресов. А БД учета строений все равно должна работать и служить > достойным информационным обеспечением > для управленческих решений!!! ;-) > > С уважением, > Григорий > > P.S. Извините, что не сразу ответил - долго думал ;-) > > Илья --- ifmail v.2.15dev5 * Origin: MTU-Intel ISP (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/9104847ab09e.html, оценка из 5, голосов 10
|