Валидация данных

Валидация данных направлена на обеспечение определённых гарантий пригодности, точности и согласованности любых пользовательских данных, вводимых в приложение или автоматизированную систему. Правила валидации данных могут быть определены и спроектированы различными методологиями и внедрены в различных контекстах^[1].

Правила валидации данных могут определяться, проектироваться и внедряться, например:

Контексты определения и проектирования:

• в процессе сбора требований при инженерии программного обеспечения или проектировании спецификации
• на этапе моделирования бизнес-процессов

Отделы/реализации:

• в виде набора программ или бизнес-логики на языке программирования
• в виде набора хранимых процедур в СУБД

В бизнес-приложениях валидация может определяться посредством декларативных правил целостности данных или бизнес-правил, реализованных как декларативно, так и с помощью императивных процедур^[2]. Несоблюдение этих правил негативно сказывается на бизнес-процессах, поэтому определение бизнес-процесса и набора бизнес-правил лежит в основе всего процесса валидации. Сбор правил происходит на этапе сбора требований^[3].

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

Например:

• Проверка типа данных
• Проверка диапазона и ограничений
• Проверка кода и перекрёстных ссылок
• Структурная валидация

Проверка типа данных обычно проводится для одного или нескольких простых полей данных. Наиболее примитивный вариант такой проверки заключается в том, чтобы удостовериться, что каждый введённый символ соответствует ожидаемому для конкретного типа данных. Это определение задаётся в языке программирования или механизме хранения и извлечения, чаще всего выделяют три типа: 1) целое; 2) вещественное (десятичное); 3) строка.

Например, многие современные СУБД позволяют также задавать разрешённые спецсимволы, такие как «,», «+», «-» или "(". Более сложные процедуры дополнительно проверяют соответствие, например, — что телефонный код соответствует стандартам заданной страны/региона.

Процесс валидации состоит из двух этапов: (а) собственно проверка; (б) дальнейшие действия по результатам проверки. Первый этап реализуется одной или несколькими вычислительными процедурами.

Валидация диапазона и ограничений проверяет соответствие введённых данных минимальным/максимальным значениям или требованиям, а также соответствие текстовых полей определённым паттернам — например, с помощью регулярных выражений. К примеру, номер американского телефона должен содержать ровно 10 цифр, но не буквы или спецсимволы.

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

К примеру, пользователь может ввести строку, формально подходящую под стандарт валидного email-адреса по RFC 5322^[4][5][6], но данный email может не соответствовать реально существующему аккаунту.

Структурная валидация объединяет базовые этапы — проверки типа, логики, а также сложные процедурные операции. Может включать тестирование условных ограничений для сложных объектов данных или наборов операций.

Правило валидации — это критерий либо ограничение, применяемое к данным после их ввода, обычно реализуемое через специальные программы. Это не то же самое, что формальная верификация, при которой проверяется корректность работы самой программы относительно спецификации. Текущие решения валидации, распространённые в программных продуктах, были изначально реализованы сотрудником Microsoft в 1997—1999 годах.

Суть метода состоит в сопоставлении данных с установленными системным аналитиком допустимыми параметрами. Полной гарантия корректности достигается только сочетанием всех встроенных и внешних системных механизмов валидации. Различие между валидностью и точностью иллюстрируется на простом примере: если работник организации для поля «класс» выберет A, B, C или D, система примет любую корректную букву, но она может не соответствовать действительному классу данного сотрудника, точная категория устанавливается только административной проверкой по другим источникам.

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

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

• Хотя на ISBN не распространяется, в большинстве случаев валидация включает проверку попадания значения в установленные рамки, например — номера счёта ограничены только диапазоном от 10000 до 20000, если такая система применяется.

Примером проверки служит процедура валидации ISBN, которая включает следующие этапы:

• Проверка размера: длина проверяемого значения должна совпадать с заданной (например, старый формат ISBN содержал 10 символов, новый — 13).
• Формат: первые 9 символов должны быть числами от 0 до 9, 10-й — цифра или X.
• Контрольное число: вычисленное дополнительное значение, позволяющее отслеживать возможные ошибки при вводе (например, для ISBN — последний символ).

Проверка допустимых символов

Допускаются только ожидаемые символы (например, в числовом поле — только цифры, десятичная точка, возможно — минус или запятая). Для email — наличие «@», других структурных элементов. Для этого часто применяются регулярные выражения.

Суммы по партиям (batch totals)

Проверяются пропущенные записи, количество или сумма по партии. Например, суммы по определённому полю всех транзакций в партии сверяются с вводимым итогом.

Проверка кардинальности

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

Проверка контрольного числа

В цифровых данных часто добавляется специальное число, вычисляемое по формуле для всего массива (например, последний знак ISBN — контрольное число, вычисляемое по модулю 10).

Проверки согласованности

Взаимная логическая согласованность данных между связанными полями (например, если в поле «Фамилия» написано «Иванов», и в поле «Отчество» — «Петрович», то соответствие всех зависимых полей проверяется).

Контрольная сумма

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

Межсистемная проверка согласованности

Сверка одних и тех же данных в разных информационных системах (например, адрес клиента с тем же идентификатором должен совпадать во всех реестрах; нередко приходится преобразовывать формат для корректного сравнения).

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

Проверяется совпадение введённого значения с ожидаемым типом (например, ввод букв вместо числа вызывает ошибку).

Проверка существования файла

Удостоверяется наличие указанных файлов — актуально для программ, работающих с файлами напрямую.

Проверка формата/образца

Ввод должен соответствовать определённому шаблону (например, дата строго в формате ДД/ММ/ГГГГ); регулярные выражения для таких задач — стандартный инструмент.

Хэш-суммы

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

Проверка границ (больше/меньше)

Проверка значений на соответствие верхней или нижней границе (например, значение должно быть не больше 2).

Логическая проверка

Контроль данных на предмет логических ошибок (например, деление на ноль).

Проверка наличия

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

Проверка интервалов

Проверка того, что значение принадлежит заранее определённому диапазону (например, месяц рождения — от 1 до 12).

Референтная целостность

Внутри базы данных контроль ссылочной целостности: значения внешних ключей всегда должны ссылаться на реальные строки других таблиц.

Проверка орфографии и грамматики

Проверка правописания (для текстовых полей).

Проверка уникальности

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

Сверка по списку (table lookup)

Вводимое значение сопоставляется с перечнем допустимых значений, хранящихся в справочной таблице.

Принятие/отклонение

Обычно в интерактивных системах некорректные данные отклоняются, и пользователь обязан внести корректировки. Для пакетной обработки — отклоняется полностью файл, с объяснением причины. Бывает и автоматическая коррекция (например, преобразование всех знаков в строчные/прописные без уведомления пользователя), однако злоупотребление этим может привести к потере важных данных (например, если длинный комментарий будет усечён системой).

Информирующее действие

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

Подтверждающее действие

Пользователь получает запрос на подтверждение принятого ввода, иногда система предлагает исправленный вариант значения (например, корректировка адреса по эталону). Окончательный выбор — за пользователем.

Журналирование валидации

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

Ошибки или упущения на этапе валидации могут привести к уязвимостям, компрометации безопасности или потере данных^[7]. Валидация необходима для проверки того, что данные пригодны для обработки, валидны, разумны и безопасны перед их использованием^[8].