1

1. АРХИТЕКТУРА КЛИЕНТ-СЕРВЕР

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

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

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

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

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

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

Как правило пользователям компьютеров нужны и высокая вычислительная мощность и прекрасные свойства персональных компьютеров. Поэтому там, где для выполнения сложных вычислений используются мощные изолированные центральные компьютеры с терминами, их пользователям периодически приходится ходить на персональные компьютеры для редактирования текстов или выполнения задач, использующих электронные таблицы. Это заставляет пользователей освоить 2 различные операционные системы (на больших машинах обычно установлены OC MVS, VMS, VM, UNIX, а на персональных - MS DOS, OS/2 или Netware) и не решает задачи совместного использования данных.

В результате опроса представителей 300 крупнейших фирм США, использующих персональные компьютеры, выяснилось, что для 81% опрошенных необходим доступ к данным более чем одного компьютера. Чтобы решить эту задачу, персональные компьютеры начали объединять в локальные сети и устанавливать на них специальные сетевые операционные системы, например, NetWare фирмы Novell. Для совместного использования компьютерами сети файлов, размещенных в различных узлах сети, используются пакеты, называемые файл-серверы. Например, для среды NetWare используется файл-сервер Btrieve. Однако файл-серверы имеют ряд недостатков. Они не позволяют в полной мере обеспечить конфиденциальность доступа и целостность данных. По сети файлы передаются целиком, независимо от того, какая часть содержащихся в них данных нужна пользователю. Это сильно перегружает сеть и уменьшает быстродействие системы. Невысока и надежность системы на основе файл-серверов. Сбой на одной из рабочих станций в момент записи файла часто приводит к потере данных. Для обеспечения непротиворечивости данных приходится блокировать файлы, что также приводит к замедлению работы. Основным же недостатком такой локальной сети персональных компьютеров является то, что все ее узлы обладают невыыокой производительностью и не годятся для решения задач, требующих сложных длительных вычислений.

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

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

Следующим шагом в решении описанной выше проблемы явилось использование архитектуры клиент-сервер. В такой архитектуре все компьютеры сети разделены на 2 группы: клиенты и серверы. Компьютер-сервер - это мощный компьютер с большой оперативной памятью и большим количеством дискового пространства. На нем хранится база данных и выполняется сложная обработка, требующая больших вычислительных ресурсов. На компьютерах-клиентах выполняются первичная и финишная обработка данных, извлеченных с сервера. В качестве компьютеров-клиентов обычно используются персональные компьютеры типа IBM PC или Macintosh. Преимущества архитектуры клиент-сервер очевидны. Каждый тип компьютера используется по своему назначению, а следовательно обеспечивается более полное использование возможностей компьютеров.

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

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

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

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

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

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

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

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

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

, мощные средства администрирования. Поэтому для создания приложений с распределенной БД и распределенной обработкой используются специальные распределенные СУБД. Наиболее известными из них являются Informix, Ingres, InterBase, Oracle, Sybase. Самые мощные из них, например, Oracle, позволяют одновременно использовать в одном приложении, работающем на сети, компьютеры, операционные системы, сетевые протоколы и СУБД различных типов.

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

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

Очевидно, на сегодняшний день наиболее реально организовать для работы с распределенной БД смешанную архитектуру, в которой часть узлов является и серверами и клиентами, а часть выступает только в роли клиентов. Кроме того, если в качестве серверов используются мощные машины фирм IBM, DEC, HP, SEQUENT, то они могут иметь и множество собственных терминалов.

Следует заметить, что поскольку сервер БД обеспечивает одновременную работу с данными нескольких пользователей, он должен работать в многозадачной или многопользовательской операционной системе (например, OS/2, NetWare, Unix, VMS, MVS, VM). Серверов БД для MS DOS не существует. Там возможна лишь работа с локальной БД.

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

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

Какими же соображениями следует руководствоваться при выборе компьютера для сервера? В первую очередь следует обратить внимание на быстродействие, стоимость и надежность компьютера. Так для задач, предъявляющих высокие требования по надежности работы могут использоваться особо надежные (Fault Tolerant) машины, машины и операционные системы, выполняющие дублирование записи на диски (mirroring), многопроцессорные машины, продолжающие работу при выходе из строя нескольких процессоров.

