Работа с качеством 2.0

Качество данных, поставляемых Поставщиком данных Потребителям данных по СМЭВ обеспечивается Поставщиком данных. В первую очередь качество должно обеспечиваться и контролироваться в информационных системах (ИС) Поставщика данных.

Обеспечение качества данных в ИС органически связано с остальными процессами управления данными, такими как управление архитектурой данных, моделью данных и метаданными, интеграцией данных и т.д*.

Механизмы проверки качества данных, реализованные в ЕИП НСУД, обеспечивают независимый прозрачный контроль данных, размещенных в Витринах данных Поставщиков. Они позволяют Поставщикам понимать, насколько качественно реализованы процессы управления данными в их информационных системах, а Потребителям – видеть, насколько качественными являются поступающие к ним данные.

Инциденты и несоответствия качества данных Поставщика, обнаруживаемые проверками качества данных ЕИП НСУД, должны устраняться Поставщиком данных в его ИС**.

Примечание

*С современными практиками управления данными в организации можно ознакомиться в кратком Регламенте управления данными ГосТех https://platform.gov.ru/documents/reglament-standart-upravleniya-danny/ или фундаментальном DAMA-DMBOK2 (доступен перевод на русский язык).

**О работе с инцидентами качества данных читайте в статье «Работа с инцидентами качества данных».

Бизнес-логика проверок качества на стороне Поставщика данных

Проверки качества данных в ЕИП НСУД представляют собой процедуры, которые периодически либо по событию осуществляют контроль данных в таблицах витрины данных на предмет их соответствия предъявляемым к ним требованиям к качеству.

В проверках качества данных может быть также определен критический уровень объема ошибочных данных в таблице витрины данных, который определяется как отношение количества данных, несоответствующих требованиям к их качеству, к общему количеству данных в таблице.

Бизнес-процесс обеспечения качества данных на основе использования проверок качества данных ЕИП НСУД на стороне Поставщика данных состоит из следующих этапов:

создания проверок и установления требований:

1. Установить требования к качеству данных в своих ИС с учетом требований, предъявляемых к этим данным Потребителями.
2. Принять меры по обеспечению и контролю качества данных в своих ИС, убедиться в их действенности.
3. Сформировать проверки качества для данных, размещенных в Витрине. Для каждой проверки установить критерии качества данных, проверить работоспособность, задать условия запуска (по факту загрузки данных или по расписанию)
4. Согласовать сформированные проверки с Оператором ЕИП НСУД.
5. Определить ответственных за решение инцидентов качества данных, поступающих в процессе эксплуатации проверок, и за обработку обращений и заявок на создание новых проверок качества данных.

эксплуатации проверок:

1. Оперативно реагировать в случаях, когда поступают:

• инциденты качества данных в ЕИП НСУД и Ситуационном центре электронного правительства (СЦ) – исправлять данные в своих ИС, чтобы данные после загрузки из ИС в Витрину соответствовали критерию качества;

• заявки на создание новых проверок – по согласованию создавать требуемые проверки (выполнять шаги 3-5).

2. Регулярно (несколько раз в неделю) анализировать результаты уведомительных проверок качества данных в своей Витрине данных, при обнаружении несоответствий – исправлять данные в своих ИС, чтобы данные в Витрине соответствовали критериям качества.

3. Регулярно (несколько раз в год) проводить опрос Потребителей о качестве данных в Витрине Поставщика.

4. По результатам опроса Потребителей, анализа ошибок в СЦ и результатов проверок качества данных проводить ревизию проверок качества данных и принимать решения о возможных изменениях проверок: о добавлении новых, отключении бесполезных, об ужесточении выставленных критериев качества.

Взгляд со стороны Потребителя данных

Потребитель данных имеет возможность получить представление об уровне качества данных в любой Витрине Поставщика: ему доступны в ЕИП НСУД для просмотра как содержание проверок качества данных, так и их сводные результаты (подробнее в п. "Проверки качества данных 2.0" Инструкции по работе в ФГИС ЕИП НСУД).

