Концепция правил качества¶
Важной составляющей управления ключевыми данными является контроль качества самих данных. Система Юнидата имеет несколько инструментов контроля качества, каждый из которых призван решать определенные задачи.
Главным инструментом являются правила качества данных. Общая идея правил качества заключается в том, что правила предназначены для проверки значений атрибутов записей на соответствие заданным условиям. Если значение атрибута не отвечает условиям, то создается ошибка качества, которую следует исправить.
Правила качества настраиваются для каждого атрибута реестра/справочника отдельно. При создании правила задаётся его имя (уникальное для каждого правила), описание, условия при котором оно запускается и для каких источников данных будет применяться.
Каждое правило качества создается на основе функции обработки данных. Функция принимает на вход данные, определенным образом обрабатывает и выдает выходные параметры.
Функции делятся на стандартные и пользовательские, простые и композитные. Стандартные: предустановленные функции, которые идут в комплекте с продуктом. Пользовательские: созданные заказчиком для личных целей. Простые функции: выполняющие действие, состоящее из одного шага. Композитные: состоящие из 2 или более шагов, зачастую создаваемые из нескольких простых функций.
Примеры функций. Простая: перевод текста в верхний регистр. Комплексная: поиск в тексте одного из нескольких ключевых слов и добавление к определенному слову специального префикса.
Каждое правило качества может работать в одном из трех режимов. При разработке функций обработки данных необходимо учитывать, в каком режиме будет работать правило качества, для которого создается функция.
“Валидация”. Проверка значения атрибута на соответствие заданным правилам. Цель валидации – удостовериться, верно ли значение атрибута, поэтому на основании проверки выдается ошибка (см. примечание ниже). Пример валидации: заполнен ли атрибут «Телефон». Если нет, то создается ошибка с указанием проблемы.
“Обогащение”. Изменение данных в ходе работы функции. Цель обогащения – трансформировать данные так, чтобы они были заполнены унифицировано, либо дополнить данные новыми значениями. При срабатывании обогащения сохранение записи приводит к созданию новой или обновленной исходной записи. Примеры обогащения: 1) автоматический перевод первого символа из строчного в прописной для атрибута «Имя»; 2) заполнение атрибута «Телефон» из содержимого атрибута «Комментарий».
“Валидация + обогащение”. Объединение двух типов. При наличии ошибки валидации также возможно, что запись нельзя будет сохранить (см. примечание ниже).
Каждое правило качества содержит категории критичности. Критичность позволяет определить, насколько серьезна ошибка, что повлияет на формирование статистики по реестру, и поможет оператору данных расставить приоритеты для отработки ошибок.
Порядок правил в реестре/справочнике имеет значение. Первое правило качества будет выполняться первым, второе – следующим, и так далее. Доступно изменение порядка правил в интерфейсе пользователя.
Сохраненные правила качества можно протестировать на существующих или пользовательских (абстрактных) записях.
Important
Публикация записи с ошибками валидации зависит от критичности ошибки. При уровне критичности RED и в фазе выполнения Origin сохранение записи с ошибкой валидации невозможно. Во всех остальных случаях, например, при уровне критичности RED и базовой фазе выполнения запись с ошибкой валидации будет опубликована.
Виды простых правил обогащения данных:
Удаление лишних пробелов, оставляя лишь по одному пробелу между словами;
Преобразование текста в верхний регистр;
Преобразование двойных дефисов в одинарный;
Удаление пробела между дефисом и словом.
Как срабатывают правила качества¶
После того, как созданы правила качества, они начинают срабатывать при изменении записей в реестрах/справочниках.
Механизм срабатывания правил качества зависит от настроек потоков выполнения. Поток выполнения правил качества описывает, в какой именно момент производится проверка правил качества, и на каком этапе выдаются ошибки пользователю.
Пример алгоритма срабатывания правил качества по умолчанию:
При попытке публикации черновика записи производится проверка. Проверяются условия:
Если нет ошибок правил качества: публикация успешна.
Если найдена ошибка для правила с валидацией: публикация может быть отклонена (зависит от критичности и потока выполнения).
Если найдена ошибка для правила с обогащением: данные в записи будут изменены в соответствии с правилами валидации.
Если найдена ошибка для правила с валидацией и обогащением: действия валидации могут не позволить опубликовать запись (зависит от критичности и потока выполнения). Действия обогащения изменят данные в соответствии с правилами валидации.
Также на алгоритм срабатывания влияет:
Контекст выполнения. Используется для ограничения действия функции обработки данных, используемой правилом качества, на определенные атрибуты. Возможные варианты: глобальный или локальный.
Режим работы правила. Используется для выбора действий с найденными ошибками качества. Возможные варианты: валидация (проверка значения атрибута на соответствие заданным правилам), обогащение (изменение данных в ходе работы функции), валидация + обогащения.
Пример использования¶
После загрузки данных из нескольких источников стало ясно, что у записей от каждого источника были собственные правила заполнения атрибутов.
В первом источнике все данные были введены в верхнем регистре;
Во втором источнике атрибут “Комментарий” был обязательным, и туда зачастую вводили пустые данные;
В третьем источнике атрибут “Контактное лицо” был представлен в виде двух атрибутов: “Имя контактного лица” и “Телефон контактного лица”.
Чтобы привести данные к единым правилам, администратор данных должен выполнить следующий порядок действий:
Создать правило качества данных, которое содержит информацию о режиме работы правила, системе-источнике, используемой функции обработки данных и т.д.
Поместить правило в существующий или новый набор правил.
Назначить набор реестру/справочнику.
Также может потребоваться создать собственную функцию обработки данных.
Администратор системы также должен настроить потоки выполнения: указать, в какой именно момент обработки данных запускать правила. Например, правила обогащения могут срабатывать после сохранения записи, а правила валидации - перед попыткой сохранения.
Оператор данных получает ошибки качества данных в процессе работы, выполняя действия, которые были предусмотрены администратором системы и администратором данных.