Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы валидации [ править ]

Допустимые проверки персонажей
Проверяет, что в поле присутствуют только ожидаемые символы. Например, числовое поле может содержать только цифры 0–9, десятичную точку и, возможно, знак минус или запятые. Текстовое поле, такое как личное имя, может запрещать использование символов для разметки . Для адреса электронной почты может потребоваться как минимум один знак @ и различные другие структурные детали. Регулярные выражения могут быть эффективным способом реализации таких проверок.
Итоги партии
Проверяет отсутствие записей. Числовые поля можно складывать вместе для всех записей в пакете. Вводится сумма партии, и компьютер проверяет ее правильность, например, складывает поле «Общая стоимость» нескольких транзакций вместе.
Проверка мощности
Проверяет, что запись имеет допустимое количество связанных записей. Например, если запись контакта классифицируется как «клиент», то с ней должен быть связан хотя бы один заказ (количество элементов> 0). Этот тип правила может быть усложнен дополнительными условиями. Например, если контактная запись в базе данных заработной платы классифицируется как «бывший сотрудник», тогда с ней не должно быть никаких связанных выплат заработной платы после даты увольнения (количество элементов = 0).
Проверить цифры
Используется для числовых данных. Для поддержки обнаружения ошибок к числу добавляется дополнительная цифра, которая рассчитывается на основе других цифр.
Проверки согласованности
Проверяет поля, чтобы гарантировать соответствие данных в этих полях, например, если срок действия в прошлом, то статус не является «активным».
Проверки согласованности между системами
Сравнивает данные в разных системах, чтобы убедиться в их непротиворечивости. Системы могут представлять одни и те же данные по-разному, и в этом случае для сравнения требуется преобразование (например, одна система может хранить имя клиента в одном поле имени как «Доу, Джон Q», в то время как другая использует имя «Джон», а также фамилию «Доу» и отчество. 'Качество').
Проверки типа данных
Проверяет соответствие ввода типизированным данным. Например, поле ввода, принимающее числовые данные, может отклонять букву «О».
Проверка существования файла
Проверяет, существует ли файл с указанным именем. Эта проверка важна для программ, использующих обработку файлов.
Проверка формата
Проверяет, что данные находятся в указанном формате (шаблоне), например, даты должны быть в формате ГГГГ-ММ-ДД. Для такого рода проверки могут использоваться регулярные выражения.
Проверка присутствия
Проверяет наличие данных, например, от клиентов может потребоваться адрес электронной почты.
Проверка диапазона
Проверяет, находятся ли данные в заданном диапазоне значений, например, вероятность должна быть от 0 до 1.
Ссылочная целостность
Значения в двух таблицах реляционной базы данных могут быть связаны через внешний ключ и первичный ключ. Если значения в поле внешнего ключа не ограничиваются внутренними механизмами, то они должны быть проверены, чтобы гарантировать, что ссылочная таблица всегда ссылается на строку в ссылочной таблице.
Проверка орфографии и грамматики
Ищет орфографические и грамматические ошибки.
Проверка уникальности
Проверяет уникальность каждого значения. Это может быть применено к нескольким полям (например, Адрес, Имя, Фамилия).
Проверка поиска по таблице
При проверке поиска по таблице данные сравниваются с набором допустимых значений.

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

Правоприменительные меры
Действие принудительного применения обычно отклоняет запрос на ввод данных и требует, чтобы субъект ввода внес изменение, которое приводит данные в соответствие. Это больше всего подходит для интерактивного использования, когда за компьютером сидит реальный человек и делает запись. Он также хорошо работает для пакетной загрузки, когда ввод файла может быть отклонен, а набор сообщений, отправленных обратно источнику ввода, объясняет, почему данные отклоняются.
Другая форма принудительных действий включает автоматическое изменение данных и сохранение соответствующей версии вместо исходной. Это больше всего подходит для косметических изменений. Например, преобразование записи [all-caps] в запись [Pascal case] не требует ввода пользователем. Неуместное использование автоматического принуждения может иметь место в ситуациях, когда принудительное исполнение приводит к потере деловой информации. Например, сохранение усеченного комментария, если его длина больше ожидаемой. Обычно это не очень хорошо, поскольку может привести к потере важных данных.
Консультативное действие
Консультативные действия обычно позволяют вводить данные без изменений, но отправляют сообщение исходному субъекту, указывающее на те проблемы проверки, которые были обнаружены. Это наиболее подходит для неинтерактивных систем, для систем, в которых изменение не критично для бизнеса, для этапов очистки существующих данных и для этапов проверки процесса ввода.
Действие проверки
Действия по проверке - это особые случаи рекомендательных действий. В этом случае исходного актера просят подтвердить, что эти данные - это то, что они действительно хотели бы ввести, в свете предположения об обратном. Здесь этап проверки предлагает альтернативу (например, проверка почтового адреса возвращает другой способ форматирования этого адреса или предлагает совершенно другой адрес). В этом случае вы захотите дать пользователю возможность принять рекомендацию или сохранить свою версию. Это не строгий процесс проверки по замыслу и полезен для захвата адресов в новое расположение или расположение, которое еще не поддерживается базами данных проверки.
Журнал проверки
Даже в тех случаях, когда проверка данных не выявила каких-либо проблем, важно предоставить журнал проведенных проверок и их результатов. Это полезно для выявления любых недостающих проверок достоверности данных в свете проблем с данными и для улучшения проверки.

Проверка и безопасность [ править ]

Сбои или упущения при проверке данных могут привести к повреждению данных или уязвимости системы безопасности . [4] Проверка данных проверяет соответствие данных цели, [5] достоверность, разумность, разумность и безопасность перед их обработкой. Некоторые методы управления рисками для защиты компаний от мошенничества, снижения эксплуатационных расходов и обеспечения соответствия различным нормативным политикам - это « Знай своего клиента» (KYC) и Программа идентификации клиентов (CIP). Подтверждение знай своего клиента - это проверка клиентов, которая проводится либо до, либо в то время, когда они начали свои отношения с бизнесом.

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

  • Проверка данных
  • Верификация и валидация

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

  1. ^ Методология проверки данных 1.0
  2. ^ Проверка данных, целостность данных, разработка распределенных приложений с помощью Visual Studio .NET.
  3. ^ Часто задаваемые вопросы о новом стандарте ISBN. Архивировано 10 июня 2007 г. в ISO- образе Wayback Machine .
  4. ^ Глава 10. Проверка достоверности данных
  5. ^ Более эффективная проверка данных с помощью Spotless

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

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