Распределенные информационные системы

Размещено на http://www.allbest.ru/

Распределенные информационные системы



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

Первоначальные подходы к созданию баз данных АИС заключались в сосредоточении данных логически и физически в одном месте - на одной вычислительной машине. Однако такая организация информационного ресурса чаще всего является не совсем естественной с точки зрения традиционных («бумажных») информационных технологий конкретного предприятия (организационной структуры) и при внедрении АИС происходит изменение привычных информационных потоков. Все информационные ресурсы предприятия сосредотачиваются централизованно в одном месте, что требует определенных технологических, кадровых и материальных затрат и может порождать ряд новых проблем и задач. Следует отметить, что такому подходу также способствовала и господствующая на начальном этапе автоматизации предприятий и организаций в 70-х годах тогдашняя парадигма вычислительных систем - общая мощная вычислительная установка (main frame) и групповая работа пользователей с удаленных терминалов через системы разделения времени.

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

Осознание подобных проблем постепенно стало приводить к мысли о распределенных информационных системах.

Понятие распределенных информационных систем

Впервые задача об исследовании основ и принципов создания и функционирования распределенных информационных систем была поставлена известным специалистом в области баз данных К. Дейтом в рамках проекта System R, что в конце 70-х - начале 80-х годов вылилось в отдельный проект создания первой распределенной системы (проект system R*). Большую роль в исследовании принципов создания и функционирования распределенных баз данных внесли также и разработчики системы Ingres.

Собственно в основе распределенных АИС лежат две основные идеи:

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

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



Основные принципы их создания и функционирования

K.Дейт сформулировал несколько основных принципов создания и функционирования распределенных баз данных. К их числу относятся:

прозрачность расположения данных для пользователя (иначе говоря, для пользователя распределенная база данных должна представляться и выглядеть точно так же, как и нераспределенная);

изолированность пользователей друг от друга (пользователь должен «не чувствовать», «не видеть» работу других пользователей в тот момент, когда он изменяет, обновляет, удаляет данные);

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

Из основных вытекает ряд дополнительных принципов:

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

отсутствие центральной установки (следствие предыдущего пункта);

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

непрерывность функционирования (отсутствие плановых отключений системы в целом, например для подключения новой установки или обновления версии СУБД);

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

независимость от дублирования данных (когда какая-либо таблица базы данных, или ее часть физически может быть представлена несколькими копиями, расположенными на различных машинах, причем «прозрачно» для пользователя);

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

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

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

независимость от типа операционной системы (система должна функционировать вне зависимости от возможного различия ОС на различных вычислительных машинах);

независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах);

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

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

Важнейшую роль в технологии создания и функционирования распределенных баз данных играет техника «представлений» (View).

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

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

Схематично идея техники представлений проиллюстрирована на рис. 1.

распределенный информационный система

Размещено на http://www.allbest.ru/

Рисунок 1- Основная идея техники представлений

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

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

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

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

Create View Имя Представления as

Select from Table1 ...;

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

GRANT SELECT ON Имя Представления TO Имя Пользователя1,

Имя Пользователя2,...;

Соответственно директива REVOKE отменяет уставленные ранее привилегии.

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

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

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

Технологии и модели «Клиент-сервер»

Системы на основе технологий «Клиент-сервер» исторически выросли из первых централизованных многопользовательских автоматизированных информационных систем, интенсивно развивавшихся в 70-х годах, и получили, вероятно, наиболее широкое распространение в сфере информационного обеспечения крупных предприятий и корпораций.

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

* хранение общие для всех пользователей данных на одном или нескольких серверах;

* много пользователей (клиентов) на различных вычислительных машинах совместно (параллельно и одновременно) обрабатывают общие данные.

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

Важное значение в технологиях «Клиент-сервер» имеют понятия сервера и клиента.

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

Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом.

В своем развитии системы «Клиент-сервер» прошли несколько этапов, в ходе которых сформировались различные модели систем «Клиент-сервер». Их реализация и, следовательно, правильное понимание основаны на разделении структуры СУБД на три компонента:

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

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

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

Исходя из особенностей реализации и распределения (расположения) в системе этих трех компонентов различают четыре модели технологий "Клиент-сервер":

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

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

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

* модель сервера приложний (ApplicationServer - А8).

Модель файлового сервера

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

Размещено на http://www.allbest.ru/

Рисунок 2 - Модель файлового сервера

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

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

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

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

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

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 3 - Модель удаленного доступа к данным (RDА-модель)

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

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

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

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

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

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

Развитием RDA-модели стала модель сервера базы данных.

Её сердцевиной является использование хранимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области АИС события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Схематично DBS-модель приведена на рис. 4.

Размещено на http://www.allbest.ru/

Рисунок 4 - Модель сервера базы данных (DBS-модель)

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

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

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

Модель сервера приложений

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

Размещено на http://www.allbest.ru/

Рисунок 5 - Модель сервера приложений (AS-модель)

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

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

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

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

Мониторы транзакций

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

Если условия ограничений целостности данных не выполняются, то происходит «откат» транзакции (выполняется SQL-инструкция ROLLBACK), в противном случае транзакция фиксируется (выполняется инструкция СОММIТ).

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

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

* потерянные изменения;

* «грязные» данные;

* неповторяющиеся чтения.

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

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

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

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

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

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

синхронизационные захваты (блокировки) объектов базы данных;

временные метки объектов базы данных.

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

Наиболее распространенным вариантом первого подхода является реализация двухфазного протокола синхронизационных захватов (блокировок) объектов базы данных - 2РL (Тwo-Phase Locks). В соответствии с данным протоколом выполнение транзакции происходит в два этапа. На первом этапе (первая фаза) перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в соответствующем режиме. После получения и накопления необходимых захватов (блокировок) осуществляется вторая фаза - фиксация изменений (или откатно соображениям целостности данных) и освобождение захватов.

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

