В процессе проектирования базы данных принимается решение о том, какие таблицы должны входить в базу данных, какие у них будут имена (идентификаторы), какие типы данных потребуются для построения таблиц и какие пользователи получат доступ к каждой из них. Кроме того, для эффективного создания таблиц необходимо ответить на следующие вопросы:
- Столбцы какого типа и размера будут составлять каждую из таблиц, какие требуется выбрать имена для столбцов таблиц?
- Какие столбцы могут содержать значение 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 .
«A
table
or
view
can
have
only
one
unique
key
.»
Oracle9i
SQL
Reference
об ограничении использования Ограничений уникальности
Утверждение, представленное в качестве эпиграфа, взято из документации Oracle, но вся практика до прочтения документации указывала на противоположное. Проверка путём создания пары Unique Constraint -ов подтвердила это. Налицо ошибка в документации.
А что ещё (с надеждой на безошибочность описания) можно почерпнуть из документации об Ограничениях целостности в Oracle? Я постарался выписать различные терминологические и функциональные особенности Ограничений целостности как отдельных типов объектов БД Oracle без углубления в синтаксис и подробности их использования. Многое для меня оказалось новым, не буду скрывать.
Начнёмссамогоначала - Oracle9i Database Concepts Release 2 (9.2) . В документации выделяется понятие «Целостность данных» (Data Integrity ), которое связывается с выполнением бизнес-правил, сопряжённых с БД. Data Integrity делится на пять типов правил, часть из которых обеспечивается «Ограничениями целостности» (Integrity Constraints ) СУБД Oracle :
1. NULL -правило - NOT NULL ограничение;
2. уникальные значения - ограничения уникального ключа;
3. значения первичного ключа - ограничения первичного ключа;
4. правила ссылочной целостности - ограничения внешнего ключа (или «ограничения ссылочной целостности» - в документации Oracle встречаются оба названия);
5. проверка комплексного ограничения - Check -ограничения.
(Здесь слева от тире представлено правило «Целостности данных», а справа - тип «Ограничений целостности», реализующий это правило)
Четвёртый тип правил «Целостности данных» является составным, и обеспечивается «Ограничениями целостности» лишь частично:
1. выставление в NULL зависимых данных при удалении справочных данных;
2. каскадное удаление зависимых данных при удалении справочных данных;
3. а также отсутствие какого либо действия над зависимыми данными при изменении или удалении справочных данных. (Здесь для меня осталась неясность в плане отличия Restrict от No Action . Может, кто из читателей поможет обнаружить различие…)
Оставшиеся существующие подтипы четвёртого пункта «Целостности данных»:
o выставление в NULL зависимых данных при изменении справочных данных;
o каскадное изменении зависимых данных при изменении справочных данных;
o выставление в значение по умолчанию зависимых данных при изменении или удалении справочных данных;
Те типы правил «Целостности данных», которые нельзя обеспечить с помощью существующих типов «Ограничений целостности», можно реализовать с помощью триггеров. Впрочем, любые типы правил «Целостности данных» можно организовать посредством триггеров, только этот путь более сложен и менее производителен.
Далее для краткости и в силу привычки буду использовать названия «Ограничений целостности» в английском варианте (соотнесение с вышеупомянутыми русскими названиями, на мой взгляд, очевидно), а вместо «Ограничения целостности» писать просто Ограничения.
Итак, UNIQUE Key Constraint . Это Ограничение требует, чтобы каждое значение в поле ключа было уникальным. Под понятием «значение» здесь подразумевается определённая величина, а NULL-значение под данное определение не подпадает, так что одно, два, да даже все поля в ключе UNIQUE Key Constraint могут быть равны NULL. В отличие от ключа PRIMARY Key Constraint , в котором NULL-значение не допускается вовсе.
При создании UNIQUE Key Constraints или PRIMARY Key Constraints неявно создаётся уникальный индекс по тем полям таблицы, на которые накладывается данное Ограничение. Однако, если некий (неважно - уникальный или неуникальный) индекс по полям ключа уже используется, то будет использоваться именно он вместо неявного создания нового. При удалении этих Ограничений будут удаляться и индексы. Уникальные Ограничения, созданные с атрибутом DEFERRABLE (см. ниже) всегда используют неуникальные индексы. При удалении таких Ограничений неуникальные индексы остаются.
Referential Integrity Constraint требуетсуществованиявродительской (справочной) таблице UNIQUE Key Constraint или PRIMARY Key Constraint. При отсутствии Ограничения NOT NULL на каком либо поле, входящем в Referential Integrity Constraint , в этом поле
допускается NULL -значение, и такой Referential Integrity Constraint будет считаться правильным.
- Если на внешнем ключе отсутствует индекс. Тогда при удалении или изменении первичного ключа родительской таблицы, Oracle будет выставлять блокировку дочерней таблицы на уровне таблицы, освобождая эту блокировку сразу после её получения. Если внешний ключ определён как ON DELETE CASCADE , то удаление записей из родительской таблицы будет приводить к share-subexclusive блокировкам на дочерней таблице. Разделяемая блокировка всей дочерней таблицы также потребуется при изменении тех полей в родительской таблице, на которые ссылаются поля дочерней таблицы. Разделяемая блокировка позволяет только чтение данных, так что ни вставка, ни удаление, ни изменение данных в дочерней таблице не будут доступны до тех пор, пока не завершится транзакция на родительской таблице.
- Если на внешнем ключе присутствует индекс, то никаких блокировок на уровне таблицы уже не будет, и при любом удалении или изменении данных в родительской таблице, в дочерней таблице будут блокированы до завершения транзакции только отдельные соответствующие записи (эксклюзивная блокировка на уровне строк).
CHECK Integrity Constraints . Допускаются на одном или нескольких полях таблицы и требует в качестве результата выполнения определённого условия TRUE или UNKNOWN для каждой строки таблицы. Примечательно, что под UNKNOWN подразумевается… NULL! Иными словами, если везде (во всяком случае, следуя той же документации Oracle) NULL -значение не равно ничему, в том числе и самому себе, то здесь оно «работает» как TRUE . Забавно, не так ли?
Особенности:
- может использоваться только Булево выражение;
- нельзя использовать подзапросы, SQL-функции или последовательности (интересно, почему?);
- нельзя использовать SYSDATE , UID , USE R, USERENV , LEVEL , ROWNUM .
Количество CHECK Integrity Constraints неограниченно, но порядок их срабатывания непредсказуем. Ну, и при использовании строчных литералов или таких SQL -функций, как TO_CHAR, TO_DATE, TO_NUMBER с параметрами поддержки глобализации в качестве аргументов, Oracle использует значения этих параметров по умолчанию на уровне базы. Эти значения можно переписать в создаваемом CHECK Integrity Constraint .
Все перечисленные Ограничения, реализованные в Orac le, допускают их нарушение на уровне оператора, то есть сначала оператор будет полностью выполнен (пускай он коснётся хоть миллиона строк), а потом начнётся проверка Ограничений. Хотя, возможна отложенная проверка Ограничений- до завершения транзакции (о чём речь далее).
Режим SET CONSTRAINTS.
Оператор SET CONSTRAINTS делает Ограничения или DEFERRED , или IMMEDIATE (DEFERRED и IMMEDIATE относятся к атрибутам Ограничений, о чём речь далее) для части транзакции. Данный оператор можно использовать для установки режима либо для списка Ограничений, либо для всех (ALL ) Ограничений. Действие данного оператора заканчивается вместе с завершением текущей транзакции, либо с началом действия ещё одного такого же оператора. Данный оператор недоступен в триггерах.
SET CONSTRAINTS … IMMEDIATE вначале вызывает проверку наличия отложенных ранее срабатываний Ограничений, а потом уже срабатывают Ограничения, вызванные выполняющимися операторами в текущей транзакции. Любое нарушение Ограничения при таком процессе будет просигнализировано ошибкой, а при достижении COMMIT’а будет вызван полный откат текущей транзакции. Оператор ALTER SESSION также может иметь выражение SET CONSTRAINTS , но только для всех Ограничений (нельзя их перечислить списком). Это эквивалентно выполнению оператора SET CONSTRAINTS в самом начале каждой транзакции.
Выполнение оператора SET CONSTRAINTS … IMMEDIATE перед самым завершением транзакции позволяет определить успешность предстоящего COMMIT’а и избежать лишних откатов.
Состояния Ограничений.
С помощью операторов CREATE TABLE или ALTER TABLE можно задавать состояние каждого Ограничения на уровне таблицы, используя следующие выражения:
- ENABLE гарантирует удовлетворение всех входных данных Ограничению;
- DISABLE позволяет входным данным не соответствовать Ограничению;
- VALIDATE гарантирует, что все уже имеющиеся в таблице данные соответствуют Ограничению;
- NOVALIDATE позволяет уже имеющимся в таблице данным не соответствовать Ограничению;
…и их комбинации:
- ENABLE VALIDATE аналогично ENABLE и гарантирует, что абсолютно все (и уже вставленные, и вставляемые) записи удовлетворяют Ограничению;
- ENABLE NOVALIDATE гарантирует удовлетворение Ограничению всех входных данных, однако уже имеющиеся в таблице данные могут не соответствовать Ограничению;
- DISABLE NOVALIDATE аналогично DISABLE . Не гарантируется удовлетворение Ограничению как входных данных, так и уже имеющихся в таблице;
- DISABLE VALIDATE отключает Ограничение, удаляет индекс, на котором оно строилось, и запрещает любые изменения на полях, входящих в Ограничение.
… и немного об особенностях применения:
· выражение ENABLE подразумевает ENABLE VALIDATE ;
· выражение DISABLE подразумевает DISABLE NOVALIDATE ;
· VALIDATE и NOVALIDATE ничего не подразумевают в отношении ENABLE и DISABLE (скажем так, они являются зависимой частью выражения при ENABLE и DISABLE );
· про создание и удаление индексов уже упоминалось;
· при изменении состояния из NOVALIDATE в VALIDATE выполняется проверка всех имеющихся в таблице данных, что может занять очень много времени. Наоборот, при приведении состояния Ограничения из VALIDATE в NOVALIDATE просто «забывается», что имеющиеся данные когда-то соответствовали Ограничению;
· перевод одиночного ограничения из состояния ENABLE NOVALIDATE в состояние ENABLE VALIDATE не блокирует чтения, записи или другие DDL операции, они могут быть выполнены параллельно.
И последние важные замечания.
- При создании Ограничения можно указать в качестве атрибута, возможно ли в дальнейшем в ходе транзакции установить оператором SET CONSTRAINTS (см. выше) отложенную (DEFERRED ) проверку данного Ограничения. По умолчанию выставляется NOT DEFERRABLE (что оно означает, думаю, понятно). После создания Ограничения изменить значение выставленного атрибута нельзя, кроме как пересоздав Ограничение, так что «семь раз подумай»!
- INIT IALLY является дополнительным атрибутом к DEFERRABLE, который может быть переписан оператором SET CONSTRAINT (опять см. выше), и который определяет поведение по умолчанию при срабатывании Ограничения с установленным атрибутом DEFERRABLE. При создании Ограничения по умолчанию выставляется INIT IALLY IMMEDIATE , тогда срабатывание Ограничения будет происходить каждый раз при выполнении отдельного оператора, при выставлении INIT IALLY DEFERRED срабатывание Ограничения будет отложено до окончания каждой транзакции. Для NOT DEFERRABLE такого дополнительного атрибута не требуется, так как он является INIT IALLY IMMEDIATE по определению.
- Выражение RELY. По умолчанию при изменении Ограничения (с помощью ALTER TABLE или MODIFY constraint ) выставляется NORELY . А означает оно следующее: стоит ли Oracle"у принимать в расчёт Ограничение, находящеесяв состоянии NOVALIDATE, для перезаписи запроса? RELY активирует существующее Ограничение в режиме (здесь в документации SQL Reference используется слово «mode », хотя я уже привык к слову «state» из Concepts , - по-видимому, писали разные люди, позабыв договориться о терминах) NOVALIDATE, что позволит переписать запрос, который иначе мог быть переписанным только с Ограничением в режиме VALIDATE. Примерно так. Подробнее - в следующий раз.
- EXCEPTIONS INTO определяет схему и таблицу, в которую будут внесены ROWID, нарушающие Ограничение при изменении его (Ограничения) состояния. Если имя схемы и таблицы не указать, то будет предполагаться, что нужно использовать таблицу с именем EXCEPTIONS в текущей схеме.
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД - это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные .
Целостность сущностей описывается совокупностью ограничений которые должны выполняться для любых отношений в любых реляционных базах данных. Теоретики баз данных формулируют эти ограничения по-разному. Например, в называют «Условиями целостности … будем называть особые, отдельно хранящиеся данные, которыми на концептуальном уровне … представлено … правило (закон, критерий) принадлежности кортежей отношению, представленному этими данными (записями) в базе данных. К уровням целостности базы данных, как правило, присоединяются также спецификации условий принадлежности значений каждого из атрибутов реляционной таблицы к соответствующему ему домену в базе данных».
Из данного определения можем извлечь следующие простые формулировки ограничений:
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.
Это состояние отражается в таблице СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (курсивом выделены ключевые поля).
Ограничения базы данных
Эта статья посвящена ограничениям базы данных InterBase. Ограничения базы данных, - это правила, которые определяют взаимосвязи между таблицами и могут проверять и изменять данные в базе данных Реализованы эти правила в виде особых объектов базы данных.
Главное преимущество использования ограничений состоит в возможности реализовать проверку данных, а значит, и часть бизнес-логики приложения на уровне базы данных, т. е. централизовать и упростить ее, а значит, сделать разработку приложений баз данных проще и надежнее.
Часто начинающие разработчики пренебрегают использованием ограничений базы данных, считая, что они стесняют возможность творчества. Однако на самом деле такое мнение происходит от недостаточного знания теории и практики проектирования баз данных.
В то же время наиболее опытные разработчики позволяют себе отказаться от использования некоторых видов ограничений, за счет чего их приложения выигрывают в быстродействии. Опыт высококвалифицированных разработчиков позволяет им очень хорошо понимать работу сервера и точно предсказывать его поведение в сложных случаях, поэтому начинающим программистам InterBase лучше не апеллировать к подобным действиям опытных коллег.
В рамках данной книги мы не рассматриваем проектирование баз данных, поэтому для получения дополнительной информации по этому вопросу следует обратиться к списку литературы в конце книги. Здесь же мы лишь проведем обзор всех видов ограничений в базе данных InterBase и рассмотрим примеры их применения.
Виды ограничений в базе данных
Существуют следующие виды ограничений в базе данных InterBase:
- первичный ключ - PRIMARY KEY;
- уникальный ключ - UNIQUE KEY;
- внешний ключ - FOREIGN KEY
Может включать автоматические триггеры ON UPDATE и ON DELETE;
- проверки - CHECK.
Ограничения базы данных бывают двух типов - на основе одного поля и на основе нескольких полей таблицы. Синтаксис обоих видов ограничений приведен ниже.
|
|
Для ограничений на основе нескольких полей синтаксис следующий:
|
|
Разница в синтаксисе между ограничениями на основе одного поля и на основе нескольких очевидна - в последних молено указать несколько полей, которые входя i в ограничение. В сд\чае ограничения на основе одного поля все описанные опции относятся только к текущему полю.
Конечно, у этих двух типов ограничений отличается способ их применения: ограничения на основе одного поля просто дописываются к определению нужного поля, а ограничения на основе нескольких полей указываются через запятую в общем определении таблицы. Подробные примеры приведены в следующих разделах этой главы.
Пример типичного ограничения
Фактически ограничения на основе одного поля являются частным сл\чаем ограничений на основе нескольких полей.
Пример создания ограничения первичного ключа с использованием этих двух различных подходов приведен ниже. Давайте создадим таблицу, содержащую только одно поле и наложим на нее ограничение первичного ключа.
Первичный ключ с использованием синтаксиса ограничения на основе одного поля.
Создание ограничений
Давайте рассмотрим создание ограничений подробнее. Первой в описании общего синтаксиса ограничений идет опция . Как видите, эта опция взята в квадратные скобки и, значит, необязательна.
С помощью этой опции можно задавать имя создаваемому ограничению и в случае использования синтаксиса ограничений на основе одного поля, и в случае ограничений на основе нескольких полей.
Если не указать имя для ограничения, InterBase автоматически сгенерирует его. Но лучше все же явно назначить имя создаваемому ограничению, чтобы улучшить читабельность схемы базы данных, а также упростить управление ограничениями в дальнейшем.
Назначив имя ограничению, необходимо определить его тип. Рассмотрим различные типы ограничений в том порядке, как они указаны в описании общего синтаксиса ограничений.
Первичный и уникальный ключи
Первичные ключи являются одним из основных видов ограничений в базе данных. Они применяются для однозначной идентификации записей в таблице. Допустим, мы храним в базе данных список людей. Вполне вероятно, что могут появиться два (или больше) человека с одинаковыми фамилией, именем и отчеством Как же гарантированно отличить одного человека от другого (конечно. речь идет о том, чтобы отличить одного человека от другого на основании информации, хранящейся в базе данных)?
В данном случае "человек" представлен одной записью в таблице, поэтому можно задаться более общим вопросом - как отличить одну запись в (любой) таблице от другой записи в этой же таблице. Для этого используются ограничения - первичные ключи. Первичный ключ представляет собой одно или несколько полей в таблице, сочетание которых уникально для каждой записи. Для одной таблицы не существует повторяющихся значений первичного ключа.
Уникальные ключи несут аналогичную нагрузку - они также служат для однозначной идентификации записей в таблице. Отличие первичных ключей от уникальных состоит в том, что первичный ключ может быть в таблице только один, а уникальных ключей - несколько. Надо отметить, что и первичный и уникальный ключ могут быть использованы в качестве ссылочной основы для внешних ключей (см. далее).
Синтаксис создания первичного и уникального ключа на основе единственного поля следующий:
|
|
Примеры первичных и уникальных ключей:
Синтаксис создания первичного и уникального ключей на основе нескольких полей:
|
|
Такой синтаксис позволяет создавать ключи на основе комбинации полей. Вот примеры создания первичных и уникальных ключей из нескольких полей:
Обратите внимание, что все поля, входящие в состав первичного и уникального ключей, должны быть объявлены как NOT NULL, так как эти ключи не могут иметь неопределенного значения.
Помимо создания ограничения первичных и уникальных ключей в момент создания таблицы имеется возможность добавлять ограничения в уже существующую таблицу. Для этого используется предложение DDL: ALTER TABLE. Синтаксис добавтения ограничений первичного или уникального ключа в существующую таблицу аналогичен описанному выше:
Затем добавляем ключи. Сначала первичный:
Важно отметить, что добавление (а также удаление) ограничений первичных и уникальных ключей к таблице может производить только владелец этой таблицы или системный администратор SYSDBA.
Внешние ключи
Следующим ограничением, которое часто используется в базах данных InterBase, является ограничение внешнего ключа. Это очень мощное средство для поддержания ссылочной целостности в базе данных, которое позволяет не только контролировать наличие правильных ссылок в базе данных, но и автоматически управлять этими ссылками!
Смысл создания внешнего ключа следующий: если две таблицы служат для хранения взаимосвязанной информации, то необходимо гарантировать, чтобы эта взаимосвязь была всегда корректной. Пример - документ "накладная", содержащий общий заголовок (дата, номер накладной и т. д.) и множество подробных записей (наименование товара, количество и т. д.).
Для хранения такого документа в базе данных создается две таблицы - одна для хранения заголовков накладных, а вторая - для хранения содержимого накладной - записей о товарах и их количестве. Такие таблицы называются главной и подчиненной или таблицей-мастером и деталь-таблицей.
Согласно здравому смыслу невозможно существование содержимого накладной без наличия ее заголовка. Другими словами, мы не можем вставлять записи о товарах, не создав заголовок накладной, а также не можем удалять запись заголовка, если существуют записи о товарах.
Для реализации такого поведения таблица заголовка соединяется с таблицей подробностей с помощью ограничения внешнего ключа.
Давайте рассмотрим смысл наложения ограничений внешнего ключа на примере таблиц, содержащих информацию о накладных.
Для этого создадим две таблицы для хранения накладной - таблицу TITLE для хранения заголовка и таблицу INVENTORY для хранения информации о товарах, входящих в накладную.
| CREATE TABLE TITLE( IDJTITLE INTEGER NOT NULL Primary Key, DateNakl DATE, NumNakl INTEGER, NoteNakl VARCHAR(255)); |
Обратите внимание на то, что мы сразу определили первичный ключ в таблице заголовка на основе поля ID_TITLE. Остальные поля таблицы TITLE содержат тривиальную информацию о заголовке накладной - дату, номер, примечание.
Теперь определим таблицу для хранения информации о товарах, входящих в накладную:
| CREATE TABLE INVENTORY( ID_INVENTORY INTEGER NOT NULL PRIMARY KEY, FK_TITLE INTEGER NOT NULL, ProductName VARCHAR (255), Kolvo DOUBLE PRECISION, Positio INTEGER); |
Давайте рассмотрим, какие поля входят в таблицу INVENTORY. Во-первых, это ID_INVENTORY - первичный ключ этой таблицы. Затем идет целочисленное поле FK_TITLE, которое служит для ссылки на идентификатор заголовка ID_TITLE в таблице заголовков накладных. Далее идут поля ProductName, Kolvo и Positio. описывающие наименование товара, его количество и позицию в накладной.
Для нашего примера важнее всего поле FK_TITLE. Если мы захотим вывести информацию о товарах определенной накладной, то нам следует воспользоваться следу ющиУ1 запросом, в котором параметр mas_ID_TITLE определяет идентификатор заголовка:
| SELECT * FROM INVENTORY II WHERE II.FK_TITLE=?mas_ID_TITLE |
В сущности, в описываемой ситуации ничто не мешает заполнить таблицу INVENTORY записями, ссылающимися на несуществующие записи в таблице TITEE. Также ничего не препятствует удалению заголовка уже существующей накладной, в результате чего записи о товарах могут стать "бесхозными".
Сервер не будет препятствовать всем этим вставкам и удалениям. Таким образом, контроль за целостностью данных в базе данных полностью возлагается на клиентское приложение. А ведь с одной базой данных могут работать несколько приложений, разрабатываемых, быть может, разными программистами, что может привести к различной интерпретации данных и к ошибкам.
Поэтому необходимо явно наложить ограничение на то, что в таблиц} INVENTORY могут помещаться лишь такие записи о товарах, которые имеют корректною ССЫЛКУ на заголовок накладной. Собственно это и есть ограничение внешнего ключа, которое позволяет вставлять в поля, входящие в ограничения, только те значения, которые есть в другой таблице.
Такое ограничение можно организовать с помощью внешнего ключа. Для данного примера необходимо наложить ограничения внешнего ключа на поле FK_TITLE и связать его с первичным ключом ID_TITLE в TITEE. Добавить внешний ключ в уже существующую таблицу можно следующей командой:
| ALTER TABLE INVENTORY ADD CONSTRAINT fktitlel FOREIGN KEY(FK_TITLE) REFERENCES TITLE(ID_TITLE) |
Часто при добавлении внешнего ключа возникает ошибка object is in use (объект используется) Дело в ю, что для создания внешнею ключа, необходимо открьпь базу данных в монопольном режиме - чтобы оиювременно не бьпо других пользователей Также нетьзя производить никаких обращений к модифицируемой таблице-это может вызвать object is in use
Здесь INVENTORY - имя таблицы, на которую накладывается ограничение внешнего ключа; fktitlel - имя внешнего ключа; FK_TITLE - поля, составляющие внешний ключ; TITLE - имя таблицы, предоставляющей значения (ссылочную ОСНОВУ) для внешнего ключа; ID_TITLE - поля первичного или уникального ключа в таблице TITLE которые являются ссылочной основой для внешнего ключа.
Полный синтаксис ограничения внешнего ключа (с возможностью создавать ограничения на основании нескольких полей) приведен ниже:
|
|
Как видите, определения содержат большой набор опций. Для начала давайте рассмотрим базовое определение внешнего ключа, которое наиболее часто используется в реальных базах данных, а затем разберем возможные опции.
Чаще всего употребляются декларативная форма ограничения внешнего ключа, когда указывается набор полей (col [, col ...]), которые будут составлять ограничение; таблица other_table, которая содержит в полях [(other_col [, other_col ...]) список возможных значений для внешнего ключа.
Пример такого определения при создании таблицы:
| CREATE TABLE Inventory2( ... FK_TABLE INTEGER NOT NULL CONSTRAINT fkinv REFERENCES TITLE(ID_TITLE) ...) ; |
Обратите внимание, что в этом определении опущены ключевые слова FOREIGN KEY, а также подразумевается, что в качестве внешнего ключа будет использоваться единственное поле - FK_TITLE.
А в следующем примере приведена более полная форма создания внешнего ключа одновременно с таблицей:
| CREATE TABLE Inventory2( ... FK_TABLE INTEGER NOT NULL, CONSTRAINT fkinv FOREIGN KEY (FKJTABLE) REFERENCES TITLE(IDJTITLE) ...) ; |
Использование NULL в полях внешнего ключа
В полях, на основе которых создается внешний ключ, допускается применение NULL-полей. Эта возможность добавлена для разрешения взаимных ссылок. Например, еспи есть две таблицы, ссылающиеся друг на друга с помощью внешних ключей Ьсли не разрешить пустую ссылку (т. е. на NULL) в этих внешних ключах, то в связанные таблицы невозможно будет добавить ни одной записи: чтобы добавить запись в первую таблицу, надо будет иметь запись во второй таблице, и наоборот.
Использование NULL в качестве пустой ссылки позволяет организовать взаимные ссылки двух перекрестно ссылающихся таблиц, а также хранить иерархические структуры в реляционных таблицах - при этом корневые узлы ссылаются на "п\стые" записи (т. е. просто содержат NULL).
Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа
Обычно вполне достаточно декларативного варианта ограничения внешнего ключа, при котором сервер только следит за тем, чтобы в таблицу с внешним ключом нельзя было вставить некорректные значения или - при попытке сделать это возникает ошибка. Но InterBase позволяет выполнять ряд автоматических действий при изменении/удалении внешнего ключа. Для этого служит следующий набор опций внешнего ключа:
| SET NULL}] |
Эти опции позволяют определить различные действия при изменении или удалении значения внешнего ключа.
Например, мы можем указать, что при удалении первичного ключа в таблице-мастере необходимо удалять все записи с таким же внешним ключом в подчиненной таблице. Для этого следует так определить внешний ключ:
| ALTER TABLE INVENTORY ADD CONSTRAINT fkautodel FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE) ON DELETE CASCADE |
Фактически для реализации этих действий создается системный триггер, который и выполняет определенные действия. В табл. 1.2 приведено описание происходящих действий при различных опциях (обратите внимание, что опции NO ACTION|CASCADE|SET DEFAULT|SET NULL не могут использоваться совместно в одном предложении ON XXX).
|
Действие |
||||
|
При удалении внешнего ключа ничего не делать - используется по умолчанию |
При удалении удалить все связанные записи из подчиненной таблицы |
При изменении установить поле внешнего ключа в значение по умолчанию |
При изменении установить поле внешнего ключа в NULL |
|
|
При изменении ничего не делать - используется по умолчанию |
При изменении записи изменить во всех связанных записях в подчиненных таблицах |
При удалении установить поле внешнего ключа в значение по умолчанию |
При удалении установить поле внешнего ключа в NULL |
|
Если мы ничего не указываем или указываем NO ACTION, то необходимо позаботиться об изменении внешнего ключа (в случае изменения первичного) самостоятельно, а при удалении первичного ключа предварительно удалить записи из подчиненной таблицы.
Осторожно надо обращаться с опцией CASCADE: неосторожное ее использование может привести к удалению большого количества связанных записей.
Ограничение CHECK
Одним из наиболее полезных ограничений в базе данных является ограничение проверки. Идея его очень проста - проверять вставляемое в таблицу значение на какое-либо условие и, в зависимости от выполнения условия, вставлять или не вставлять данные.
Синтаксисегодостаточнопрост:
|
|
Здесь constraint - имя ограничения;
Самый простой пример проверки:
| create table checktst( ID integer CHECK(ID>0)); |
Эта проверка устанавливает, больше ли нуля вставляемое/изменяемое значение поля ID, и в зависимости от результата позволяет вставить/изменить новое значение или возбудить исключение (см. главу "Расширенные возможности языка хранимых процедур InterBase" (ч. 1)).
Возможны и более сложные варианты проверок. Полный синтаксис условия поиска
|
|
Таким образом, CHECK предоставляет большой набор опций для проверки вставляемых/изменяемых значений. Необходимо помнить о следующих ограничениях в использовании СНЕК:
Данные в CHECK берутся только из текущей записи. Не следует брать данные для выражения в CHECK из других записей этой же таблицы - они могут быть изменены другими пользователями.
Поле может иметь только одно ограничение CHECK.
Если для описания поля использовался домен, который имеет доменное ограничение CHECK, то его нельзя переопределить на уровне конкретного поля в таблице.
Надо сказать, что CHECK реализованы при помощи системных триггеров, поэтому следует быть осторожным в использовании очень больших условий, которые могут сильно замедлить процессы вставки и обновления записей.
Удаление ограничений
Часто приходится удалять различные ограничения по самым разным причинам. Чтобы удалить ограничение, необходимо воспользоваться предложением ALTER TABLE следующего вида:
| ALTER TABLE cablename DROP CONSTRAINT constraintname |
где constraintname - имя ограничения, которое следует удалять. Если при создании ограничения было задано какое-то имя, то следует им воспользоваться, а если нет, то надо открыть какое-либо средство администрирования InterBase, поискать все связанные с ним ограничения и выяснить, какое системное имя сгенерировал InterBase для искомого ограничения.
Надо отметить, что удалять ограничения может только владелец таблицы или системный администратор SYSDBA.
Проблема целостности состоит в обеспечении правильности данных в БД в любой момент времени. Целостность данных обеспечивается набором специальных условий или утверждений, называемых ограничениями целостности. Ограничения целостности - это утверждение о допустимости значений отдельных информационных единиц и связей между ними. Ограничения целостности (ОЦ) определяются в большинстве случаев особенностями ПО, хотя могут отражать и чисто информационные характеристики.
ОЦ могут относиться к разным информационным единицам: атрибутам (полям), кортежам (строкам, записям), отношениям (таблицам, файлам), связям между отношениями и т.п.
Для полей чаще всего используются следующие виды ограничений.
1. Тип и формат поля.
2. Задание диапазона значений. Значения диапазона и его тип зависят от особенностей ПО.
3. Признак непустого поля. Характеризует недопустимость пустого значения поля в БД. Например, в отношении, содержащем сведения о сотрудниках, поля “фамилия”, ”имя”, ”отчество”, ”оклад” должны обязательно иметь какое-то значение, а у поля “ученая степень” значение может отсутствовать.
4. Задание домена. Поле может принимать значение из заданного множества значений. Например, значением поля “пол” может быть только либо “мужской”, либо “женский”. Значением поля “должность” для профессорско-преподавательского состава может быть одно из следующих значений: “ассистент”, “старший преподаватель”, “доцент”, “профессор”. Домен необязательно должен определяться перечислением входящих в него значений.
Как всякая классификация, приведенная выше классификация видов ограничений является условной. Кроме того, домен может определяться и алгоритмически. Например, многие СУБД поддерживают тип поля “ДАТА” и при вводе значений обеспечивают автоматическую проверку на допустимость введенной даты. Поэтому для поддержания целостности данных важно знать о возможностях СУБД и правильно выбрать тип поля.
Специфическим ограничением на значение поля является признак его уникальности. Это ограничение проверяет допустимость значения данного поля, но при этом просматривается вся таблица (файл).
Признак уникальности значения тесно связан с понятием ключа, но уже первичного, так как ключ может быть представлен не только одним полем, а быть составным. Уникальное поле является возможным ключом данного отношения. При наличии нескольких возможных ключей один из них должен быть выбран в качестве первичного ключа. Это поле не должно иметь пустое значение. Не все СУБД поддерживают концепцию ключа и требуют определять его при описании БД.
Рассматриваемое ограничение чаще всего возникает при отображении в БД каких-то объектов, и уникальное поле является идентификатором объекта. Поэтому оно часто называется ограничением целостности объекта.
Рассмотренные выше ограничения определяли проверку значения поля вне зависимости от того, вводится ли это значение впервые или корректируются имеющиеся в БД значения. Ограничения, которые используются только при проверке допустимости корректировки, называются ограничениями перехода. Например, если в БД имеется поле “возраст сотрудника”, то при корректировке значение этого поля может только увеличиваться. Если в БД хранится поле “год рождения”, то при корректировать это поле следует запретить.
Когда речь идет об ограничениях целостности, относящихся к кортежу, то имеется в виду либо ограничение на значение всей строки, рассматриваемой как единое целое, либо ограничения на соотношения значений отдельных полей в пределах одной строки. Так, естественным ограничением является требование уникальности каждой строки таблицы. По определению в реляционном отношении не может быть одинаковых кортежей, но не все реляционные СУБД обеспечивают соблюдение этого ограничения. В качестве ограничения на соотношения значений полей внутри одного кортежа можно привести следующее: в БД подсистеме “Абитуриент” кортеж (строка) содержит атрибуты (поля) с оценками за экзамены и поле с максимальной оценкой, которое всегда должно отражать правильное значение.
В качестве примера ограничений, относящихся ко всей таблице, можно привести следующий. Предположим, что фонд заработной платы формируется исходя из величины средней зарплаты одного сотрудника и эта величина равна N руб. Тогда в качестве ограничения целостности таблицы может быть задано условие, указывающее, что среднее значение поля “оклад” должно быть не больше N. Примерами ограничения целостности, которыми проверяют соотношения между строками одной таблицы, являются следующие: 1) нельзя быть родителем и ребенком одного и того же человека; 2) год рождения родителя должен быть меньше, чем год рождения ребенка. Первый из приведенных примеров является частным случаем более общего ограничения на отсутствие циклов.
К аналогичным ограничениям относятся ограничения на отсутствие циклов при определении состава изделия (узел не может входить сам в себя), при описании организационной структуры и во многих других случаях. Если СУБД не позволяет контролировать подобные ограничения целостности, то следует напивать процедуру, позволяющую делать это.
Все ограничения, которые были рассмотрены ранее, затрагивали информационные единицы в пределах одной таблицы. Кроме такого рода ограничений часто используются ограничения, затрагивающие несколько взаимосвязанных таблиц. Наиболее часто встречающееся из этих ограничений - ограничение целостности связи. Оно выражается в том, что значение атрибута, отражающего связи между объектами и являющегося внешним (вторичным) ключом отношения, обязательно должно совпадать с одним из значений атрибута, являющегося первичным ключом отношения, описывающего соответствующий объект.
Разновидностью ограничения целостности связи является ограничение связи по существованию, заключающееся в том, что для существования объекта в отношении R1 необходимо, чтобы он был связан с объектом в отношении R2. Например, при приеме на работу каждый из работающих должен быть зачислен в какой-то отдел, и соответствующая запись в таблице “Кадры” в поле “отдел” должна иметь значение, совпадающее с одним из значений соответствующего поля в таблице “Отделы”.
Кроме того, ограничения, отражающие связь таблиц могут представлять собой условия, проверяющие отсутствие логических противоречий между данными во взаимосвязанных таблицах. Например, если для каждой должности установлена определенная “вилка” оклада, то значение поля “оклад” в таблице “Кадры” не должно выходить за пределы “вилки”, которая зафиксирована в таблице “Должности”.
Своеобразным видом ограничений целостности является запрет на обновление. Он может быть обусловлен технологией обработки данных или спецификой ПО. Так, если описывается объект “Личность”, то такие атрибуты, как дата рождения и место рождения, являются постоянными (статическими) и меняться не могут.
По моменту контроля за соблюдением ограничений целостности различают безотлагательные (одномоментные) и отложенные ограничения целостности. Отложенные ограничения целостности могут не соблюдаться в процессе выполнения какой-то группы операций, но обязаны быть соблюдены по завершению выполнения этой группы операций. С понятием отложенного ограничения целостности тесно связано понятие транзакции.
Очень важным видом ограничений целостности являются функциональные зависимости. Информация об имеющихся в данной ПО функциональных зависимостях фиксируется в ИЛМ и используется при проектировании БД и для контроля целостности при функционировании БД. Для соответствующих полей в БД желательно задать запрет на обновление.
Запрет на обновление может относиться не только к отдельному полю, но и ко всей строке (записи) и к таблице.
Рассмотрим пример ограничения на обновление строки (записи). Пусть в БД по кадровому составу для каждого из сотрудников хранятся сведения о поощрениях. Эта информация хранится в таблице “Поощрения”, имеющей такие атрибуты (поля): табельный номер сотрудника, вид поощрения, дата. В эту таблицу могут добавляться строки, но каждая отдельная запись изменяться не может.
В этом примере наблюдается также ограничение связи по существованию между таблицами “Поощрения” и “Сотрудники”: табельный номер в таблице “Поощрения” должен обязательно присутствовать в таблице “Сотрудники”; при удалении строки из таблицы “Сотрудники” все связанные с ней строки в таблице “Поощрения” должны быть также удалены.
Некоторые СУБД позволяют при описании данных задавать так называемое обязательное членство для включения и каскадное удаление. В этом случае целостность при корректировке будет обеспечиваться системой автоматически и гарантируется ограничение связи по существованию.
СУБД FoxPro обеспечивает целостность при корректировке, если предусмотрена соответствующая связь таблиц в БД с помощью SET Relation и SET SKIP.
Для автоматического контроля целостности эта информация должна быть зафиксирована в машинном словаре данных. Для контроля целостности при выполнении операций реляционной алгебры по меньшей мере должна быть зафиксирована информация о ключах и возможных ключах отношений.
По способу задания ограничения целостности могут быть явными и неявными. Неявные ограничения целостности определяются спецификой модели данных и проверяются СУБД автоматически.
Рассмотренные выше примеры ограничений целостности относились к данным пользователя. Понятие целостности может относиться и к служебной информации. Это прежде всего относится к поддержанию соответствия между индексными файлами и соответствующими им индексируемыми файлами БД.
Наряду с понятием целостности БД может быть введено понятие информационной целостности банка данных, заключающееся в обеспечении правильности взаимосвязи всех его информационных компонентов (файлов БД, программных файлов, описаний форм ввода-вывода, отчетов). Например, если для файла БД имеется связанная с ним форма отчета, то при удалении из файла поля, вывод которого предусмотрен в этой форме, возникает ошибка при выводе отчета. Нарушения целостности могут возникнуть, если изменяется тип данных, хранящихся в поле, и во многих других случаях.
Некоторые СУБД имеют специальный механизм, позволяющий отслеживать согласованность различных информационных компонентов банка данных. Например, в системе Paradox имеется понятие “семейство”, включающее в себя файлы БД и относящиеся к ним индексы, отчеты, формы и т.п. Для отслеживания взаимосвязи между всеми информационными компонентами БнД должны использоваться словари данных.
Задание ограничений целостности и их проверка являются важной частью проектирования и функционирования БнД.
Ограничения целостности, присущие той или иной ПО, должны быть выявлены при обследовании и зафиксированы в ИЛМ. Вопрос о необходимости проверки ОЦ при функционировании БнД должен решаться на основе анализа эффективности проекта, так как в некоторых случаях для реализации проверки ОЦ требуются значительные затраты времени.
ОЦ в БнД могут задаваться либо при описании структуры таблиц БД (т.е. в схеме БД), либо в программах обработки данных. Первый подход предпочтительнее и не только потому, что описательный (декларативный) способ задания ОЦ представляет собой более высокий уровень контроля, но и потому, что заданные ограничения будут контролироваться при выполнении всех операций над данными.
Разные СУБД обладают различным набором средств для обеспечения целостности данных. Так, некоторые РСУБД поддерживают концепцию ключа, домена и внешнего ключа. При этом соответствующие проверки ОЦ выполняются автоматически. В некоторых системах при описании структуры БД для поля можно задать запрет содержать пустое значение (понятие NOT NULL), можно определить диапазон допустимых значений и другие ОЦ.
При проектировании БнД необходимо изучит, какие возможности по контролю целостности предоставляет используемая СУБД. Если СУБД автоматически не поддерживает нужное ограничение, то обеспечение его соблюдения становится заботой проектировщика.
