49. Субд Oracle. Создание ограничений

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

Существует 2 основных типа ограничений:

1. Целостности данных (Data Integrity Constraints)

2. Ограничения целостности ссылок (Referential Constraints) — относятся к связям между таблицами (например на основе первичного и внешнего ключей).

Для облегчения вставки данных в связанные таблицы можно использовать команды DISABLE/ENABLE CONSTRAINT, которые позволяют временно игнорировать ограничения.

ALTER TABLE имя_таблицы DISABLE CONSTRAINT имя_огра [CASCADE]; — позволяет удалить ограничение и все связанные с ним при использовании параметра CASCADE.

ALTER TABLE имя_таблицы ENABLE CONSTRAINT имя_огра; — позволяет снова наложить ограничение.

Родительская таблица (Parent Table) или родительская строка (parent row) — таблица с первичным ключом или строка в такой таблице.

Дочерняя таблица (child table) или дочерняя строка (children record) — таблица со внешним ключом или строка данных в такой таблице.

50. Субд Oracle. Создание табличных пространств

Табличное пространство (tablespace) — …

CREATE TABLESPACE имя_пространства DATAFILE 'полный_путь_к_файлу' SIZEn DEFAULT STORAGE (INITIAL nK, NEXT nK, MINEXTENTS n, MAXEXTENTS n) ONLINE;

Давайте после множества примеров PL/SQL - обратимся, к такому понятию БД Oracle, как табличное пространство. В шаге-23, мы немного рассмотрели этот вопрос, но только в начальной стадии. Теперь давайте познакомимся с этим понятием более детально. Помните наш запрос:

В данном случае мы видим, что наша с вами система, имеет шесть табличных пространств, каждое из которых содержится в своем файле данных, который в свою очередь расположен в системном каталоге Oracle Server - C:\Oracle\ORADATA\proba. Иначе, это можно описать как C:\ORAHOME\ORADATA\SID. По умолчанию при создании экземпляра БД используется именно такой путь к файлам данных табличных пространств. Если говорить прямо, то табличное пространство, это конкретный файл данных, расположенный в системном каталоге Oracle. А, в строгой формулировке - табличное пространство это логическая структура, которая используется для группировки данных с однотипными методами доступа. В табличное пространство может входить, один или несколько файлов данных. Но, как правило, один или несколько файлов данных не могут хранить два табличных пространства, а только одно!

Помните когда мы создавали пользователя (схему), мы с вами указывали где он будет хранить свои данные. Это и есть то самое табличное пространство. И вот здесь мы с вами подходим к очень интересному моменту. При создании любой БД, как правило, оговаривается ее тип, исходя из этого и создается сам экземпляр! Так вот в нашей учебной БД, вы этого не видели. Но, если бы мы пошли по более конструктивному пути, (мы еще это проделаем!) а, именно установили сам сервер Oracle, затем создали бы экземпляр и провели его настройку, то вы бы это все увидели. Итак, к чему я это все болтаю, а вот к чему!

БД Oracle содержит и поддерживает несколько типов при создании экземпляра. Но основные из них это OLTP (On-Line Transaction Processing) и DSS (Decision Support System). Я понимаю, что это немного утомляет когда много теории, но знать это необходимо. Рассмотрим подробнее.

Рассмотрим систему OLTP. Данная система характеризуется высоким параллелизмом (большим количеством интерактивных пользователей) и как следствие высокой интенсивностью обновлений (то есть большое количество одновременно открытых транзакций). В таких системах, объем данных может значительно изменяться во времени как бы, то пусто, то густо! По этому, при создании табличных пространств (вот к чему я и вел!) и экстентов в них для систем OLTP необходимо задавать максимально возможный размер. Так как табличные пространства с включенной опцией динамического расширения может привести к тому, что производительность системы может значительно упасть! Вследствие этого возникает парадокс, что для достижения высокой производительности табличные пространства должны быть фиксированной длинны и при этом превосходить по объему максимальный размер данных, обрабатываемых в нем. Так же для управления транзакциями необходимо иметь принципиальную возможность выполнения достаточного количества отмен и откатов. Для коротких транзакций небольшие сегменты отката, для длительной и объемной транзакции большие сегменты отката. Так же большее количество журналов регистрации транзакций и более продуманной системы построения экземпляра в целом с применением методов диагностики и настройки. Вообще по большому счету при работе с любой БД, администрирование и настройка БД, это каждодневный и нелегкий труд админа! Такая у него доля! Кстати ярким примером системы OLTP, может служить система, применяемая сегодня в супермаркетах, коих у нас великое множество (Эльдорадо (Москва) НК - Сити (Хабаровск) и т.д.). В единицу времени может списываться сотня наименований товаров, со склада с подсчетом общего баланса и в то же время сотни наименований могут быть приняты на учет, так как пришел груз и получатель его оприходует в тот же момент! Собственно это и есть кратко система OLTP.

Далее продолжим рассмотрение второго типа экземпляров БД, для более ясного усвоения изложенного! :)