Критерии проверки витрин и регламентированных запросов

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

Витрины данных

1. Состав витрин

Правила:

Пример:

Ни описание витрины "Витрины данных АИС НСИ", ни мнемоника не поясняют, что в ней содержится.

Желательно (для удобства), чтобы различия были заметны в первых же словах витрины.

Пример:

Ни из наименований витрин, ни из мнемоник, невозможно понять, чем они различаются.

Пример:

Непонятно, данные какого региона представлены в витрине.

Пример:

Данные дублируются в разных витринах одного ведомства

2. Таблицы в витрине

Правила:

Пример:

Из наименования поля невозможно понять о каком разряде идет речь

Пример:

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

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

Пример:

Если проанализировать поля таблиц - они повторяются на 80%

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

Пример:

В строке предполагается коллекция дат, для её обработки потребуется специальная логика

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

Пример:

ВНЖ с одним номером и серией вряд ли может быть выдан людям с разными фамилиями

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

Пример: Отчество связано с фамилией и именем, но не связано с реквизитами ВНЖ (см. рисунок выше).

• Третья и более высокие нормальные формы для витрины нежелательны: витрина предназначена для представления данных, а не манипулирования с ними. Другими словами, дочерние таблицы рекомендуются только в следующих случаях:
• связанная таблица содержит НСИ либо эталонные справочные данные (например, получение названия муниципального образования по ОКТМО);
• в связанной таблице размещаются данные большого объема (например, бинарные данные либо текстовые данные неограниченной длины);
• реализуется ассоциативная связь между различными наборами данных (например, между автомобилями и происшествиями).

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

Пример:

Таблицы типа «код-значение» нецелесообразны, лучше вставить значение (либо оба поля) в основную таблицу.

Регламентированные запросы

1. Состав регламентированных запросов

Правила:

Пример:

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

• Названия регламентированных запросов должны различаться.

Пример:

Названия запросов внутри витрины совпадают

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

Пример:

Фильтры задаются не параметрами запроса, а самим запросом. Вряд ли это обусловлено различными требованиями по доступу к данным по запросам.

2. Регламентированный запрос

Правила:

• За редким исключением, регламентированные запросы должны иметь параметры.

Отсутствие параметров означает, что по запросу передадутся все записи таблицы. Такое возможно, например, когда запрашивается таблица не более чем с десятками записей, либо когда запрос используется только для подписки или оповещения. Но в этих случаях все равно необходимо удостовериться, что потребителю необходимы именно все записи таблицы.
Это же относится и к регзапросам с параметрами, если видно, что по нему будет возвращаться необоснованно большое количество записей.

Пример:

Есть основание уточнить насколько большая таблица и как её будут использовать

• Регламентированный запрос должен содержать явное перечисление запрашиваемых полей, конструкции типа select (*) не допускаются. Для регзапросов по проверке качества допускается select count (*).

Ситуация возможна только при ручном вводе SQL запроса

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

Особенно важно это для регзапросов, содержащих:

• персональные данные (попоскольку их обработка должна быть обоснована законом);
• «тяжелые» поля (blob или text) - таким запросам лучше содержать не более десятка полей.

• связываться по ключевым полям;
• мастер-таблицей желательно быть таблице с потенциально минимальным количеством значений.