Г.М. Ладыженский
Oracle CIS, (+7 095) 258-41-80 , glodigen@ru.oracle.com
Раздел 2. Сервер базы данных
Раздел 2. Сервер базы данных
Современная СУБД должна удовлетворять ряду требований, важнейшее из которых - высокопроизводительный интеллектуальный сервер базы данных. Далее мы рассмотрим основные тенденции его развития и обсудим конкретные механизмы, в которых они находят свое воплощение.
Процесс технического совершенствования сервера базы данных пока остается невидимым для большинства пользователей современных СУБД. Поэтому при выборе той или иной системы они, как правило, не учитывают ни технический уровень решений, заложенных в механизм его функционирования, ни влияние этих решений на общую производительность СУБД. Между тем ее качество определяется отнюдь не богатством интерфейсов с пользователем, не разнообразием средств поддержки разработок, а в первую очередь зависит от особенностей архитектуры сервера базы данных. Далее будут рассмотрены модели технологии "клиент-сервер", определено место сервера БД в этих моделях и кратко описаны важнейшие механизмы сервера БД - процедуры, правила (триггеры), события. Последние будут проиллюстрированы примерами, в которых использован диалект SQL, принятый в СУБД Ingres.
2.1. Технология и модели "клиент-сервер".
"Клиент-сервер" - это модель взаимодействия компьютеров в сети. Как правило, компьютеры не являются равноправными. Каждый из них имеет свое, отличное от других, назначение, играет свою роль. Некоторые компьютеры в сети владеют и распоряжается информационно-вычислительными ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база данных. Другие же компьютеры имеют возможность обращаться к этим службам, пользуясь услугами первых. Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса, а компьютер, желающий им воспользоваться - клиентом. Конкретный сервер определяется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь идет о сервере баз данных, назначение которого - обслуживать запросы клиентов, связанные с обработкой данных; если ресурс - это файловая система, то говорят о файловом сервере, или файл-сервере, и т. д.
В сети один и тот же компьютер может выполнять роль как клиента, так и сервера. Например, в информационной системе, включающей персональные компьютеры, большую ЭВМ и мини-компьютер под управлением UNIX, последний может выступать как в качестве сервера базы данных, обслуживая запросы от клиентов - персональных компьютеров, так и в качестве клиента, направляя запросы большой ЭВМ.
Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть клиентами. Так, ядро реляционной SQL-ориентированной СУБД часто называют сервером базы данных, или SQL-сервером, а программу, обращающуюся к нему за услугами по обработке данных - SQL-клиентом.
Рисунок 1.
Системы с централизованной архитектурой.
Первоначально СУБД имели централизованную архитектуру (рис.1). В ней сама СУБД и прикладные программы, которые работали с базами данных, функционировали на центральном компьютере (большая ЭВМ или мини-компьютер). Там же располагались базы данных. К центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест пользователей. Все процессы, связанные с обработкой данных, как то: поддержка ввода, осуществляемого пользователем, формирование, оптимизация и выполнение запросов, обмен с устройствами внешней памяти и т.д., выполнялись на центральном компьютере, что предъявляло жесткие требования к его производительности. Особенности СУБД первого поколения напрямую связаны с архитектурой систем больших ЭВМ и мини-компьютеров и и адекватно отражают все их преимущества и недостатки. Однако нас больше интересует современное состояние многопользовательских СУБД, для которых архитектура "клиент-сервер" стала фактическим стандартом.
Для более четкого представления об ее особенностях необходимо рассмотреть несколько моделей технологии "клиент-сервер", что и будет сделано.
Если предполагается, что проектируемая информационная система (ИС) будет иметь технологию "клиент-сервер", то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер. Иными словами, часть функций прикладной программы (или, проще, приложения) будет реализована в программе-клиенте, другая - в программе-сервере, причем для их взаимодействия будет определен некоторый протокол.
Основной принцип технологии "клиент-сервер" заключается в разделении функций стандартного интерактивного приложения на четыре группы, имеющие различную природу. Первая группа - это функции ввода и отображения данных. Вторая группа объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы - открытие счета, перевод денег с одного счета на другой и т.д.). К третьей группе относятся фундаментальные функции хранения и управления информационными ресурсами (базами данных, файловыми системами и т.д.). Наконец, функции четвертой группы - это служебные функции (играющие роль связок между функциями первых трех групп.
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
· компонент представления, реализующий функции первой группы;
· прикладной компонент, поддерживающий функции второй группы;
· компонент доступа к информационным ресурсам, поддерживающий функции третьей групп, а также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).
Различия в реализациях технологии "клиент-сервер" определяются четырьмя факторами. Во-первых, тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов. Во-вторых, тем, какие механизмы программного обеспечения используются для реализации функций всех трех групп. Во-третьих, как логические компоненты распределяются между компьютерами в сети. В-четвертых, какие механизмы используются для связи компонентов между собой.
Выделяются четыре подхода, реализованные в моделях:
· модель файлового сервера (File Server - FS);
· модель доступа к удаленным данным (Remote Data Access - RDA);
· модель севера базы данных (DataBase Server - DBS);
· модель сервера приложений (Application Server - AS).
Рисунок 2.
Модель файлового сервера.
FS-модель является базовой для локальных сетей персональных компьютеров. Не так давно она была исключительно популярной среди отечественных разработчиков, использовавших такие системы, как FoxPRO, Clipper, Clarion, Paradox и т.д. Суть модели проста и всем известна. Один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы (например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (то есть к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены компонент представления и прикладной компонент (рис.2). Протокол обмена представляет собой набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.
FS-модель послужила фундаментом для расширения возможностей персональных СУБД в направлении поддержки многопользовательского режима. В таких системах на нескольких персональных компьютерах выполняется как прикладная программа, так и копия СУБД, а базы данных содержатся в разделяемых файлах, которые находятся на файловом сервере. Когда прикладная программа обращается к базе данных, СУБД направляет запрос на файловый сервер. В этом запросе указаны файлы, где находятся запрашиваемые данные. В ответ на запрос файловый сервер направляет по сети требуемый блок данных. СУБД, получив его, выполняет над данными действия, которые были декларированы в прикладной программе.
К технологическим недостаткам модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипуляции с данными ("данные - это файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т.д. Собственно, перечисленное не есть недостатки, но - следствие внутренне присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают, когда FS-модель используют не по назначению, например, пытаются интерпретировать как модель сервера базы данных. Место FS-модели в иерархии моделей "клиент-сервер" - это место модели файлового сервера, и ничего более. Именно поэтому обречены на провал попытки создания на основе FS-модели крупных корпоративных систем - попытки, которые предпринимались в недавнем прошлом и нередко предпринимаются сейчас.
Рисунок 3.
Модель доступа к удаленным данным.
Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер. В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто прикладные функции. Доступ к информационным ресурсам обеспечивается либо операторами специального языка (языка SQL, например, если речь идет о базах данных), либо вызовами функций специальной библиотеки (если имеется соответствующий интерфейс прикладного программирования - API).
Клиент направляет запросы к информационным ресурсам (например, к базам данных) по сети удаленному компьютеру. На нем функционирует ядро СУБД, которое обрабатывает запросы, выполняя предписанные в них действия, и возвращает клиенту результат, оформленный как блок данных (рис.3). При этом инициатором манипуляций с данными выступают программы, выполняющиеся на компьютерах-клиентах, в то время как ядру СУБД отводится пассивная роль - обслуживание запросов и обработка данных. В Разделе 2 будет показано, что такое распределение обязанностей между клиентами и сервером базы данных не догма - сервер БД может играть более активную роль, чем та, которая предписана ему традиционной парадигмой.
RDA-модель избавляет от недостатков, присущих как системам с централизованной архитектурой, так и системам с файловым сервером.
Прежде всего перенос компонента представления и прикладного компонента на компьютеры-клиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов операционной системы. Сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций. Это становится возможным благодаря отказу от терминалов и оснащению рабочих мест компьютерами, которые обладают собственными локальными вычислительными ресурсами, полностью используемыми программами переднего плана. С другой стороны, резко уменьшается загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как в системах с файловым сервером), а запросы на языке SQL, их объем существенно меньше.
Основное достоинство RDA-модели - унификация интерфейса "клиент-сервер" в виде языка SQL. Действительно, взаимодействие прикладного компонента с ядром СУБД невозможно без стандартизованного средства общения. Запросы, направляемые программой ядру, должны быть понятны обоим. Для этого их следует сформулировать на специальном языке. Но в СУБД уже существует язык SQL, о котором уже шла речь . Поэтому целесообразно использовать его не только в качестве средства доступа к данным, но и стандарта общения клиента и сервера.
Такое общение можно сравнить с беседой нескольких человек, когда один отвечает на вопросы остальных (вопросы задаются одновременно). Причем делает это он так быстро, что время ожидания ответа приближается к нулю. Высокая скорость общения достигается прежде всего благодаря четкой формулировке вопроса, когда спрашивающему и отвечающему не нужно дополнительных консультаций по сути вопроса. Беседующие обмениваются несколькими короткими однозначными фразами, им ничего не нужно уточнять.
К сожалению, RDA-модель не лишена ряда недостатков. Во-первых, взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть. Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные). Более подробно о недостатках RDA-модели сказано в п. 2.3.1.
Рисунок 4.
Модель сервера базы данных.
Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель (рис. 4). Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД. Более подробно о хранимых процедурах рассказано в п. 2.3.3.
В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД. Достоинства DBS-модели очевидны: это и возможность централизованного администрирования прикладных функций, и снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур), и возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. К недостаткам модели можно отнести ограниченность средств, используемых для написания хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональным возможностям с языками третьего поколения, такими как C или Pascal. Сфера их использования ограничена конкретной СУБД, в большинстве СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.
На практике часто используется смешанные модели, когда поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель). Так или иначе современные многопользовательские СУБД опираются на RDA- и DBS-модели и при создании ИС, предполагающем использование только СУБД, выбирают одну из этих двух моделей либо их разумное сочетание.
Рисунок 5.
Модель сервера приложений.
В AS-модели (рис.5) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за интерфейс с пользователем (то есть осуществляет функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов - базы данных, очереди, почтовые службы и др.
RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с компонентом представления, во-втором - интегрируется в компонент доступа к информационным ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций, которые выделяются как особый вид программного обеспечения. Мониторы транзакций - предмет Раздела 4.
В заключение отметим, что, часто, говоря о сервере базы данных, подразумевают как компьютер, так и программное обеспечение - ядро СУБД. При описании архитектуры "Клиент-сервер" под сервером базы данных мы имели в виду компьютер. Далее сервер базы данных будет пониматься как программное обеспечение - ядро СУБД.
2.2. Эволюция серверов баз данных
В период создания первых СУБД технология "клиент-сервер" только зарождалась. Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия такого типа, в современных же системах он жизненно необходим.
Чтобы понять суть проблемы, рассмотрим эволюцию серверов баз данных. Первое время доминировала модель, когда управление данными (функция Сервера) и взаимодействие с пользователем были совмещены в одной программе (рис.6a). Затем функции управления данными были выделены в самостоятельную группу - сервер, однако модель взаимодействия пользователя с сервером соответствовала парадигме "один-к-одному" (рис.6б), то есть сервер обслуживал запросы ровно одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов. Выделение сервера в отдельную программу - революционный шаг, позволяющий, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем - на другую, осуществляя взаимодействие между ними по сети (рис.7). Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.
Рисунок 6.
Централизованная архитектура (а) и архитектура "один к одному"
(б).
Рисунок 7.
Размещение клиента и сервера на различных машинах.
Рисунок 8.
Многопотоковая архитектура.
Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис.8). Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей (trashing). С другой стороны, возможность взаимодействия с одним сервером многих клиентов позволяет в полной степени использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой "один-к-одному" будет создано 50 копий процессов СУБД для 50 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один сервер.
Однако такое решение привносит новую проблему. Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается заменой выделенного сервера на диспетчер или виртуальный сервер (virtual server) (рис.9), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчеризации запросов к актуальным серверам. Таким образом, в архитектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает возможности управления взаимодействием "клиент-сервер". Во-первых, становиться невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными - нет возможности устанавливать приоритеты для обслуживания запросов.
Рисунок 9.
Архитектура с виртуальным сервером.
Подобная организация взаимодействия "клиент-сервер" является аналогом банка, где имеется несколько окон кассиров, и банковский служащий (диспетчер), направляет каждого вновь пришедшего посетителя (клиента) к свободному кассиру (актуальному серверу). Система работает нормально, пока все посетители равноправны (имеют равные приоритеты), однако, стоит лишь появиться посетителям с высшим приоритетом (которые должны обслуживаться в специальном окне), как возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной обработки транзакций, однако именно эту возможность не может предоставить архитектура систем с диспетчеризацией.
Рисунок 10.
Многопотоковая мультисерверная архитектура.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если эти два условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколькими серверами (multi-threaded, multi-server architecture), представленной на рис.10.
2.3. Активный сервер
Действительно профессиональные СУБД обладают мощным активным сервером базы данных. Это не просто технические новшество. Идея активного сервера коренным образом изменяет представление о роли, масштабах и принципах использования СУБД, а в чисто практическом плане позволяет выбрать современные, эффективные методы построения глобальных информационных систем.
Идея активного интеллектуального сервера БД возникла не сама по себе - она стала ответом на задачи реальной жизни. В Разделе 1 было сформулировано общее представление о базе данных. Однако вдумчивый читатель может его расширить. Действительно, объекты реального мира, помимо непосредственных, прямых связей, имеют друг с другом более сложные причинно-следственные связи; они динамичны, находятся в постоянном изменении. Эти связи и процессы должны каким-то образом отражаться и в базе данных, если мы имеем в виду не статичное хранилище данных, а информационную модель маленькой части реального мира. Иными словами, в базе данных, помимо собственно данных и непосредственных связей между ними, должны хранится знания о данных, а сама база должна адекватно отражать процессы, происходящие в реальном мире. Значит, необходимо иметь средства хранения и управления такой информацией.
2.3.1. Актуальные задачи
Указанные требования выливаются в решение следующих задач.
Во-первых, необходимо, чтобы база данных в любой момент правильно отражала состояние предметной области - данные должны быть взаимно непротиворечивыми. Пусть, например, база данных Кадры хранит сведения о рядовых сотрудниках, отделах, в которых они работают, и их руководителях. Нужно учесть следующие правила: каждый сотрудник должен быть подчинен реальному руководителю; если руководитель уволился, то все его сотрудники переходят в подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный руководитель; если отдел сокращен, то его руководитель переводится в резерв на выдвижение и т.д.
Во-вторых, база данных должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rule). Завод может нормально работать, только в том случае, если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно, как только количество деталей некоторого типа станет меньше минимально допустимого, завод должен докупить эти детали в нужном количестве.
В-третьих, необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений, и адекватная реакция на них. Например, в автоматизированной системе управления производством датчики контролируют температуру инструмента; она периодически передается в базу данных и там сохраняется; как только температура инструмента превышает максимально возможное значение, он отключается.
В-четвертых, необходимо, чтобы возникновение некоторой ситуации в базе данных четко и оперативно влияло на ход выполнения прикладной программы. Многие программы требуют оперативного оповещения о всех происходящих в базе данных изменениях. Так, в системах автоматизированного управления производством необходимо моментально уведомлять программы о любых изменениях параметров технологических процессов, когда последние хранятся в базе данных. Почтовая служба требует оперативного уведомления получателя, как только получено новое сообщение. Брокер на бирже СУБД должен немедленно получать сообщение об изменении цены акций, поскольку промедление в несколько секунд грозит большими потерями.
Оповещение о возникновении определенного состояния базы данных и изменениях в ней может потребоваться в любом учреждении для контроля прохождения документов. Если документ, который должен быть просмотрен и последовательно завизирован несколькими руководителями, хранится в базе данных, то каждый из них в свою очередь будет оперативно уведомлен о поступлении документа ему на подпись.
Важная проблема СУБД - контроль типов данных. В Разделе 1 уже говорилось о том, что в базе данных каждый столбец в любой таблице содержит данные некоторых типов. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стандартных типов данных, разрешенных в СУБД. Стало быть, в базе данных можно хранить только данные стандартных типов - числа, целые и вещественные, строки символов, данные типа "дата", "время" и "денежная единица" - репертуар реальной СУБД ограничен именно этими типами данных. Как же быть с нестандартными данными? Ведь в реальной жизни требуется хранить и обрабатывать данные в значительно более широком диапазоне - плоскостные и пространственные координаты, единицы различных метрик, пятидневные недели (рабочая неделя, в которой сразу после пятницы следует понедельник), дроби, не говоря уже о графических изображениях.
2.3.2. Традиционные подходы
До недавнего времени функции управления знаниями оставались за границами возможностей реляционных СУБД или были очень ограниченны.
Знания о предметной области традиционно включались непосредственно в прикладные программы, для чего использовались возможности процедурных языков программирования. Этот подход в подавляющем большинстве случаев преобладает и сейчас.
Рассмотрим, например, базу данных Склад, хранящую информацию о наличии деталей на заводском складе. Прикладная программа Складской Учет обеспечивает учет имеющихся и вновь поступающих деталей. В ее функции входит просмотр содержимого базы данных, добавление информации о новых деталях, замена снятых с производства деталей на новые и т.д. В программе реализованы некоторые правила, например "В любой момент времени количество деталей типа "втулка" не должно быть меньше 1000" (ситуация со втулками на производстве всегда напряженная). Нетрудно понять, что оно должно применяться только в том случае, когда количество втулок уменьшается. Значит, нужно проверить: а не уменьшилось ли оно настолько, что стало меньше 1000. Если это произошло, то нужно срочно направить на завод-изготовитель письмо с просьбой отгрузить нужное количество втулок, если, конечно, такое письмо не было направлено до этого.
А чтобы это правило применялось, программа должна периодически, через определенные интервалы времени опрашивать значение в столбце Количество таблицы Деталь для всех строк, которые удовлетворяют условию Деталь. Название ="Втулка". Если это значение становится меньше 1000, программа должна послать письмо на завод-изготовитель.
Фрагмент программы указан в Примере 1.
...
SELECT Количество, Номер_поставщика
FROM Деталь
WHERE Название = "Втулка";
IF (Количество < 1000)
THEN
BEGIN
SELECT Адрес_поставщика
FROM Поставщик
WHERE Номер = Номер_поставщика;
Послать письмо(Адрес_поставщика, 1000-Количество);
END
ELSE Ничего не делать
...
{ ...
ВЫБРАТЬ Количество, Номер_поставщика
ИЗ Деталь
ГДЕ Название = "Втулка";
ЕСЛИ (Количество < 1000) ТО
НАЧАТЬ
ВЫБРАТЬ Адрес_поставщика
ИЗ Поставщик
ГДЕ Номер = Номер_поставщика;
Послать письмо(Адрес_поставщика, 1000-Количество);
ЗАКОНЧИТЬ
ИНАЧЕ Ничего не делать
... }
Пример 1.
В чем недостатки такого подхода?
Во-первых, реализация правил перегружает прикладную программу и усложняет ее написание и понимание. Во-вторых, и это более существенный недостаток, когда изменяется само правило, изменения должны быть отражены в тексте программы. Когда же правила изменяются кардинальным образом, разработчику приходится пересматривать логику выполнения программы и практически переписывать ее заново.
Удобнее оставить за прикладными программами только базовые алгоритмы управления данными, а часто меняющиеся правила, которые действуют во внешнем мире, вынести за рамки программ и оформить как-то иначе. В противном случае разработчиков ждут неприятные сюрпризы.
Рассмотрим для примера прикладную банковскую систему. При ее создании разработчики в алгоритмах управления данными учли те правила финансовой деятельности, которые диктовались действующим законодательством. Предположим теперь, что законы претерпели некоторые изменения (что в наше время происходит слишком часто!). Естественно, эти изменения должны быть немедленно отражены и в алгоритмах управления данными, что повлечет за собой необходимость модификации всех прикладных программ, составляющих информационную систему.
Это огромная работа - нужно исправить и отладить программы, откомпилировать и собрать их, внести изменения в документацию и переобучить персонал.
С другой стороны, правила, о которых идет речь, не должны противоречить друг другу. Когда их реализует группа разработчиков, нет никаких гарантий взаимной непротиворечивости правил. Фактически правила должен формулировать и контролировать один человек - администратор базы данных. При традиционном подходе практически невозможно обеспечить централизованный контроль за взаимным соответствием правил, если они разбросаны по многим программам, и, что более важно для коммерческих организаций, практически невозможно проконтролировать преднамеренное искажение правил программистами.
Таким образом, включение правил в прикладные программы, когда серверу отводится пассивная роль поставщика и хранителя данных, а вся интеллектуальная часть реализуется в программе, представляет собой устаревшую технологию. Она чревата большими накладными расходами при изменении правил и не обеспечивает централизованного контроля за их непротиворечивостью. Ясно, что эта технология имеет в своей основе столь популярную ныне RDA-модель (о ней речь шла выше).
Традиционное решение задач контроля за состоянием базы данных и уведомления прикладных программ о всех происходящих в ней событиях опирается на механизмы опроса (polling) прикладными программами базы данных, которому присущи следующие недостатки.
Прикладная программа не может непрерывно опрашивать базу данных, так как это приведет к перегрузке сервера бесполезными запросами. Опрос производится через интервалы времени, которые определяет программист. Следовательно, если в базе данных происходят какие-либо изменения, то они выявляются не сразу, а через какое-то время. Именно поэтому традиционное решение не обеспечивает оперативного оповещения, в прикладных же программах, работающих в реальном времени (см. примеры выше), это требование является ключевым. Постоянный опрос базы данных сильно сказывается на производительности системы - программы, опрашивающие базу данных, перегружают своими запросами сервер и сеть. Громоздкие конструкции в тексте программ, реализующие опрос, серьезно затрудняют ее написание и понимание.
Другое важное требование реальной жизни - синхронизация работы нескольких программ, обращающихся к базе данных. Рассмотрим пример. Финансовая система завода должна отслеживать поступление платежей за продукцию на некоторый счет. Как только деньги поступили (все знают, насколько это важное событие - "пришли деньги!"), все прикладные программы, включенные в финансовую систему, должны быть оповещены об этом. После этого каждая из них может предпринять некоторые действия. Так, программа Отгрузка Продукции должна найти в базе данных соответствующий заказ, определить номенклатуру заказанной продукции, ее количество, сроки поставки, сформировать и послать на склад готовой продукции заказ на отгрузку, распечатать сопроводительные документы - иными словами подготовить продукцию к отправке. Программа Бухгалтерия, в частности, должна по дате поступления денег определить, просрочен ли платеж, и, если это так, начислить штраф. Все эти действия активизируются событием в базе данных - поступлением денег на счет (в терминах реляционной СУБД это означает добавление новой строки в таблицу Платежи). Работа всех программ синхронизируется этим событием.
Традиционное решение проблемы синхронизации программ обеспечивается стандартными средствами многозадачной операционной системы. Однако такая синхронизация может быть связана с изменениями, происходящими в базе данных, только посредством постоянного опроса таблицы Платежи. Недостатки такого подхода очевидны - в нем взаимосвязь программ обеспечивается на уровне операционной системы, тогда как эту функцию, безусловно, должна выполнять СУБД. Кроме того, приходится привлекать программы опроса, недостатки которого мы уже обсуждали.
Общепринятый способ преодоления ограничения на типы данных в СУБД - приведение данных новых типов к стандартным. Как правило, данные новых типов рассматриваются как целые или вещественные числа, или как строки символов.
Рассмотрим пример. В ряде стран, в том числе и в США, для измерения длины наряду с привычными мерами метрической системоы используются также футы и дюймы. Правила выполнения арифметических операций в этой системе отличны от десятичной. Так, три фута одиннадцать дюймов плюс один дюйм равно четырем футам ( 3"11" + 1" = 4"). Стандартный набор типов данных не позволяет определить данные в этой системе и оперировать с ними. Они должны быть преобразованы в вещественные числа с плавающей точкой, то есть представлены соответственно, как 3.91666 (три фута одиннадцать дюймов) и 0.08333 (один дюйм). Выполнив операцию сложения (3.91666+0.08333=3.99999), мы убедимся, что такое представление приводит к потере точности (ведь результат должен быть равен четырем!).
Следовательно, прямое приведение новых типов данных к стандартным чревато ошибками - необходимо их преобразование в данные стандартных типов. Функции преобразования данных должны взять на себя прикладные программы (больше некому). В результате получается довольно громоздкая схема. Программа извлекает из базы данных данные новых типов, представленные как стандартные, преобразует и обрабатывает их, затем вновь преобразует и передает серверу для хранения. Сервер в обработке данных новых типов при такой схеме участия не принимает - ведь он рассматривает их как стандартные и будет обрабатывать как стандартные (и тогда возникнут ошибки!).
Сегодня, например, для отечественных банков актуальна проблема больших чисел. Масштаб расчетов настолько возрос, что в некоторых итоговых операциях фигурируют суммы, которые превосходят разрядную сетку для целых чисел. Поэтому в программах приходится преобразовывать целые числа в строки и наоборот, что не упрощает их логику. Хранение и обработка больших целых как вещественных приводит к потере точности, что в финансовой системе недопустимо.
Далее мы увидим, что решение проблемы заключается в определении нового типа данных "большие целые". Как только это сделано, сервер базы данных начинает "понимать" новый тип данных и выполнять над ним все операции, характерные для целых чисел.
Другое важнейшее требование к современным СУБД - возможность хранения неструктурированных объектов большого объема (Binary Large OBjects - BLOB). Отвечая на это требование, разработчики СУБД предусматривают такую возможность. Однако сервер лишь хранит такие объекты, не обладая возможностями их обработки. Например, работая с графическим объектами, сервер не делает различий между изображением автомобиля BMW и структурой ДНК. Сервер вынужден передавать их для интерпретации прикладной программе, которая сможет разобраться, кто есть кто.
Не следует забывать и о проблеме целостности. Если одна программа интерпретирует данные некоторого типа, преобразуя его в собственный формат, то ничто не мешает делать то же самое другой программе с той только разницей, что формат представления тех же данных будет уже другим. Это делает принципиально невозможным контроль целостности данных хотя бы потому, что различные программы интерпретируют их по-разному.
Отметим, что отсутствие в СУБД нестандартных типов данных заметно сказывается на их производительности, так как нормальное взаимодействие клиента и сервера возможно только тогда, когда и тот и другой адекватно воспринимают типы данных, с которыми ведется работа. Если используются типы данных, не известные серверу, то он вынужден передавать клиенту для обработки практически всю базу данных, что перегружает сеть и приводит к потере производительности. Фактически в такой схеме появление нестандартных типов данных приводит к деградации архитектуры системы к архитектуре с файловым сервером. Не понимая нового типа данных, сервер способен лишь послушно сохранять его, не умея сравнивать, сортировать, выполнять какие бы то ни было операции над данными.
С другой стороны, это ограничение приводит к тому, что основная тяжесть обработки данных нестандартных типов ложится на прикладные программы. При этом вопрос о целостности данных остается открытым, поскольку не поддерживается централизованный контроль типов данных, несомненно являющейся функцией сервера базы данных.
Итак, в традиционной технологии решение задач, о которых шла речь выше, ложится целиком на прикладные программы. Недостатки традиционной технологии - следствие того, что традиционно в СУБД в модели взаимодействия "клиент-сервер" последнему отводится в основном пассивная роль. Во-первых, сервер базы данных лишен функций хранения и обработки знаний о предметной области. Во-вторых, за границами возможностей сервера остается контроль за состоянием базы данных и программирование реакции на ее изменения. В-третьих, пассивный сервер не имеет средств отслеживания событий в базе данных, а также средств воздействия на работу прикладных программ и возможностей их синхронизации.
2.3.3. Современные решения
Идеи, реализованные в СУБД третьего поколения (пока, к сожалению, не во всех), заключаются в том, что знания выносятся за рамки прикладных программ и оформляются как объекты базы данных. Функции применения знаний начинает выполнять непосредственно сервер базы данных.
Такая архитектура суть воплощение концепции активного сервера. Она опирается на четыре "столпа":
- процедуры базы данных
- правила (триггеры)
- события в базе данных
- типы данных, определяемые пользователем
Процедуры базы данных
В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д. Ниже будем пользоваться терминологией, принятой в СУБД Ingres.
Использование процедур базы данных преследует четыре цели.
Во-первых, обеспечивается новый независимый уровень централизованного контроля доступа к данным, осуществляемый администратором базы данных.
Во-вторых, одна процедура может использоваться несколькими прикладными программами - это позволяет существенно сократить время написания программ за счет оформления их общих частей в виде процедур базы данных. Процедура компилируется и помещается в базу данных, становясь доступной для многократных вызовов. Так как план ее выполнения определяется единожды при компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что существенно экономит вычислительные ресурсы системы.
В-третьих, использование процедур баз данных позволяет значительно снизить трафик сети в системах с архитектурой "клиент-сервер". Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ (рис.11a). Если бы эти фрагменты остались частью программы, они загружали бы сеть посылкой полных SQL-запросов (рис.11б).
Рисунок 11.
Увеличение производительности системы за счет использования процедур
базы данных.
а. процедуры не используются;
б. выделение фрагмента прикладных программ в виде процедуры БД.
Наконец, в-четвертых, процедуры базы данных в сочетании с правилами, о которых речь пойдет ниже, предоставляют администратору мощные средства поддержки целостности базы данных.
В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL ( например, SELECT, INSERT), операторы проверки условий (IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.
Например, необходимо разработать процедуру, которая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из таблицы Сотрудник, содержащей сведения о сотрудниках, в таблицу Резерв для всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, является параметром процедуры и передается ей при вызове из прикладной программы оператором EXECUTE PROCRDURE (ВЫПОЛНИТЬ ПРОЦЕДУРУ). (Пример 2.)
CREATE PROCEDURE Назначение (Номер_сотрудника integer not nul) AS
BEGIN
INSERT INTO Резерв
SELECT *
FROM Сотрудник
WHERE Номер = Номер_сотрудника;
DELETE
FROM Сотрудник
WHERE Номер = Номер_сотрудника;
END
{ СОЗДАТЬ ПРОЦЕДУРУ Назначение (Номер_сотрудника целый не пустой) КАК
НАЧАТЬ
ВКЛЮЧИТЬ В Резерв
ВЫБРАТЬ ВСЕ
ИЗ Сотрудник
ГДЕ Номер = Номер_сотрудника;
УДАЛИТЬ ИЗ Сотрудник
ГДЕ Номер = Номер_сотрудника;
ЗАКОНЧИТЬ }
Пример 2.
Правила
Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при любых изменениях в базе данных.
Правило придается таблице базы данных и применяется при выполнении над ней операций включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы. Применение правила заключается в проверке сформулированных в нем условий, при выполнении которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно, что правило может быть применено как до, так и после выполнения операции обновления, следовательно, возможна отмена операции.
Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от прикладных программ.
Одна из целей механизма правил - отражение некоторых внешних правил деятельности организации. Пусть, например, в базе данных Склад содержится таблица Деталь, хранящая сведения о наличии деталей на складе завода. Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда на складе количество деталей любого типа становится меньше, допустим, 1000.
Это требование описывается правилом Проверить_деталь. Оно применяется в случае обновления столбца Количество таблицы Деталь: если новое значение в столбце меньше 1000, то выполняется процедура Заказать_деталь. В качестве параметров ей передаются номер детали данного типа и остаток (количкство деталей на складе). (Пример 3.)
CREATE RULE Проверить_деталь
AFTER UPDATE (Количество) OF Деталь
WHERE Деталь.Количество < 1000
EXECUTE PROCEDURE
Заказать_деталь (Номер детали = Деталь.Номер,
Остаток = Деталь.Количество);
{ СОЗДАТЬ ПРАВИЛО Проверить_деталь
ПОСЛЕ ОБНОВЛЕНИЯ (Количество) В Деталь
ГДЕ Деталь.Количество < 1000
ВЫПОЛНИТЬ ПРОЦЕДУРУ
Заказать_деталь (Номер детали=Деталь.Номер,
Остаток=Деталь.Количество);
}
Пример 3.
Таким образом, если возникает ситуация, когда на складе количество деталей какого-либо типа становиться меньше требуемого, запускается процедура базы данных, которая заказывает недостающее количество деталей этого типа. Заказ сводится к посылке письма (например, по электронной почте) на завод или в цех, который изготавливает нужные детали. Процедура проверяет, был ли ранее сделан заказ, если - нет, то посылает письмо. Все это происходит автоматически, без вмешательства пользователя. Пример этот, разумеется, упрощенный - в нем не учтено, что заказ мог быть сделан и раньше.
Важнейшая цель механизма правил - обеспечить целостность базы данных. Один из аспектов целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между собой. Напомним, что эта связь поддерживается внешними ключами.
Пусть, например, таблица Руководитель содержит сведения о начальниках, а таблица Сотрудник - о сотрудниках некоторой организации (см. пример в 1.1.). Столбец Номер руководителя является внешним ключом таблицы Сотрудник и является ссылкой этой таблицы к таблице Руководитель.
Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в таблицу Сотрудник добавляется новая строка, значение столбца Номер_руководителя должно быть взято из множества значений столбца Номер таблицы Руководитель (сотрудник может быть подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таблицы Руководитель в таблице Сотрудник не должно остаться ни одной строки, в которой в столбце Номер руководителя было бы значение, тождественное значению столбца Номер в удаляемой строке (все сотрудники, если их руководитель уволился, должны перейти в подчинение другому).
Как учесть эти требования на практике? Очевидно, должны быть созданы правила, их реализующие. Первое правило Добавить_сотрудника срабатывает при включении строки в таблицу Сотрудник; его применение заключается в вызове процедуры Проверить_руководителей, проверяющей, существует ли среди множества значений столбца Номер_руководителя значение, тождественное значению поля Номер добавляемой строки. Если это не так, процедура должна ее отвергнуть. Второе правило применяется при попытке удалить строку из таблицы Руководитель; оно состоит в вызове процедуры, которая сравнивает значения в столбце Номер_руководителя таблицы Сотрудник со значением поля Номер в удаляемой строке. В случае совпадения значения в столбце Номер_руководителя обновляются (Пример 4.)
CREATE RULE Добавить_сотрудника
AFTER INSERT INTO Сотрудник
EXECUTE PROCEDURE Проверить_руководителя (Номер = Сотрудник.Номер);
{ СОЗДАТЬ ПРАВИЛО Добавить_сотрудника
ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник
ВЫПОЛНИТЬ ПРОЦЕДУРУ Проверить_руководителя (Номер=Сотрудник.Номер)
}
Пример 4.
Механизм правил позволяет реализовать и более общие ограничения целостности. К примеру, таблица Сотрудник содержит информацию о сотрудниках, в том числе имя и название отдела, в котором они работают. Таблица Отдел хранит для каждого отдела число работающих в нем сотрудников в столбце Количество сотрудников. Одно из ограничений целостности заключается в том, что это число должно совпадать с количеством строк для данного отдела в таблице Сотрудник. Как учесть это ограничение? Одно из возможных решений состоит в использовании правила Добавить_сотрудника, которое применяется при включении строки в таблицу Сотрудник и запускает процедуру Новый_сотрудник. Она, в свою очередь, обновляет значение столбца Номер_сотрудника, увеличивая его на единицу. Параметр процедуры - название отдела. (Пример 5.)
CREATE RULE
AFTER INSERT INTO Сотрудник
EXECUTE PROCEDURE Новый_сотрудник (Отдел = Сотрудник.Отдел);
{ СОЗДАТЬ ПРАВИЛО Включить_сотрудника
ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник
ВЫПОЛНИТЬ ПРОЦЕДУРУ Новый_сотрудник (Отдел = Сотрудник.Отдел)
}
Пример 5.
Разумеется, на практике при помощи механизма правил реализуются более сложные и изощренные ограничения целостности.
Механизм правил - сердце активного сервера базы данных. Аналогом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase (насколько известно автору) и впоследствии были реализованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД.
События в базе данных
Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями целиком ложатся на сервер базы данных.
Рисунок 12.
События в базе данных.
Рис.12 иллюстрирует один из примеров использования механизма событий: различные прикладные программы и процедуры вызывают события в базе данных, а сервер оповещает монитор прикладных программ об их наступлении. Реакция монитора на события заключается в выполнении действий, которые предусмотрел его разработчик.
Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что данная программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).
Пример 6 иллюстрирует обработку всех событий из очереди.
loop
EXEC SQL GET DBEVENT;
EXEC SQL INQUIRE_SQL (:event_name = DBEVENTNAME);
if (event_name = "event_1"
обработать событие event_1
else if (event_name = "event_2")
обработать событие event_2
else
...
endif
until event_name = " "
{ цикл
ПОЛУЧИТЬ СОБЫТИЕ
ПОЛУЧИТЬ ИМЯ СОБЫТИЯ
если (имя события = "первое событие")
обработать первое событие
иначе если (имя события = "второе событие")
обработать второе событие
иначе
...
конец если
пока имя события не равно пустой строке
}
Пример 6.
Рассмотрим пример из производственной системы, иллюстрирующий использование механизма событий в базе данных совместно с правилами и процедурами. События используются для определения ситуации, когда рабочий инструмент нагревается до температуры выше допустимой и должен быть отключен.
1. Создается правило, которое применяется всякий раз, когда новое значение температуры инструмента заносится в таблицу Инструмент. Как только она превосходит 500 градусов, правило вызывает процедуру Отключить_инструмент.
CREATE RULE Перегрев_инструмента
AFTER UPDATE OF
Инструмент (Температура)
WHERE Новое.Температура >= 500
EXECUTE PROCEDURE
Отключить_инструмент
(Номер_инструмента =
Инструмент.Номер);
{ СОЗДАТЬ ПРАВИЛО
Перегрев_инструмента
ПОСЛЕ ОБНОВЛЕНИЯ
Инструмент (Температура)
ГДЕ Новое.Температура >= 500
ВЫПОЛНИТЬ ПРОЦЕДУРУ
Отключить_инструмент
(Номер_инструмента =
Инструмент.Номер);
}
2. Создается процедура базы данных Отключить_инструмент, которая вызывает событие Перегрев; она будет выполнена в результате применения правила, определенного на шаге 1. Эта процедура регистрирует время, в течение которого инструмент был отключен, и вызывает событие Перегрев:
CREATE PROCEDURE
Отключить_инструмент
(Номер_инструмента) AS
BEGIN
UPDATE Инструмент
SET Статус = "ВЫКЛ"
WHERE Номер = Номер_инструмента;
RAISE DBEVENT Перегрев;
END;
{ СОЗДАТЬ ПРОЦЕДУРУ
Отключить_инструмент
(Номер_инструмента) КАК
НАЧАТЬ
ОБНОВИТЬ Инструмент
УСТАНОВИТЬ Статус = "ВЫКЛ"
ГДЕ Номер = Номер_инструмента;
ВЫЗВАТЬ СОБЫТИЕ Перегрев;
END;
}
3. Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:
CREATE DBEVENT Перегрев;
{ СОЗДАТЬ СОБЫТИЕ Перегрев }
4. Наконец, создается прикладная программа Монитор Инструментов, которая следит за состоянием инструментов. Она регистрируется сервером в качестве получателя события Перегрев с помощью оператора REGISTER DBEVENT. Если событие произошло, программа посылает сообщение пользователю и сигнал, необходимый для отключения инструмента.
...
EXEC SQL REGISTER
DBEVENT Перегрев;
...
EXEC SQL GET DBEVENT;
EXEC SQL INQUIRE_SQL
(Имя события = DBEVENTNAME, ...);
if (Имя события = "Перегрев")
then
послать сообщение;
отключить инструмент;
endif;
{...
ВЫПОЛНИТЬ SQL
ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ Перегрев;
...
ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ СОБЫТИЕ;
ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ ИМЯ СОБЫТИЯ;
если Имя события = "Перегрев"
то
послать сообщение;
отключить инструмент;
конец если;
}
Описанные конструкции в совокупности определяют следующую логику работы (рис.13):
1. Прикладная программа Монитор Инструментов периодически регистрирует с помощью датчиков текущие значения параметров множества различных инструментов.
2. Та же программа заносит в таблицу Инструмент новое значение температуры для данного инструмента.
3. Всякий раз, когда это происходит, то есть обновляется значение в столбце Температура таблицы Инструмент, применяется правило Перегрев_инструмента.
4. Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое значение, то запускается процедура Отключить_инструмент.
5. Она изменяет значение в столбце Статус таблицы Инструмент на "ВЫКЛ".
6. Она же вызывает событие Перегрев.
7. Программа Монитор Событий получает (перехватывает) событие Перегрев.
8. Она же посылает сообщение на экран диспетчеру.
9. Она же отключает инструмент.
Рисунок 13.
Пример использования механизма событий в базе данных.
Когда используются традиционные методы опроса БД, логика работы совершенно иная. Пришлось бы разработать дополнительную программу, которая периодически выполняла бы операцию выборки из таблицы Инструмент по критерию "Температура > 5000". Это очень заметно сказалось бы на эффективности, поскольку операция SELECT влечет серьезные накладные расходы.
Разумеется, пример приведен лишь для иллюстрации схемы срабатывания механизма "правило - процедура - событие" и ни в коей мере не отражает реальные схемы управления технологическими процессами на производстве.
Типы данных, определяемые пользователем
Проблемы с типами данных, о которых шла речь выше, решаются за счет интеграции в сервер новых типов данных. К сожалению, далеко не все современные СУБД поддерживают типы данных, определенные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система предоставляет программисту возможность определять собственные типы данных и операции над ними и использовать их в операторах SQL. Для определения нового типа данных необходимо написать и откомпилировать функции на языке СИ, после чего собрать редактором связей некоторые модули Ingres. Отметим, что введение новых типов данных является по сути изменением ядра СУБД. Важно и то, что в Ingres типы данных, определяемые пользователем, могут быть параметризованными.
Определение нового типа данных сводится к указанию в его имени, размера и идентификатора в глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют стандартные операции (сравнение, преобразование в различные форматы, и т.д.), программист должен разработать их самостоятельно (интерфейс функций предопределен). Указатели на эти функции являются элементами глобальной структуры. Как только новый тип данных определен, то все операции выполняются над ним, как над данными стандартного типа. Разрешение пользователю создавать собственные типы данных - один из шагов развития реляционных СУБД в направлении объектно-реляционных систем.
Продолжение - в следующем номере.
*) Продолжение. Начало см. СУБД #1
(c) Jet Infosystems, 1995