Войти

Проверки качества данных

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

1. Наборы проверок

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

Пример: 

Рисунок1.png

Из названий наборов проверок не ясно чем именно они различаются. Кроме того, два полностью совпадающих набора проверок.

2. Состав проверок в наборе

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

Пример:

Рисунок2.png

В витрине три таблицы. Из названия проверки неизвестно, какой таблицы она касается.

  • Таблица проверки должна соответствовать основной таблице в тексте проверки.

Пример:

Рисунок3.png

Название проверки содержит название поля и не содержит названия таблицы.

  • Каждая таблица должна иметь хотя бы одну проверку (не обязательно в одном и том же наборе). Таблицу легко определить по тексту проверки (см. пример выше)
  • Не должно быть дублирующих проверок.
  • Периодичность проверок набора данных должна соответствовать целесообразности.

Пример: Наборы данных, которые изменяются редко (например, НСИ) нет необходимости проверять ежедневно, достаточно еженедельно.

3. Правила проверок качества по бизнес-ключам

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

Рисунок4.png

Для приведенной на рисунке таблицы разрешений организациям ожидается, что в один день не может быть выдано двух разрешений с одним номером и двух разрешений одной и той же организации.

Правила:

  • Для каждого атрибута, входящего в состав бизнес ключа, желательны проверки на непустоту и на корректность.
  • Для бизнес-ключей желательны проверки на недублирование записей.
  • Критерии качества данных (допустимая доля ошибок) для бизнес-ключей ожидаются выше, чем для остальных полей.

Пример: Критерий качества для атрибутов, являющихся параметрами для регламентированных запросов нежелательно устанавливать ниже 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/).

Ниже мы приведем несколько примеров, иллюстрирующих наиболее простые и употребимые варианты их использования:

1. Проверка на корректность номера паспорта:
SIMILAR TO '[0-9]{6}'        – в строке должны быть ровно шесть символов ({6}), каждый из которых может быть только числом ([0-9]). В квадратных скобках можно указывать либо перечень допустимых символов, либо их диапазон через дефис.

2. Проверка на формат СНИЛС:
SIMILAR TO '[0-9]{3}[-][0-9]{3}[-][0-9]{3}[-][0-9]{2}'  – строка проверяется на соответствие шаблону NNN-NNN-NNN-NN, где N – любое число. Вместо диапазона '[0-9]' можно использовать шаблон 'd', также означающего одну любую цифру;

3. Проверка номера автомобиля:
SIMILAR TO '[АВЕКМНОРСТУХ]{1}[0-9]{3}[АВЕКМНОРСТУХ]{2}[0-9]{2,3}' – одна буква из допустимого набора, три цифры, две буквы и две или три цифры;

4. Проверка на наличие только символов кириллицы:
SIMILAR TO '[а-яА-ЯёЁ]'   – строка проверяется на наличие только символов кириллицы (любые другие символы в строке, включая дефисы и пробелы проверку не пройдут). Обратите внимание, что в кодовой таблице символы Ё и ё находятся вне диапазонов [А-Я]  и [а-я], и их необходимо указывать отдельно.

5. Проверка того, что строка начинается с пробела (или иного символа, воспринимающегося как пробел) и не заканчивается на пробел:
SIMILAR TO '^[s]+|[s]+$'  – '^' указывает что поиск ведется с начала строки, шаблон 's' означает «любой пробельный символ», '+' означает любое количество повторений (в данном случае пробелов), '|' означает «или», '$' означает, что поиск ведется с конца строки. Шаблон 'S' наоборот, задает любой символ, не являющийся пробелом – изменение регистра в шаблонах меняет их значение на противоположное.

Авторизуйтесь, чтобы оставить комментарий к статье