Изменить значение области по умолчанию можно с помощью предложения:

ALTER DOMAIN MoveDomain SET DEFAULT no such tit e:

В результате значение по умолчанию unknown, введенное для MovieOomafn в примере 5,35, заменяется строкой по such title. 1У1ожно внести и другие изменения, например касающиеся ограничений области, которые рассматриваются в главе 6. Определение области удаляется с помощью предложения:

DROP DOMAIN MovieDomain;

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

5-7.7 Индексы

Индекс атрибута А это структура данных, обеспечивающая эффективный поиск кортежей, имеющих фиксированное значение для атрибута А. Индексы, как правило, полезны в запросах, в которых атрибут А сравнивается с константой, например /4 = 3 или даже /} s 3. При очень большом отношетши накладно сканировать все его кортежи в поиске (возможно, очень малого числа) кортежей, удовлетворяющих заданному условию.

Рассмотрим первый запрос из примера 5.1;

SELECT * FROM Movie

WHERE StudioName =Disney AND year =1990;

Здесь может быть 10 тыс. кортежей Movie, из которых только 200 фильмов выпущено в 1990 г.

Примитивный способ обработки этого запроса состоит в проверке условия пункта WHERE на каждом из 10 тыс. кортежей. Гораздо эффективнее как-нибудь найти ЭОО кортежей, относящихся к 1990 г., а затем проверить, есть ли в них студия Disney. Еше лучше - сразу найти только десяток кортежей, удовлетворяющих обоим условиям пункта WHERE, ио это уже превышает возможности обычных структур данных.

Хотя создание индексов не предусмотрено ни одним стандартом SQL, вютючая SQL2, в большинстве коммерческих систем разрабогчики БД имеют возможность задать системе операцию создания индекса для конкретного атрибута из определенного отношения. Обычно для этого применяется следующий синтаксис. Предложение-

CREATE INDEX Yearlndex ON Movie(yaar);

создает индекс с именем Yearlndex на атрибуте year из отношения Movie. В дальнейшем процессор запросов SQL может обрабатывать запросы относительно года так, что будут проверяться только те кортежи отношения Movie, в которых есть указанный год. В результате сокращается время, необходимое для получения ответа на запрос.

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

Пример 5.36. Еслн title и year образуют ключ шш Mov\e, значит, либо определены значения обоих эт1!\ атрибутов, либо не определено ни одно нз нн.х. Типичное описание индекса этих атрибутов:

CREATE INDEX Keylndex ON Movie(title. year);

Поскольку (title year) - ключ., при заданных названии и голе выпчска фильма индекс у1сажет единсзвенный требуемый кортеж. Напротив, еслн запрос определяет н год, и название, ио при эзом дост>псн ли1иь индекс Yearlndex. система может найти только все фильмы за.аанного года выпуска, а затем искать среди них нужное название.

Лучше иметь индекс на одном атрибуте title, чем на одном атр[буте yesr, так как обыч1ю в один год выпускается множество фильмов, а фильмы с одинаковым названием встречаются крайне редко. В данном примере поиск всех заданных названии фильмов с последующей их проверкой по заданному году требует не намного больше времени, чем применение многоатрибутного индекса для title и year. □

Дпя улал1>1ия индекса досгаточно поястаа1ггь его имя в предложение

DROP INDEX Yearlndex При выборе индексов нужно соблюдать 01феделенный баланс.

С одной стороны, сушествова1Н1е индекса иа атрибуте обычно увеличивает скорость выполнения запросов, определяющих значение этого атриб>та.

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

Выбор индексов - один из самых трудных эяеменгов проектирования БД, так как при этом требуется определить, какими будут типичные множества запросов и другие операции на БД. Как правило, имеет смысл строить индексы тогда, когда к отношению чвще применяются запросы, чем изменения. Если же доминируют изменения, к созданию индексов следует подходить осторожно. Однако даже индерсс часто изменяющегося атрибута может быть эффективным. Поскольку некоторые команды изменения включают в себя запросы (напри.мер, INSERT с подзапросом типа select-from-wliere или DELETE с условием), н-жно внимательно следить за относительной частотой изменений и запросов.

5-7-8 Упражнения к разделу 5-7

Упражнение 5.7.1. В этом разделе дано формальное описание только отношения MovieStar. Дайте подходящие описания остальных четырех отношений:

Movie(title, year, length, inColor. studioNeme. producerC#) Starsln(movieTille. movieYear, starName) fi<ovieExec(name, address. cert#. netWorth) Studio(name, address, presC#)

Цпрожненнс 5.7.2. Используя неформальные схемы БД из упражнения 4.1.1

Product(maker. model, type) PC(nnodel, speed, ram, hd cd, price) Laptop(model, speed, ram. hd, screen price) Printer(model. color, type, price)

5.8 Определения пользовательских представлений 239

дайте описания:

a) схемы отношений ProducI;

b) схемы отношения РС; с) схемы отношения Laptop;

с1) схемы отношения Printer;

e) определения области ModelType, значениями которой валяются номера моделей; покажите, как применить эт; область в схемах fa) - (d);

*f) изменения схемы <с), состояшсго в добавлении атрибута cd; если ПК-блокнот не имеет считывающего устройства CD, используйте для этого атрибута значение по умолчанию попе;

g) изменения схемы (d), состоящего в удалении атрибута color.

Упрожнение 5.7.3. Используя неформальные схемы БД из упражнения 4.1.3

Classes(class, type, country, numGuns, bore, displacement) Ships(name, class, launched) Battles(name, date) Outcomes(ship, battle, result)

дайте описания:

a) схемы отношения Classes;

b) схемы отно1пения Ships;

c) схемы отношения Battles:

d) схемы отношения Outcomes;

с) определения области ShIpNames, применимой н к кораблям, и к именам классов; покажите, как применить эту область в схемах (а), (Ь) и (с);

f) изменения счеыы (Ь), состоящего в добавлении атрибута yard, обозначающего док, в котором был построен корабль;

g) изменения схемы (а), состоящего в удалении атрибута bore.

! Упрожнение 5.7.4. Объясните разницу между предложениялт DROP R

DELETE FROM R.

5.8 Определения

пользовательских представлений

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

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