Типы правил проверки данных
Перечисленные требования можно разделить на три группы.
Первая группа. Требования, которые предписывают обязательно заполнять поля. Если пользователь оставил поле незаполненным, то при сохранении данных в таблице ему будет автоматически присвоено значение NULL.
Вторая группа. Предписывают проверять вводимые значения.
В третью группу войдут правила, требующие дополнительных расчётов. В простейшем случае это вычисление арифметических выражений. В более сложных ситуациях это проверки и вычисление по какому-либо алгоритму.
Для реализации правил первой и второй группы в ORACLE предусмотрен механизм декларативной целостности данных.
Для правил третьей группы придётся писать программный код и размещать его либо в программе-клиенте, либо на сервере базы данных.
В этом уроке остановимся на правилах декларативной целостности данных. Это те правила, которые программист может объявить и хранить вместе с таблицей. ORACLE будет проверять соблюдение этих правил при любых изменениях данных в таблице.
Простые правила декларативной целостности данных.
Проверка обязательности заполнения колонки.
Проверка значения на принадлежность к заданному диапазону.
Проверка значения на вхождение в список.
Комбинация из простых правил.
Более сложные.
Проверка на уникальность значений.
Проверка на присутствие значения в другой таблице.
Мы с ними познакомимся после того, как рассмотрим ситуацию с дублированием записей и понятие уникальности значений.
Дублирование записей
Обратимся к таблице учебного примера EXDOC. Из предыдущих уроков мы знаем, что команды манипулирования данными ориентированы на работу с группой записей. Для указания на конкретную запись нам нужно её описать, используя значения, которые в ней хранятся.
Посмотрите на пример заполнения таблицы счетов. В таблице две строки. Причём значения в первой совпадают со значениями второй. Она точная копия первой, дубликат.
Р
исунок
1. Таблица EXDOC с дубликатами.
Представим, как будет записана команда UPDATE на изменение только одной записи. Например, требуется изменить только вторую запись. Как бы мы ни пытались, но написать "простой" запрос, используя знания предыдущих уроков, вряд ли удастся. Команда будет изменять всё время обе записи. "Простым SQL’ем" мы её не достанем.
В общем, работа с таблицей, которая содержит дубликаты, требует к себе повышенного внимания. Для манипулирования записями придется в запросах прибегать к уловкам. С одной из них мы познакомимся в практической части.
Надо заметить, что есть ряд случаев, когда допускается дублирование записей. Это делается специально.
Уникальность
От дубликатов переходим к понятию уникальности значений. Рассмотрим ещё один вариант заполнения таблицы счетов.
Р
исунок
2. Пример заполнения таблицы EXDOC.
Мы договорились об обязательном заполнении колонки "Номер счёта". В повседневной жизни двух счетов с одинаковым номером в одной организации быть не может. Если такой случай произойдет, то это может привести к пересортице товара, сбою в отслеживании платежей и т.д. Скажем так: у каждого счёта должен быть свой номер, неповторимый, уникальный.
Это означает, что в колонке "Номер счёта" будут храниться уникальные значения. Одно значение дважды не встретиться. А коль это случится, то мы не будем иметь в таблице записи-дубликаты. Все записи будут уникальными, отличными друг от друга.
Если существует правило уникальности, то про него говорят – первичный ключ.
В ряде случаев уникальность записей обеспечивается не одной колонкой, а комбинацией значений из нескольких колонок. Говорят о составном ключе.
Например. Пусть в организации каждый год нумерация счётов начинается с 1. Следствием этого, будет тот факт, что счёт с номером 125 может быть выписан и в 2003 году, и в 2004 году. Это нарушит правило уникальности для колонки "Номер счёта" в таблице EXDOC. Хотя записи всё равно будут уникальны. Но уникальность будет достигаться комбинацией значений в колонках "Номер счёта" и "Дата счёта".
Если рассматривать остальные колонки таблицы счетов, то про их уникальность можно говорить с большой натяжкой.
Судите сами. На одного и того же покупателя может быть выписано несколько счетов. Это случай с постоянными покупателями.
Адрес доставки может быть использован тоже в нескольких счетах. Поле не обязательно для заполнения и вследствие этого несколько записей будут иметь пустое значение. Пустое значение, NULL – это тоже значение! Запомните это свойство колонок, которые не обязательны для заполнения. Уникальности в них не ищите!
Совпадение по суммам носит вероятностный характер. Гарантий у нас нет.