у вас могут быть и другие команды, позволяющие вам влиять на установку индексов. Например, опции индексации, предусмотренные в Transact-SQL (FILLFACTOR, MAX ROWS PER PAGE), позволяют вам управлять величиной заполнения каждой страницы нового индекса. Это значение влияет на производительность из-за времени, которое требуется системе на разбивку индексных страниц, когда они заполняются на 100 процентов.

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

Недостатком малых значений коэффициента заполнения (FILLFACTOR) является то, что каждый индекс занимает больше места в памяти, что снижает общую производительность системы.

ЦЕЛОСТНОСТЬ ДАННЫХ

в широком смысле, целостность данных означает точность и непротиворечивость данных в базе данных. В идеале, в программном обеспечении базы данных должен быть предусмотрен ряд механизмов для проверки целостности данных; к сожалению, несколько важных типов целостности не поддерживаются большинством реляционных систем.

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

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

Тремя другими видами целостности, которые обсуждаются в этом разделе, являются:

Офаничения на домен

целостность объекта

ссылочная целостность

Ограничения на домен

Домен (domain) представляет собой совокупность логически связанных значений, из которой может быть получено значение в определенном столбце. Вот несколько примеров доменов в базе данных bookbiz.

Доменом столбца authors.auid являются все коды социального сфахования, вьщаваемые правительством США.

Доменом столбцов authors.city и publishers.city являются все города США, а для столбцов authors.state и publishers.state - все штаты США. (Мы предполагаем, что все авторы проживают в США.)

Доменом titles.type является следующая совокупность значений: business, popular comp, psychology, mod cook и trad cook.

Доменом titles.title id является совокупность значений со следующим форматом: первые два символа - прописные буквы алфавита из набора BU, PC, PS, МС, ТС; следующие четыре символа - цифры от О до 9 включительно.

Доменом titleauthors.royaltyshare являются все значения в интервале от О до 1 включительно.

Обратите внимание на разные виды логических взаимосвязей между значениями в этих доменах. Некоторые из доменов представляют офаничения, определенные в приложениях, - т.е. правила и нормы бизнеса. Например, офаничения на формат чисел идентификатора названия были определены кем-то в издательской компании. Там же, наверное, решили, что цена на книги не может быть меньше $1.99 и больше $99.99; таким образом, цены в долларах и центах, укладывающиеся между этими двумя значениями, и будут представлять собой домен для titles.price.

Другие домены основываются не на бизнес-правилах, а на физических или математических офаничениях. Значения в titleauthors.royaltyshare, например, представляют собой доли, поэтому они должны укладываться в диапазон от О до 1. Другой пример: допустим, издателю потребовалось фиксировать пол каждого автора в базе данных. Домен для этого столбца был бы офаничен человеческой биологией (ее широко распространенными интерпретациями), т.е. значениями мужчина, женщина и неизвестно.

Описания доменов в приведенном выше списке были получены на основе анализа значений в базе данных bookbiz. Для выражения многих из них можно воспользоваться Офаничением CHECK в операторе CREATE TABLE. Transact-SQL поддерживает дополнительный механизм для указания доменов - команду CREATE RULE. Правилом называется именованный объект базы данных, который может быть ассоциирован с любым числом столбцов или со всеми столбцами указанного типа данных. Подобно ограничению CHECK, определение правила может включать любое выражение, которое допускается в предложении WHERE (арифметические операторы, операторы сравнения, LIKE, IN, BETWEEN и т.д.). Эта гибкость в определении правил позволяет вам в качестве основы доменов указывать списки значений (подобно домену для titles.type), диапазоны (подобно домену для titleauthors.royaltyshare) или формат (подобно домену для titles.title Jd).

Механизм правил Transact-SQL офаничен, однако, в том отношении, что определение правил не может содержать ссылку на другой столбец в базе данных. Однако определение правил вне оператора CREATE TABLE удобно для часто меняющихся правил.

И, наконец, последнее замечание. Вспомните материал главы 7, в котором утверждалось, что если значения в двух столбцах имеют одни и те же домены, объединения между этими столбцами обычно являются логически оправданными. Например, authors.city и publishers.city имеют один и тот же домен (все города США); следовательно, имело бы смысл воспользоваться их объединением.

Целостность объекта

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

Офаничение целостности объекта является следствием самой реляционной модели, а не требований какого-либо конкретного приложения. Кроме того, проблема целостности объекта не присуща другим моделям управления базами данных (чего не скажешь о доменных ограничениях). Требование, чтобы ни один из первичных ключей не содержал нулевого значения, основывается на том, что объекты

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

Когда вы проектируете свою базу данных, то должны гарантировать целостность объекта назначением такого первичного ключа, который не будет принимать нулевых значений. Этого можно добиться, использовав ключевое слово NOT NULL в операторе CREATE TABLE и воспользовавшись ограничением PRIMARY KEY или создав для соответствующего столбца уникальный индекс. (Обзор этих понятий приведен в главах 2 и 3.)

Ссылочная целостность

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

Вот определение, данное Коддом: Для каждого отдельного ненулевого значения внешнего ключа в реляционной базе данных должно сушествовать соответствующее значение первичного ключа из того же домена .

В главе 2 поясняется, что взаимосвязи между внешними и первичным ключами устанавливаются в ходе проектирования базы данных; они отражают логические взаимосвязи между данными (хотя их наличие никоим образом не ограничивает возможные пути доступа к данным). При рассмотрении ссылочной целостности вопрос заключается в том, что именно может сделать система базы данных, чтобы гарантировать поддержание соответствия между значениями внешних ключей и значением первичного ключа, на который они указывают (т.е. обеспечить соблюдение ссылочных Офаничений). В главе 3 рассмафивались офаничения REFERENCES и FOREIGN KEY в операторе CREATE TABLE. Эти предложения гарантируют определенную ссылочную целостность - они позволяют вам обеспечить проверки, которые предотвращают добавление внешнего ключа, если он не соответствует первичному ключу. Но это лишь один аспект ссылочной целостности.

Например, изменение идентификатора автора может представлять определенную проблему, поскольку такое изменение нарушило бы связь между таблицами authors, titles и titleauthors. Предложение REFERENCES предотвращает этот вид изменения во внешнем ключе (titleauthors.auid), но не в первичном ключе {authors.au id). Как быть с первичным ключом при изменении идентификатора в таблице authors либо при удалении или изменении идентификатора издателя в таблице publishers, когда книги в таблице titles по-прежнему ссылаются на старый идентификатор? Один из подходов заключается в принятии решения о том, что первичные ключи никогда не должны изменяться, и в предотвращении их изменения.

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

Третья возможность состоит в том, чтобы согласиться с операциями модификации данных в отношении первичного ключа, даже если они нарушают ссылочную целостность, но перед этим изменить значения соответствующих внешних ключей на NULL. (Разумеется, если внешний ключ был определен таким образом, чтобы не принимать нулевых значений, этот подход не сработает.) Воспользуемся приведенным выше примером, слегка видоизменив его: в ответ на команду DELETE, которая удаляет сфоку, соответствующую Algodata Infosystems, из таблицы publishers, значения titles.pubjd для всех книг, опубликованных Algodata, будут установлены в NULL.

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

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