Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
BSBD_k_ekzamenu / Материал_к_билетам_6-10 / Билет_7_вопрос_2 / Распределенные_базы_данных.doc
Скачиваний:
14
Добавлен:
05.06.2015
Размер:
464.38 Кб
Скачать

9. Аппаратная независимость

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

10. Независимость от операционной системы

Достижение этой цели частично зависит от достижения предыдущей и также не тре­бует дополнительного обсуждения. Очевидно, что необходимо иметь не только возмож­ность обеспечить функционирование одной и той же СУБД на различных аппаратных платформах, но и обеспечить ее функционирование под управлением различных опера­ционных систем для многих платформ — включая различные операционные системы на одном и том же оборудовании (например, чтобы версия СУБД для операционной систе­мы OS/390, версия для UNIX и версия для Windows могли совместно использоваться в одной и той же распределенной системе).

П. Независимость от сети

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

12. Независимость от типа субд

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

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

Однако эта тема слишком обширна (и важна на практике), поэтому ниже ей посвя­щен отдельный раздел (см. раздел 21.6).

21.4. Проблемы распределенных систем

В этом разделе подробно рассматриваются проблемы, которые упоминались в разде­ле 21.3. Ключевая проблема распределенных систем состоит в том, что коммуникацион­ные сети, по крайней мере, сети, которые охватывают большую территорию, или гло­бальные сети, пока остаются медленными. Обычная глобальная сеть чаще всего имеет среднюю скорость передачи данных от 5 до 10 тысяч байтов в секунду. Обычный же же­сткий диск имеет скорость обмена данными около 5—10 миллионов байтов в секунду. (С другой стороны, некоторые локальные сети поддерживают скорость обмена данными того же порядка, что и диски.) Поэтому основная задача распределенных систем (по меньшей мере, в случае глобальной сети, а также до некоторой степени и в случае ло­кальной сети) — минимизировать использование сетей, т.е. минимизировать количество и объем передаваемых сообщений. Решение этой задачи, в свою очередь, затрудняется из-за проблем в нескольких дополнительных областях. Ниже приведен список таких облас­тей, хотя нельзя гарантировать, что он является полным.

  • Обработка запросов.

  • Управление каталогом.

  • Распространение обновлений.

  • Управление восстановлением.

  • Управление параллельностью.