Определение ограничений целостности. Ограничения целостности бд
7. Ограничения целостности
Ограничения целостности в базах данных, назначение, доменная целостность, сущностная целостность, ссылочная целостность, декларативная и процедурная целостность, перехват ошибок при нарушениях целостности
7.1 Что такое ограничения целостности
Ограничения целостности можно определить как специальные средства в базах данных, главное назначение которых - не дать попасть в базу недопустимым данным (например, предупредить ошибки пользователей при вводе данных).
Вначале - немного теории.
Все ограничения целостности можно разделить на три большие категории:
· первая категория - средства обеспечения доменной целостности. Они отвечают за то, чтобы в соответствующем поле базы данных были допустимые значения. Например, фамилия, как правило, должна состоять из букв, а почтовый индекс - из цифр. В базах данных такая целостность обычно обеспечивается условиями на значение, запретом пустых значений, триггерами и хранимыми процедурами, а также ключами;
· третья категория - ссылочная целостность, обеспечивается системой первичных и внешних ключей. Например, при помощи этих средств можно гарантировать, что у нас не будет заказов, оформленных на покупателей, которых нет в базе данных.
Еще две большие категории, на которые можно поделить средства обеспечения целостности - средства декларативного и процедурного характера. Средства декларативного характера создаются как составные части объектов при их определении в базе данных (например, условие на значение при определении таблицы в базе данных). Средства процедурного характера (триггеры и хранимые процедуры) реализуются как отдельные программные модули. В общем случае декларативные ограничения менее функциональны, но более экономны с точки зрения ресурсов и наоборот.
Надо сказать, что наличие развитой системы ограничений целостности во многом определяет зрелость базы данных. Обычно проще сразу позаботиться о том, чтобы в базу данных не попадали неверные значения, чем потом их убирать из базы данных.
Кроме того, при создании ограничений целостности разработчики должны позаботиться о том, чтобы ошибки, возникающие при нарушениях целостности, перехватывались клиентским приложением.
Ограничения целостности данных позволяют добавить для них требования, дополнительные к соблюдению типа. Заявляемые (схемные, формальные, "декларативные") ограничения целостности записываются ("провозглашаются") в виде условий, которые должны соблюдаться явно как таковые , на уровне схемы данных, и этим отличаются от правил целостности, сформулированных в виде запрограммированных проверок (см. ниже). Поэтому иначе такие ограничения можно называть "явными". Оригинальный термин имеет полное название " integrity data constraints" - "ограничения на значения данных, налагаемые для более точного учета обстоятельств предметной области ", но часто сокращается до " integrity constraints " или даже просто "constraints". Слово " integrity " вряд ли хорошо понятно массам разработчиков.Само понятие заявляемых ограничений целостности в SQL было унаследовано от реляционной модели и усложнялось вместе с развитием стандарта. В Oracle номенклатура ограничений целостности в целом соответствует SQL -92 (при том, что объем реализации не выдержан), но не доведена до уровня SQL :1999. Так, Oracle не позволяет завести ограничение целостности на уровне БД (с помощью служебного слова ASSERTION ) и сильно ограничен в формулировании условия проверки значений конструкцией CHECK тем, что не допускает обращения к данным базы.
Слово ASSERTION из стандарта SQL подсказывает еще один перевод (и понимание) integrity constraints , как "утвердительные ограничения целостности".
Заявляемые ограничения целостности в Oracle можно задавать на уровнях:
- отдельного поля строки в таблице;
- отдельной строки;
- пары таблиц.
Проверка на выполнение действующих заявляемых ограничений целостности выполняется СУБД автоматически и всегда, вне зависимости от источника поступления изменений, чем и гарантировано их соблюдение, в отличие, скажем, от проверок вводимых значений, осуществляемых клиентскими прикладными программами.
Oracle позволяет формулировать подобные ограничения при создании таблицы командой CREATE TABLE , а для уже существующих таблиц их можно добавлять и отменять следующими командами:
- ALTER TABLE … MODIFY - добавление ограничений всех видов и снятие ограничения NOT NULL ;
- ALTER TABLE … ADD/DROP - добавление и снятие ограничений всех видов, кроме NOT NULL .
Всем ограничениям целостности, сформулированными в схеме, Oracle сообщает имена. Если при создании ограничения употребить конструкцию CONSTRAINT имя , ограничение получит имя от программиста, в противном случае СУБД создаст имя по своему усмотрению. Сведения о каждом существующем ограничении можно найти в таблице словаря-справочника USER_CONSTRAINTS по его имени. Неудачное имя ограничения можно изменить; к примеру:
ALTER TABLE projx RENAME CONSTRAINT sys_c0011509 TO name_is_needed;
Разновидности заявляемых ограничений целостности
Ограничение NOT NULL
Ограничение NOT NULL обязывает столбец или группу столбцов всегда иметь значение (если группа - то хотя бы в одном поле). Требование непустоты столбца крайне желательно, так как избавляет программиста от многочисленных забот, связанных с особенностями обработки NULL . К сожалению, требования предметной области и некоторые действия в SQL (например, GROUP BY ROLLUP … ) не позволяют совсем отказаться от столбцов со свойством NULL .
Это единственное из ограничений целостности, информация о котором хранится не только в таблице USER_CONSTRAINTS , но и в таблице USER_TAB_COLUMNS в качестве свойства столбца. (Когда-то признак NULL/NOT NULL формально считался свойством столбца, а не ограничением целостности). По этой причине добавление и упразднение этого ограничения оформляется по правилам изменения свойства столбца, только через ключевое слово MODIFY :
ALTER TABLE proj MODIFY (budget NOT NULL); -- создание ограничения с системным именем; скобки необязательны ALTER TABLE proj MODIFY (budget NULL); -- упразднение ограничения; скобки необязательны ALTER TABLE proj MODIFY (budget CONSTRAINT is_mandatory NOT NULL); -- создание ограничения с именем, заданным программистом
В современных версиях Oracle самостоятельное ограничение NOT NULL будет оформлено технически как ограничение вида CHECK с условием для проверки: budget IS NOT NULL и одновременно будет зафиксировано в USER_CONSTRAINTS значением NULLABLE = "Y" . Свойство NOT NULL , вытекающее из правила первичного ключа, будет отражено только в USER_CONSTRAINTS .
Первичные ключи
От столбцов, назначенных первичным ключом, требуется, чтобы значения в их полях всех строк были уникальными и имелись всегда (для ключа из нескольких столбцов значение должно быть хотя бы в одном поле). Примеры создания и удаления:
ALTER TABLE proj ADD PRIMARY KEY (projno, pname); -- создание ограничения (первичный ключ на основе двух столбцов) с системным именем ALTER TABLE proj DROP PRIMARY KEY; -- упразднение ограничения ALTER TABLE proj ADD CONSTRAINT pk_proj PRIMARY KEY (projno); -- создание ограничения с именем, заданным программистом
Значения в полях первичного ключа должны существовать всегда.
Некоторые типы столбцов не допускаются до формирования первичного ключа (например, LOB или TIMESTAMP WITH TIME ZONE ).
Уникальность значений в столбцах
От столбцов, назначенных уникальными, требуется, чтобы значения в их полях всех строк были уникальными. Уникальность в SQL наиболее близка к понятию "альтернативного", "возможного" (candidate) или же просто "ключа" в реляционной модели.
Пример создания:
ALTER TABLE proj ADD UNIQUE (pname);
Обратите внимание, что в столбце PNAME не запрещаются пропуски значений. По стандарту SQL уникальность отслеживается для имеющихся значений столбца. Если на такой столбец дополнительно наложить ограничение
ALTER TABLE proj MODIFY (pname NOT NULL);
он сможет играть роль ключа в реляционной модели и быть объявлен первичным (путем замены двух ограничений: UNIQUE и NOT NULL на одно PRIMARY KEY ). Если же уникальной объявляется группа столбцов, сообщить ей свойства ключа средствами SQL сложнее (обязательность хотя бы одного значения в уникальной группе можно потребовать ограничением вида CHECK ).
Другое отличие ограничения уникальности от первичного ключа в том, что первых в таблице может быть сформулировано несколько, а второе присутствует разве что в единственном числе. Oracle не препятствует объявлению уникальности не только непересекающихся групп столбцов, но даже и повторяющихся. Следующая цепочка команд не вызовет ошибок:
ALTER TABLE t ADD CONSTRAINT xx UNIQUE (a, b); -- Ошибка!
Внешние ключи
Столбцы, объявленные внешним ключом, обязаны (а) ссылаться на однотипные столбцы из другой или той же таблицы при условии, что адресат - это первичный ключ или уникальная группа столбцов, и (б) принимать только существующие в данный момент в столбцах-адресатах значения. Пример создания:
ALTER TABLE proj ADD (ldept NUMBER (2)) ; ALTER TABLE proj ADD FOREIGN KEY (ldept) REFERENCES dept (deptno) ;
По правилам внешнего ключа в столбце LDEPT не запрещаются пропуски значений. Стандарт SQL требует от СУБД проверки соответствия значениям в столбцах-адресатах таблицы только имеющихся значений внешнего ключа; иными словами, значения в полях внешнего ключа могут отсутствовать.
Внешних ключей в таблице может быть определено несколько. Например, при более тщательном моделировании примера "сотрудники - отделы" в дополнение к имеющемуся внешнему ключу DEPTNO таблицы EMP можно было бы объявить внешним ключом столбец JOB , заставив его ссылаться на отдельную таблицу с описаниями штатных должностей.
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД - это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные .
Целостность сущностей описывается совокупностью ограничений которые должны выполняться для любых отношений в любых реляционных базах данных. Теоретики баз данных формулируют эти ограничения по-разному. Например, в называют «Условиями целостности … будем называть особые, отдельно хранящиеся данные, которыми на концептуальном уровне … представлено … правило (закон, критерий) принадлежности кортежей отношению, представленному этими данными (записями) в базе данных. К уровням целостности базы данных, как правило, присоединяются также спецификации условий принадлежности значений каждого из атрибутов реляционной таблицы к соответствующему ему домену в базе данных».
Из данного определения можем извлечь следующие простые формулировки ограничений:
1. Все строки таблицы должны иметь одинаковую структуру, одно и то же количество атрибутов.
2. Никакие две записи не могут совпадать. Если определен первичный ключ отношения, то каждая строка таблицы должна иметь свое значение первичного ключа.
3. Значения атрибутов должны быть атомарными.
4. Значения каждого атрибута должны быть взяты из некоторого фиксированного множества значений (домена).
Первое ограничение фиксирующее, что единственной структурой данных, используемых в реляционных БД, является отношение, по сути определяет само понятие отношения (таблица). Следствием второго ограничения является обязательное наличие атрибута, объявленного первичным ключом, обеспечивающим уникальность записей. Третье – не является строгим, т.е. результат невыполнения этого ограничения не обязательно скажется на целостности, но вероятность ошибок велика.
В ограничения целостности сущностей заключаются в требовании уникальности кортежей отношения (записей таблицы), из которого вытекают следующие ограничения:
1. отсутствие кортежей-дубликатов (данное требование предъявляется лишь к атрибутам первичных ключей);
2. отсутствие атрибутов с множественным характером значений.
1. Найти соответствие условий целостности из условиям, названным выше, (1 – 4).
2. Составить перечень атрибутов для сведений об адресе отношения СОТРУДНИК, обеспечивающих атомарность.
Ограничения целостности ссылок заключаются в том, что для любой записи с конкретным значением внешнего ключа должна обязательно существовать запись связанной таблицы-отношения с соответствующим значением первичного ключа.
Пример 1. Рассмотрим отношение СОТРУДНИКИ с внешним ключом «Код отдела» и связано с отношением ОТДЕЛЫ с первичным ключом «Код отдела» (см. рис. 8). Если существует сотрудник Волков И. И., работающий в отделе О1, то соответствующий отдел должен существовать и данные о нем должны храниться в таблице ОТДЕЛЫ .
Отношение Сотрудники
Отношение Отделы
Пример 2. Связь между таблицами Студент и Сдал осуществляется по полю НОМЕР_Зачетки, это связь типа один-ко-многим (1:М). Причем главной является таблица Студент, а подчиненной - таблица Сдал, т.к. в ней возможно любое количество записей со значением в поле НОМЕР_Зачетки, которое в таблице Студент может быть только один раз. Поле связи должно быть обязательно первичным ключом главной таблицы. Главную таблицу иногда называют родительской, а подчиненную - дочерней.
Поля связи в связываемых таблицах не обязательно должны иметь одинаковые имена, но значения полей должны быть взяты из одного и того же множества. Возможно использование для связи не только одного поля, но и совокупности полей.
Большинство СУБД реляционного типа, но не все, осуществляют контроль ссылочной целостности данных. Контроль данных на непротиворечивость осуществляется СУБД автоматически в следующих случаях:
1)При добавлении данных в подчиненную таблицу. Нельзя добавить строку, в которой поле связи содержит значение, отсутствующее в главной таблице. При добавлении данных в главную таблицу контроль ссылочной целостности не требуется.
2)При удалении данных из главной таблицы. Из главной таблицы запрещается удалять строку, если в подчиненной таблице есть строки, связанные с ней. Альтернативным способом решения проблемы сохранения ссылочной целостности данных при удалении является каскадное удаление, то есть удаление строки из главной таблицы с одновременным удалением соответствующих ей строк из подчиненной.
3)При модификации значения поля связи, как в главной, так и в подчиненной таблице. В подчиненной таблице значение поля связи можно изменить на другое значение, но только в случае, если новое значение есть в главной таблице. Изменить значение поля связи главной таблицы нельзя или следует произвести соответствующую замену и во всех строках подчиненной таблице, то есть выполнить каскадное изменение данных. Изменение в таблицах значений полей, не участвующих в связи контроля ссылочной целостности не требует.
Задания для самостоятельной работы
1. Добавить в таблицу СОТРУДНИКИ запись о Фроловой О.А., работающей в отделе кадров. Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.
2. Удалить из таблицы ОТДЕЛЫ запись со значением атрибута Краткое_наим_отдела «ЛИД». Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.
Замечания
1 Основное внимание в ограничениях целостности в иерархической модели уделяется целостности ссылок между предками и потомками с учетом основного правила: никакой потомок не может существовать без родителя.
2 В сетевой модели данных ослаблен контроль целостности связей из-за допустимости установления произвольных связей между записями.
Все операции над базой данных сводятся к манипуляциям с записями и полями таблиц. Обращаясь к нашему студенческому архиву (см. Таб.1), возможно, захочется узнать, кто из студентов учится в группе 407 – ответ: Сидоров (запись 3) и Соловьев (запись 4). Другой пример: кто среди студентов самый старший – ответ: Петров (запись 2). Это примеры простейших операций выборки.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное счисление .
Обеспечение манипуляционной целостности характеризует свойство БД сохранять достоверность в результате выполняемых операций: выборка, объединение, пересечение, разность, соединение, проекция, деление и т.д. , входящие в набор базовых теоретико-множественных операций и специальных реляционных. Неустойчивость БД, другими словами, потеря целостности, приводит к ошибкам и даже разрушению данных. Обеспечение манипуляционной целостности находится в прямой зависимости от нормализации БД.
В основу манипуляционной части модели положена теория множеств с некоторыми уточнениями. Основная идея состоит в том, что, поскольку отношение - это множество, то средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми операциями, специфичными для БД.
Набор операций, предложенный Коддом, содержит восемь операций:
1)теоретико-множественные операции, такие как объединение, пересечение, разность и декартово произведение, а ко второму - селекция, проекция, соединение и деление
2)специальные реляционные операции, к которым относятся операция присваивания, позволяющая сохранить в БД результат вычисления алгебраических выражений, и операция переименования атрибутов, которая дает возможность корректно сформировать заголовок результирующего отношения - его схему.
Пример 1. Объединение. R3 = R1 È R2
Пусть отношение R1 - это таблица «Абитуриенты - победители олимпиады», а R2 - таблица «Абитуриенты, прошедшие по конкурсу на основании экзаменов».
Таблица Абитуриенты - победители олимпиады.
Таблица Абитуриенты, прошедшие по конкурсу на основании экзаменов.
Пусть основанием для зачисления в университет является победа в олимпиаде, либо успешная сдача вступительных экзаменов. Результат объединения (R3), который мы назовем «Абитуриенты, зачисленные в университет», включает все строки первой таблицы и недостающие строки из второй.
Таблица Абитуриенты, зачисленные в университет.
Пример 2. Пересечение. R3 = R1 Ç R2
Исходные данные те же, что и в случае объединения. Результат пересечения включает только те строки первой таблицы, которые есть во второй. В нашем случае результатом будет таблица, которую можно назвать «Абитуриенты, зачисленные в университет по двум показателям».
Таблица Абитуриенты, зачисленные в университет по двум показателям.
В теории множеств операции объединения, пересечения и разности имеют смысл для любых двух множеств. В случае реляционной алгебры это не так. Результатом любой из этих операций должно стать отношение, то есть множество однотипных строк, следовательно, операндами должны быть отношения с одинаковыми, а точнее совместимыми, схемами. Это означает, что отношения должны иметь одинаковую степень и одинаковые типы соответствующих атрибутов. Имена атрибутов могут отличаться, тогда после переименования можно выполнить основную операцию, то есть объединение, пересечение или разность.
Для операции декартово произведение, применяемой к паре отношений, важно, чтобы схемы, т.е. имена атрибутов были разными.
При нарушениях условий целостности возможно возникновение аномалий. Существует несколько видов аномалий: избыточности, обновления, включения, удаления.
Основная задача при проектировании реляционных БД -формирование оптимальных отношений.
Пример 1. Рассмотрим БД «Объединение кооперативов». В отношении ПОСТАВЩИКИ (НАЗВАНИЕ ПОСТАВЩИКА, АДРЕС ПОСТАВЩИКА, ТОВАР, ЦЕНА), в связи с такой его схемой, могут возникают следующие проблемы:
1. Аномалия избыточность: адрес поставщика повторяется для каждого повторяемого товара.
2. Аномалия обновления (потенциальная противоречивость, может и не возникнуть): вследствие избыточности можно обновить адрес поставщика в одном кортеже, оставив его неизменным в другом. При этом может оказаться, что для некоторых поставщиков нет единого адреса.
3. Аномалия удаления: при необходимости удаления всех товаров, поставляемых данным поставщиком, непреднамеренно можно утратить его адрес.
4. Аномалия включения: в БД может быть записан адрес поставщика, который в настоящее время не поставляет товар, можно поместить неопределенные значения атрибутов ТОВАР и ЦЕНА. Но если он начнет поставлять некоторый товар, можно забыть удалить кортеж с неопределенными значениями. ТОВАР и НАЗВАНИЕ ТОВАРА образуют ключ данного отношения, а поиск кортежей с неопределенными значениями может быть затруднен или невозможен.
Избыточность в данных потенциально приводит к различным аномалиям и нарушениям целостности данных. Аномалия это то, что не является нормой и в связи с этим считается странностью и исключением. Логически таблица БД построена, вроде бы, правильно, но возникает ошибка, которая может повлечь нарушение всей структуры БД. Т.к. аномалии проявляют себя при выполнении операций, изменяющих состояние базы данных, то различают следующие виды аномалий:
· Аномалии вставки (INSERT)
· Аномалии обновления (UPDATE)
· Аномалии удаления (DELETE)
Пример 2: Рассмотрим в качестве предметной области некоторую организацию, выполняющую некоторые проекты. В текущий момент состояние предметной области отражается следующими фактами:
· Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 1 и во втором проекте "Климат" задание 1.
· Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 2.
· Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте "Космос" задание 3 и во втором проекте "Климат" задание 2.
Это состояние отражается в таблице СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (курсивом выделены ключевые поля).
В процессе проектирования базы данных принимается решение о том, какие таблицы должны входить в базу данных, какие у них будут имена (идентификаторы), какие типы данных потребуются для построения таблиц и какие пользователи получат доступ к каждой из них. Кроме того, для эффективного создания таблиц необходимо ответить на следующие вопросы:
- Столбцы какого типа и размера будут составлять каждую из таблиц, какие требуется выбрать имена для столбцов таблиц?
- Какие столбцы могут содержать значение NULL ?
- Будут ли использованы ограничения целостности , значения по умолчанию и правила для столбцов?
- Необходимо ли индексирование столбцов, какие типы индексов будут применены для конкретных столбцов?
- Какие столбцы будут входить в первичные и внешние ключи .
Для создания таблиц в среде MS SQL Server используется команда:
<определение_таблицы> ::= CREATE TABLE [ имя_базы_данных.[владелец]. | владелец. ]имя_таблицы (<элемент_таблицы>[,...n])
<элемент_таблицы> ::= {<определение_столбца>} | <имя_столбца> AS <выражение> | <ограничение_таблицы>
Обычно владельцем таблицы (dbo) является тот, кто ее создал.
<Выражение> задает значение для вычисляемого столбца . Вычисляемые столбцы - это виртуальные столбцы, т. е. физически в таблице они не хранятся и вычисляются с использованием значений столбцов той же таблицы. В выражении для вычисляемого столбца могут присутствовать имена обычных столбцов, константы и функции, связанные одним или несколькими операторами. Подзапросы в таком выражении участвовать не могут. Вычисляемые столбцы могут быть включены в раздел SELECT при указании списка столбцов, которые должны быть возвращены в результате выполнения запроса. Вычисляемые столбцы не могут входить во внешний ключ , для них не используются значения по умолчанию. Кроме того, вычисляемые столбцы не могут участвовать в операциях INSERT и DELETE .
<определение_столбца> ::= { имя_столбца <тип_данных>} [ [ DEFAULT <выражение> ] | [ IDENTITY (начало, шаг) ]]] [<ограничение_столбца>][...n]]
В определении столбца обратим внимание на параметр IDENTITY , который указывает, что соответствующий столбец будет столбцом-счетчиком . Для таблицы может быть определен только один столбец с таким свойством. Можно дополнительно указать начальное значение и шаг приращения. Если эти значения не указываются, то по умолчанию они оба равны 1. Если с ключевым словом IDENTITY указано NOT FOR REPLICATION , то сервер не будет выполнять автоматического генерирования значений для этого столбца, а разрешит вставку в столбец произвольных значений.
В качестве ограничений используются ограничения столбца и ограничения таблицы . Различие между ними в том, что ограничение столбца применяется только к определенному полю, а ограничение таблицы - к группам из одного или более полей.
<ограничение_столбца>::= [ CONSTRAINT имя_ограничения ] { [ NULL | NOT NULL ] | [ {PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ] [ WITH FILLFACTOR=фактор_заполнения ] [ ON {имя_группы_файлов | DEFAULT } ] ] ] | [ [ FOREIGN KEY ] REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы) ] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] [ NOT FOR REPLICATION ]] | CHECK [ NOT FOR REPLICATION](<лог_выражение>) } <ограничение_таблицы>::= { [ {PRIMARY KEY | UNIQUE } [ CLUSTERED | NONCLUSTERED ] {(имя_столбца [,...n])} ] |FOREIGN KEY[(имя_столбца [,...n])] REFERENCES имя_род_таблицы [(имя_столбца_род_таблицы [,...n])] [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ] | NOT FOR REPLICATION ] | CHECK [ NOT FOR REPLICATION ] (лог_выражение) }
Рассмотрим отдельные параметры представленных конструкций, связанные с ограничениями целостности данных . Ограничения целостности имеют приоритет над триггерами, правилами и значениями по умолчанию. К ограничениям целостности относятся ограничение первичного ключа PRIMARY KEY , ограничение внешнего ключа FOREIGN KEY , ограничение уникальности UNIQUE , ограничение значения NULL , ограничение на проверку CHECK .
Ограничение первичного ключа (PRIMARY KEY)
Таблица обычно имеет столбец или комбинацию столбцов, значения которых уникально идентифицируют каждую строку в таблице. Этот столбец (или столбцы) называется первичным ключом таблицы и нужен для обеспечения ее целостности. Если в первичный ключ входит более одного столбца, то значения в пределах одного столбца могут дублироваться, но любая комбинация значений всех столбцов первичного ключа должна быть уникальна.
При создании первичного ключа SQL Server автоматически создает уникальный индекс для столбцов, входящих в первичный ключ . Он ускоряет доступ к данным этих столбцов при использовании первичного ключа в запросах.
Таблица может иметь только одно ограничение PRIMARY KEY , причем ни один из включенных в первичный ключ столбцов не может принимать значение NULL . При попытке использовать в качестве первичного ключа столбец (или группу столбцов), для которого ограничения первичного ключа не выполняются, первичный ключ создан не будет, а система выдаст сообщение об ошибке.
Поскольку ограничение PRIMARY KEY гарантирует уникальность данных, оно часто определяется для столбцов-счетчиков . Создание ограничения целостности PRIMARY KEY возможно как при создании, так и при изменении таблицы . Одним из назначений первичного ключа является обеспечение ссылочной целостности данных нескольких таблиц. Естественно, это может быть реализовано только при определении соответствующих внешних ключей в других таблицах.
Ограничение внешнего ключа (FOREIGN KEY)
Ограничение внешнего ключа - это основной механизм для поддержания ссылочной целостности между таблицами реляционной базы данных. Столбец дочерней таблицы, определенный в качестве внешнего ключа в параметре FOREIGN KEY , применяется для ссылки на столбец родительской таблицы, являющийся в ней первичным ключом . Имя родительской таблицы и столбцы ее первичного ключа указываются в предложении REFERENCES . Данные в столбцах, определенных в качестве внешнего ключа , могут принимать только такие же значения, какие находятся в связанных с ним столбцах первичного ключа родительской таблицы. Совпадение имен столбцов для связи дочерней и родительской таблиц необязательно. Первичный ключ может быть определен для столбца с одним именем, в то время как столбец, на который наложено ограничение FOREIGN KEY , может иметь совершенно другое имя. Единственным требованием остается соответствие столбцов по типу и размеру данных.
На первичный ключ могут ссылаться не только столбцы других таблиц, но и столбцы, расположенные в той же таблице, что и собственно первичный ключ ; это позволяет создавать рекурсивные структуры.
Внешний ключ может быть связан не только с первичным ключом другой таблицы. Он может быть определен и для столбцов с ограничением UNIQUE второй таблицы или любых других столбцов, но таблицы должны находиться в одной базе данных.
Столбцы внешнего ключа могут содержать значение NULL , однако проверка на ограничение FOREIGN KEY игнорируется. Внешний ключ может быть проиндексирован, тогда сервер будет быстрее отыскивать нужные данные. Внешний ключ определяется как при создании, так и при изменении таблиц .
Ограничение ссылочной целостности задает требование, согласно которому для каждой записи в дочерней таблице должна иметься запись в родительской таблице. При этом изменение значения столбца связи в записи родительской таблицы при наличии дочерней записи блокируется, равно как и удаление родительской записи (запрет каскадного изменения и удаления), что гарантируется параметрами ON DELETE NO ACTION и ON UPDATE NO ACTION , принятыми по умолчанию. Для разрешения каскадного воздействия следует использовать параметры ON DELETE CASCADE и ON UPDATE CASCADE .
Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:
целостность ссылок
целостность отношений.
Целостность отношений.
Объект реального мира представляется в реляционной базе данных как кортеж некоторого отношения. Требование целостности отношений заключается в следующем:
каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).
Вполне очевидно, что если данное требование не соблюдается (т.е. кортежи в рамках одного отношения не уникальны), то в базе данных может храниться противоречивая информация об одном и том же объекте. Поддержание целостности сущностей обеспечивается средствами системы управления базой данных (СУБД). Это осуществляется с помощью двух ограничений:
при добавлении записей в таблицу проверяется уникальность их первичных ключей
не позволяется изменение значений атрибутов, входящих в первичный ключ.
Целостность ссылок
Сложные объекты реального мира представляются в реляционной базе данных в виде кортежей нескольких нормализованных отношений, связанных между собой. При этом:
Связи между данными отношениями описываются в терминах функциональных зависимостей.
Для отражения функциональных зависимостей между кортежами разных отношений используется дублирование первичного ключа одного отношения (родительского) в другое (дочернее). Атрибуты, представляющие собой копии ключей родительских отношений, называются внешними ключами.
для каждого значения внешнего ключа, появляющегося в дочернем отношении, в родительском отношении должен найтись кортеж с таким же значением первичного ключа.
Пусть, например, даны отношения ОТДЕЛ (N_ОТДЕЛА , ИМЯ_ОТДЕЛА) и СОТРУДНИК (N_СОТРУДНИКА , N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_отдела" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута "N_отдела" , которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует, значение внешнего ключа в отношении СОТРУДНИК считается неопределенным.
Как правило, поддержание целостности ссылок также возлагается на систему управления базой данных.
Существуют две основные стратегии поддержания ссылочной целостности :
RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.
CASCADE (КАСКАДИРОВАТЬ) - разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочернее отношение само может быть родительским для некоторого третьего отношения. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между кортежами родительского и дочернего отношений.
Первичный и внешний ключи
Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:
Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.
Каждое отношение обладает хотя бы одним возможным ключом, поскольку, по меньшей мере, комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.
Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным , его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами .
Различные объекты предметной области, информация о которых хранится в базе данных, всегда взаимосвязаны друг с другом. Такие взаимосвязи отражаются в реляционных базах данных при помощи внешних ключей , связывающих несколько отношений.
Формальное определение.
Пусть дано отношение . Подмножество атрибутовотношениябудем называтьвнешним ключом , если:
Замечание . Внешний ключ, также как и возможный, может быть простым и составным.
Замечание . Внешний ключ должен быть определен на тех же доменах, что и соответствующий первичный ключ родительского отношения.
Замечание . Внешний ключ, как правило, не обладает свойством уникальности . Так и должно быть, т.к. в дочернем отношении может быть несколько кортежей, ссылающихся на один и тот же кортеж родительского отношения. Это, собственно, и дает тип отношения "один-ко-многим".
Замечание . Для внешнего ключа не требуется, чтобы он был компонентом некоторого возможного ключа.
Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:
Отношение – Таблица (иногда Файл), Кортеж – Строка (иногда Запись), Атрибут – Столбец, Поле.
