4.7. Построение сетевых баз данных: одно- и многопользовательские решения

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

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

При построении БД необходимо сразу решить, в каком режиме бу­дет осуществляться доступ к данным:

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

• в многопользовательском режиме, когда с БД одновременно могут работать несколько пользователей (многопользовательская БД).

4.7.1. Персональные базы данных

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

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

• системы, доступные для непрограммистов;

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

4.7.2. Многопользовательские базы данных

Многотерминальная система

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

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

Многопользовательская база данных на файл-сервере

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

При этом манипуляция данными осуществляется следующим обра­зом. База данных (а иногда и код приложения) хранится на сервере, а вся работа по обновлению, хранению, добавлению и отображению ин­формации выполняется в локальной системе. Файл-сервер в этом слу­чае выступает в роли удаленного жесткого диска для базы данных и кода приложения. Большинство персональных СУБД поддерживает меха­низм блокировок для обеспечения целостности данных. Таким образом, эти системы могут быть использованы для построения и работы с по­добной многопользовательской базой данных. При этом выбор СУБД оп­ределяется уровнем сложности системы и профессиональным уровнем разработчика. Если создаваемая база данных относительно мала - размер каждой из таблиц не превышает 25 Мбайт, и одновременный доступ к ней будет производить небольшое количество пользователей, то этот подход работает прекрасно. Но производительность такой системы начинает резко падать при увеличении размеров таблиц и ко­личества пользователей, пытающихся одновременно обратиться к базе данных. Особенность этого подхода заключается в том, что при про­смотре таблицы ее содержимое полностью передается по сети на ло­кальную машину. Сети имеют сравнительно низкую пропускную способ­ность, так что если один из пользователей начнет выполнять сорти­ровку в большой таблице, то это может сделать работу остальных пользователей в сети невозможной на долгое время. Если же локаль­ная сеть подключена к территориально разнесенной сети (WAN - Wide Area Network) и требуется обеспечить возможность работы с базой данных с удаленного компьютера, то необходимость пересылки больших объемов данных по сетевым мостам и маршрутизаторам через несколько сетевых сегментов еще более обострит проблему.

Рис. 4.8. Многотерминальная система

Архитектура клиент-сервер

В системе, построенной на этом подходе, обработка данных раз­деляется между двумя или более компьютерами. При этом клиентская часть системы (front end) использует ПК для представления данных и манипуляции ими. Сервер (back end) используется для хранения, сор­тировки, изменения, комбинирования и защиты данных (рис. 4.10). В противоположность предыдущему подходу по сети передаются не табли­цы, а выборки, являющиеся результатами выполнения запросов, напи­санных на языке SQL.

Рис. 4.9. Сеть персональных компьютеров с файл-сервером

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

Рис. 4.10. Система с архитектурой клиент-сервер

Можно, к примеру, внести изменения в клиентскую часть или перенести сервер на более мощную машину. Пусть, например, разра­ботчик построил систему типа клиент-сервер с использованием пакета PowerBuilder (инструмент для создания клиентских прило­жений), работающего на ПК под WINDOWS, для доступа к данным, хра­нящимся на сервере Oracle, работающем под OS/2. Позднее было реше­но, что использование RISC-сервера позволит повысить производи­тельность. При этом не потребуется переписывать код приложения или менять операционную систему на ПК-клиенте для того, чтобы Oracle стал работать под UNIX. То же самое приложение можно использовать с базой данных на сервере Oracle, работающем под NetWare NLM. Ис­пользование архитектуры клиент-сервер позволяет более гибко подхо­дить к проблеме выбора инструментов для построения клиентских при­ложений. Например, разработчик может реализовать большую часть своего приложения на Visual Basic, а для создания специальных от­четов использовать какой-то другой инструмент. С другой стороны, архитектура кли­ент-сервер не лишена недостатков. Возможность совмещения несколь­ких операционных систем порождает усложнение инфраструктуры разра­батываемой системы, которая может быстро стать технически запутан­ной. В конце концов разработчик часто сталкивается с необходи­мостью поддержки нескольких операционных систем - одной для сети, одной или более для сервера базы данных и одной или нескольких для клиентов, что естественным образом повышает сложность управления и администрирования подобной системы.