|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Gregory Kudinov 2:5020/400 23 Nov 2002 15:20:37
To : Ilya Brikker
Subject : Re: А вы сталкивались с проблемами с качеством данных?
--------------------------------------------------------------------------------
Здравствуйте, Илья
> > Интересно вглубь - какие они проблемы с КД?
> > Что должно быть прописано? Понятно, что смешно говорить о КД в
> > БД отдела кадров ;-)
>
> Почему смешно? Hа основании этих данных деньги ведь считаются
Скажем не смешно, а просто. Это относительно простой случай.
Чем чаще какие-то данные затребованы, тем выше будет их качество.
Это эмпирическое правило также усиливается тем фактом, что деньги
счет любят. Т.е. каждый, кто хочет получать деньги, иметь нормальную
запись в рабочей книжке и иметь нормальные налоговые вычеты - сам
и лично проследит за качеством данных в этой БД.
Предметная область, если так можно выразиться, сама поддерживает
БД в актуальном состоянии. Хотя в этом случае еще желательно выявить
те поля, которые наиболее редко затребованы и производить их
профилактическую выверку. Это уравновесит КД по всей БД.
> > Живой пример:
> > Если маркетинговая БД по клиентам супермаркета - она по определению
> > неполна количественно и недостоверна.
> >
> > Обычно пополняется во время маркетинговых кампаний вида:
> > "мы вам дисконтную карточку именную дадим",
> > или "скидка владельцам кредитных карточек".
> > Или "а не доставить ли вам ТВ на дом?"
> > Hе каждый клиент "засветит" свои личные данные, плюс
> > потоки данных неравномерны и каждый раз дают непредсказуемую
> > выборку из генеральной совокупности.
> >
> > Типичные вопросы на которые надо ответить на основе этой БД:
> > В среднем сколько и какой клиент тратит, что покупает,
> > сколько всего клиентов + спрогнозировать то же самое на будущее.
> > Отчеты должны выдаватьс укрупненные и по всему множеству
> > клиентов с указанием погрешности.
> >
> > Проблемы: поиск дублей (записи по сущностям-дублям объединяются
> > записи по схожим разводятся), разделение домохозяйств
> > (каждый член семьи может отовариться по-отдельности, но покупательная
> > способность одна на всю семью), отсев "случайных" покупателей.
> >
> > Тут явно нужен пользователь по имени "специалист по КД", который
> > будет чистить данные и используя статистические методы дополнять
> > отсутствующую информацию.
>
> Слишком расплывчатое понятие получается - "качество данных" :-)
>
> Приведенный пример - решение типичной задачи, точное название которой
> я не помню, что-то из области социологии. Суть в том, что есть
> специальные метрики и методы, чтобы составить репрезентативную выборку,
> и на основании нее получить интересующую цифру с наперед заданной
> погрешностью. Или наоборот, рассчитать эту погрешность.
> Человек, который владеет этой методикой (профессия его называется
> маркетолог, наверное, или социолог) и должен заниматься такой работой
> - это ж наука целая. Hе админа же грузить подобной байдой.
Прикладная мат. статистика + знание психологии - для грамотной работы
с фокус группой. Это все действительно очень контекстнозависимая
и неформализуемая в общем виде вещь. Согласен.
> Если максимально упростить задачу, остается - напечатать анкеты,
> проанкетировать, ввести анкеты в компьютер, проанализировать данные
> (получить требуемый отчет)
Вот тут начинается КД. После того, как данные поступили на вход
конкретного информационного продукта, который их будет в дальнейшем
обрабатывать. До этого момента будет не качество данных, а качество той
области знания, к которой относится предметная область.
> Что я лично понимаю под качеством данных в этой задаче - это правильно
> ввести в базу данных анкеты. Простейший метод обеспечить хорошее качество
> этих данных - ввести анкеты вручную, два раза, разными людьми, потом
> 'пользователь по имени "специалист по КД"' сравнивает результаты ввода,
> и по тем анкетам, по которым есть расхождение, принимает решение
> "как правильно". Организовать такой механизм и есть чисто ИТ-шная задача
> обеспечения "качества данных", т.е. минимизировать ошибку на том участке,
> где она может возникнуть (ошибки ручного ввода данных или модуля
> распознавания). Другой вопрос, насколько оправданы такие издержки,
> ведь данные вводятся чисто для статистики.
Можно реализовать, например, классификатор на входе, который
будет сразу фильтровать входящие данные согласно заданным
_социологами_ критериям.
> Более дешевый способ - удалять "подозрительные" анкеты (возраст: 111 лет,
> единичка, быть может :-) запала) - фильтры придумывать на основании
> здравого смысла.
Пример больно у вас специфический ;-)
В анкеты всегда составляются с учетом возможности введения
недостоверной информации, так как с точки зрения социологического
анализа важно не только как вам правду говорят, но и как врут. Что бы
вы социологу не сказали - он все интерпретирует ;-)
> Алгоритмы и методики, которые работают дальше (анализ данных)
> - нельзя, имхо, относить к проблеме "качества данных". Это чисто
> прикладная проблема. Ведь задача не состоит в скрупулезном ведении
> базы данных постоянных покупателей.
Hо. Существует такое понятие NULL. И такое понятие как целостность БД.
Они не ориентированы на какую-то конкретную область.
Если пытаться строить КД от сущности конкретной предметной области,
то получится качество в приложении к предметной области.
Если же в центр поставить сущность - хранимое в БД описание сущности
предметной области, то безотносительно к предметной области можно
говорить о соотношении числа объектов предметной области и количества
их описаний в БД - вот и получился показатель КД "полнота".
Если было опрошено 120 человек, а анкет вам принесли 112 - значит
полнота относительно хранимой сущности "анкета" составит 0,9(3).
Если учитывать время, то можно спросить насколько
полна БД с точки зрения всех проводившихся исследований.
(какова временная ретроспектива)?
Достоверность это не всегда семантическая достоверность,
иногда важно знать какова доля незаполненных _оператором_
полей (которые тот просто не смог дешифровать).
Частота внесения коррекций, проводимых для данных вводимых
определенным оператором Васей, естественным образом может
лечь в основу такого показателя как качество источника данных
"Вася".
Если бы все источники данных имели соответствующие
паспорта качества, то это бы не только упростило обеспечение КД,
но и сделало бы более прозрачным ценообразование на БД.
Пора мне остановиться, а то вы читать устанете про разные
показатели качества ;-)
Я защищаю следующий тезис: можно построить некоторый базис
показателей качества данных (или их аспектов) и на его основе
вывести большинство остальных. Соответственно эти показатели
должны быть настолько же безразличны к предметной области,
насколько реляционная модель данных безразлична ;-)
А админ сам реализовывать всю систему показателей не должен.
Он должен либо использовать некий модуль с Мастером настройки.
Либо прочитать как это сделать в специализированном tutorial.
> тут я полностью с Вами согласен
> Система должна быть устойчивой - контроль оно хорошо, но ошибочные
> данные рано или поздно попадут в базу данных, какой бы ни был мощный
> контроль. Значит, обязательно должны быть заранее продуманы и отработаны
> механизмы внесения исправлений.
Мало того, иногда ошибочные данные уже там.
Hе все системы строятся с нуля. А у всякой долгоживущей системы
будет несоответствие между предметной областью и ее отражением
в БД. Предметная область в виду естественного дрейфа интересов фирмы
плывет, открываются новые производства, вводятся новые формы отчетности.
Данные теряют свое качество не только из-за дефектов в них,
они могут просто перестать соответствовать задачам, которые ставятся
перед системой. Появилась потребность учитывать новый параметр,
а его в старых данных физически нет, вот и стали старые данные относительно
новой модели метаданных недостоверными.
В какой то момент оказывается проще переписать систему заново, чем
добавить в нее новую функциональность. Этот момент напрямую
зависит от того как быстро деградирует качество метаданных, т.е.
как быстро растет несоответствие между моделью предметной области,
состояние которой кодировано в БД, и предметной областью в реальности.
Потом, если при внедрении очередной процедуры обеспечения КД совокупные
издержки качества вырастают (а не снижаются за счет большого снижения
издержек несоответствия качества данных, как это бывает поначалу), то
такое качество просто будет экономически неоправданным.
С уважением, Григорий
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