Для приложений с небольшим количеством одновременно работающих пользователей (несколько десятков) и не очень большой БД в качестве машины сервера можно использовать компьютеры с 486 процессором. Для более мощных приложений широко используются компьютеры фирм DEC, HP, Sun. Очень перспективна в качестве сервера многопроцессорная машина фирмы Sequent. Она имеет достаточно низкую цену, высокое быстродействие и надежность. Причем быстродействие может легко повышаться за счет увеличения числа процессоров (от 2 до 30).

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

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

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

- сетевые версии СУБД для персональных компьютеров;

- СУБД, поддерживающие архитектуру клиент-сервер.

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

2. СЕТЕВЫЕ ВЕРСИИ СУБД ДЛЯ РС

Для персональных компьютеров было разработано много компактных СУБД, имеющих дружественные интерфейсы и мощные и простые в использовании средства разработки приложений. Наиболее известными СУБД для РС являются: Clarion, Paradox, FoxPro, dBase, Clipper, Rbase, dbVista. В начале эти СУБД разрабатывались как однопользовательские и их архитектура была ориентирована на максимально эффективное использование возможностей РС. В дальнейшем появились сетевые версии этих СУБД, но они являются просто развитием однопользовательских версий и вынуждены сохранять принципы и концепции заложенные при разработке однопользовательских версий. В то же время реализация мнопользовательских СУБД, позволяющих эффективно работать с БД десяткам и тысячам пользователей выдвигает ряд новых требований к архитектуре СУБД. Они должны минимизировать задержки и ожидания, обеспечить высокую надежность и защиту данных при многопользовательской работе, свести к минимуму блокировку данных, обеспечить мощные средства администрирования данных и разработки приложений.

Сетевые версии СУБД dBase, FoxPro, Clarion, Clipper, dbVista не позволяют выполнять настройку на ресурсы среды эксплуатации, иметь мощные механизмы защиты и восстановления данных, поддерживать архитектуру клиент-сервер, сводить до минимума вероятность ожидания заблокированных данных и взаимоблокировок, и иметь еще много специализированных механизмов, необходимых для многопользовательской сетевой СУБД.

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

Практика работы с заказчиками (например, муниципалитет Санкт-Питербурга, Тверь банк и т.д.) показывает, что им приходится переходить на мощные распределенные многопользовательские СУБД от систем на основе Paradox, Clipper, FoxPro и т.д., поскольку при увеличении числа пользователей свыше 3 - 6 человек производительность работы резко снижается и время отклика системы становится намного выше допустимого. Сложные запросы приходится запрещать выполнять в дневное время, т.к. иначе блокируется работа остальных пользователей.

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

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

3. РАСПРЕДЕЛЕННЫЕ СУБД

3.1. Специфические функции распределенных СУБД

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

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

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

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

данными БД.

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

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

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

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

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

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

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

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

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

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

1. РАСПРЕДЕЛЕННЫЙ СЛОВАРЬ ДАННЫХ. В словаре содержится информация о типе данных, месте их размещения и о способе доступа к данным.

2. "ПРОЗРАЧНЫЙ" ПРОТОКОЛ ДВУХФАЗНОЙ ФИКСАЦИИ ИЗМЕНЕНИЙ. Этот протокол обеспечивает непротиворечивость данных. При выполнении транзакции, изменяющей данные в нескольких узлах, протокол двухфазной фиксации обеспечивает успешное выполнение всей транзакции только в том случае, если успешно выполнилась обработка в каждом узле. Если же в одном из узлов обработка не выполнена успешно, то анулируются результаты работы всей транзакции.

3. ГОРИЗОНТАЛЬНАЯ И ВЕРТИКАЛЬНАЯ ФРАГМЕНТАЦИЯ. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети.

4. НЕЗАВИСИМОСТЬ ДУБЛИРОВАНИЯ ДАННЫХ. Это свойство СУБД позволяет создавать в узлах сети дубли (копии) данных без снижения производительности приложения и без нарушения непротиворечивости данных.

