Включение и выключение триггеров.

Триггер может быть в одном из двух состояниях: включен или выключен. Если включен, то Oracle возбуждает триггер для выполнения его тела. Если создаем триггер, то Oracle автоматически включил его. Для включения/отключения триггера используется

After triggerимя триггераDISABLE/ ENABLE

Удаление триггера

Drop trigger имя триггера

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

СЛУЖАЩИЕ (НОМЕР_ПРОПУСКА, ФИО, НОМЕР_ОТДЕЛА, ЗАРПЛАТА)

ОТДЕЛЫ (НОМЕР_ОТДЕЛА, НОМЕР_ПРОПУСКА_НАЧАЛЬНИКА, ЧИСЛО_СЛУЖАЩИХ,

ФОНД_ЗАРПЛАТЫ)

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

SELECT ЧИСЛО_СЛУЖАЩИХ FROM ОТДЕЛЫ =

SELECT COUNT (*) FROM СЛУЖАЩИЕ

WHERE НОМЕР_ОТДЕЛА = ОТДЕЛЫ.НОМЕР_ОТДЕЛА

SELECT ФОНД_ЗАРПЛАТЫ FROM ОТДЕЛЫ <=

SELECT SUM (ЗАРПЛАТА) FROM СЛУЖАЩИЕ

WHERE НОМЕР_ОТДЕЛА = ОТДЕЛЫ.НОМЕР_ОТДЕЛА

Предположим, что в отделе кадров работает всего два человека: начальник отдела кадров, который, естественно, имеет доступ к обеим таблицам и, в частности, является ответственным за выполнение операций смены начальника отдела или изменения фонда заработной платы. Второй человек - рядовой клерк, который по указанию начальника выполняет рутинную работу оформления новых сотрудников или увольнения ранее работавших. Естественно, что для выполнения его операций достаточно иметь доступ только к таблице СОТРУДНИКИ. Но тогда при выполнении любой из двух операций он просто не может не нарушить по крайней мере первое из упомянутых выше ограничений целостности. Конечно, можно внести соответствующие корректирующие действия в код прикладной программы, соответствующей операциям клерка, но тогда он неявно получит доступ по изменению ответственной таблицы ОТДЕЛЫ. Поэтому лучше определить триггеры вида

ON INSERT TO СЛУЖАЩИЕ

UPDATE ОТДЕЛЫ SET NEW (ЧИСЛО_СЛУЖАЩИХ) = OLD (ЧИСЛО_СЛУЖАЩИХ) + 1

WHERE НОМЕР_ОТДЕЛА = СЛУЖАЩИЕ.НОМЕР_ОТДЕЛА

ON DELETE FROM СЛУЖАЩИЕ

UPDATE ОТДЕЛЫ SET NEW (ЧИСЛО_СЛУЖАЩИХ) = OLD (ЧИСЛО_СЛУЖАЩИХ) - 1

WHERE НОМЕР_ОТДЕЛА = СЛУЖАЩИЕ.НОМЕР_ОТДЕЛА

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

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

СТАТИСТИКА (ТЕКУЩАЯ_ДАТА, ЧИСЛО_ОПЕРАЦИЙ)

и триггер вида

ON INSERT, DELETE FROM СЛУЖАЩИЕ

IF EXISTS (SELECT * FROM СТАТИСТИКА WHERE ТЕКУЩАЯ_ДАТА = TODAY)

UPDATE СТАТИСТИКА SET

NEW (ЧИСЛО_ОПЕРАЦИЙ) = OLD (ЧИСЛО_ОПЕРАЦИЙ) + 1

WHERE ТЕКУЩАЯ_ДАТА = TODAY

ELSE

INSERT INTO СТАТИСТИКА (TODAY, 1)

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

Наконец, в базе данных могут находитьсяхранимые процедуры. Интересно, что в стандарте SQL/92 вообще не встречается термин "хранимая процедура". В стандарте специфицированы два способа взаимодействия прикладной программы с сервером баз данных.

1.Первый, наиболее часто используемый способ состоит во встраивании операторов языка SQL в программу, написанную на одном из традиционных языков программирования. В самом стандарте определены правила встраивания SQL в программы, которые написаны на языках Си, Паскаль, Фортран, Ада и т. д.

2. Второй способ основан на специфицированном в стандарте "языке модулей SQL". С использованием этого языка можно определить модуль, содержащий несколько процедур, каждая из которых соответствует некоторому параметризованному оператору SQL. В прикладной программе содержатся не операторы SQL, а лишь вызовы процедур (с указанием фактических параметров) из модуля SQL, с которым эта прикладная программа связана (правила связывания в стандарте не определены). Заметим, что стандарт не обязывает следовать каким-то конкретным правилам при реализации встроенного SQL или языка модулей.

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

Тема 13. Физическая организация БД на примере Oracle9i. Организация табличных пространств, журналов транзакций. Серверные процессы. Структуры памяти и взаимодействие между процессами.

Архитектура БД.

БД - есть некоторое количество файлов данных и программ, выполняющих необходимые операции над этими файлами. Файлы данных содержат информацию, хранящуюся в БД. Эту информацию можно разделить на две категории: 1)данные пользователя - используются различными приложениями пользователя; 2)системные данные - информация, необходимая для управления пользовательскими данными и для обеспечения своей работоспособности.

Табличное пространство: Файлы данных группируются в определенных табличных пространствах. Перед вводом информации в БД необходимо сначала создать табличное пространство - table space. А затем только саму таблицу с данными. Пример: Шкаф - это база данных, ящики в шкафу - табличное пространство, папки - файлы данных, листы бумаги - таблицы.

