DQ: Бизнес-требования к качеству данных. Часть 1
Разбираемся дальше с процессом сбора требований к данным. Концентрируемся на удовлетворении потребностей в качестве данных, т.е. будем смотреть на данные через призму Характеристик качества данных.
Как можно собирать требования к качеству данных? - от хвоста или от головы )). От хвоста, значит от регулятора: это когда ты знаешь каким критериям качества должны удовлетворять твои продукты, чтобы в зачётке тебе "Ок" поставили. В этом случае начинаем раскручивать с конца, примерно так:
- Регулятор хочет, чтобы данные удовлетворяли характеристике качества Согласованность.
Согласованность - Взаимная непротиворечивость данных, хранящихся в информационных системах, других источниках и носителях информации, унификация данных при их перемещении в информационных системах и процессах, целостность соответствующих идентификационных ссылок и связей в структурах баз данных (Положение 716-П).
2. Задаем себе вопрос: как проверить что данные удовлетворяют Согласованности?
- проверить на непротиворечивость и унификацию данных при их перемещении в информационных системах и процессах;
- проверить на целостность соответствующих идентификационных ссылок и связей в структурах баз данных;
- проверить на соответствие связей в структурах баз данных установленным правилам и ограничениям между сущностями (связи «один к одному», «один ко многим» и т.п.) .
3. Получается, что надо разбить одну характеристику качества Согласованность как минимум на три проверки, которую дадут нам в итоге качественную характеристику Согласованность. Назовем их:
- Непротиворечивость - проверка на соответствие по идентификаторам и альтернативным ключам.
- Целостность - проверка на отсутствие битых ссылок.
- Мощность - проверка на соответствие установленным в бизнес-правилах типам связей.
4. А теперь нужно сформулировать под каждую проверку бизнес-требование, которое будет установлено на данные, итак:
- Проверка на соответствие по идентификаторам и альтернативным ключам требует - Выделения бизнес-ключей
- Проверка на отсутствие битых ссылок требует - Показать связи между сущностями
- Проверка на соответствие установленным в бизнес-правилах типам связей требует - Показать типы отношений сущностей друг к другу
5. Что такое эти бизнес-требования? Давайте их теперь опишем:
На пункте 5 мы получили с вами требования к качеству данных, которые вам должен собрать и предоставить на блюдечке с голубой каёмочкой продукт, иначе говоря, он должен принести вам логическую модель данных продукта.
Если над вами не занесён меч регулятора, то требования к качеству данных и продукту вы можете формировать самостоятельно. В этом случае сбор требований будет проходить с головы ))
Процесс выглядит примерно так:
- Мне нужно, чтобы в информационной системе можно было вводить ИНН физического лица - это бизнес-Термин.
- ИНН физического лица - это идентификационный номер налогоплательщика физического лица, который вы (или ваш работодатель за вас) используете для уплаты налогов. Это Описание термина.
- ИНН физического лица должно удовлетворять следующим требованиям: это 12-значный номер (не больше и не меньше) - это требование к разработке и к качеству данных.
- Вопрос: какую характеристику качества данных мы закрываем, контролируя это требование? Точность - соответствие реальным значениям свойств.
Точность и достоверность - Точность данных в части отсутствия синтаксических и семантических ошибок в данных, а также их соответствия реальным и статистически наиболее вероятным значениям свойств, характеристик и параметров, зафиксированных в данных (Положение 716-П).
Для наглядности можно уточнить требование к Точности приведя реальный пример значения, например, ИНН: 987654321098
ИНН, кстати, является натуральным или бизнес-ключом, а значит при проверке качества заполнения этого поля/атрибута мы также получаем плюсик по характеристике Согласованность, метрика Непротиворечивость.
Вне зависимости от того каким путём вы пойдёте - с головы или с хвоста, у вас в итоге получится примерно вот такая вот табличка связей бизнес-требований к продукту и характеристик качества данных:
И далее вы повторяете процесс для каждой характеристики качества, декомпозируя её до бизнес-требований к качеству данных. В итоге вы получите довольно-таки внушительную таблицу бизнес-требований, которую можно отдать в офис PMO (Product Management Office) и сказать, что вам теперь надо, чтобы они всё это для вас (Data Governance Office) собирали на этапе подготовки бизнес-требований к продукту.
И продукты будут повторят этот процесс для каждого атрибута данных, устанавливая для него таким образом требования к качеству. Конечно, делать это в первую очередь нужно для бизнес-критичных атрибутов, а уже потом для всех остальных.
Если торопитесь или не хотите самостоятельно проходить весь путь декомпозиции характеристик, можете воспользоваться готовым решением: результат процесса систематизации требований к качеству данных, а именно список характеристик качества данных с разбивкой по Метрикам и бизнес-требованиям к ним можно скачать на boosty (файл электронных таблиц).
Поддержать канал | Подписаться на скачивание файлов | Читать в телеграм
Увидели незнакомые слова - обратитесь в Толковый словарь Data Governance
Если статья была полезна или просто понравилась, помогите другим быстрее найти её - поставьте лайк.
