Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Ограничения целостности




Целостность данных

Целостность данных связана с определением правил проверки достоверности данных (таких как "процентное значение должно находиться между 0 и 100") гарантирующих, что недействительные данные не попадут в таблицы. Раньше эти правила устанавливались непосредственно прикладными программами (и одни и те же правила проверялись неоднократно в различных программах). Oracle, однако, позволяет определять и хранить эти правила для объектов базы данных, которых они касаются, таким образом, чтобы кодировать их только однажды. При этом они активируются всякий раз, когда какой-либо вид изменения проводится в таблице, независимо от того, какая программа выполняет вставки, модификации или удаления. Этот контроль осуществляется в форме ограничений целостности и триггеров базы данных.

 

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

Поскольку ограничения целостности проверяются на уровне базы данных, они выполняются независимо от того, откуда были инициированы операторы вставки, модификации или удаления. Определение проверок через эти ограничения также выполняется быстрее, чем при использовании SQL. Кроме того, информация, вводимая при объявлении ограничений, используется оптимизатором Oracle для принятия решений о том, как выполнить оператор для данной таблицы.

Для таблицы можно задавать следующие типы ограничений целостности: NOT NULL, PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK и индексы.

 

Ограничения NOT NULL (не пусто)

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

 

PRIMARY KEY (первичный ключ)

Ограничение PRIMARY KEY определяет столбец или группу столбцов, которую можно использовать для уникальной идентификации строки. Никакие две строки в таблице не могут иметь одинаковых значений столбцов первичного ключа. Кроме того, столбцы первичного ключа должны всегда содержать значение. Другими словами, они — NOT NULL. Если налагается ограничение на таблицу после ее создания, столбцы, которые формируют ограничение PRIMARY KEY, изменяются на NOT NULL. Для таблицы может быть задан только один первичный ключ PRIMARY KEY. Например, введя ограничение PRIMARY KEY для таблицы заказов, указывается, что таблица не может иметь две записи с одним номером заказа.

 

UNIQUE (уникальный)

Ограничение UNIQUE определяет вторичный ключ для таблицы. Это — столбец или группа столбцов, которую можно использовать, как другой способ уникальной идентификации строки. Никакие две строки не могут иметь одинаковых значений для столбца или столбцов ключа UNIQUE. Хотя таблица не может иметь более одного первичного ключа, на нее можно наложить несколько ограничений UNIQUE.

Столбцы для ограничения UNIQUE не обязательно должны быть NOT NULL (хотя как правило гак и есть). Если значения для каких-либо столбцов, которые формируют уникальное ограничение, пустые, ограничение не проверяется. Например, при использовании ограничения PRIMARY KEY и UNIQUE для таблицы заказчиков можно указать, что номер заказчика - первичный ключ и имя заказчика является уникальным ключом (это подразумевало бы, что нельзя иметь в таблице двух заказчиков с одинаковыми именами.

ПРЕДОСТЕРЕЖЕНИЕ

FOREIGN KEY (внешний ключ)

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

Ограничения FOREIGN KEY используются для установления отношений родитель/потомок между таблицами. Можно даже использовать их, чтобы установить ограничения "ссылка на себя", обычно в ситуациях, где иерархическая структура создается на строках, хранимых в одной таблице. Если какие-либо столбцы внешнего ключа пусты, ограничение вообще не проверяется. Столбцы внешнего ключа обычно объявляются как NOT NULL.

Можно указать серверу БД, что когда родительская строка удаляется, удаление должно автоматически каскадироваться и должны удаляться строки потомка. Это — опасная ситуация. Пользователь информируется только об удалении главных строк, и он может не знать о дополнительных строках, которые были удалены автоматически в фоновом режиме, так как ему ничто не указывает, что это каскадное удаление произошло.

Подобное автоматическое удаление строк потомка поддерживается, только если задано предложение ON DELETE CASCADE в конце оператора создания внешнего ключа. Однако если изменяется значение ключа главной таблицы, строки потомка не обновляются автоматически, чтобы соответствовать новому ключу; можно реализовать это требование каскадной модификации, используя триггеры базы данных.

ПРЕДОСТЕРЕЖЕНИЕ




Поделиться с друзьями:


Дата добавления: 2013-12-12; Просмотров: 299; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.