Пример
Для добавления ограничения UNIQUE в таблицу EMPLOYEE вы можете использовать следующий оператор:
ALTER TABLE EMPLOYEE
ADD CONSTRAINT UQ_PHONE_EXT UNIQUE(PHONE_EXT);
Когда недостаточно ALTER TABLE
Иногда бывает нужным произвести изменение столбца, которое нельзя совершить с помощью ALTER TABLE. Примером может быть случай, когда столбец, хранящий международные элементы языка, имеет набор символов NONE, который нужно заменить на другой набор символов, чтобы исправить ошибку проектирования, или телефонный номер, определенный вначале кем-то как целое, нужно заменить на 18-символьный столбец.
В первом случае невозможно изменить набор символов для столбца, следовательно, вам нужно средство, чтобы сохранить данные и сделать их доступными в правильном наборе символов. Во втором случае простое изменение типа данных столбца с телефонным номером не будет работать, если у нас уже существуют целые числа в этом столбце. Мы хотим сохранить существующие числа, но нам нужно преобразовать их в строки. Это не может быть выполнено в существующей структуре, потому что столбец с целым типом данных не может хранить строки.
Прием заключается в создании в таблице временного столбца с правильными атрибутами и переносе туда данных, после чего вы удалите и пересоздадите нужный столбец.
1. Добавьте в таблицу временный столбец с теми атрибутами, которые вам нужны.
ALTER TABLE PERSONNEL
ADD TEMP_COL VARCHAR (18) ;
COMMIT;
2. Скопируйте данные из столбца, который вы будете изменять, во временный столбец, преобразовывая их соответствующим образом (например, изменяя набор символов для конвертирования текстовых данных в правильный набор символов или, как в нашем примере, выполняя преобразование).
UPDATE PERSONNEL
SET TEMP_COL = CAST(TEL_NUMBER AS VARCHAR(18))
WHERE TEL_NUMBER IS NOT NULL;
COMMIT;
3. После проверки того, что данные во временном столбце были изменены, как планировалось, удалите старый столбец.
ALTER TABLE PERSONNEL DROP TEL_NUMBER;
4. Создайте "новый" столбец, с тем же именем, как и тот, который вы только что удалили, и с теми же атрибутами, что и у временного столбца.
ALTER TABLE PERSONNEL
ADD TEL_NUMBER VARCHAR (18);
5. Скопируйте данные во вновь созданный столбец.
UPDATE PERSONNEL
SET TEL_NOMBER = TEMP_COL WHERE TEMP_COL IS NOT NULL;
COMMIT;
6. После проверки того, что данные во вновь созданном столбце правильные, удалите временный столбец. Если хотите, вы можете также переместить пересозданный столбец на его старую позицию.
ALTER TABLE PERSONNEL
DROP COLUMN TEMP_COL,
ALTER TEL_NUMBER POSITION 6;
COMMIT;
Удаление таблицы
DROP TABLE
Используйте оператор DROP TABLE для удаления таблицы и ее данных из базы данных.
Это полное удаление, оно не может быть отменено после подтверждения транзакции.
DROP TABLE имя;
Следующий оператор удаляет таблицу PERSONNEL:
DROP TABLE PERSONNEL;
RECREATE TABLE
Иногда бывает нужно удалить таблицу и снова создать ее "с нуля". Для таких случаев Firebird имеет оператор RECREATE TABLE, который делает следующее:
* удаляет существующую таблицу и все принадлежащие ей объекты;
* подтверждает изменения;
* создает новую таблицу в соответствии с указанной спецификацией.
Синтаксис
Синтаксис RECREATE TABLE идентичен синтаксису оператора CREATE TABLE. Просто замените ключевое слово CREATE на RECREATE.
! ! !
ВНИМАНИЕ! Убедитесь, что вы сохранили исходные тексты триггеров, ключей и индексов этой таблицы до выполнения запроса RECREATE TABLE!
. ! .
Ограничения и рекомендации
Если при выполнении оператора DROP или RECREATE таблица находится в использовании, запрос не будет выполнен, появится сообщение "Object xxxxx is in use" (Объект xxxxx используется).
Всегда выполняйте резервное копирование перед любыми действиями, изменяющими метаданные.
Хотя возможно изменение метаданных при наличии соединенных пользователей, этого делать не рекомендуется, особенно в случаях радикальных изменений типа удаления или пересоздания таблиц. Если нужно, отключите пользователей и получите исключительный доступ. Инструкции по получению исключительного доступа см. в главе 39.
Временные таблицы
Firebird не поддерживает временные таблицы, которые управляются системой. Здесь они меньше нужны, чем в других СУБД. Например, у Firebird есть возможность получать виртуальные таблицы напрямую через хранимую процедуру, написанную с использованием специального синтаксиса. Более подробно об этом см. разд. "Хранимые процедуры выбора" в главах 29 и 30.
Постоянные "временные" таблицы
Популярная модель хранения временных данных для доступа приложений - определить постоянную структуру данных, которая включает "идентификатор сессии" или "идентификатор пакета", получающие значение от генератора, или, в Firebird 1.5,
значение CURRENT_TRANSACTION. Приложения могут добавлять, обрабатывать и удалять строки из такой таблицы в процессе решения задачи. Запомните, что Firebird не блокирует таблицы в нормальных ситуациях.
В соответствии с условиями и потребностями приложения оно само будет ответственным за удаление временных строк по окончании сессии при использовании идентификатора сессии для удаления "своих" строк. Альтернативно приложение может послать в служебную таблицу строку, сигнализирующую "требуется чистка", для более поздней отложенной операции, запускаемой перед резервным копированием.
! ! !
СОВЕТ. Временные таблицы, скорее всего, появятся в следующем релизе Firebird.
. ! .
Пора дальше
Одной из важных особенностей реляционной СУБД является ее возможность поддерживать отношения между группами постоянных данных, хранимых в таблицах. Далее мы рассмотрим, как Firebird реализует правила по защите ссылочной целостности в этих межтабличных отношениях.
ГЛАВА 17. Ссылочная целостность данных.
Термин ссылочная целостность относится к возможности базы данных защищать себя от получения входных данных, результатом которых может стать нарушение отношений. А именно ссылочная целостность базы данных существует в соответствии с ее способностью осуществлять и защищать отношение между двумя таблицами.
Реализация формальных ограничений целостности добавляет некоторую дополнительную работу разработчикам баз данных - так какова же окупаемость? Если вы новичок в этой концепции, то вы, безусловно, должны найти множество причин для оправдания дополнительного времени и внимания.
* Бомбоубежище: формальные ссылочные ограничения - особенно при разумном использовании других ограничений - станут надежным бомбоубежищем бизнес- правил вашей базы данных от ошибок приложений, независимо от их источника. Это будет в особенности важным, когда вы начнете устанавливать ваши системы на сайты, где неквалифицированный или частично квалифицированный персонал будет получать доступ к базе данных через утилиты сторонних организаций.
* Скорость запросов: индексы, автоматически созданные для ограничений ссылочной целостности, увеличат скорость операций соединения (join).
* Качество управления: в процессе разработки и тестирования потенциальные ошибки имеют тенденцию проявляться раньше, потому что база данных отменяет операции, которые нарушают правила. Они эффективно уменьшают неприятности в разработке приложения при ошибочных предположениях о согласованности данных.
* Документированность: правила целостности, установленные в вашей базе данных, дают "свободную" документацию, которая уменьшает потребность в любой описательной документации, помимо скриптов схемы. Правила, корректно определенные в метаданных, становятся надежным справочником по модели данных для новых групп и будущей разработки.
Терминология
Если реляционная СУБД позволяет объявлять отношение между двумя таблицами, иногда это называется декларативной ссылочной целостностью - туманный термин, который, похоже, распространялся писателями журнальных статей. Ссылочная целостность является целью проектирования, уровнем его качества. Автор предпочитает термин формальные ссылочные ограничения, когда обращается к механизмам реализации таких правил.
В системе управления реляционными базами данных (реляционные СУБД) отношение между двумя таблицами создается посредством ограничения внешнего ключа. Ограничение внешнего ключа реализует правила существования строк, защищая таблицу от попыток добавлять строки, несовместимые с моделью данных. Однако такое ограничение не работает в одиночестве. Другие ограничения целостности (подробно описанные в главе 16) могут работать в комбинации с ссылочными ограничениями для поддержания непротиворечивости отношений.