Организация удаленного доступа к распределенным базам данных

1.1 Основные понятия теории реляционных баз данных

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

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

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

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

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

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

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

Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой данных сводятся к манипуляциям с таблицами. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка - конкретный объект.

Значения атрибутов выбираются из множества допустимых значений, которое называется доменом (domain).

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Кроме того, привязка к номеру строки некорректна в многопользовательских СУБД. Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Если таблица удовлетворяет этому требованию, она называется отношением (relation).

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют "данные о данных", например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

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

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

Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблицы выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам (referential integrity). Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств, таких как привила (rules), триггеры (triggers) и домены (domains).

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

Появление и развития этого языка как средства описания доступа к базе данных связано с созданием теории реляционных баз данных. Прообраз языка SQL возник в 1970 году в рамках научно-исследовательского проекта System/R, работа над которым велась в лаборатории Санта-Тереза фирмы IBM. Ныне SQL - это стандарт интерфейса с реляционными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, Adabas или Betrieve), снабжают свои системы SQL-интерфейсом.

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

SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Поэтому SQL - декларативный язык. Это означает, что с его помощью можно сформулировать, что необходимо получить, но нельзя указать, как это следует сделать. В частности, в отличие от процедурных языков программирования (Си, Паскаль, Ада), в языке SQL отсутствуют такие операторы, как if...then...else, for, while, хотя следует указать, что в расширении SQL для хранимых процедур и триггеров (SQL/PTL - SQL/Procedure And Trigger Language) они присутствуют.

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

Ниже в таб. 1.1 перечислены наиболее важные операторы, которые входят в стандарт ANSI/ISO SQL.

Таблица 1.1 - Основные операторы языка SQL

В запросах на языке SQL используются имена, которые однозначно идентифицируют объекты базы данных. Наряду с простыми, используются также сложные имена - например, квалификационное имя столбца (qualified column name) определяет имя столбца и имя таблицы, которой он принадлежит.

Каждый столбец в любой таблице хранит данные определенных типов. Различают базовые типы данных - строки символов фиксированной длины, целые и вещественные числа, и дополнительные типы данных - строки символов переменной длины, денежные единицы, дату и время, логические данные (два значения - "ИСТИНА" и "ЛОЖЬ"). В языке SQL можно использовать числовые, строковые, символьные константы и константы типа "дата" и "время".

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

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

Если же был предварительно создан индекс по столбцам, входящим у условие WHERE запроса, то время поиска в таблице будет сокращено до минимума. Индекс создается оператором SQL CREATE INDEX (СОЗДАТЬ ИНДЕКС).

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

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

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

1.2 Сервер базы данных

Технология и модели "клиент-сервер"

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

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

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

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

В настоящее время фактическим стандартом для многопользовательских СУБД, стала архитектура "клиент-сервер".

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

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

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

компонент представления, реализующий функции первой группы;

прикладной компонент, поддерживающий функции второй группы;

компонент доступа к информационным ресурсам, поддерживающий функции третьей группы;

протокол взаимодействия.

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

Выделяются четыре подхода, реализованные в следующих моделях:

модель файлового сервера (File Server - FS);

модель доступа к удаленным данным (Remote Data Access - RDA);

модель севера базы данных (DataBase Server - DBS);

модель сервера приложений (Application Server - AS).

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

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

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

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

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

Рис. 1.2 - Модель доступа к удаленным данным

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

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

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

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

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

Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель. Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle, InterBase). Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разрабатываются хранимые процедуры (SQL/PTL), представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

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

Рис. 1.3 - Модель сервера баз данных

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

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

Рис. 1.4 - Модель сервера приложений

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

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

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

Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).

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

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

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

Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если два эти условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколькими серверами (multi-threaded, multi-server architecture).

Механизмы реализации активного ядра

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

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

Данные требования выливаются в решение следующих задач.

Необходимо, чтобы база данных в любой момент времени правильно отражала состояние предметной области - данные должны быть взаимно непротиворечивыми.

База данных должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules).

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

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

Важная проблема СУБД - контроль типов данных. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стандартных типов данных, разрешенных в СУБД. Как правило, это данные стандартных типов - числа, целые и вещественные, строки символов, а также данные типа "дата", "время" и "денежная единица".

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

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

процедурами базы данных;

правилами (триггерами);

событиями в базе данных;

типами данных, определяемыми пользователем;

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

В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д. Ниже будем пользоваться терминологией, принятой в СУБД InterBase.

Использование процедур базы данных преследует четыре цели:

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

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

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

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

В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (IF/THEN/ ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.

Правила (триггеры)

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

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

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

Важнейшая цель механизма правил - обеспечение целостности базы данных. Один из аспектов целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между собой. Эта связь поддерживается внешними ключами. Механизм правил позволяет реализовать и более общие ограничения целостности.

Механизм событий

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

Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее, во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).

1.3 Обработка распределенных данных

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

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

Ответом на задачи реальной жизни стали две технологии: технология распределенных баз данных (Distributed Database) и технология тиражирования данных (Data Replication).

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

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

Ранее были рассмотрены четыре модели технологии "клиент-сервер". Традиционной и наиболее популярной является модель доступа к удаленным данным (RDA-модель). В соответствии с этой моделью, имеется компьютер, на котором запускаются программы переднего плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции) - клиент (называемый обычно локальным узлом - local node), соединенный в сети с компьютером, на котором выполняется сервер базы данных и находится сама база данных (обычно его называют удаленным узлом - remote node). Все проблемы, возникающие при взаимодействии клиента и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то же время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net).

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

Прозрачность расположения;

Прозрачность сети;

Автоматическое преобразование форматов данных;

Автоматическая трансляция кодов;

Межоперабельность;

Прозрачность расположения.

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

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

Однако в том случае, когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того, чтобы получить доступ к базе данных на удаленном узле, необходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре "имя_узла, имя_БД", то прикладная программа становится зависимой от расположения БД. Например, обращение к БД "host::stock", где первый компонент есть имя узла, будет зависимым от расположения.

Одно из возможных решений этой проблемы состоит в использовании виртуальных имен узлов. Управление ими обеспечивается специальным программным компонентом СУБД - сервером имен (Name Server), который адресует запросы клиентов к серверам.

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

Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk, и др.).

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

В неоднородной компьютерной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент - с другой (например, ASCII), при этом происходит рассогласование трактовки кодов символов. Поэтому, если на локальном узле используется одна кодовая таблица, а на удаленном - другая, то при передаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.

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

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

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

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

Управление именами в распределенной среде;

Оптимизация распределенных запросов;

Управление распределенными транзакциями.

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

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

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

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

Решение всех трех задач, возложено на специальный компонент СУБД - сервер распределенных баз данных (Distributed Database Server).

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

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

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

Для СУБД это качество означает следующее:

способность приложений, созданных средствами разработки данной СУБД, оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных;

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

Первое достигается использованием шлюзов, второе - использованием интерфейсов ODBC (Open Database Connectivity) и BDE (Borland Database Engine).

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

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

Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащие различным узлам распределенной системы. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание триггера, перехватывающего любые изменения тиражируемого объекта БД. Возможно и программное управление репликатором посредством сигнализаторов о событиях в базе данных.

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

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