Потребитель может направлять Поставщику заявки на создание новых проверок качества данных. Необходимость в них может возникать при появлении новых нормативных требований или в случае, если в поставляемых данных систематически наблюдаются недостатки. Процесс создания заявки на формирование новой проверки качества данных описан в разделе "Заявки на создание проверок 2.0 " Инструкции по работе в ФГИС ЕИП НСУД.

Примечание

Если для регламентированного запроса указать признак «чистые данные» и задать конкретные проверки качества, то Потребителю будут передаваться только те данные, которые не содержат ошибок по результатам выполнения указанных проверок. Включение признака «чистые данные» Потребитель указывает в заявке на создание регламентированного запроса.

Преимущества новой версии проверок качества

Ранее Поставщики данных в СМЭВ4 (владельцы Витрины) могли пользоваться сервисом «Проверки качества данных» (ПКЧ) версии 1.0. Такие проверки настраивались и выполнялись в интерфейсе ЕИП НСУД.

Реализация проверок версии 2.0 по сравнению с ПКЧ 1.0 имеет ряд дополнительных функций и преимуществ, в том числе:

• просмотр детального журнала результатов проверок, что даёт возможность самостоятельного анализа, локализации и диагностики выявленных отклонений качества данных;
• графическая визуализация агрегированной статистики качества данных;
• управление инцидентами качества данных, сформированными по результатам выполнения проверок;
• обеспечение сверки данных, размещенных в Витринах данных, на предмет их соответствия сведениям в Едином федеральном информационном регистре населения(ЕРН) и справочниках и классификаторах в Единой системе нормативной справочной информации(ЕСНСИ) ;
• отдельные выделенные типы проверок: полнота, достоверность, точность и консистентность.

Примечание

Функциональность ПКЧ 1.0 будет доступна для использования до перехода Поставщиков на ПКЧ 2.0.

Виды и типы проверок

При создании проверки качества указывается ее тип и вид, а также порядок ее запуска.

1) Вид проверки качества данных определяет последующее действие:

• Уведомительная – фиксируется результат проведения проверки без создания инцидента качества данных.
• Блокирующая (пороговый инцидент) – создается пороговый инцидент качества данных при превышении установленного порогового значения уровня ошибок.

2) Типы проверок соответствуют проверяемым параметрам качества данных:

• Полнота – проверяется полнота данных.
• Достоверность – проверяется соответствие данных заданному формату и ограничениям.
• Точность – проверяется соответствие данных значениям в справочниках из внешних источников.
• Консистентность – проверяется связанность данных и их непротиворечивость по отношению к данным в Витрине.

Примечание

Тип проверки «Проверка сведений для ГИР ВУ (ПП 506)» имеет специфический характер, разработан под конкретные услуги, в данной статье рассматриваться не будет.

3) Выполнение проверки может запускаться:

• по загрузке – после каждой загрузки или обновления данных в витрине.
• по расписанию – проверка будет запускаться в указанное время согласно указанному расписанию: ежедневно, еженедельно, ежемесячно, либо задать вручную.

Подробное описание, как создавать проверки качества 2.0, приведено в Инструкции ЕИП НСУД (п. "Создание проверки качества данных 2.0").

Что необходимо сделать для работы проверок, описано в статье «Настройка работы с качеством данных 2.0».

Далее разберем каждый из типов проверок с конкретными примерами использования.

Проверка типа «Полнота»

Проверка данного типа контролирует заполнение обязательных полей.

При создании проверки нужно указать проверяемые атрибуты. При этом нет необходимости создавать условие — система автоматически добавит правило «значение ≠ NULL» для указанных атрибутов.

Примеры ситуаций для использования проверки типа «Полнота»:

1. Проверка наличия данных, удостоверяющих личность, для однозначной идентификации человека.

2. Проверка на наличия данных в поле email, когда без указания адреса почты не сработает обязательная рассылка уведомлений.

