Специалисты Центра компетенции НСУД при согласовании витрин данных и регламентированных запросов обращают внимание на разнообразные критерии, приведенные в этой статье.
1. Витрина данных
1.1. Состав витрин
Правила:
а) Каждая витрина должна иметь понятные название и мнемонику, соответствующие содержимому витрины.
Пример:
б) Наименования витрин должны различаться.
Желательно (для удобства), чтобы различия были заметны в первых же словах витрины.
Пример:
в) На витрине должны размещаться все необходимые для межведа данные одной или нескольких предметных областей. Не допускается размещение данных одной предметной области в разных витринах.
Пример:
1.2. Таблицы в витрине
Правила:
а) Таблицы, поля (атрибуты) таблиц должны иметь понятные названия и коды, из которых должно быть однозначно понятно какие сведения в них размещаются.
(Чтобы не создавать длинные наименования, допускается пояснять наименование в описаниях)
Пример:
б) Типы полей таблиц должны соответствовать содержимому полей (например, если в поле содержится номер или дата - его тип не может быть строкой)
Пример:
в) В витрине не должно быть повторяющихся таблиц, каждая таблица должна содержать специфическую уникальную в рамках витрины информацию (но разные таблицы могут содержать одинаковые поля).
Пример:
г) Каждая таблица витрины должна удовлетворять первой нормальной форме. То есть: в полях таблиц должны размещаться атомарные значения, никаких списков или дополнительных структур (исключения допустимы только для blob-полей, но с ними отдельная история).
Пример:
д) Каждая таблица витрины в части первичного ключа должна удовлетворять второй нормальной форме. То есть:
- в каждой таблице должен быть один первичный ключ из одного или нескольких полей, определяющих уникальную запись;
- этот первичный ключ должен являться минимально возможным (если исключить из ключа любое поле - ключ перестанет быть уникальным).
Пример:
е) Витрина должна соответствовать второй нормальной форме. То есть: в каждой таблице витрины не должны содержаться атрибуты, зависящие только от части первичного ключа (случай редкий, но для аргументированности позиции следует о нем помнить)
Пример: См. рисунок выше: Отчество связано с фамилией и именем, но не связано с реквизитами ВНЖ
ж) Третья и более высокие нормальные формы для витрины нежелательны: витрина предназначена для представления данных, а не манипулирования с ними. Другими словами, дочерние таблицы рекомендуются только в следующих случаях:
- связанная таблица содержит НСИ либо эталонные справочные данные (например, получение названия муниципального образования по ОКТМО);
- в связанной таблице размещаются данные большого объема (например, бинарные данные либо текстовые данные неограниченной длины);
- реализуется ассоциативная связь между различными наборами данных (например, между автомобилями и происшествиями).
Критерий не является абсолютным, всё зависит от собственной экспертной оценки - чем более насыщена дочерними таблицами и ассоциативными связями витрина - тем хуже.
Пример:
2. Регламентированные запросы
2.1. Состав регламентированных запросов
Правила:
а) Регламентированные запросы должны иметь понятные названия и мнемоники, соответствующее их смыслу
(с учетом известных сведений о владельце витрины).
Пример:
б) Названия регламентированных запросов должны различаться.
Пример:
в) Не должно быть дублирования регламентированных запросов.
Нежелательной также является ситуация с большим количеством однотипных запросов, различающихся лишь значениями параметров - для проверки нужно выяснить основание, почему эти значения невозможно включить в параметр единого запроса (например, из соображений разных ограничений по доступу).
Пример:
2.2. Регламентированный запрос
Правила:
а) За редким исключением, регламентированные запросы должны иметь параметры.
Отсутствие параметров означает, что по запросу передадутся все записи таблицы. Такое возможно, например, когда запрашивается таблица не более чем с десятками записей, либо когда запрос используется только для подписки или оповещения. Но в этих случаях все равно необходимо удостовериться, что потребителю необходимы именно все записи таблицы.
Это же относится и к регзапросам с параметрами, если видно, что по нему будет возвращаться необоснованно большое количество записей.
Пример:
б) Регламентированный запрос должен содержать явное перечисление запрашиваемых полей, конструкции типа select (*) не допускаются
(для регзапросов по проверке качества допускается select count (*)).
Ситуация возможна только при ручном вводе SQL запроса
г) Регламентированному запросу нежелательно быть "тяжелым" - как правило, в нормальном регзапросе не более пары десятков полей и не более пары джойнов. Регзапросы с большим количеством полей и джойнов целесообразно разделить на несколько.
Особенно важно это для регзапросов, содержащих:
- персональные данные (попоскольку их обработка должна быть обоснована законом);
- большими полями - blob или text - таким запросам лучше содержать не более десятка полей.
Пример:
д) Связи (JOIN) в межвитринном регламентированном запросе должны быть оптимизированы по производительности:
- связываться по ключевым полям
- мастер-таблицей желательно быть таблице с потенциально минимальным количеством значений.