БАЗЫ ДАННЫХ

Плеханова» Экономический факультет
Кафедра вычислительной техники и информационных технологий

последнее время все возрастает. Выделим следующие основные понятия сетевой и

распределенной обработки данных:
распределенная обработка данных;
базы данных с сетевым доступом;
архитектура «клиент-сервер»;
распределенные базы данных.
Параллельный доступ к одной БД нескольких пользователей, в том случае если БД расположена на одной машине, соответствует режиму распределенного доступа к централизованной БД и такая система называется системой распределенной обработки данных.
Если же БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен параллельный доступ нескольких пользователей, то такая система называется системой распределенных баз данных.
Системы БД с сетевым доступом построены с помощью сетевых версий СУБД на основе оборудования и программного обеспечения локальных вычислительных сетей.

архитектуры «клиент-сервер». Каждый из составляющих эту архитектуру элементов играет свою

роль: сервер владеет и распоряжается информационными ресурсами системы (например, БД); клиент имеет возможность пользоваться ими. Для современных СУБД архитектура «клиент-сервер» стала фактическим стандартом.
Если предполагается, что проектируемая ИС будет иметь архитектуру «клиент-сервер», то прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т.е. часть функций будет реализована в программе-клиенте, а другая – в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на 4 группы:
функции ввода и отображения данных;
прикладные функции, характерные для предметной области (например, открытие счета для банковской системы);
фундаментальные функции хранения и управления информационными ресурсами (БД, файловыми системами);
служебные функции, играющие роль связок между функциями первых трех групп.

может состоять из компонентов (таблица 1).
Таблица 1 – Связь между

компонентами и функциями приложения
№ Функции Логический компонент
1 Ввода и отображения данных Компонент представления (КП)
2 Прикладные Прикладной компонент (ПрК)
3 Хранения и управления Компонент доступа к ресурсам (КДР)
информационными ресурсами

Различия в реализациях технологии «клиент-сервер» определяются четырьмя факторами:
тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов;
тем, какие механизмы программного обеспечения используются для реализации функций первых 3 групп;
как логические компоненты распределяются между компьютерами в сети;
какие механизмы используются для связи компонентов между собой.

«клиент-сервер»:
модель файлового сервера
(File Server – FS);
модель доступа

к удаленным данным
(Remote Data Access - RDA);
модель сервера БД
(Database Server – DBS );
модель сервера приложений
(Application Server - AS)

приложению),
узкий спектр операций манипулирования данными ("данные - это файлы"),

отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы), т.е. управление параллельной работой, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
проблема «толстого клиента» - Windows, интерфейс, коды приложения и полная копия СУБД могут перегрузить даже мощный компьютер

Технологии и модели архитектуры «клиент-сервер»

унификация интерфейса "клиент-сервер" в виде языка SQL.
Перенос компонента представления

и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов операционной системы.
Уменьшается загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как в FS), а запросы на языке SQL, их объем существенно меньше.

SQL-запросов по-прежнему значительно загружает сеть
Удовлетворительное администрирование приложений в RDA-модели практически

невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные)

функций
Снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых

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

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

СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.

на RDA- и DBS-модели, либо используют их разумное сочетание.
Поддержка

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

приложений для большого числа клиентов при отсутствии унификации в конфигурациях

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

требования к вычислительным ресурсам сервера в отношении быстродействия и памяти

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

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

выполнением низкоуровневых операций по доступу и изменению данных сервер приложений, как

в RDA-модели, обращается к SQL-серверу, направляя ему вызовы SQL-процедур, и получая, соответственно, от него наборы данных. Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией. 
В этом отношении сервер приложений от клиентов системы управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors — TRM), или просто монитором транзакций

сохраняя сильные стороны DBS-модели, позволяет более оптимально построить вычислительную схему информационной

системы, однако, как и в случае RDA-модели, повышает трафик сети.
В еще не устоявшейся до конца терминологии по моделям и технологиям «Клиент-сервер» RDA-модель характеризуют еще как модель с так называемыми «толстыми», а DBS-модель и AS-модель как модели, соответственно, с «тонкими» клиентами. 
По критерию звеньев системы RDA-модель и DBS-модель называютдвухзвенными (двухуровневыми) системами, a AS-модель трехзвенной (трехуровневой) системой.

несколько баз) в различных узлах компьютерной сети.
Каждый компонент БД

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

данных по сети.
Способы решения этой задачи:
в каждом узле сети

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

подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые

располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД.
Распределенная БД выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. Слово «распределенная» отражает способ организации БД, но не внешнюю ее характеристику («распределенность» БД невидима извне).
Примерами СУБД, обеспечивающих распределенную обработку данных являются: R-Star, Distributed Ingres, Oracle 7, Ingres/Star, Sybase, Informix-OnLine Dynamic Server.

