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

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

Это отличается от формальной проверки , которая пытается доказать или опровергнуть правильность алгоритмов реализации спецификации или свойства.

Обзор [ править ]

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

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

Разные виды [ править ]

При оценке основ проверки данных можно сделать обобщения относительно различных видов проверки в зависимости от их объема, сложности и цели.

Например:

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

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

Проверка типа данных обычно выполняется для одного или нескольких простых полей данных.

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

Например, целочисленное поле может потребовать, чтобы при вводе использовались только символы от 0 до 9.

Простая проверка диапазона и ограничений [ править ]

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

Проверка кода и перекрестных ссылок [ править ]

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

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

Структурированная проверка [ править ]

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

Проверка соответствия [ править ]

Проверка согласованности гарантирует, что данные логичны. Например, может быть запрещено, чтобы дата доставки заказа предшествовала дате его отгрузки.

Пример [ править ]

Несколько видов проверки данных применимы к 10-значным ISBN, выпущенным до 2007 года (издание ISO 2108 2005 года требовало, чтобы ISBN имели 13 цифр, начиная с 2007 года). ^[3]).

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

Типы проверки [ править ]

Разрешенные проверки символов: Проверяет, присутствуют ли в поле только ожидаемые символы. Например, в числовом поле можно использовать только цифры 0–9, десятичную точку и, возможно, знак минус или запятые. В текстовом поле, например личном имени, могут быть запрещены символы, используемые для разметки . Для адреса электронной почты может потребоваться хотя бы один знак @ и различные другие структурные детали. Регулярные выражения могут быть эффективным способом реализации таких проверок.

Итоги партии: Проверяет недостающие записи. Числовые поля можно суммировать для всех записей в пакете. Вводится общая сумма пакета, и компьютер проверяет ее правильность, например, суммируя поле «Общая стоимость» нескольких транзакций вместе.

Проверка мощности: Проверяет, что запись имеет допустимое количество связанных записей. Например, если запись контакта классифицируется как «клиент», то с ней должен быть хотя бы один связанный заказ (количество элементов > 0). Этот тип правил может быть осложнен дополнительными условиями. Например, если запись о контакте в базе данных расчета заработной платы классифицируется как «бывший сотрудник», то после даты увольнения с ней не должно быть связанных выплат заработной платы (количество элементов = 0).

Проверьте цифры: Используется для числовых данных. Чтобы обеспечить обнаружение ошибок, к числу, которое рассчитывается на основе других цифр, добавляется дополнительная цифра.

Проверка согласованности: Проверяет поля на соответствие данных в этих полях, например, если срок действия уже прошел, то статус не «активен».

Межсистемные проверки согласованности: Сравнивает данные в разных системах, чтобы убедиться в их согласованности. Системы могут представлять одни и те же данные по-разному, и в этом случае сравнение требует преобразования (например, одна система может хранить имя клиента в одном поле имени как «Доу, Джон Q», а другая использует Имя «Джон», Фамилию «Доу» и «Отчество» 'Качество').

Проверки типов данных: Проверяет соответствие ввода введенным данным. Например, поле ввода, принимающее числовые данные, может отклонить букву «О».

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

Проверка формата: Проверяет, что данные находятся в указанном формате (шаблоне), например, даты должны быть в формате ГГГГ-ММ-ДД. Для такого рода проверки можно использовать регулярные выражения.

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

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

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

Проверка орфографии и грамматики: Ищет орфографические и грамматические ошибки.

Проверка уникальности: Проверяет уникальность каждого значения. Это можно применить к нескольким полям (например, «Адрес», «Имя», «Фамилия»).

Проверка поиска по таблице: Проверка поиска в таблице сравнивает данные с набором допустимых значений.

Действия после проверки [ править ]

Правоприменительные меры: Принудительные действия обычно отклоняют запрос на ввод данных и требуют от субъекта ввода внести изменение, которое приведет данные в соответствие. Это наиболее подходит для интерактивного использования, когда за компьютером сидит реальный человек и вводит данные. Это также хорошо работает для пакетной загрузки, когда ввод файла может быть отклонен, а источнику ввода отправлен набор сообщений с указанием причин отклонения данных.; Другая форма принудительных мер предполагает автоматическое изменение данных и сохранение соответствующей версии вместо исходной. Это наиболее подходит для косметических изменений. Например, преобразование записи [все заглавные буквы] в запись [регистр Pascal] не требует ввода данных пользователем. Ненадлежащим применением автоматического правоприменения может быть ситуация, когда правоприменение приводит к потере деловой информации. Например, сохранение усеченного комментария, если его длина превышает ожидаемую. Обычно это нехорошо, поскольку может привести к потере важных данных.

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

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

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

Валидация и безопасность [ править ]

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

См. также [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

Проверка данных , OWASP
Проверка ввода , серия шпаргалок OWASP, github.com

[1] Методология проверки данных 1.0

[2] Проверка данных, целостность данных, проектирование распределенных приложений с помощью Visual Studio .NET.

[3] Часто задаваемые вопросы о новом стандарте ISBN. Архивировано 10 июня 2007 г. в Wayback Machine ISO .

[4] Глава 10. Валидация данных

[5] Более эффективная проверка данных с Spotless

[1]

[2]

[3]

[4]

[5]