Вы находитесь на странице: 1из 28

Лекція

«Архітектура СУБД, які розраховані на


багато користувачів»

1. Функції, що реалізовуються в СУБД.


2. Компоненти СУБД.
3. Телеобробка.
4. Файловий сервер.
5. Технологія "клиєнт/сервер".

Кафедра безпеки інформаційних систем і технологій


Функции, реализуемые в СУБД
Функции, которые должны быть реализованы в любой полномасштабной СУБД:
1. СУБД должна предоставлять пользователям возможность сохранять, извлекать и
обновлять данные в базе данных (хранение, извлечение и обновление данных) –
фундаментальная функция СУБД. (Способ реализации этой функции в СУБД должен позволять
скрывать от конечного пользователя внутренние детали физической реализации системы, например,
файловую организацию или используемые структуры хранения.)
2. СУБД должна предоставлять доступ конечным пользователям к системному каталогу,
в котором хранится описание элементов данных. Ключевой особенностью архитектуры
ANSI/SPARC является наличие интегрированного системного каталога с данными о
схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как
пользователям, так и функциям СУБД. Обычно в системном каталоге хранятся
следующие сведения:
 имена, типы и размеры элементов данных;
 имена связей;
 накладываемые на данные ограничения поддержки целостности;
 имена пользователей, которым предоставлено право доступа к данным;
 внешняя, концептуальная и внутренняя схемы и отображения между ними;
 статистические данные, например частота транзакций и счетчики обращений к
объектам базы данных и т. д.
3. СУБД должна иметь механизм поддержки транзакций. Транзакция представляет собой набор
действий, выполняемых отдельным пользователем или прикладной программой с целью доступа или
изменения содержимого базы данных.
Функции, реализуемые в СУБД
4. СУБД должна иметь механизм, который гарантирует корректное обновление базы
данных при параллельном выполнении операций обновления многими пользователями
(управление параллельной работой).
5. СУБД должна предоставлять средства восстановления базы данных на случай какого-
либо ее повреждения или разрушения.
6. СУБД должна иметь механизм, гарантирующий возможность доступа к базе данных
только санкционированным пользователям (контроль доступа к данным).
7. СУБД должна обладать способностью к интеграции с коммуникационным
программным обеспечением (поддержка обмена данными). Даже СУБД для
персональных компьютеров должны поддерживать работу в локальной сети, чтобы
вместо нескольких разрозненных баз данных для каждого отдельного пользователя
можно было бы установить одну централизованную базу данных и использовать ее как
общий ресурс для всех существующих пользователей.
8. СУБД должна обладать инструментами контроля, чтобы данные и их изменения
соответствовали заданным правилам (поддержка целостности данных). Целостность
базы данных означает корректность и непротиворечивость хранимых данных.
9. СУБД должна обладать инструментами поддержки независимости программ от
фактической структуры базы данных (поддержка независимости от данных).
10. СУБД должна предоставлять некоторый набор различных вспомогательных служб.
Вспомогательные утилиты обычно предназначены для оказания помощи АБД в
эффективном администрировании базы данных.
Компоненты СУБД
Основные компоненты типичной системы управления базами данных
Компоненты СУБД
Основные компоненты типичной системы управления базами данных
Процессор запросов преобразует запросы в последовательность низкоуровневых команд
для диспетчера базы данных.
Диспетчер базы данных. Этот компонент взаимодействует с запущенными
пользователями прикладными программами и запросами. Диспетчер базы данных
принимает запросы и проверяет внешние и концептуальные схемы для определения тех
концептуальных записей, которые необходимы для удовлетворения требований запроса.
Затем диспетчер БД вызывает диспетчер файлов для выполнения поступившего запроса.
Диспетчер файлов. Манипулирует предназначенными для хранения данных файлами и
отвечает за распределение доступного дискового пространства. Он создает и
поддерживает список структур и индексов, определенных во внутренней схеме. Если
используются хешированные файлы, то в его обязанности входит и вызов функций
хеширования для генерации адресов записей. Диспетчер файлов не управляет
физическим вводом/выводом данных непосредственно, а лишь передает запросы
соответствующим методам доступа, которые считывают данные в системные буферы или
записывают их оттуда на диск (или в кэш).
Препроцессор языка DML преобразует внедренные в прикладные программы DML-
операторы в вызовы стандартных функций базового языка (модуль объектный код
программы). Для генерации соответствующего кода препроцессор языка DML должен
взаимодействовать с процессором запросов.
Компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор
таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а
управляющая информация – в заголовках файлов с данными.
Диспетчер словаря. Диспетчер словаря управляет доступом к системному каталогу и
обеспечивает работу с ним.
Компоненты СУБД
Компоненты диспетчера базы данных
Компоненты СУБД
Компоненты диспетчера базы данных
Модуль контроля прав доступа проверяет наличие у данного пользователя
полномочий для выполнения затребованной операции. После проверки полномочий
пользователя для выполнения затребованной операции управление передается
процессору команд.
Модуль контроля целостности данных. В случае операций, которые изменяют
содержимое базы данных, модуль контроля целостности данных выполняет проверку
того, удовлетворяет ли затребованная операция всем установленным ограничениям
поддержки целостности данных (например, требованиям, установленным для ключей).
Оптимизатор запросов определяет оптимальную стратегию выполнения запроса.
Диспетчер транзакций осуществляет требуемую обработку операций, поступающих в
процессе выполнения транзакций.
Планировщик. Этот модуль отвечает за бесконфликтное выполнение параллельных
операций с базой данных. Он управляет относительным порядком выполнения
операций, затребованных в отдельных транзакциях.
Диспетчер восстановления. Этот модуль гарантирует восстановление базы данных до
непротиворечивого состояния при возникновении сбоев.
Диспетчер буферов отвечает за перенос данных между оперативной памятью и
вторичным запоминающим устройством.
Диспетчер восстановления и диспетчер буферов иногда (в совокупности) называют
диспетчером данных, а сам диспетчер буферов – диспетчером кэша.
Телеобработка
Топология телеобработки
Телеобработка
Классическая централизованная архитектура
Телеобработка
Современная централизованная архитектура,
включая соединения LAN и WAN
Файловый сервер

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

а) один клиент — один сервер;

б) несколько клиентов – один


сервер;

в) несколько клиентов –
несколько серверов
Технология "клиент/сервер"
Небольшая локальная сеть с сетевым доступом к серверу база данных
Технология "клиент/сервер"
Распределенная архитектура базы данных
Технология "клиент/сервер"
Функции, выполняемые участниками взаимодействия в среде
"клиент/сервер"
Клиент Сервер
Управляет пользовательским Проверяет полномочия пользователей.
интерфейсом. Принимает и обрабатывает запросы к базе
Принимает и проверяет синтаксис данных со стороны клиентов.
введенного пользователем запроса. Гарантирует соблюдение ограничений
Выполняет приложение. целостности.
Генерирует запрос к базе данных и Выполняет запросы (при необходимости
передает его серверу. возвращает результаты клиенту).
Отображает полученные данные Поддерживает системный каталог.
пользователю. Обеспечивает параллельный доступ к базе
данных.
Обеспечивает управление восстановлением.
Технология "клиент/сервер"
Преимущества архитектуры «клиент-сервер»:
 Обеспечивается более широкий доступ к существующим базам данных.
 Повышается общая производительность системы. Поскольку клиенты и
сервер находятся на разных компьютерах, их процессоры способны выполнять
приложения параллельно. При этом настройка производительности компьютера
с сервером упрощается, если на нем выполняется только работа с базой
данных.
 Стоимость аппаратного обеспечения снижается. Достаточно мощный
компьютер с большим устройством хранения нужен только серверу  для
хранения и управления базой данных.
 Сокращаются коммуникационные расходы. Приложения выполняют часть
операций на клиентских компьютерах и посылают через сеть только запросы к
базе данных, что позволяет существенно сократить объем пересылаемых по
сети данных.
 Повышается уровень непротиворечивости данных. Сервер может
самостоятельно управлять проверкой целостности данных, поскольку все
ограничения определяются и проверяются только в одном месте. При этом
каждому приложению не приходится выполнять собственную проверку.
 Данная архитектура естественным образом отображается на архитектуру