Проверка типа «Достоверность»

Проверка данного типа поможет проконтролировать соответствие данных заданному формату и ограничениям.

Варианты условий, которые можно задавать в проверке:

1) равно или не равно;

2) больше или меньше;

3) входит или не входит в множество;

4) множество значений указывается в квадратных скобках через запятую;

5) соответствие регулярному выражению.

Используемое регулярное выражение должно соответствовать структуре POSIX.

Для упрощения составления регулярного выражения предлагается список преднастроенных выражений с наименованиями и описаниями формата, например, «Паспорт РФ (1234 567890)». Преднастроенные регулярные выражения можно редактировать в соответствии со своими потребностями. Также можно формировать регулярные выражения самостоятельно

В проверке типа «Достоверность» можно задать несколько условий, используя операторы AND или OR.

Оператор AND (И) используется, когда должны выполниться все условия. Ошибка фиксируется, если хотя бы одно из этих требований нарушено.

Оператор OR (ИЛИ) используется, когда достаточно выполнения одного условия. Ошибка фиксируется, только если нарушены оба условия одновременно.

Примеры ситуаций для использования типа проверки «Достоверность»:

1. Проверка полей на соответствие определённому формату.
Для кода ОКТМО:

oktmo =~ "^d{8}(d{3})?$" – верный ОКТМО должен состоять из 8 или 11 цифр.

2. Проверка диапазонов возможных дат или возраста.
Для года поступления действующего студента:
year >= 2025 – значение должно быть больше или равно номеру текущего года.

3. Проверка данных на вхождение в строго определенный перечень.
Например, документом, удостоверяющим личность может быть документ из следующего перечня: паспорт гражданина РФ, заграничный паспорт, свидетельство о рождении (для детей) или временное удостоверение личности.

Дополнительные примеры и форматы регулярных выражений приведены в Инструкции ЕИП НСУД (п. "Реализация проверки качества для типа «Достоверность»").

Проверка типа «Точность»

С помощью данной проверки можно сравнивать данные в своей Витрине с данными из внешних источников.

В настоящий момент в качестве внешнего источника чаще всего используется ЕСНСИ.

При создании проверки указывается, с каким элементом из какого справочника ЕСНСИ требуется сравнивать выбранные атрибуты Витрины. Если необходимого вам справочника нет в ЕСНСИ, его можно создать, это описано в статье «Как создать справочник» https://info.gosuslugi.ru/articles/Как_создать_справочник/. Если справочник уже есть в ЕСНСИ, но его нет в Витрине системы ЕСНСИ, то можно инициировать его перенос в Витрину, отправив в СЦ заявку в свободной форме.

Внешним источником можно также выбрать ЕРН. Настройка таких проверок имеет специфический характер и подробно описана в Инструкции ЕИП НСУД (п. "Реализация проверки качества для типа «Точность» – «ЕРН»"). В связи с тем, что проверка этого типа работает через СМЭВ3, для ее реализации необходимо:

1)  получить доступ к Виду сведений ФНС России «Предоставление сведений о номере записи федерального регистра сведений о населении»;

2)  дополнительно настроить Витрину и Адаптер СМЭВ3 для работы через СМЭВ3 (подробнее об этом читайте в статье «Настройка работы с качеством данных 2.0»);

3)  дополнительно заполнить блоки:

• Параметры идентификации физического лица – для определения способа идентификации и хранения идентификационных параметров в Витрине;
• Преобразование формата данных – в случае использования форматов данных, отличных от форматов ЕРН;
• SQL-запрос для получения данных из Витрины – для получения сравниваемых данных из Витрины (можно сгенерировать автоматически).

Примечание

При создании проверки для некоторых конкретных услуг также можно выбрать в качестве источника ЦП ЕСИА. Данный тип проверок предполагает подключение витрины с компонентом "Стандартизация" к цифровому профилю "ЕСУМД", в данной статье рассматриваться не будет.

