Анализ правил проверки качества данных в Центре компетенции НСУД при согласовании витрин данных проводится на основании достаточно мягких критериев. Но, к сожалению, многие витрины данных не удовлетворяют даже им
Проверки качества данных
1. Наборы проверок
Правила
а) Согласованные наборы проверок должны иметь понятные названия, соответствующие их смыслу.
Названия наборов проверок в рамках одной версии витрины данных должны различаться.
Пример:
Из названий наборов проверок не ясно чем именно они различаются. Кроме того два полностью совпадающих набора проверок.
2. Состав проверок в наборе
Правила:
а) Для каждой проверки должна быть указана основная таблица.
б) Проверки должны иметь понятные названия, соответствующие их смыслу.
Названия наборов проверок (с учетом основной таблицы) должны быть уникальны.
Пример:
Поскольку таблицы запросов не указаны, названия проверок дублируются.
в) Каждая таблица должна иметь хотя бы одну проверку.
Пример: см. выше
г) Таблица проверки должна соответствовать основной таблице в тексте проверки
д) Каждая таблица должна иметь хотя бы одну проверку (не обязательно в одном и том же наборе).
Таблицу легко определить по тексту проверки:
е) Не должно быть дублирующих проверок.
ж) Периодичность проверок набора данных должна соответствовать целесообразности.
Пример: Наборы данных, которые изменяются редко (например, НСИ) нет необходимости проверять ежедневно, достаточно еженедельно.
3. Правила проверок качества по бизнес-ключам
Бизнес-ключом (альтернативным ключом), назовем поле (набор полей) таблицы, совокупность значений которых предполагаются уникальными. Регламентированные запросы чаще всего в качестве параметров используют атрибуты бизнес ключей.
Пример:
Для приведенной на рисунке таблицы разрешений организациям ожидается, что в один день не может быть выдано двух разрешений с одним номером и двух разрешений одной и той же организации.
Правила:
а) Для каждого атрибута, входящего в состав бизнес ключа, желательны проверки на непустоту и на корректность.
б) Для бизнес-ключей желательны проверки на недублирование записей.
в) Критерии качества данных (допустимая доля ошибок) для бизнес-ключей ожидаются выше, чем для остальных полей.
Пример: Критерий качества для атрибутов, являющихся параметрами для регламентированных запросов нежелательно устанавливать ниже 95%.
4. Регулярные выражения
Для проверки формата текстовых строк в правилах проверки качества часто используются операторы NOT LIKE 'шаблон' и NOT SIMILAR TO 'шаблон', сверяющие значения в проверяемых полях на не соответствие заданным шаблонам (соответственно, операторы LIKE и SIMILAR TO сверяют значения на соответствие шаблонам).
Как правило, используют оператор NOT SIMILAR TO, обладающий более богатыми возможностями, но начнем с более простого оператора NOT LIKE.
4.1. LIKE и NOT LIKE
Синтаксис шаблона операторов LIKE и NOT LIKE предельно прост. Если в шаблоне указан любой символ кроме специальных – проверяться будет наличие именно такого символа на указанном месте.
Набор специальных символов ограничен, но при этом шаблоны легко читаются человеком.
Специальные символы:
_ – любой одиночный символ;
% – любое количество символов;
\ – позволяет задать в условии спецсимвол (может быть заменен модификатором ESCAPE 'спецсимвол').
Примеры:
LIKE 'n__d.ru' – любая строка из семи символов, начинающаяся с 'n' и заканчивающаяся на 'd.ru', в которой второй и третий символы любые;
LIKE 'n%d.ru' – любая строка начинающаяся с 'n' и заканчивающаяся на 'd.ru';
LIKE '\%%\%' – любая строка, начинающаяся и заканчивающаяся на '%'.
4.2. SIMILAR TO и NOT SIMILAR TO
Синтаксис шаблонов операторов SIMILAR TO и NOT SIMILAR TO использует регулярные выражения, позволяющие задать практически любой возможный шаблон поиска для строк символов.
В сети существуют учебники, подробно расписывающие синтаксис регулярных выражений (например, https://ru.wikibooks.org/wiki/Регулярные_выражения), а также сервисы для чтения и проверки регулярных выражений онлайн (например, https://regexr.com/).
Ниже мы приведем несколько примеров, иллюстрирующих наиболее простые и употребимые варианты их использования:
- Проверка на корректность номера паспорта:
SIMILAR TO '[0-9]{6}' – в строке должны быть ровно шесть символов ({6}), каждый из которых может быть только числом ([0-9]). В квадратных скобках можно указывать либо перечень допустимых символов, либо их диапазон через дефис.
- Проверка на формат СНИЛС:
SIMILAR TO '[0-9]{3}[-][0-9]{3}[-][0-9]{3}[-][0-9]{2}' – строка проверяется на соответствие шаблону NNN-NNN-NNN-NN, где N – любое число. Вместо диапазона '[0-9]' можно использовать шаблон '\d', также означающего одну любую цифру;
- Проверка номера автомобиля:
SIMILAR TO '[АВЕКМНОРСТУХ]{1}[0-9]{3}[АВЕКМНОРСТУХ]{2}[0-9]{2,3}' – одна буква из допустимого набора, три цифры, две буквы и две или три цифры;
- Проверка на наличие только символов кириллицы:
SIMILAR TO '[а-яА-ЯёЁ]' – строка проверяется на наличие только символов кириллицы (любые другие символы в строке, включая дефисы и пробелы проверку не пройдут). Обратите внимание, что в кодовой таблице символы Ё и ё находятся вне диапазонов [А-Я] и [а-я], и их необходимо указывать отдельно.
- Проверка того, что строка начинается с пробела (или иного символа, воспринимающегося как пробел) и не заканчивается на пробел:
SIMILAR TO '^[\s]+|[\s]+$' – '^' указывает что поиск ведется с начала строки, шаблон '\s' означает «любой пробельный символ», '+' означает любое количество повторений (в данном случае пробелов), '|' означает «или», '$' означает, что поиск ведется с конца строки. Шаблон '\S' наоборот, задает любой символ, не являющийся пробелом – изменение регистра в шаблонах меняет их значение на противоположное.