5. РАСПРЕДЕЛЕННЫЕ ПРЕДСТАВЛЕНИЯ (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах.

6. ОПТИМИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ЗАПРОСОВ. Оптимизация алгоритмов выполнения сложных операций, например соединения таблиц, выполняется с учетом размещения данных в глобальной сети. При этом учитывается пропускная способность сети, ее загрузка и объем передаваемой информации, вычислительная мощность узлов. На основе этой информации делается вывод о том, где лучше всего производить операцию соединения таблиц (как наиболее трудоемкую операцию).

7. РАСПРЕДЕЛЕННЫЕ ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы-мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы.

8. ЛОКАЛЬНАЯ АВТОНОМИЯ. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов.

9. НЕПРЕРЫВНАЯ ОБРАБОТКА (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.

10. НЕЗАВИСИМОСТЬ РАЗМЕЩЕНИЯ. Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.

11. ОБРАБОТКА РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов.

12. ГЛОБАЛЬНАЯ ОБРАБОТКА ВЗАИМОБЛОКИРОВОК И ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ ОДНОВРЕМЕННОМ ДОСТУПЕ К ДАННЫМ. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга.

13. НЕЗАВИСИМОСТЬ ОТ ТИПА КОМПЬЮТЕРОВ, ОПЕРАЦИОННЫХ СИСТЕМ, СЕТЕВЫХ ПРОТОКОЛОВ, ТИПОВ СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).

3.2. Требования к характеристикам распределенных СУБД

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

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

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

3.3. Средства для работы с распределенными данными

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

ФРАГМЕНТАЦИЯ И ДУБЛИРОВАНИЕ

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

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

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

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

СЛОВАРИ ДАННЫХ И ДИРРЕКТОРИИ

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

В Ingres глобальный словарь реализуется с помощью компоненты Ingres/Star. Эта компонента извлекает информацию из всех локальных словарей данных и выполняет оптимизацию запросов. Недостатком такого подхода является то, что все данные словарей собираются на центральном узле Ingres/Star и при его отключении или сбое теряется доступ к остальным узлам распределенной БД. Для восстановления доступа придется создавать другой центральный узел. В ORACLE7 все данные словаря распределены и при отключении или сбое одного из узлов все остальные узлы продолжают корректно работать. Транзакции, работающие с вышедшим из строя узлом, будут задержаны. Их можно будет выполнить позже (после восстановления узла) или отбросить.

ДВУХФАЗНАЯ ФИКСАЦИЯ ИЗМЕНЕНИЙ

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

Рассматриваемые СУБД поддерживают выполнение двухфазного протокола фиксации изменений. У Ingres, Informix и ORACLE7 для указания точки фиксации достаточно выполнить 1 команду (один оператор в программе).

Очень мощный и сложный алгоритм реализации протокола двухфазной фиксации изменений реализован в ORACLE7. Он состоит из следующих этапов:

1. Запускается распределенная транзакция, включающая команду COMMIT.

2. Этап подготовки

a) Узел-родитель обращается к каждому из своих узлов-детей с просьбой "дать обещание", что он зафиксирует или откатит свою часть изменений только после получения определенной команды;

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

c) Узел сообщает своему узлу-родителю о том, что он готов к работе;

d) Узел не может завершить транзакцию до тех пор, пока не получит на это разрешение от узда родителя.

3. Этап фиксации

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

b) Узел дает команду своим узлам-детям выполнить фиксации изменений (или откатить изменения);

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

d) После того, как все узлы зафиксировали или откатили изменения, снимается блокировка ресурсов.

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

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

ОБЕСПЕЧЕНИЕ ЦЕЛОСТНОСТИ РАСПРЕДЕЛЕННОЙ БД

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

- таблица, содержащая информацию о детях сотрудников;

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

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

Все эти таблицы содержат столбец "ФИО сотрудника". Правила обеспечения ссылочной целостности требуют, чтобы при изменении значений столбца "ФИО сотрудника" в одной таблице, автоматически выполнялась корректировка значений этого столбца в других таблицах. Для обеспечения ссылочной целостности используются 2 различных метода - триггеры и декларативные ограничения целостности стандарта ANSI.

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

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

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

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

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

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

4. СУБД, ПОДДЕРЖИВАЮЩИЕ АРХИТЕКТУРУ КЛИЕНТ-СЕРВЕР

Если в качестве сервера используется персональный компьютер с 486 процессором, количество одновременно работающих пользователей, не велико (5-10 человек) и к приложению не предъявляются повышенные требования по надежности, быстродействию, защите данных, то можно воспользоваться недорогими серверами для OS/2 и Novell NetWare.

