demo@10g>insert into EMPLOYEE1 (select * from EMPLOYEE);
32 строк создано.
В созданной таблице – один столбец (employee_id) является primary key и три столбца (job_id, manager_id,department_id) образуют три разных foreign key по одному столбцу в каждом. Кроме того определено ограничение целостности (constraint) LST_NAME_DEPT_ID, требующий уникальности фамилии служащего в отделе. Столбцы, для которых указано «NOT NULL», должны быть заполнены информацией при вставке строк в таблицу. Ограничение CHECK задает диапазон значений DEPARTMENT_ID от 10 до 99. Это ограничение отключено (…DISABLE).
Q5_4 Добавим ограничение целостности к столбцу E_SEX
demo@10g> alter table EMPLOYEE1 add constraint check_sex check(e_sex in ('M','F'));
Таблица изменена.
Q5_5 Задействуем отключенное при создании таблицы EMPLOYEE1 ограничение целостности для столбца department_id, которым устанавливается диапазон значений от 10 до 99. Для такого задействования нам надо определить имя этого ограничения, которое Oracle присваивает автоматически при создании таблицы. Для этого извлечем данные из таблицы словаря Oracle, предварительно отформатировав один из ее столбцов:
demo@10g> col search_condition format a40
demo@10g> select constraint_name,search_condition,status from user_constraints
where table_name='EMPLOYEE1';
Теперь можно «включить» ограничение SYS_C006046 (как видно из результата запроса, ограничению с таким именем соответствует фраза «DEPARTMENT_ID BETWEEN 10 AND 99»):
demo@10g> alter table employee1 modify constraint SYS_C006046 enable;
Таблица изменена
Чтобы убедиться, что ограничение включено, повторим запрос к словарю:
demo@10g> select constraint_name,search_condition,status from user_constraints
demo@10g> alter table employee1 drop constraint check_sex;
Таблица изменена.
Q5_7 Скорректируем максимальную длину столбца LAST_NAME
demo@10g> alter table EMPLOYEE1 modify (last_name varchar2(30));
Таблица переименована.
Q5_8 Переименование таблицы
demo@10g> rename EMPLOYEE1 to EMPLOYEE2;
Таблица переименована.
Q5_9 Переименование столбца таблицы EMPLOYEE2
demo@10g> alter table employee2 rename column e_sex to sex;
Таблица изменена.
Q5_10 Удалим таблицы DEPARTMENT1, EMPLOYEE2:
demo@10g>drop table DEPARTMENT1;
drop table DEPARTMENT1
*
ошибка в строке 1:
ORA-02449: уникальный/первичный ключ в таблице, на которую ссылаются по внешнему ключу
На таблицу DEPARTMENT1 ссылаются записи таблицы EMPLOYEE2 (переименованной таблицы EMPLOYEE1), поэтому команду удаления таблицы DEPARTMENT1 надо писать иначе:
Создадим таблицу, которую будем использовать для занесения информации о строках, нарушающих ограничение целостности
demo@10g> create table my_exceptions (
row_id rowid,
owner varchar2(30),
table_name varchar2(30),
constraint varchar2(30));
Нарушать ограничение целостности будем для таблицы S_GRADE. Текущее ее содержимое:
demo@10g> select * from S_GRADE;
Продублируем информацию в ней:
demo@10g> insert into S_Grade (select * from S_GRADE);
4 строк создано.
demo@10g> select * from S_GRADE;
Видно, что в столбце grade_id значения повторяются.
Скорректируем таблицу S_GRADE, сделаем попытку определить столбец grade_id, как primary key. Часть команды «…exseption into my_exseption» указывает Oracle, куда помещать информацию о тех строках таблицы, из-за которых корректировка невозможна – не удается столбец grade_id определить, как primary key.
demo@10g> alter table S_GRADE add constraint pk_grade_id primary key(grade_id)
exceptions into MY_EXCEPTIONS;
alter table S_GRADE add constraint pk_grade_id primary key(grade_id)
*
ошибка в строке 1:
ORA-02437: невозможно подтвердить (DEMO.PK_GRADE_ID) - нарушен первичный ключ
Так как значения столбца grade_id повторяются, выполнить команду невозможно, Oracle выдает сообщение об ошибке и помещает в таблицу MY_EXSEPTION строки, из-за которых эта ошибка появляется.
demo@10g> select * from my_exceptions;
Q5_12 Тип LONG в документации Oracle определяется устаревшим типом и оставляется для использования для обратной совместимости с прежними версиями Oracle. Таблица user_constraints, из которой мы выше извлекали информацию имеет столбец search_condition типа LONG.
Теперь попробуем извлечь из таблицы user_constraints информацию, воспользовавшись условием where для столбца search_condition типа LONG:
