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

Любая БД должна быть многопользовательской.

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

Сеть – это некая среда обмена информацией между компьютерами.

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

Архитектура Клиент – Сервер.

Рассмотрим модели взаимодействия клиента и сервера. Основным принципом этого взаимодействия является разделение функций интерактивного взаимодействия. В этом разделении можно выделить 4 функции:

1.

2. Определение конкретных функций.

3. Функции хранения и управления данными.

4. Служебные функции взаимодействия между тремя вышеуказанными группами.

В любом приложении можно выделить 3 основных компонента:

1. Компонент представления – основная задача обеспечение ввода и внешнего представления данных. Поддерживает интерфейс данных.

2. Прикладной компонент.

3. Компонент доступа к информационным ресурсам.

Модели взаимодействия клиента и сервера отличаются характеристиками:

- способ распределения этих компонентов между клиентом и сервером,

- интерфейсом внутренним между этими компонентами.

Основные модели взаимодействия клиент – сервер.

1. Файл – серверная модель (FS).

2. Модель удаленного доступа к данным (RDA).

3. Сервер баз данных (DBS)

4. Сервер приложений (AS)

1. FS.

Компонент представления и прикладной компонент размещаются на клиенте. На сервер выносится компонент доступа.

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

Преимущества:

1. Сервер поддерживает лишь один компонент доступа к ресурсам, следовательно сервер может не выделятся из общей среды.

Недостатки: клиент должен поддерживать прикладной и интерактивный компонент, следовательно к клиенту предъявляются требования.

2. Приходится тиражировать ядро СУБД.

3. Очень высокий трафик.

4. Низкоуровневый интерфейс.

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

2. RDA.

Клиент посылает SQL запрос и получает SQL ответ, т.е. таблицу.

Преимущества:

1. Существенно снижается трафик

2. Разгрузка сервера от несвойственных ему функций.

3. Унифицируется интерфейс.

4. Невысокие требования к серверу.

Недостатки:

1. Загрузка сети по прежнему достаточно велика

2. Высокая степень децентрализации. Сложно организовать администрирование.

3. Роль сервера пассивна, т.е. сервер лишь отвечает на запросы клиента.

3. DBS

Прикладной компонент переносится на сервер.

Пояснение: здесь два типа взаимодействия

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

2. Взаимодействие между прикладным компонентом и компонентом доступа, с использованием SQL

Такую схему позволяют строить практически все современный БД: Informix, Sybase, Ingress, Oracle. Основой такой схемы является механизм хранимых процедур.

Плюсы:

1. Существенно снижается трафик. Хранимые процедуры выполняются на сервере, следовательно, предельно низкий трафик, предельно разгружена сеть.

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

3. Предельно высокая степень централизации позволяет организовать надежную защиту данных.

4. Ядро СУБД размещается на одном камне, следовательно, не требуется поддерживать другие ядра.

5. Перенесение одного компонента на другой позволяет активизировать сервер, передать ему кое-какие активные функции.

Минусы:

1. Очень высокие требования к серверу.

2. Язык хранимых процедур недостаточно выразителен, совершенно не стандартизован. Система не обладает мобильностью, переносимостью

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

4. AS

Выделяются два сервера.

Каждый компонент размещается на отдельном камне, этот компонент является клиентом: сервер приложений и сервер данных.

API - интерфейс.

AS работает под управлением многозадачной операционной системы.

Это трехзвенная архитектура.

Дата добавления: 2014-08-04; просмотров: 468; Нарушение авторских прав

Мы поможем в написании ваших работ!