Удаление таблиц

Удаление таблиц (имеется в виду удаление именно таблиц, а не их содержимого) — очень простой процесс. Таблицы удаляются с помощью оператора DROP TABLE:

DROP TABLE CustCopy;

Этот оператор удаляет таблицу CustCopy. В данном случае не требуется никакого подтверждения, невозможно возвратиться к прежнему состоянию — в результате применения этого оператора таблица будет безвозвратно удалена.

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

Ограничения базы данных

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

Виды ограничений в базе данных

Существуют следующие виды ограничений в базе данных InterBase:

• первичный ключ - PRIMARY KEY;

• уникальный ключ - UNIQUE KEY;

• внешний ключ - FOREIGN KEY

- может включать автоматические триггеры ON UPDATE и ON DELETE;

• проверки - CHECK.

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

Первичный ключ с использованием синтаксиса ограничения на основе одного поля.  CREATE TABLE testl(  ID_PK INTEGER CONSTRAINT pktest NOT NULL PRIMARY KEY) ;  Для той же самой цели можно воспользоваться синтаксисом ограничений на основе нескольких полей:  CREATE TABLE test2(  ID_PK INTEGER NOT NULL,  CONSTRAINT pktst PRIMARY KEY (ID_PK)); 

Создание ограничений

Давайте рассмотрим создание ограничений подробнее. Первой в описании общего синтаксиса ограничений идет опция [CONSTRAINT constraint]. Как видите, эта опция взята в квадратные скобки и, значит, необязательна. 

Первичный и уникальный ключи

Первичные ключи являются одним из основных видов ограничений в базе данных. Они применяются для однозначной идентификации записей в таблице.

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

Примеры первичных и уникальных ключей:  CREATE TABLE pkuk(  pk NUMERIC(15,0) NOT NULL PRIMARY KEY, /*первичный ключ*/  ukl VARCHAR(SO) NOT NULL UNIQUE,/*уникальный ключ */   uk2 INTEGER NOT NULL UNIQUE /* еще уникальный ключ */);  Такой синтаксис позволяет создавать ключи на основе комбинации полей. Вот примеры создания первичных и уникальных ключей из нескольких полей:  CREATE TABLE pkuk2(  Number1 INTEGER NOT NULL,  Namel VARCHAR(SO) NOT NULL,  Kol INTEGER NOT NULL,  Stoim NUMERIC(15,4) NOT NULL,  CONSTRAINT pkt PRIMARY KEY (Numberl, Namel), /*первичный ключ pkt на  основе двух полей*/  CONSTRAINT uktl UNIQUE (kol, Stoim) ); /*уникальный ключ uktl на основе  двух полей*/  Пример создания первичного и уникального ключа с помощью ALTER TABLE. Сначала создаем таблицу:  CREATE TABLE pkalter(   ID1 INTEGER NOT NULL,   ID2 INTEGER NOT NULL,   UID VARCHAR(24));  Затем добавляем ключи. Сначала первичный:  ALTER TABLE pkalter  ADD CONSTRAINT pkall PRIMARY KEY (idl, id2);  Затем уникальный ключ:  ALTER TABLE pkalter  ADD CONSTRAINT ukal UNIQUE (uid) ;  Внешние ключи

Следующим ограничением, которое часто используется в базах данных InterBase, является ограничение внешнего ключа. Это очень мощное средство для поддержания ссылочной целостности в базе данных, которое позволяет не только контролировать наличие правильных ссылок в базе данных, но и автоматически управлять этими ссылками!  Смысл создания внешнего ключа следующий: если две таблицы служат для хранения взаимосвязанной информации, то необходимо гарантировать, чтобы эта взаимосвязь была всегда корректной. Пример — документ "накладная", содержащий общий заголовок (дата, номер накладной и т. д.) и множество подробных записей (наименование товара, количество и т. д.).  Давайте рассмотрим смысл наложения ограничений внешнего ключа на примере таблиц, содержащих информацию о накладных.  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);  Добавить внешний ключ в уже существующую таблицу можно следующей командой:  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 которые являются ссылочной основой для внешнего ключа.  Полный синтаксис ограничения внешнего ключа (с возможностью создавать ограничения на основании нескольких полей) приведен ниже:  <tconstraint> = [CONSTRAINT constraint] FOREIGN KEY ( col [,   col } ) REFERENCES other_table [ ( other__col [ , other_col ...] } ]  [ON DELETE {NO ACTION CASCADE|SET DEFAULT|SET NULL}]   [ON UPDATE (NO ACTION|CASCADE|SET DEFAULT SET NULL}]  Как видите, определения содержат большой набор опций. Для начала давайте рассмотрим базовое определение внешнего ключа, которое наиболее часто используется в реальных базах данных, а затем разберем возможные опции.  Чаще всего употребляются декларативная форма ограничения внешнего ключа, когда указывается набор полей (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)  ...) ; 

Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа

Обычно вполне достаточно декларативного варианта ограничения внешнего ключа, при котором сервер только следит за тем, чтобы в таблицу с внешним ключом нельзя было вставить некорректные значения или - при попытке сделать это возникает ошибка. Но InterBase позволяет выполнять ряд автоматических действий при изменении/удалении внешнего ключа. Для этого служит следующий набор опций внешнего ключа:  [ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]   [ON UPDATE {NO ACTIONjCASCADEjSET DEFAULT]SET NULL}]  Эти опции позволяют определить различные действия при изменении или удалении значения внешнего ключа.  Например, мы можем указать, что при удалении первичного ключа в таблице-мастере необходимо удалять все записи с таким же внешним ключом в подчиненной таблице. Для этого следует так определить внешний ключ:  ALTER TABLE INVENTORY  ADD CONSTRAINT fkautodel  FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE)  ON DELETE CASCADE  Ограничение CHECK

Одним из наиболее полезных ограничений в базе данных является ограничение проверки. Идея его очень проста - проверять вставляемое в таблицу значение на какое-либо условие и, в зависимости от выполнения условия, вставлять или не вставлять данные.  Синтаксис его достаточно прост:  <tconstraint> = [CONSTRAINT constraint] CHECK (   <search_condition>)}  Здесь constraint - имя ограничения; <search_condition> - условие поиска, в котором в качестве параметра может участвовать вставляемое/изменяемое значение. Если условие поиска выполняется, то вставка/изменение этого значения разрешаются, если нет - возникает ошибка.  Самый простой пример проверки:  create table checktst(   ID integer CHECK(ID>0));  Эта проверка устанавливает, больше ли нуля вставляемое/изменяемое значение поля ID, и в зависимости от результата позволяет вставить/изменить новое значение или возбудить исключение (см. главу "Расширенные возможности языка хранимых процедур InterBase" (ч. 1)).  Возможны и более сложные варианты проверок. Полный синтаксис условия поиска <search_condition> следующий:  <search_condition> = {<val> <operator>   { <val> | (<select_one>)}  |<val> [NOT] BETWEEN <val> AND <val>   | <val> [NOT] LIKE <val> [ESCAPE <val>]  | <val> [NOT] IN ( <val> [ , <val> ...] | <select_list>)  | <val> IS [NOT] NULL  | <val> {[NOT] {= | < | >} | >= | <=}   {ALL | SOME | ANY} (<select_list>)  |EXISTS ( <select_expr>)   | SINGULAR ( <select_expr>)   | <val> [NOT] CONTAINING <val>  |<val> [NOT] STARTING [WITH] <val>   | (<search_condition>)   | NOT <search_condition>  | <search_condition> OR <search_condition>   | <search_condition> AND <search_condition>}  Удаление ограничений

Часто приходится удапять различные ограничения по самым разным причинам. Чтобы удалить ограничение, необходимо воспользоваться предложением ALTER TABLE следующего вида:  ALTER TABLE cablename  DROP CONSTRAINT constraintname  где constraintname - имя ограничения, которое следует удалять. Если при создании ограничения было задано какое-то имя, то следует им воспользоваться, а если нет, то надо открыть какое-либо средство администрирования InterBase, поискать все связанные с ним ограничения и выяснить, какое системное имя сгенерировал InterBase для искомого ограничения.  Надо отметить, что удалять ограничения может только владелец таблицы или системный администратор SYSDBA.