Грануляция синхронизационных блокировок позволяет строить более эффективные планы сериализации транзакций.

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

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

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

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

* проверяется, не закончилась ли транзакция, первой «пометившая» объект;

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

* если первая транзакция не закончилась, то проверяется конфликтность операций (напомним, что конфликтно любое сочетание, кроме «чтение-чтение»);

* если операции неконфликтны, то они выполняются для обеих транзакций, а объект до завершения операций помечается меткой более поздней, т. е. более молодой транзакции;

* если операции конфликтны, то далее происходит откат более поздней транзакции и выполняется операция более ранней (старшей) транзакции, а после ее завершения объект помечается меткой более молодой транзакции и цикл действий повторяется.

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

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

Технологии объектного связывания данных

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

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

Решение этой задачи основывается на поддержке современными «настольными» СУБД (МS Ассеss, FохРго, dВазе и др.) технологии «объектов доступа к данным» - DАО. При этом следует отметить, что под объектом понимается интеграция данных и методов их обработки в одно целое (объект), на чем, как известно, основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживающие DАО, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически находящимся в других файлах, возможно на других вычислительных установках и под управлением других СУБД.

Технически технология DАО основана на уже упоминавшемся протоколе ОDВС, который принят за стандарт доступа не только к данным на SQL-сервераx клиент-серверных систем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД. Непосредственно для доступа к данным на основе протокола ОDВС используются инициализируемые на тех установках, где находятся данные, специальные программные компоненты, называемые драйверами ОDВС, или инициализируемые ядра тех СУБД, под управлением которых были созданы и эксплуатируются внешние базы данных. Схематично принцип и особенности доступа к внешним базам данных на основе объектного связывания иллюстрируются на рис. 6.

Размещено на http://www.allbest.ru/

Рис. 6 - Принцип доступа к внешним данным на основе протокола ОDВС

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

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

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

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

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

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

Предметные области сведений по этим трем локальным базам данных очень близки и переплетены, однако, как и в предыдущем примере, с учетом специфики подразделений, ведение и размещение таких общепотребных таблиц как «Продукция», «Типы, номенклатура» целесообразно осуществлять в локальной базе Планово-производственного отдела, таблиц «Комплектугащие», «Сырье», «Поставщики» в локальной базе Отдела спабэ/сепия, а таблиц «Заказы» и «Клиенты» в локальной базе Отдела сбыта. Опять-таки данные по таблице «Сотрудники» могут быть получены на основе объектного связывания из локальной базы Отдела кадров.

Отношение к документу

Рег.№ документа

' Та6,№ сотрудника

' Вид (исп., подп.,

утверд)

* Дата й

Сотрудники

*Та6№

*ФИО

* Подразд-е'

* Должность

Документы

* Рег.№

*Дата

* Название вида

* Заголовок к тексту

*Гриф

* Мероприятие

Док-ты. и подр-я

Рег.№

^©*Г г подр.

Ввд (напр, подг)

Отнош. к меропр.

Таб.№ сотр.

Наим. меропр.

Вид (исп.,отв.)

Отражает

*Рег.К°док.

«Наим. меропр

Подразделения

'Ка№

*Наименование

* Руковод1гтель

Мероприятие

* Наименование

* Дата начала

* Дата оконч.

Меропр. и подр.

'№№ подр..

*Наим. меропр

* Вид (пров..

у част.)

Сотрудтки

*Та6.№

*ФИО

*Подразд-е

* Должность

*Наименование

* Должн. оклад

«Спец.по образ.

Подразделения

* Наименование

* Руководитель

^ ^

Нетрудоспособность

' Та6.№ сотр.

' Дата начала

' Дата оконч.

' Вид

Командировки

* Таб.№ сотр.

* Дата начала

* Дата оконч-я

* Пункт

* Аванс

* Факт, расходы

Штаты

* №№ подр.

* Штат.катег.

Отпуска

Та6.№сотр.

Дата начала

Дата оконч.

4-*

Сотрудники

* Та6.№

*ФИО

*Подраэд-е

* Должность'

I

Нетрудоспособность

*Таб № сотр.

* Дата начала

*Дата оконч-я

* Вид

Ц

Та6.№ сотр

* Дата начала

* Дата окончания

* Пункт

* Аванс

Факт расходы

Отпуска

* Та6.№ сотр.

* Дата начала

* Дата оконч-я

Рис. 5.7. Пример схем локальных баз данных со связанными объектами

Продукция

Типы номенклатура

Локальная база планово-производственного отдела

А - *

Комплектующие, сырье

Поставщики

Локальная база отдела снабжения

Ч - *

Типы номенклатура

Локальная база отдела сбыта

А *

Рис. 8. Пример схем локальных баз данных со связанными объектами

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

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

Аналогичным образом обеспечивается доступ к данным находящимся в базах данных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FохРго, dBАSЕ, а так же к данным электронных таблиц.

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

Доступ к базам данных других СУБД (см. рис. 6) реализуется через технику драйверов ОВВС, которые инсталлируются и выполняются на тех вычислительных установках, где находятся удаленные данные. «Идеология» в данном случае такова. В составе настольной СУБД, поддерживающей локальную базу данных, можно инсталлировать дополнительный программный компонент, называемый драйвером ОВВС. Инсталлируемый драйвер ОВВС «регистрируется» в специальном подкаталоге системного каталога операционной системы. Так образуется рабочая область прямого доступа к источникам данных ОDВС.

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

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

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

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

Технологии реплицирования данных

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

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

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

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

* обеспечение согласованного состояния во всех репликах количества и значений общих данных;

* обеспечение согласованного состояния во всех репликах структуры данных.

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

* принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

* принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).

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

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