Internet, поэтому первоочередной задачей компании является оснащение своего сервера средствами электронной коммерции

Корпоративная большая ЭВМ

I ims . DB2

Инженерный отдел

Oracle

Отдел маркетинга

MS Access > Таблицы Excel

Дистрибьюторские центры

Отдел кадров

1 SQL Server

Плановый отдел

Informix

Отдел сбыта

Web-серверы

Sybase

Менеджеры

Intern

Клиенты

Рис. 22. h ПрнмвнвншраэличнЩБД а типичной кароративйой сети

В связи с тем что данные распределены по различным системам, нетрудно представить себе запросы, связанные с обращением сразу к нескольким базам данных:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ни одна из существующих распределенных СУБД по своим возможностям не соответствует этому идеалу. Имеются препятствия, из-за которых с трудом реализуются даже простые формы управления распределенными базами данных. К ним относятся-

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

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

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

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

Проблема совместимости данных. В различных вычислительных системах существуют разные типы данных, и даже когда в двух системах присутствуют данные одного и того же типа, они могут иметь разные форматы. Например, в компьютерах VAX и Macintosh 16-разрядные целые числа представляются по-разному. Для представления символов в мэйнфреймах компании IBM используется кодировка EBCDIC, а в персональных компьютерах - кодировка ASCII. В распределенной СУБД эти различия должны быть незаметны.

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

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