и выполнение функций управления данными в нескольких узлах и передачу

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

(RDA-модель), в которой
имеется компьютер-клиент, на нем запускаются программы переднего

плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции). Этот компьютер, называемый локальным узлом (local node) соединен в сети с компьютером, на котором выполняется
сервер БД, и находится сама БД (обычно его называют удаленным узлом – remote node).

Распределенная обработка данных:
Аспекты сетевого взаимодействия

и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером

(Communication Server, DBMS Server Net).
Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net).

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

возможности современных СУБД и требования к ним при сетевом взаимодействии и распределенной обработки данных:
1.Локальная автономия (local autonomy). Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально Будучи фрагментом общего пространства данных, она, в то же время функционирует как полноценная локальная БД; управление ею выполняется локально и независимо от других узлов системы
2.Независимость узлов (no reliance on central site). В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. БД на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа

можно трактовать как возможность непрерывного доступа к данным (известное «24

часа в сутки, семь дней в неделю») или данные доступны всегда, а операции над ними выполняются непрерывно.
4.Прозрачность расположения (location independence) означает полную прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами.

это возможность распределенного (то есть на различных узлах) размещения данных,

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

типа фрагментации. Имеется таблица employee (emp_id, emp_name, phone), определенная в

базе данных на узле в Фениксе. Имеется точно такая же таблица, определенная в базе данных на узле в Денвере. Обе таблицы хранят информацию о сотрудниках компании. Кроме того, в базе данных на узле в Далласе определена таблица emp_salary (emp_id, salary). Тогда запрос «получить информацию о сотрудниках компании» может быть сформулирован так:
SELECT * FROM employee@phoenix, employee@denver ORDER BY emp_id
В то же время запрос «получить информацию о заработной плате сотрудников компании» будет выглядеть следующим образом:
SELECT employee.emp_id, emp_name, salary FROM employee@denver, employee@phoenix, emp_salary@dallas WHERE employee.emp_id= salary. emp_id ORDER BY emp_id

- это асинхронный процесс переноса изменений объектов исходной БД в

базы, расположенные на других узлах распределенной системы. Прозрачность тиражирования означает возможность переноса изменений между БД средствами, невидимыми пользователю распределенной системы, т.е. внутрисистемными средствами.
7.Обработка распределенных запросов (distributed query processing) трактуется как возможность выполнения операций выборки над распределенной БД, сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что и операцию над локальной БД.

возможность выполнения операций обновления распределенной БД (INSERT, UPDATE, DELETE), не

разрушающих целостность и согласованность данных. Это достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol). Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной транзакции.
9.Независимость от оборудования (hardware independence)- это означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до ПК.

independence)- это означает многообразие операционных систем, управляющих узлами распределенной системы.

11.Прозрачность сети (network independence). Доступ к любым БД может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных.
12. Независимость от СУБД (DBMS independence) или межоперабельность, что означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. Для этого могут использоваться шлюзы.

из набора узлов, связанных вместе коммуникационной сетью, в которой:
каждый узел

обладает собственной системой БД;
узлы работают согласованно, поэтому пользователь может получить доступ к данным на любом узле сети, как будто все данные находятся на его собственном узле.
Пример 2 Пусть БД «Склад» расположена на узле «узел_1», а БД «Предприятие» на узле «узел_2». В первой содержится таблица Деталь, а во второй - Поставщик. Пусть БД «Номенклатура» должна включать таблицы Деталь и Поставщик, физически принадлежащие различным БД. Логически она будет рассматриваться как нераспределенная БД. Следующие операторы SQL устанавливают ссылки на таблицы локальных БД. Они включены в в описание распределенной БД и передаются серверу БД.
REGISTER TABLE Деталь AS LINK WITH NODE=узел_1, DATABASE=Склад;
REGISTER TABLE Поставщик AS LINK WITH NODE=узел_2, DATABASE=Предприятие;

описании распределенной БД «Номенклатура» явно задаются ссылки на конкретные таблицы

реально существующих БД, однако при работе с такой БД это физическое распределение прозрачно для пользователя.
Наибольшую сложность при организации работы распределенной БД вызывает решение следующих задач:
1. Управление именами в распределенной среде
Прозрачность расположения в реальных продуктах должна поддерживаться соответствующими механизмами. Разработчики СУБД придерживаются различных подходов. Во многих СУБД задача управления именами объектов DDB решается путем использования глобального словаря данных, хранящего информацию о DDB: расположение данных, возможности других СУБД (если используются шлюзы), сведения о скорости передачи по сети с различной топологией и т.д.
2. Управления распределенными транзакциями.

