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

Вид материала

Документы

Содержание Таблица 9.8. Неоднозначный поиск Prod_code = '350tyx' Планировщик (scheduler) Управление параллельным выполнением транзакций методом блокировки Основные сведения Создание триггера For {after | instead of} {insert | update | delete} Table, grant и revoke, reconfigure, load database или transaction, update statistics, select into For insert, update Триггер удаления For delete as Хранимые процедуры Назначение хранимых процедур Системные хранимые процедуры Пользовательские хранимые процедуры Создание и использование хранимых процедур Rule и creat trigger. S3 smallint Архитектура многопользовательских СУБД Тенденции развития многопользовательских систем ... Полное содержание

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

Таблица 9.8. Неоднозначный поиск

Таблица 9.8 (окончание)

Время Транзакция Действие Значение Всего

11. Т2 ***** COMMIT *****
    
12. Т1 Чтение PROD_QOH для 100 455
    

PROD_CODE = '350TYX'

13 Т1 Чтение PROD_QOH для 30 485

PROD_CODE = '355TYX'

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

систему.


Планировщик

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

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

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

Планировщик также обеспечивает эффективную работу центрального процессора компьютера (CPU). Если невозможно спланировать выполнение транзакций, то все транзакции будут выполняться по принципу "первый пришел — первым обслужен". Проблема такого подхода в том, что время центрального процессора тратится попусту на время ожидания окончания операций READ (чтение) или WRITE (запись! I Короче говоря, порядок обработки по принципу "первый пришел — первым обслу-1 жен" приводит к увеличению времени отклика в многопользовательских СУБД. Поэтому необходим иной метод, который помог бы увеличить общую производительность системы, задействовав время простоя процессора.

Операции с базой данных, в которых используются чтение и/или запись, могут привести к конфликтам. Например, в табл. 9.9 представлены возможные конфликты при одновременном выполнении двух транзакций Т1 и Т2 над одними и теми же данными. На основе табл. 9.9 можно сделать вывод, что две операции конфликтуют при получении доступа к одним и тем же данным, по крайней мере, во время одной из операций записи (WRITE).

Таблица 9.9. Конфликт чтения/записи: матрица конфликтов базы данных

ТРАНЗАКЦИИ

Т1 Т2

Операции Read Read

Read Write

Write Read

Write Write

Примечание: в таблице жирным курсивом выделены неконфликтующие операции.

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


Управление параллельным выполнением транзакций методом блокировки

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

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


Триггеры

Триггеры представляют собой методы, с помощью которых можно обеспе­чивать целостность базы данных даже в том случае, если она используется множеством приложений. Посмотрим, как эти методы реализованы в СУБД MS SQL Server.

Основные сведения

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

Допустим, что в базе данных есть таблицы, связанные через поле Surname. Например, это могут быть таблица клиентов предприятия и их заказов. Ра­зумно определить триггер, который при каждой попытке удалить запись клиента проверит наличие у него заказов и позволит удалить эту запись только при их отсутствии. Конечно, подобную задачу можно решить при помощи средств декларативной ссылочной целостности. Однако при помо­щи триггеров можно создавать значительно более сложные рабочие правила. Можно создать триггер, который при каждом добавлении записи в таблицу заказов анализирует предыдущие заказы этого же клиента и определяет при­емлемый срок оплаты этого заказа.

Триггеры не принимают параметров и не возвращают значений. Они вы­полняются неявно. То есть триггер запускается только при попытке измене­ния данных.

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

По умолчанию все триггеры (insert, delete, update) срабатывают сразу по­сле выполнения операции изменения данных. Эти триггеры относятся к ти­пу after (после). Начиная с SQL Server 2000 появилась еще одна группа триггеров — instead of (вместо), которые выполняются вместо оператора, предполагающего изменение данных.

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

Триггер является частью транзакции, следовательно, если триггер терпит неудачу, отменяется вся транзакция. И наоборот, если какая-то часть тран­закции не удалась, то и триггер будет отменен.

В своей работе триггеры используют таблицы Inserted и Deleted. Это логиче­ские таблицы, они постоянно находятся в оперативной памяти и имеют ту же структуру, что и таблица, для которой создан триггер. Каждая добавлен­ная к защищаемой триггером таблице строка добавляется и в таблицу Inserted. Обновление производится почти так же, как и удаление с после­дующей вставкой. Когда строка обновляется, старая строка записывается в таблицу Deleted, затем обновленная строка записывается в базовую табли­цу и в таблицу Inserted.

Создание триггера

Триггер создается оператором create trigger. Рассмотрим его синтаксис:

CREATE TRIGGER [владелец.] имя_триггера

ON [владелец.]имя_таблицы | имя_представления

FOR {AFTER | INSTEAD OF} {INSERT | UPDATE | DELETE}

[WITH ENCRYPTION]

AS onepaTop_SQL

Таблица может иметь произвольное количество триггеров любых типов (insert, update или delete). По умолчанию триггер выполняется после из­менения данных, однако, если указать параметр insead of, to создается триггер, выполняющийся вместо изменения данных.

Каждая операция (insert, update и delete) может вызывать выполнение произвольного количества триггеров. С единственным ограничением — имена триггеров, вызываемых одной операцией, должны быть уникальными. Изменить триггер можно, удалив его и создав заново в другом виде или при помощи оператора alter trigger. При удалении таблицы, имеющей триг­геры, все они также удаляются. При создании триггеров необходимо придерживаться следующих правил:

• Триггеры создаются для поддержания целостности данных, ссылочной
  целостности и рабочих правил.
  
• Нельзя создавать триггеры для временных таблиц. Однако триггеры могут
  к таким таблицам обращаться так же, как и к представлениям.
  
• Триггер не может возвращать результирующих наборов данных. Это зна­чит, что к использованию оператора select при его создании нужно подходить крайне осторожно. Обычно в этих случаях используется опера­тор SELECT С ДИреКТИВОЙ IF EXISTS.
  
• С помощью опции with encryption исходный код триггера, хранящийся
  в таблице syscomments, можно зашифровать.
  
• Операторы writetext не инициализируют триггеры. Они используются
  для изменения данных типа Text или Image, а эти изменения не заносят­
  ся в журнал транзакций.
  
• В триггерах нельзя использовать следующие операторы: все операторы create, все операторы drop, alter table, alter database, truncate
  

TABLE, GRANT И REVOKE, RECONFIGURE, LOAD DATABASE ИЛИ TRANSACTION, UPDATE STATISTICS, SELECT INTO И ВСе Операторы DISK.

• Операторы отмены транзакций, входящие в состав триггера, могут стать
  причиной непредсказуемого поведения операторов вызывающей про­
  граммы.
  

Следующий пример демонстрирует использование триггера, срабатывающего при вставке или обновлении таблицы. По умолчанию это триггер after.

USE pubs

GO

CREATE TRIGGER trAddAuthor

ON authors

FOR INSERT, UPDATE

AS raiserror ('%d rows have been modifed', 0, 1

@@rowcount)

RETURN

Данный триггер будет стартовать при каждой вставке или изменении дан­ных и возвращать сообщение о количестве измененных строк. Рассмотрим результат его работы:

USE pubs GO

INSERT authors

(au_id, au_name, au_fname, phone, address, city, state, zip, contract) VALUES

('777-66-555', 'Vasiliy', 'Sidorov', '+7000666666', '666 hell-street', "Magadan', 'Magad. Obi.', '874763',0)

После выполнения этого кода на экран будет выведено:

1 rows have been modified (1 row(s) affected).

Где первая строка и есть результат работы триггера.

Триггер удаления

Рассмотрим триггеры удаления (delete). Стоит отметить, что при использо­вании оператора truncate table (удаляющего все строки таблицы) триггер не сработает. Для демонстрации создадим еще одну запись в таблице authors, отличающуюся от предыдущей только значением поля au_id.

USE pubs GO

INSERT authors

(au_id, au_name, au_fname, phone, address, city, state, zip, contract) VALUES

('777-66-555', 'Vasiliy', 'Sidorov', '+7000666666', '666 hell-street',

'Magadan', 'Magad. Obi.', ' 874763',0)

После выполнения этого кода на экран будет выведено:

1 rows have been modified
(1 row(s) affected).

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

CREATE TRIGGER trDelAuthors

ON authors

FOR DELETE AS reiserror

('%d rows are going to be deleted from this table', 0, 1, @@rowcount)

Теперь при удалении всех строк со значением поля au_fname равным Sidorov:

DELETE FROM authors

WHERE au_fname = 'Sidorov'

После выполнения этого кода на экран будет выведено:

2 rows are going to be deleted from this table
(2 row(s) affected).

Основным применением триггеров является обеспечение целостности дан­ных (ссылочная целостность, поддержка правил, каскадное изменение дан­ных). Операция каскадного изменения легко программируется в триггере. Допустим, закрывается книжный магазин. Можно создать триггер, удаляю­щий его из таблицы shops и все относящиеся к нему строки из таблицы sales. Такой триггер называется каскадным триггером delete.

Для начала можно создать две таблицы:

sp_dboption pubs , 'SELECT INTO', TRUE

GO

SELECT * INTO tblShops FROM pubs..stores

SELECT * INTO tblSales FROM pubs..sales

После выполнения этого кода на экран будет выведено:

CHECKPOINTing database that was changed. (6 row(s) affected) (21 row(s) affected)

Просмотреть содержимое полученных таблиц можно, выполнив команду:

SELECT sa.stor_id, st.stor_name FROM tblShops st, tblSales sa WHERE st.stor_id = sa.stor_id

Будем удалять 4 строки с stor_id, равным 7 067. Перед этим создадим для таблицы tblSales триггер, сообщающий, сколько удаляется строк при удале­нии записи о магазине из таблицы tblStores:

CREATE TRIGGER trDelSales ON tblSales FOR DELETE AS

Raiserror ( ⁽%d rows are going to be deleted frOom the sales table', 0, 1, @@rowcount)

Теперь создается триггер для таблицы tblShops:

CREATE TRIGGER trDelShops

ON tblShops

FOR DELETE AS

DELETE tblSales FROM deleted WHERE deleted.stor_id = tblShops.stor_id

Удаление из таблицы tblShops, например, магазина под названием News&Brews наглядно демонстрирует работу созданных триггеров:

DELETE FROM tblShops

WHERE tblShops.stor_id = '7067'

Результат:

4 rows are going to be deleted form sales table (1 row(s) affected).

Триггеры также применяются для поддержки правил. Конечно, для этого час­то достаточно использования ограничений ANSI, значений по умолчанию или пользовательских типов данных, однако при необходимости обращения к другим таблицам триггеры оказываются совершенно незаменимыми. Кроме того, при помощи триггеров реализуется механизм ссылочной целостности. Нужно отметить, что триггеры изначально были разработаны именно для этой цели. Они особенно эффективны при каскадном удалении и обновлении дан­ных. При изменении данных условия триггеров проверяются в последнюю очередь, а в начале проверяются ограничения. То есть если условие ограниче­ния нарушено, то операция отменяется, и триггер не срабатывает.

Отдельное внимание стоит уделить триггерам типа instead of. Если триггер создается с этой опцией, то код триггера выполняется не после заданной пользователем (или удаленной программой) команды, а вместо нее. Например, разумно использовать триггеры instead of для сообщений о невоз­можности удаления какого-либо объекта. Разумеется, эту функцию можно реализовать и с помощью триггера after, однако в этом случае придется отменять уже проделанную операцию, что неприемлемо для высоко загру­женных систем, где ведется строгий контроль производительности.

Хранимые процедуры

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

Назначение хранимых процедур

Хранимая процедура — это последовательность компилированных операторов Transact-SQL, хранящихся в системной базе данных SQL Server. Хранимые процедуры предварительно откомпилированы, поэтому эффективность их выполнения выше, чем у обычных запросов. Хранимые процедуры работают непосредственно на сервере и хорошо укладываются в модель клиент — сервер.

Существует два вида хранимых процедур: системные и пользовательские.

Системные хранимые процедуры предназначены для получения информации из системных таблиц и выполнения различных служебных операций и осо­бенно полезны при администрировании базы данных. Их имена начинаются с sp_ (stored procedure).

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

Полезность хранимых процедур определяется в первую очередь высокой (по сравнению с обычными T-SQL запросами) скоростью их выполнения. Кро­ме того, они являются средством систематизации часто выполняемых опе­раций. При выполнении в первый раз хранимой процедуры можно выделить ряд этапов.

1. Процедура разбивается на отдельные компоненты лексическим анализа­
   тором выражений.
   
2. Компоненты, ссылающиеся на объекты базы данных (таблицы, индексы,
   представления и т. п.), сопоставляются с этими объектами с предвари­
   тельной проверкой их существования. Этот процесс носит название раз­
   решение ссылок.
   
3. В системной таблице syscomments сохраняется исходный текст процеду­ры, а в таблице sysobjects — ее название.
   

4. Создается предварительный план выполнения запроса. Этот предвари­
   тельный план называется нормализованным планом или деревом запроса и
   хранится в системной таблице sysprocedures.
   
5. При первом выполнении хранимой процедуры дерево запроса считывает-
   ся и окончательно оптимизируется. Выполняется ранее созданный план
   процедуры.
   

Такая схема дает возможность при повторных вызовах не тратить время на синтаксический анализ, разрешение ссылок и компиляцию дерева запросов.

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

Использование хранимых процедур имеют еще ряд дополнительных пре­имуществ.

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

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

Хранимые процедуры — мощное средство обработки данных. Системные хранимые процедуры играют очень важную роль в администрировании и поддержке базы данных. Пользовательские хранимые процедуры применя­ются при решении практически любых задач. Кроме того, пользователь мо­жет получить право выполнения хранимой процедуры, даже если он не име­ет права доступа к объектам, к которым обращается процедура.

Создание и использование хранимых процедур

Хранимые процедуры создаются при помощи оператора create procedure. Процедура создается в текущей базе данных или, если это временная хра­нимая процедура, во временной базе tempdb. Для создания необходимо об­ладать правом вызова оператора create procedure.

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

П Имя хранимой процедуры подчиняется правилам по именованию иден­тификаторов.

• Во время выполнения хранимой процедуры все объекты, на которые она
  ссылается, должны присутствовать в базе данных. Однако существует
  свойство (позднее связывание имени), которое позволяет ссылаться на
  несуществующий объект во время компиляции. Кроме того, хранимая
  процедура при создании может генерировать временные объекты и затем
  ссылаться на них при запуске.
  
• В хранимой процедуре нельзя, создав объект, удалить его или создать за­
  ново под тем же именем.
  
• Хранимая процедура имеет не более 1 024 параметров.
  
• В хранимой процедуре можно ссылаться на временные таблицы. Все ло­кальные временные таблицы по окончании ее выполнения удаляются.
  

• В хранимых процедурах нельзя применять следующие операторы созда­ния объектов: create default, create procedure, create view, create
  

RULE И CREAT TRIGGER.

• Позволяется создавать процедуры, с уровнем вложенности, равным 32.
  
• Если в хранимой процедуре используется оператор select * и в базовую
  таблицу добавлены столбцы после создания этой процедуры, то новые
  столбцы не будут отображаться при ее выполнении. Для того чтобы уст­
  ранить это обстоятельство, необходимо использовать оператор alter
  

PROCEDURE.

Синтаксис оператора create procedure:

CREATE PROC[EDURE] имя_процедуры {; число}

[(Эпараматр тип_данных} [VARYING] [= значение_по_умолчанию] [OUTPUT] ] [ , ...п]

[WITH {RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION}] [FOR APPLICATIONS] AS onepaop_SQL [... n]

Как уже было сказано выше, хранимые процедуры могут принимать пара­метры. Рассмотрим их синтаксис:

Эпараметр тип_данных [ = значение_по_умолчению I NULL] [VARYING] [OUTPUT]

Ключевое слово параметр задает имя параметра хранимой процедуры. Ко­личество параметров не может превышать 1 024. Тип данных может быть любым системным или пользовательским типом, кроме Image. Далее опре­деляется значение параметра по умолчанию или null (параметр не опреде­лен). Ключевое слово output определяет возвращаемость или невозвращаемость параметра. Рассмотрим использование процедур с параметрами на простом примере:

CREATE PROCEDURE scores

@sl SMALLINT,

@s2 SMALLINT,

@S3 SMALLINT,

@s4 SMALLINT,

@s5 SMALLINT,

@myAvg SMALLINT OUTPUT

AS SELECT @myAvg = (@sl + @ si + @s3 + @s4 + @s5) / 5

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

DECLARE @AvgScore SMALLINT

EXEC scores 10, 9, 8, 8, 10, ©AvgScore OUTPUT

SELECT 'Average score is: ' , @AvgScore

GO

В результате на экран будет выведен следующий текст:

Average score is: 9 (1 row(s) affected)

Хранимые процедуры могут создаваться и использоваться не только на ло­кальных машинах, но и на удаленных. Для этого должны быть выполнены следующие три требования:

1. Сервер должен допускать удаленные подключения. Эта опция задается
   при инсталляции и по умолчанию включена.
   
2. Оба сервера должны быть зарегистрированы друг у друга в таблицах
   sysservers.
   
3. Оба сервера должны иметь в своих таблицах syslogins сведения об учетной
   записи пользователя.
   

Архитектура многопользовательских СУБД

Архитектура систем баз данных ANSI/SPARC в зависимости от точки зре­ния определяет для одной и той же БД три различных уровня описания. Основным назначением трехуровневой архитектуры является обеспечение независимости от данных. В этом разделе предлагается посмотреть на базу данных несколько иначе, а именно — кто и в каком порядке может исполь­зовать данные, хранимые в базе данных.

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

При переходе к многопользовательскому режиму, а здесь есть только один путь — интеграция компьютеров в локальные сети, как следствие этого про­цесса, возникает возможность распределения приложений, работающих с единой базой данных, и даже самой базы данных по созданной сети.

Тенденции развития многопользовательских систем

Традиционной архитектурой многопользовательских систем, которая сложи­лась до появления ПК, считалась схема, при которой один мощный компь­ютер с единственным процессором был соединен с несколькими пользова­тельскими терминалами, не имеющими для хранения и обработки данных собственных ресурсов. Системы распределенной обработки данных строи­лись на мультипрограммных операционных системах и использовали цен­трализованное хранение БД на устройствах внешней памяти центральной ЭВМ и терминальный многопользовательский режим доступа к ней. СУБД и приложения также располагались на центральной ЭВМ. Пользовательские приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. Естественно, что при такой архитектуре основная и чрезвычайно большая нагрузка воз­лагалась на центральный компьютер, который должен выполнять не только действия прикладных программ и СУБД, но и большую работу по обслужи­ванию терминалов (рис. 2.2).

Первой системой, работающей в многопользовательском режиме, была СУБД SYSTEM R, разработанная фирмой IBM. В ней были реализованы основные принципы синхронизации, применяемые при распределенной об­работке данных, которые до сих пор являются базисными практически во всех коммерческих СУБД.




Рис. 2.2. Схема ранней многопользовательской системы

С момента появления СУБД SYSTEM R прошел длительный период време­ни. В этот период происходили значительные колебания в вычислительных ресурсах и схемах их применения, используемых для хранения и обработки информации. Наблюдались и отдельные тенденции в этих колебаниях:

1. Downsizing — децентрализация;
   
2. UpSizing — централизация;
   
3. RightSizing — определение размера и схемы в соответствии с реальной
   ситуацией.
   

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

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

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



Различные варианты реализации режимов работы систем б,аз данных можно представить в виде схемы (рис. 2.3).



Рис. 2.3. Технологии использования БД

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

Из всех режимов, показанных на рис. 2.3, наибольшие проблемы возникают при реализации баз данных с параллельным доступом. Исключим здесь из рассмотрения распределенные БД, материализация которых имеет много особенностей, и сосредоточим свое внимание на технологиях параллельного или распределенного доступа, применяемых в настоящее время для работы с централизованными БД. Наиболее часто упоминаются в соответствующей литературе в этом плане два типа технологий: технология файлового сервера и технология "клиент — сервер", которые являются двухуровневыми струк­турами. Поскольку, как будет показано ниже, первую можно считать част­ным случаем второй, то в дальнейшем будем все технологии такого рода относить к технологиям "клиент — сервер", последующее развитие которых, стремление устранить их некоторые недостатки вызвали появление дру­гих моделей и структур совместной работы клиентов и сервера. Рассмот­рим подробнее модели, которые были получены в рамках двухуровневых структур.


Модели двухуровневой технологии

"клиент — cервер"

Еще раз подчеркнем, что общая цель систем баз данных — поддержка раз­работки и выполнения приложений баз данных. Систему баз данных можно рассматривать как систему, где осуществлено распределение процесса вы­полнения по принципу взаимодействия двух программных процессов, один из которых в этой модели называется "клиентом", а другой, обслуживающий клиента, — сервером (машина, хранящая базы данных). Клиентский процесс запрашивает некоторые услуги, а серверный процесс обеспечивает их вы­полнение. При этом предполагается, что один серверный процесс может обслужить множество клиентских процессов (рис. 2.4).



Рис. 2.4. Структура системы БД с выделением клиентов и сервера

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

Клиенты — это различные приложения, которые выполняются над СУБД.

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

1. функции ввода и отображения данных;
   
2. прикладные функции, определяющие основные алгоритмы решения за­
   дач приложения;
   
3. функции обработки данных внутри приложения; О функции управления информационными ресурсами;
   
4. служебные функции, играющие роль связок между функциями первых
   четырех групп.
   

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

1. формирование экранных изображений;
   
2. чтение и запись в экранные формы информации;
   
3. управление экраном;
   
4. обработка движений мыши и нажатий клавиш клавиатуры.
   

Прикладные функции определяют основные алгоритмы решения конкретных задач приложения. Обычно код приложения пишется с использованием раз­личных языков программирования, таких как С, Cobol, SmallTalk, Pascal.

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

Функции управления информационными ресурсами (процессор управления дан­ными) — это собственно СУБД, которая обеспечивает хранение и управле­ние базами данных.

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

В монолитном исполнении все перечисленные компоненты приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.

В децентрализованной архитектуре эти части приложения распределяются по сети.

Если все пять компонентов приложения распределяются только между дву­мя процессами, которые выполняются на двух платформах: на клиенте и на сервере, то такая модель называется двухуровневой. Она имеет несколько ос­новных разновидностей. Рассмотрим их.

Файловый сервер

Модель файлового сервера называется моделью удаленного управления данными. Данная модель предполагает следующее распределение функций: на клиенте располагаются почти все части приложения: презентационная часть приложе­ния, прикладные функции, а также функции управления информационными ресурсами. Файловый сервер содержит файлы, необходимые для работы при­ложений и самой СУБД и поддерживает доступ к файлам (рис. 2.5).



Рис. 2.5. Модель файлового сервера

СУБД посылает запросы файловому серверу по всем необходимым ей дан­ным. Запрос клиента формулируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента. Далее на кли­енте СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, то принимается решение о передаче следующего блока информации и т. д. Передача информации с сервера про­изводится до тех пор, пока не будет получен ответ на запрос клиента.

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


Помимо этого недостатка использование файлового сервера несет еще и другие:

• на каждой рабочей станции должна находиться полная копия СУБД;
  
• управление параллельностью, восстановлением и целостностью усложня­
  ется, поскольку доступ к одним и тем же файлам могут осуществлять
  сразу несколько экземпляров СУБД;
  

• узкий спектр операций манипулирования данными, который определяет­ся только файловыми командами;
  
• защита данных осуществляется только на уровне файловой системы.
  

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

Модель удаленного доступа к данным

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

Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 2.6.



Рис. 2.6. Модель удаленного доступа

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

Сервер принимает и обрабатывает запросы со стороны клиентов, проверяет полномочия пользователей, гарантирует соблюдение ограничений целостно­сти, выполняет обновление данных, выполняет запросы и возвращает ре­зультаты клиенту, поддерживает системный каталог, обеспечивает парал­лельный доступ к базе данных и ее восстановление. К тому же резко уменьшается загрузка сети, так как по ней от клиентов к серверу пере­даются не файловые команды, а запросы на SQL, и их объем существенно меньше. В ответ на запросы клиент получает только данные, соответствую­щие запросу, а не блоки файлов, как в модели файлового сервера. Основное достоинство данной технологии в том, что стандартом при общении прило­жения-клиента и сервера становится язык SQL.


Тем не менее данная технология обладает и рядом недостатков:

• запросы на языке SQL при интенсивной работе клиентских приложений могут существенно загрузить сеть;
  
• презентационные и прикладные функции приложения должны быть по­вторены для каждого клиентского приложения;
  
• сервер в этой модели играет пассивную роль, поэтому функции управле­ния информационными ресурсами должны выполняться на клиенте.
  

Модель сервера баз данных

Технологию "клиент — сервер" поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Только та технология, которую они поддерживают, является дальнейшим развитием только что рассмотренной модели удаленного доступа к данным. В основу данной мо­дели добавлен механизм хранимых процедур и механизм триггеров.

Механизм хранимых процедур позволяет создавать подпрограммы, работаю­щие на сервере и управляемые его процессами. Подобные подпрограммы могут быть активизированы вызывающим их приложением. Кроме того, они могут быть вызваны правилами, поддерживающими целостность данных, или триггерами. Хранимые процедуры тесно взаимодействуют с оптимиза­тором сервера, что позволяет получить высокую производительность при обработке данных.

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

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

Триггер — это особый тип хранимой процедуры, реагирующий на возникно­вение определенного события в БД. Он активизируется при попытке изме­нения данных — при операциях добавления, обновления и удаления. Триг­геры определяются для конкретных таблиц БД. Они дают возможность поддерживать целостность базы данных, не полагаясь на программное обес­печение приложений. Ядро СУБД проводит контроль всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении со­ответствующего события сервер запускает соответствующий триггер. Триггер — это фильтр, применяемый после выполнения операции. Если триггер вызывает ошибку в запросе, обновление информации не произво­дится, а в приложение, выполняющее это действие, возвращается сообще­ние об ошибке. Триггер рассматривается как единое целое — как одна тран­закция, которая либо фиксируется, либо откатывается.

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





Рис. 2.7. Модель сервера БД

И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что существенно уменьшает дубли­рование алгоритмов обработки данных в разных клиентских приложениях. Для написания хранимых процедур и триггеров используется расширение стандартного языка SQL — встроенный SQL.

При всех положительных качествах данной модели у нее все же есть один недостаток — очень большая загрузка сервера.

Для разгрузки сервера была предложена трехуровневая модель, которая бу­дет рассмотрена в следующем подразделе.

Сейчас же, завершая анализ двухуровневых моделей с архитектурой "клиент-сервер", рассмотрим возможные варианты топологии таких систем.







Рис. 2.8. Топологии двухуровневых систем с архитектурой "клиент — сервер"

(а — "один клиент — один сервер"; б — "несколько клиентов — один сервер";

в — "несколько клиентов — несколько серверов")

Первым шагом в создании механизма организации взаимодействия процес­сов типа "клиент" и "сервер" можно считать выделение функции управления данными в самостоятельную группу — сервер, который позволил, в частно­сти, поместить сервер на одну машину, а программный интерфейс с пользо­вателем — на другую, осуществляя взаимодействие между ними по сети. То­пологию такой модели взаимодействия пользователя с сервером относят к типу "один клиент — один сервер" (рис. 2.8, а), где сервер обслуживает за­просы только одного клиента и для обслуживания нескольких клиентов тре­буется запустить соответствующее число серверов. Естественно, что реали­зация такой модели предъявляла повышенные требования к ресурсам ЭВМ, на которой запускались все серверные процессы, и отличалась сложностью обеспечения взаимодействия серверных процессов.

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

Дальнейшее развитие системы "клиент — сервер" получили при применении СУБД для мультипроцессорных платформ, где количество актуальных сер­веров может быть согласовано с количеством процессоров в системе. Топо­логия подобных систем такова, что клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером, который вы­полняет только функции диспетчеризации запросов к актуальным серверам. Подобные системы относят к системам с виртуальным сервером, а их топо­логию — к виду "несколько клиентов — несколько серверов" (рис. 2.8, в). Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. Эта архитектура связана с вопро­сами распараллеливания выполнения одного пользовательского запроса несколькими серверными процессами.

Сервер приложений. Трехуровневая модель

Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Ар­хитектура трехуровневой модели приведена на рис. 2.9.



Рис. 2.9. Архитектура трехуровневой модели

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

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

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

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