Реферат по "Интегрированным системам"

Особенности распределенных баз данных.

В сегодняшнем быстро меняющемся компьютерном мире сосуществуют по крайней мере три основные идеологии: клиент - сервер, Web и распределенные объекты (DCOM, CORBA). Внутри каждого направления также существует большое количество решений и стандартов от разных производителей. Сегодняшняя ситуация вызывает очень большую озабоченность независимых разработчиков и потребителей: Какую технологию выбрать и что будет со мной и моим бизнесом, если я приму неправильное решение? При этом очевидно, что цена ошибки будет весьма высока, кроме того большие средства уже вложены в разработку и эксплуатацию уже существующих систем.

Клиент-сервер

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

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

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

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

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

Многие средства быстрой разработки приложений (RAD), которые работают с  различными базами данных, реализует  первую стратегию, т. е. "толстый" клиент обеспечивает интерфейс с  сервером базы данных через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы. Кроме того, данную систему почти невозможно перевести на Web-технологию, так как для доступа к серверу базы данных используется специализированное клиентское ПО.

Рассмотренные выше модели имеют следующие недостатки.

1. "Толстый" клиент:

• сложность администрирования;

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

2. "Толстый" сервер:

• усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;

• производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
• программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
• получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

Для решения перечисленных проблем  используются многоуровневые (три и более уровней) архитектуры клиент-сервер.

Многоуровневая архитектура клиент-сервер — разновидность архитектуры  клиент-сервер, в которой функция  обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции  хранения, обработки и представления  данных для более эффективного использования  возможностей серверов и клиентов.

Частный случай многоуровневой архитектуры - трёхуровневая (трехзвенная) архитектура.

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

«Тонкий клиент» или Терминал —  это интерфейсный (обычно графический) компонент, который представляет собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям  безопасности), быть нагруженным основной бизнес-логикой и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

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

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

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

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

Многоуровневые клиент-серверные  системы достаточно легко можно  перевести на Web-технологию - для этого достаточно заменить клиентскую часть универсальным или специализированным браузером, а сервер приложений дополнить Web-сервером и небольшими программами вызова процедур сервера. Реализация этого принципа основана на использовании либо HTTP-SQL, либо API (организация динамических приложений на стороне сервера), либо Java (JDBC - организация динамических приложений на стороне клиента) интерфейсов для формирования запросов пользователя к базам данных или к другим информационным источникам на получение и обработку информации.

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

Менеджеры транзакций

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

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

• коммуникационный менеджер (Communication Manager) контролирует обмен сообщениями между компонентами информационной системы;
• менеджер авторизации (Authorisation Manager) обеспечивает аутентификацию пользователей и проверку их прав доступа;
• менеджер транзакций (Transaction Manager) управляет распределенными операциями;
• менеджер ведения журнальных записей (Log Manager) следит за восстановлением и откатом распределенных операций;
• менеджер блокировок (Lock Manager) обеспечивает правильный доступ к совместно используемым данным.

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

Первые менеджеры транзакций появились  в начале 70-х гг. (например, CICS); с тех пор они незначительно изменились идеологически, но весьма существенно - технологически. Наибольшие идеологические изменения произошли в коммуникационном менеджере, так как в этой области появились новые объектно-ориентированные технологии (CORBA, DCOM и т.д.). Из-за бурного развития коммуникационных средств в будущем следует ожидать широкого использования различных типов менеджеров транзакций.

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

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

 Фрагментация данных

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