Наличие следующих таблиц пространств обязательно.

1. Системное табличное пространство SYSTEM, в нем содержится информация, необходимая для функционирования БД. Это обязательное табличное пространство.

2. TEMP - временное табличное пространство, в нем все временные таблицы, т.е. oracle при необходимости сохраняет на диске временные файлы (рабочая область на диске для выполнения внутренних транзакций).

3. Вспомогательное табличное пространство TOOLS, обеспечивает хранение объектов БД, предназначенных для поддержки вспомогательных средств oracle, к которым относится генератор отчетов oracle reports приложение.

4. Пользовательское табличное пространство - USERS - содержит объекты БД, принадлежащие отдельным пользователям.

5. Табличное пространство сегментов отката ROOL BACK, хранится информация, используемая при отмене выполняемых транзакций.

6. (Индекс) INDEX, табличное пространство индексов.

В БД Oracle имеются 2 группы файлов:

1) файлы данных, сгруппированных в табличном пространстве.

2) файлы данных журналов повтора.

Журналы транзакций (повтора): Это специальные файлы операционной системы, в которой Oracle записывает все изменения или транзакции, произведенные в БД при внесении изменений они сохраняются в оперативной памяти сервера для повышения его производительности (дисковый ввод\ вывод в 1000 р. медленнее). На диск записывается только окончательная версия измененных данных, с помощью журналов транзакций можно избежать утраты данных после сбоев. В БД должно быть не менее 2 оперативных журналов повтора, которые работают по жесткому принципу. Пусть есть 2 журнала повтора А и В:

1. По мере того, как транзакции создают, удаляют и модифицируют информацию БД, все изменения заносятся в журнал А.

2. Когда А заполнен целиком происходит переключение журналов и все записывается в журнал В.

Когда В заканчивается, то запись начинается опять в журнал в А и старые записи стираются (вся ранее записанная информация становится недоступной).

БД Oracle может работать в двух режимах:

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

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

Процессы: Поскольку БД - это набор программ (процессов), обрабатывающих файлы данных, то в ORACLE существует два типа таких программ (процессов):

1. пользовательские (клиентские) - это средства, используемые пользователями для доступа к БД. К ним относятся: среда программирования SQL+, генератор отчетов ORACLE reports, инструментальные средства ORACLE forms.

2. серверные процессы - принимают запросы от пользовательских процессов и непосредственно взаимодействуют с БД при выполнении этих запросов, т.е. с помощью серверных процессов осуществляется доступ пользовательских процессов к содержимому БД.

Различают следующие серверные процессы:

1. системный процесс записи в БД. Database Writer (DBWR) √ обязательный системный процесс, записывающий измененные блоки данных в соответствующие файлы, т.е. вносятся изменения в файлы данных на физическом уровне.

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

3. процесс записи в журналы. LOG Writer (LGWR) √ обязательный процесс. Записывает данные в журналы повтора.

4. системный монитор. System Monitor (SMON) √ обязательный процесс, выполняющий процедуры восстановления при запуске БД.

5. монитор процессов. Process Monitor (PMON) √ обязательный процесс, освобождает занятые пользователем ресурсы в случае аварийного завершения его сеанса работы.

Необязательные процессы

1. Arhive (архиватор) √ создание архивных копий журнала повторов в режиме Arhivelog;

2. Lock √ процесс блокировки, используется в режиме параллельного сервера (это обязательный процесс);

3. Recoverer (RECO) √ процесс восстановления, необходимый процесс, используемый в режиме распределенного сервера.

Архитектура √ это сборное понятие.

Структура памяти и взаимодействие между процессами:В сервере ORACLE используется два типа областей памяти:

1.Глобальная системная область (System Global Area √ SGA)

2.Глобальная область программ (Program Global Area √ PGA)

SGA называется место в памяти, где БД ORACLE хранит информацию о своей структуре, необходимую для всех выполняющихся процессов.

SGA совместно используется всеми серверными и пользовательскими процессами.

SGA располагается в оперативной памяти.

SGA включает в себя 4 основные части:

1. КЭШ √ буфер данных (Data Cache) √ это область, где БД хранит самые свежие блоки данных, прочитанные с диска. При вводе в БД новой информации, она сначала попадает в КЭШ √ буфер и только затем становится доступной всем пользовательским процессам.

2. КЭШ √ словарь или строковый КЭШ (Dictionary cache) √ содержит строки из словаря БД, в котором записана вся информация, необходимая для нормального функционирования БД. Например, то, каким пользователям разрешен доступ к БД, какие объекты БД принадлежат конкретным пользователям и где эти объекты расположены.

3. Буфер журнала повтора (REDOLOG) √ перед записью транзакции в журнал повтора, она попадает вначале в буфер, который периодически сбрасывается в журнал повтора.

4. Разделяемая SQL √ область (SQLAREA) √ служит КЭШ √ буфером программ пользователей.

Кэш √ словарь Dictionory CACHE	Буфер журнала повтора REDO LDG
Кэш-буфер данных DATA CACHE	SQL - область SQL - AREA

 

Тема 14. Ограничения целостности. Технология оперативной обработки транзакций (OLTP -технология). Информационные хранилища. OLAP - технология. Проблема создания и сжатия больших информационных массивов, информационных хранилищ и складов данных.

В 60^х гг. появились АИС предназначенные для хранения и обработки информации. По мере интеллектуализации АИС появилась возможность обработки текстовых документов на естественном языке (изображения и другие виды и формы представления данных).

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

- Документальные

- Фактографические

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

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