Язык определения данных

где

<изменение> ::= {| TO новое_имя_столбца | TYPE {<тип данных> | имя_домена} | POSITION номер_позиции | SET DEFAULT <значение> | DROP DEFAULT}.

При использовании конструкции 

ADD <определение_столбца>

в таблицу будет добавлен новый столбец, определенный в соответствии с конструкцией <определение_столбца>, так же как при создании таблицы.

Использование конструкции

ADD <тип_ограничения>

приводит к добавлению в таблицу ограничения, определяемого  конструкцией <тип_ограничения>, так  же как при создании таблицы.

Например, чтобы добавить столбец с именем memo в таблицу Request, необходимо выполнить следующий  запрос ALTER TABLE:

ALTER TABLE Request ADD memo VARCHAR(100);.

Чтобы для таблицы Request определить ограничения внешних ключей, можно  выполнить следующие запросы ALTER TABLE:

ALTER TABLE Request ADD FOREIGN KEY (AccountCD) REFERENCES Abonent(AccountCD);

ALTER TABLE Request ADD FOREIGN KEY (ExecutorCD) REFERENCES Executor(ExecutorCD);

ALTER TABLE Request ADD FOREIGN KEY (FailureCD) REFERENCES Disrepair (FailureCD);.

Однако можно добавить эти внешние ключи для таблицы Request и с помощью одного запроса:

ALTER TABLE Request ADD FOREIGN KEY (AccountCD) REFERENCES Abonent(AccountCD), ADD FOREIGN KEY (ExecutorCD) REFERENCES Executor (ExecutorCD), ADD FOREIGN KEY (FailureCD) REFERENCES Disrepair (FailureCD);.

Конструкция

ALTER столбец TO новое_имя_столбца

используется для переименования столбца. Например, можно изменить имя  столбца Phone в таблице Abonent следующим  образом:

ALTER TABLE Abonent ALTER Phone TO HomePhone;.

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

Конструкция

ALTER столбец TYPE {<тип данных> | имя_домена}

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

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

ALTER TABLE Abonent ALTER Phone Type varchar (10);,

то будет выдано сообщение "New size specified for column PHONE must be at least 15 characters" (новый размер, определяемый для столбца PHONE, должен быть не менее 15 символов);

•  в СУБД Firebird преобразование числового типа данных в строковый тип требует минимального размера строкового типа, как показано в табл. 4.1;

•  преобразование символьных данных в другие типы недопустимо.

Таблица 4.1. Минимальное количество символов для числовых преобразований

Тип данных	Минимальная длина  символьного типа
BIGINT	19 (или 20 для чисел со  знаком)
DECIMAL	20
DOUBLE	22
FLOAT	13
INTEGER	10 (11 для чисел со знаком)
NUMERIC	20 (или 21 для чисел со  знаком)
SMALLINT	6

Конструкция

ALTER столбец POSITION номер_позиции

используется для изменения  порядкового номера столбца в  таблице.

Конструкция

ALTER столбец SET DEFAULT <значение>

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

Конструкция

ALTER столбец DROP DEFAULT

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

Рассмотрим на примере  изменение и удаление значений по умолчанию для столбцов. Допустим, что в созданную ранее (в пункте 4.2.1) таблицу Days добавлена строка, где number = 1, а остальные значения берутся  по умолчанию. В результате таблица  будет иметь вид, представленный на рис. 4.1.

NUMBER	DAT	EVENT	USR	TEL
1	01.09.1996	<null>	SYSDBA	111111

Рис. 4.1. Таблица Days до изменения значений по умолчанию

Например, с помощью следующего запроса удалим в таблице Days значение по умолчанию столбца dat, изменим  значение по умолчанию столбца usr на Petrov, а значение по умолчанию столбца tel, взятое из домена Telephone, с '111111' на '999999':

ALTER TABLE Days ALTER dat DROP DEFAULT, ALTER usr SET DEFAULT 'Petrov', ALTER tel SET DEFAULT '999999';.

После добавления второй строки со значениями по умолчанию таблица Days примет вид, представленный на рис. 4.2.

NUMBER	DAT	EVENT	USR	TEL
1	01.09.1996	<null>	SYSDBA	111111
1	<null>	<null>	Petrov	999999

Рис. 4.2. Таблица Days после изменения и вставки

Конструкция

DROP столбец

используется для удаления существующего столбца таблицы. Удаление столбца запросом ALTER TABLE может  завершиться неудачей в следующих  случаях:

•  удаляемый столбец является частью ограничений UNIQUE, PRIMARY KEY или FOREIGN KEY;

•  удаляемый столбец используется в предложении CHECK;

•  удаляемый столбец является частью выражения, например, в конструкции COMPUTED [BY] (<выражение>) (при создании таблицы);

•  на удаляемый столбец ссылается другой объект БД, например представление.

Удаление ограничения  таблицы производится при использовании  предложения DROP CONSTRAINT запроса ALTER TABLE с  указанием имени ограничения. Если при создании таблицы (CREATE TABLE) или  изменении ее определения (ALTER TABLE) не задавалось имя ограничения, то удаление такого ограничения становится невозможным.

Например, чтобы удалить  ограничение, наложенное на таблицу  и имеющее имя Abonent_not_as_Executor, необходимо воспользоваться следующим запросом:

ALTER TABLE Abonent DROP CONSTRAINT Abonent_not_as_Executor;.

4.3. Индексы

Одним из структурных элементов  физической памяти, присутствующим в  большинстве современных реляционных  СУБД, является индекс. Индекс - это  средство, обеспечивающее быстрый доступ к строкам таблицы на основе значений одного или нескольких ее столбцов [19, 23].

В индексе хранятся значения данных и указатели на строки, где  эти данные встречаются. При выполнении запроса СУБД сначала определяет список индексов, связанных с данной таблицей. Затем устанавливает, что  является более эффективным, просмотреть  всю таблицу или для обработки  запроса использовать существующий индекс. Если СУБД решает использовать индекс, то поиск ведется сначала  по ключевым значениям в индексе, а затем, используя указатели, осуществляется просмотр самих таблиц для дополнительной фильтрации и окончательной выборки  требуемых данных.

Поиск осуществляется достаточно быстро, поскольку значения в индексе  упорядочены (в убывающем или  возрастающем порядке), а сам индекс относительно невелик. Это позволяет  найти ключевое значение. Как только ключевое значение найдено, по указателю  определяется физическое местоположение связанных с ним данных.

Использование индекса обычно требует меньшего количества обращений  к диску, чем последовательное чтение строк в таблице.

Тем не менее, индексирование оправданно далеко не всегда. Следует  помнить, что при всяком обновлении данных должны обновляться и индексы.

Таким образом, платой за быстрый  поиск является увеличение затрат времени  на обновление данных. Кроме того, сами индексы после большого числа  обновлений становятся несбалансированными, вследствие чего время поиска по ним  возрастает.

В этих условиях при проектировании БД необходимо находить компромисс между  требованиями по ускорению поиска данных и по скорости их обновления. Использование  индексов, например, для небольших  по объему таблиц вообще не оправданно. Если имеется индекс по группе полей, то поиск по первому из полей группы может прямо использовать этот индекс, следовательно, нет смысла делать по нему отдельный индекс. Если поиск  по каким-либо полям редок, то построение по ним индекса неэффективно.

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

Можно сказать, что оптимальный  выбор состава и количества индексов зависит и от структуры БД, и  от характера ее использования.

В СУБД Firebird автоматически  создаются индексы по первичным, внешним ключам таблиц и UNIQUE-ограничениям и их дополнительно создавать  не нужно. Такие индексы для ограничений  без имени по умолчанию имеют  название наподобие RDB$PRIMARY8, RDB$FOREIGN13, RDB$10 и т.д., а для ограничений с  именем название индекса совпадает  с названием ограничения. Данные в таких индексах по умолчанию  располагаются в возрастающем порядке.

Рекомендуется создавать  индекс для столбцов, которые часто  используются в условиях поиска. В SQL индекс для таких столбцов создается  запросом CREATE INDEX , который имеет  следующий формат:

CREATE [UNIQUE] [ASC | DESC] INDEX имя_индекса  ON базовая_таблица {(<список_столбцов>) | COMPUTED BY (<выражение>)};,

где

- имя_индекса, задает имя,  под которым создаваемый индекс  будет определен в БД;

- базовая_таблица и список_столбцов, определяют соответственно базовую  таблицу и индексируемые столбцы  (столбец).

Необязательные параметры  запроса CREATE INDEX:

•  UNIQUE, предотвращает вставку или обновление повторяющихся значений в индексируемые столбцы;

•  ASC, сортирует столбцы в возрастающем порядке (используется по умолчанию);

•  DESC, сортирует столбцы в убывающем порядке.

Например, для создания отсортированного по убыванию индекса с именем Month_Index по полю NachislMonth таблицы NachislSumma необходимо применить следующий запрос:

CREATE DESC INDEX Month_Index ON NachislSumma (NachislMonth);.

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

CREATE INDEX Address_Index ON Abonent (StreetCD, HouseNO);.

Результатом выполнения данного  запроса будет создание отсортированного по возрастанию индекса Address_Index, который  обеспечит ускорение поиска и  сортировки по адресу абонента.

Существует возможность  проиндексировать выражения, часто  применяемые в запросах. Индекс для  выражения создается с помощью  следующей конструкции:

COMPUTED BY (<выражение>).

Например, можно создать  индекс для таблицы Request по выражению, извлекающему значение месяца из столбца IncomingDate, с помощью следующего запроса:

CREATE INDEX Ind_1 ON Request

COMPUTED BY (EXTRACT(MONTH FROM IncomingDate));.

Данный индекс будет доступен для любого запроса с поиском  или сортировкой, если они включают выражение EXTRACT (MONTH FROM IncomingDate).

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

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

[USING [ASC[ENDING] | DESC[ENDING]] INDEX имя_индекса].

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

Например, определим в  ранее созданной таблице Days поле number как первичный ключ, задав  для связанного с ним индекса  имя PK_NUMBER и порядок данных по убыванию:

ALTER TABLE Days ADD PRIMARY KEY (number)

USING DESC INDEX PK_NUMBER;.

При изменении порядка  сортировки данных в индексах следует  помнить, что FOREIGN KEY и соответствующий  ему PRIMARY KEY должны использовать одинаковый порядок сортировки в связанных  с ними индексах.

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

Наличие или отсутствие индекса  совершенно незаметно для пользователя, обращающегося к таблице. Если для  какого-либо столбца создан индекс, то СУБД будет автоматически его  использовать.

Чтобы при выполнении запросов деактивизировать или, наоборот, активизировать использование определенного индекса, необходимо воспользоваться запросом ALTER INDEX , который имеет следующий  формат:

ALTER INDEX имя_индекса {ACTIVE | INACTIVE};

При создании любой индекс (как по столбцам ограничений, так  и по другим столбцам) автоматически  активен. Запрос ALTER INDEX может быть применен для отключения индекса перед  добавлением или изменением большого количества строк и устранения при  этом дополнительных затрат для поддержки  индексов в процессе длительной операции. После этой операции индексирование может быть восстановлено и индексы  будут пересозданы.