STAR) 3. Оптимизация распределенных запросов
Обработка распределенных запросов (Distributed Query -DQ) -

задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента - оптимизатора DQ.
Пример 3 Обратимся к базе данных, распределенной по двум узлам сети. Таблица Деталь хранится на одном узле, таблица Поставщик - на другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:
SELECT Деталь_имя, Поставщик_имя, Поставщик_адрес
FROM Деталь, Поставщик WHERE
Деталь. Поставщик_номер = Поставщик. Поставщик_номер;
Результирующая таблица представляет собой соединение таблиц Деталь и Поставщик, выполненное по столбцу Деталь.Поставщик_номер (внешний ключ) и
Поставщик. Поставщик_номер (первичный ключ).

STAR)
Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным

локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица Поставщик. Следовательно, оптимизатор DQ запросов должен учитывать:
размер таблиц;
статистику распределения данных по узлам;
объем данных, передаваемых между узлами;
скорость коммуникационных линий;
структуры хранения данных;
соотношение производительности процессоров на разных узлах и т.д.
От интеллекта оптимизатора DQ впрямую зависит скорость выполнения распределенных запросов.

STAR) Решение этих трех задач возложено на специальный компонент СУБД –

сервер распределенных баз данных (Distributed Database Server). Возможны следующие варианты организации работы распределенной БД:
Если БД расположена на одном узле и прикладная программа выполняется там же, то не требуется ни коммуникационный сервер, ни сервер распределенных БД.
Если прикладная программа выполняется на локальном узле, БД находится на удаленном узле и там же выполняется сервер БД, то на удаленном узле необходим коммуникационный сервер, а на локальном – коммуникационная программа.
Если же распределенная БД состоит из таблиц локальных БД, находящихся на одном узле, и там же функционирует сервер распределенной БД, и выполняется прикладная программа, то коммуникационный сервер не нужен - нет взаимодействия по сети.
Если же локальные БД расположены на нескольких узлах, то для доступа к распределенной БД необходим и сервер распределенной БД, и коммуникационный сервер

STAR) Главное требование технологии STAR - синхронное завершение транзакций одновременно на

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

характеристика тиражирования (репликации) данных (Data Replication - DR) заключается в

отказе от физического распределения данных. Суть DR состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
DR – это набор технологий, который позволяет поддерживать несколько копий одних и тех же данных на нескольких узлах.

данных - это асинхронный перенос изменений объектов исходной базы данных

в базы, принадлежащим различным узлам распределенной системы.
Функции DR выполняет, как правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к Oracle7 DBMS опцию Replication Option.
Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR - использование «моментальных снимков» (snapshot).

4 Рассмотрим пример из Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE

START
WITH TO_DATE ('DD-MON-YY HH23:MI:55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND order_complete_flag = "N";
«Моментальный снимок» в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторяться каждые 7 дней. Каждый раз будут выбираться только завершенные заказы. .

схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для

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

технологии тиражирования данных:
данные всегда расположены там, где они обрабатываются -

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

данных не лишена недостатков.
Например, невозможно полностью исключить конфликты между

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

Необходимо отметить, что при этой технологии предъявляются высокие требования к аппаратным ресурсам всех узлов.

Технология тиражирования нашла применение там, где предъявляются повышенные требования к надежности - в сфере банковских информационных систем.

модели DBS
Профессиональные СУБД обладают мощным активным сервером БД. Идея активного

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

модели DBS
До недавнего времени функции управления знаниями о ПО оставались

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

модели DBS
В традиционной технологии решение задач, о которых речь шла

выше, целиком ложится на прикладные программы. Сервер БД при этом играет пассивную роль:
сервер БД лишен функций хранений и обработки знаний о предметной области;
за границами сервера остается контроль за состоянием БД и программирование реакции на ее изменения;
пассивный сервер не имеет средств отслеживания событий в БД, а также средств воздействия на работу прикладных программ и возможностей их синхронизации.

модели DBS
Идеи, реализованные в некоторых СУБД третьего поколения, заключаются в

том, что знания выносятся за рамки прикладных программ и оформляются как объекты БД. Функции применения знаний начинает выполнять непосредственно сервер БД. Такая концепция активного сервера опирается на четыре «столпа»:
процедуры БД;
правила (триггеры);
события в БД;
типы данных, определяемые пользователем прикладных программ.

модели DBS
1. Хранимые (stored, присоединяемые, разделяемые) процедуры - это процедуры

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

модели DBS
Хранимые процедуры обычно пишутся либо на специальном процедурном расширении

языка SQL (например, PL/SQL для ORACLE или Transact-SQL для MS SQL Server), или на некотором универсальном языке программирования, например, C++, с включением в код операторов SQL в соответствии со специальными правилами такого включения.
Основное назначение хранимых процедур - реализация бизнес-процессов предметной области.

модели DBS
Использование процедур БД преследует четыре цели:
обеспечение независимого уровня централизованного

контроля доступа к данным, осуществляемого администратором БД;
одна процедура может быть использована несколькими прикладными программами;
значительное снижение трафика сети с архитектурой «клиент-сервер» за счет вызова процедур, а не пересылки запросов.
процедуры БД в сочетании с правилами предоставляют администратору мощные средства поддержки целостности БД.

модели DBS
Пример 5 Разработать процедуру, которая переводила бы рядового сотрудника

в резерв на выдвижение на руководящую должность:
CREATE PROCEDURE Назначение (Номер_сотр integer not null) AS
BEGIN
INSERT INTO Резерв SELECT * FROM Сотрудник WHERE номер= Номер_сотр;
DELETE FROM Сотрудник WHERE номер= Номер_сотр;
END

Вызов процедуры осуществляется с помощью команды EXECUTE …,например:
EXECUTE PROCEDURE Назначение (115)

модели DBS
2. Триггеры - это хранимые процедуры без параметров, связанные

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

модели DBS
Кроме поддержки целостности БД, триггеры позволяют решать следующие задачи:
расчет

промежуточных результатов и других вычисляемых значений;
создание записей аудита для обеспечения безопасности или просто отслеживания операций, выполняемых над таблицей;
вызов внешних действий, например, процедуры для посылки почтового сообщения при срабатывании триггера;
реализация сложной защиты целостности

модели DBS
Триггеры могут быть как достаточно простыми, например, поддерживающими ссылочную

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

модели DBS
Укажем основные цели механизма правил:
1. отражение некоторых внешних

правил деятельности организации;
Пример 7 Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше 1000. Это требование описывается правилом:
CREATE RULE Проверить_деталь
AFTER UPDATE (количество) OF Деталь WHERE деталь.количество<1000
EXECUTE PROCEDURE Заказать_деталь (Ном_дет=Деталь.ном, остаток=Деталь.количество);
2.обеспечение целостности БД, особенно целостности по ссылкам

модели DBS

3. Механизм событий в БД позволяет прикладным программам и

серверу БД уведомлять другие программы о наступлении в БД определенного события и тем самым синхронизировать их работу. Операторы языка SQL, которые обеспечивают уведомление, называются сигнализаторами событий в БД (database event alerters).
Функции управления событиями целиком ложатся на сервер БД. Различные прикладные программы и процедуры вызывают события, а сервер оповещает монитор прикладных программ об их наступлении. Реакция монитора на событие заключается в выполнении действий, которые предусмотрел разработчик.

модели DBS
Механизм событий используется следующим образом:
вначале в БД для каждого

события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT – создать событие);
во все прикладные программы, на ход которых может повлиять это событие, включается оператор REGISTER DBEVENT (зарегистрировать событие), который оповещает сервер БД, что данная программа заинтересована в получении сообщения о наступлении события.

модели DBS

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

оператором RAISE DBEVENT;
каждая зарегистрированная программа может получить информацию о событии, для чего должна запросить очередное сообщение из очереди событий оператором GET DBEVENT (получить событие).

модели DBS

Типы данных, определяемые пользователем. Проблемы с типами данных решаются

за счет интеграции в сервер новых типов данных. Например, СУБД Ingres предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для этого надо написать и откомпилировать функции на языке С. Введение новых типов данных является по сути изменением ядра СУБД. В Ingres типы данных, определяемые пользователем могут быть параметризированы.

модели DBS

Определение нового типа данных сводится к указанию его нового

имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют стандартные операции (сравнение, преобразование в различные форматы и т.д.) программист должен их разработать самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип определен, то все операции выполняются над ним как над данными стандартного типа. Разрешение пользователю создавать свои типы данных – это один из шагов развития реляционных СУБД в направлении объектно-реляционных систем.

реализацию технологии «клиент-сервер»?
Какой спектр операций манипулирования данными используется в модели

файлового сервера?
Что означает пассивная роль сервера БД в модели доступа к удаленным данным?
Какие ограничения языка SQL можно отнести к недостаткам модели сервера приложений?
Как распределены роли клиента и сервера в модели сервера приложений?
Какие технологии используются при построении систем распределенных обработки данных?
Как реализуется выполнение требования прозрачности расположения данных?
Что такое фрагментация? Назовите ее типы?
Какие параметры учитываются при оптимизации распределенных запросов?
Составьте сравнительные характеристики технологий распределенных обработки данных?
Для чего нужны хранимые процедуры?
В каких случаях должны срабатывать триггеры?