Наиболее популярными из них являются

для OS/2:

- Microsoft SQL Server фирмы Microsoft,

- IBM Extended Services with Database Server for OS/2 фирмы IBM;

для Nowell NetWare

- NetWare SQL фирмы Nowell

- SQL Base Server NLM фирмы Gupta Technologies.

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

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

- Oracle 7 фирмы Oracle Corp.

- Sybase System10 фирмы Sybase Inc.

- Ingress Intelligent Database фирмы Ingress Corp.

- Informix-Online фирмы Informix Software.

В последнее время появились еще 2 распределенные коммерческие многоплатформенные СУБД - Interbase фирмы Borland и Progress фирмы Progress Software. Однако они пока значительно отстают по характеристикам от членов "большой четверки".

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

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

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

Фирма Sybase анонсировала выпуск новой версии своей СУБД, которую назвала System 10. Судя по рекламным материалам, эта СУБД, должна иметь очень хорошие характеристики и работать на мини и персональных компьютерах. Однако, пока большая часть компонент этой СУБД еще не доведена до должного уровня качества и не получила широкого распространения. Предыдущая версия СУБД Sybase широко распространена в США, но до недавнего времени в другие страны не продавалась. Поэтому на территории СНГ она известна мало и обеспечить высокий уровень технического сопровождения этой СУБД пока сложно. Кроме того, у нее не решены проблемы руссификации. Sybase предназначен для создания OLTP систем (on line transaction processing system).

СУБД Oracle версии 7 на сегодня является очень хорошим пакетом, однако ее основные недостатки являются продолжением ее достоинств. Их всего два: высокая стоимость и высокие требования к ресурсам компьютера. Особенно это актуально для персональных компьютеров.

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

Среди основных недостатков следует отметить:

- отсутствие механизма триггеров, что затрудняет обеспечение целостности БД,

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

- ограниченное число поддерживаемых платформ и сетевых протоколов,

- плохая работа с большими БД,

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

- ограниченные возможности инструментальных средств разработки приложений (требуется много программирования на языке 4GL,

- невозможность использования индексов в запросах с оператором ОR,

- использование в СУБД и инструментальных средствах различных языков,

- резкое снижение быстродействия при выполнении backup.

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

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

Для того, чтобы информация таблиц 1 и 2 была более понятна, рассмотрим более подробное описание некоторых характеристик СУБД.

Под вычислительной платформой понимается совокупность оборудования и операционной системы. Так на персональном компьютере могут стоять операционные системы DOS, OS/2, NetWare, Unix. Все это будут различные платформы. Говоря о большом числе клиентов в сети мы имеем в виду сотни и тысячи клиентов, одновременно, работающих с БД. Увеличение числа клиентов не должно сильно снижать быстродействие системы. Что касается переносимости на другие платформы, то эдесь речь идет о переносимости приложений

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

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

- ввод и вывод русских букв,

- возможность создания приложений с интерфейсом на русском языке,

- работа с русским языком функций Upper case, Lover case и других строчных функций,

- сортировка русских слов,

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

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

- русскоязычные подсказки и возможность создания в приложениях русских подсказок,

- преобразование русских букв при передаче данных по сети между узлами с различными кодовыми таблицами,

- документация на русском языке.

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

Характеристики, связанные с распределенной СУБД, описаны выше и более полно рассматриваются в таблице 3. Что касается больших БД, то таковыми считаются БД размером в десятки Гб. Работа с такими БД предъявляет дополнительные требования к быстродействию, операциям копирования и восстановления БД, администрированию и настройке БД.

Обычно СУБД предназначены либо для выполнения коротких транзакций (это СУБД для OLTP систем - online transaction processing), либо для выполнения сложных длинных транзакций (это СУБД для систем поддержки решений - Decisigin Support, иногда их называют MIS системы - management information system). Примером OLTP приложений служит, например, система продажи авиабилетов. Примером MIS системы служит система со сложными отчетами и вычислениями. Обычно в реальной жизни приложения содержат элементы как OLTP, так и MIS систем. Кроме того, и OLTP и MIS приложения работают одновременно с БД. Поэтому желательно, чтобы СУБД одинаково эффективно реализовывала и те и другие системы. Наиболее удачно это делают Oracle и Interbase.

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