открытых систем.
Технология "клиент/сервер"
Традиционная двухуровневая архитектура "клиент/сервер"
Технология "клиент/сервер"
Трехуровневая архитектура "клиент/сервер"
Технология "клиент/сервер"
Преимущества трехуровневой архитектуры перед одно- и
двухуровневой моделями:
 "Тонкий" клиент, для которого требуется менее дорогостоящее
аппаратное обеспечение.
 Централизация сопровождения приложений благодаря передаче
средств реализации прикладных алгоритмов, применяемых
многочисленными конечными пользователями, на единственный
сервер приложений. При этом устраняется необходимость
развертывания программного обеспечения на множестве компьютеров, что
представляет собой одну из самых сложных задач в двухуровневой модели
"клиент/сервер".
 Дополнительная модульность, которая упрощает модификацию
или замену программного обеспечения каждого уровня без
оказания влияния на остальные уровни.
 Отделение основных средств реализации прикладных алгоритмов
от функций базы данных упрощает задачу равномерного
распределения нагрузки.
Размещение сервера базы данных в сети при наличии веб-
сервера, взаимодействующего с базой данных
Технология "клиент/сервер"
Преимущества интеграции СУБД в среду Web:
 преимущества использования функций СУБД;
 независимость от платформы;
 стандартизация;
 прозрачный сетевой доступ;
 масштабируемость развертывания;
 новаторский подход.

Недостатки интеграции СУБД в среду Web:


 недостаточная надежность;
 слабая защищенность;
 высокая стоимость Web-узла;
 трудности при масштабировании;
 ограниченные функциональные возможности языка HTML;
 отсутствие поддержки состояния;
 высокие требования к пропускной способности сети;
 недостаточная производительность.
Использование VPN для обеспечения удаленного доступа к БД
Хранение базы данных в облаке
Хранение базы данных в облаке
Проблемы с облачными системами хранения данных
 Поскольку база данных не находится на территории компании,
безопасность становится огромной проблемой. Компания, которой
принадлежат данные, больше не имеет полного контроля над мерами
безопасности. Она должна полагаться на поставщика облачных услуг для
защиты базы данных от несанкционированного доступа. Она также должна
безоговорочно доверять сотрудникам поставщика услуг.
 Доступ к базе данных требует прямого интернет-соединения. В отличие от
архитектур, в которых база данных находится во внутренней сети
компании, обработка не может продолжаться, когда Интернет недоступен.
 Компания, которой принадлежат данные, должна полагаться на
поставщика облачного хранилища для обеспечения непрерывной работы.
Ответственность за обеспечение доступности базы данных больше не
лежит на компании; ответственность лежит на третьей стороне.

В целом, владелец данных теряет большой контроль над данными, когда


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

Применение ТР-монитора в качестве компонента промежуточного уровня в


трехуровневой архитектуре "клиент/сервер"
Технология "клиент/сервер"
Применение ТР-мониторов обеспечивает следующие преимущества:
 Маршрутизация транзакций.
ТР-монитор позволяет добиться высокой
масштабируемости с использованием средств перенаправления транзакций в
конкретные СУБД.
 Управление распределенными транзакциями.
ТР-монитор позволяет
управлять транзакциями, которые требуют доступа к данным, хранящимся в
нескольких, возможно даже в разнородных СУБД. (Например, для выполнения
транзакции может потребоваться обновление данных, хранящихся в СУБД Oracle на узле 1, в
СУБД Informix на узле 2 и в СУБД IMS на узле 3. ТР-мониторы обычно управляют транзакциями с
использованием стандарта DTP (Distributed Transaction Processing – обработка распределенных
транзакций) организации Х/Open. СУБД, поддерживающая этот стандарт, может
функционировать как диспетчер ресурсов под управлением ТР-монитора, действующего как
диспетчер транзакций.)
 Уравновешивание нагрузки. ТР-монитор способен равномерно распределять
клиентские запросы по нескольким СУБД, находящимся на одном или нескольких
компьютерах, по принципу перенаправления обращений клиента к службам
наименее загруженного сервера. Кроме того, такой монитор может в случае
необходимости переводить в рабочее состояние дополнительные СУБД, если это
требуется для обеспечения необходимого уровня производительности.
Технология "клиент/сервер"

 Мультиплексирование соединений. В среде с большим количеством


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

Вам также может понравиться