Примеры ситуаций для использования проверки типа «Точность»:

1. Сверка со справочником ЕСНСИ.

Для кода региона: он должен соответствовать коду из справочника «Регионы РФ».

2. Проверка наличия записи о физическом лице в ЕРН.

Проверка типа «Консистентность»

Проверка данного типа позволяет проверять ссылочную целостность таблиц Витрины и непротиворечивость данных из разных таблиц.

При создании такой проверки выбираются сравниваемые атрибуты из нескольких таблиц.

Подробнее о создании проверок типа «Консистентность» читайте в Инструкции ЕИП НСУД (п. "Реализация проверки качества для типа «Консистентность»").

Только в данном типе проверки для пользователей с ролью «Инженер данных» имеется возможность редактирования SQL-запроса для указания дополнительных параметров. При редактировании необходимо указывать SQL-запрос без агрегированных функций, поддерживаемый со стороны Prostore версии 6.12.1 и выше.

Примечание

1. Обратите внимание, что для корректной отработки проверки типа «Консистентность» должны отрабатывать именно по ошибочным условиям проверки.

2. Ошибки проверок типа «Консистентность» не видны в одной таблице ― они проявляются только при сравнении нескольких сущностей, поэтому «Консистентность» выделена в отдельный тип проверок.

3. Для работы проверок данного типа необходима «Карта проверок». Это DDL-описание таблиц, которое подкладывается при установке компонента Витрины данных «Агент проверок». Подробнее это описано в РА Агента проверок.

4. При ручном редактировании запроса важно следить за плейсхолдером @PARAM_KEYS.

Примеры ситуаций для использования проверки типа «Консистентность»:

1. Связь по ключам/идентификаторам (внешние ключи):

для каждого ученика должна существовать привязка к школе, то есть должен быть указан соответствующий идентификатор школы.

2. Сложные цепочки:

для существующей активной записи на приём к врачу в таблицах Витрины данных не могут отсутствовать записи о враче и о пациенте.

3. Бизнес-консистентность:

у студента, для которого есть приказ об академическом отпуске, должны быть заполнены даты начала и/или окончания академического отпуска.

4. Пример сложной проверки:

найти заказы, с даты создания которых прошло 30 дней, но к ним ещё не добавили ни одной позиции.

SELECT

o.order_id

FROM

demo.orders AS o

LEFT JOIN

demo.order_items AS i

ON i.order_id = o.order_id

WHERE

o.created_at < CURRENT_DATE - INTERVAL '30 day' -- Заказы старше 30 дней

AND

i.order_id IS NULL -- У которых нет позиций

AND o.order_id IN (@PARAM_KEYS); -- Обязательный фильтр по ключам

Заключение

Благодаря использованию проверок качества разных типов и видов, о которых шла речь в данной статье, владелец Витрины может достаточно эффективно и разносторонне следить за качеством хранящихся в ней данных, что, в свою очередь, улучшает качество предоставления услуг и сервисов для граждан и организаций.

Для достижения желаемого результата необходимо выработать согласованные с Потребителями бизнес-требования к качеству своих данных, обеспечить формализацию и параметризацию необходимых проверок, подготовить и зарегистрировать проверки. Далее важным этапом является решение инцидентов, возникающих в ходе выполнения этих проверок. Как работать с инцидентами, описано в статье «Работа с Инцидентами» и Инструкции ЕИП НСУД (п. "Управление инцидентами качества 2.0").

Важно!

Следует помнить, что проверки качества 2.0 также нагружают вашу Витрину. При их создании нужно руководствоваться теми же правилами, что и при создании регламентированных запросов. Подробные рекомендации по составлению планов запросов и их оптимизации приведены в статье «Оптимизация работы РЗ». Также следует внимательно отнестись к выбору порядка запуска проверок – по расписанию или по загрузке.

Более подробную информацию о сведениях, изложенных в указанной статье, можно получить в обучающем видеоматериале.