5. Архитектура информационной системы

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

• производительность и надежность;

• целостность и безопасность данных;

• открытая архитектура ИС, т.е. возможность расширения функций, гибкость.

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

Иначе такие системы можно определить как много клиентов/один сервер. Управление базой данных осуществляется довольно легко, поскольку она вся хранится на одном сервере, централизованно. В операционной системе Windows для использования технологии "клиент/сервер" удобнее всего использовать штатный для этой операционной системы механизм DCOM (Distributed Component Object Model), являющийся сетевым расширением технологии COM (Component Object Model). Приложение, построенное в соответствии с принципами COM, предоставляет доступ к своим функциям в виде набора интерфейсов (интерфейсом в COM называется таблица, содержащая адреса функций). DCOM позволяет общаться приложениям не только в пределах одного компьютера, но и в пределах локальной компьютерной сети (ЛКС).

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

6. Понятие архитектуры клиент–сервер

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

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

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

Второй подход носит название архитектура "клиент–сервер".

Определения:

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

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

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

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

По сравнению с такими системами системы, построенные в архитектуре Клиент – Сервер, имеют следующие преимущества:

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

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

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

• в несколько раз уменьшает объем информации, передаваемый по сети.

7. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

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

Определение Дэйта. (C.J. Date)

12 СВОЙСТВ ИЛИ КАЧЕСТВ ИДЕАЛЬНОЙ DDB:

Локальная автономия (local autonomy)

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

Независимость от центрального узла (no reliance on central site)

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

Непрерывные операции(continuous operation).

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

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

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

Прозрачная фрагментация(fragmentation independence).

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

Прозрачность тиражирования(replication independence)

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

Обработка распределенных запросов(distributed query processing)

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

Обработка распределенных транзакций(distributed transaction processing)

Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазового или двухфазного протокола фиксации транзакций (two–phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.

Независимость от оборудования(hardware independence)

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

Независимость от операционных систем(operationg system independence)

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

Прозрачность сети(network independence)

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

Независимость от баз данных(database independence)

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

Исходя из определения Дэйта, можно рассматривать DDB как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами – это потоки тиражируемых данных. Топология DDB варьируется в широком диапазоне – возможны варианты иерархии, структур типа "звезда" и т.д. В целом топология DDB определяется географией информационной системы и направленностью потоков тиражирования данных.

Целостность данных.

В DDB поддержка целостности и согласованности данных, ввиду свойств 1–2, представляет собой сложную проблему. Ее решение – синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB – достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна – то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции – СУБД, функционирующие на узлах системы, поддерживают XA–интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA–интерфейс имеют CA–OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.

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

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

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

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

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

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

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

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

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

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

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

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

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