Реферат на тему:


Воспользуйтесь поиском к примеру Реферат        Грубый поиск Точный поиск






Загрузка...
Распределенная обработка данных

Распределенная обработка данных

План

1. Основные понятия и определения

2. Управление параллельной обработкой

3. Многопользовательские СУБД.

4. Проектирование многопользовательских баз данных

5. Проектирование распределенных баз данных

6. Стандартные интерфейсы доступа к серверам баз данных

Основные понятия и определения

Режимы использования БД в общем виде показаны на рис. 10.1.

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

Распределенная обработка - это обработка с использованием централизованной базы данных, доступ к которой может выполняться с разных компьютеров сети (рис. 10.2, a). Эта топология часто называется "клиент-сервер". В этой системе одни узлы - клиенты, а другие - серверы.

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

Клиент - это процесс, который посылает запрос.

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

Распределенная СУБД - это программная система, предназначенная для управления распределенными базами данных и которая

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

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

Управление параллельной обработкой

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

Транзакция - неделимая с точки зрения влияния на БД последовательность операторов манипулирования данными, которая рассматривается СУБД как единое целое. Или транзакция успешно

выполняется, и СУБД фиксирует изменения БД, которые были сделаны этой транзакцией, во внешней памяти, или, в случае неудачи, ни одно изменение не отображается на состоянии БД. Транзакция рассматривается как логическая единица работы с БД. Для того, чтобы использование механизмов обработки транзакций позволило обеспечить целостность данных и изолированность пользователей, транзакция должна иметь следующие свойства: атомарность (Atomicity), согласованность (Cosistency), изолированность (Isolation), долгосрочность (Durability). Транзакции, которые обладают этими свойствами называются ACID-транзакциями. Свойства транзакции означают следующее:

- атомарность означает, что транзакция выполняется как единая операция доступа к БД и выполняется или полностью или не выполняется вовсе;

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

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

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

Для обработки параллельных транзакций применяется сериализация транзакций и метод временных меток.

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

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

Для повышения степени параллельности доступа нескольких пользователей к одной БД используются такие блокировки

- нежесткое блокировки или раздельное блокировки (Shared - S-блокировка); объект блокируется для выполнения операции чтения; объекты в этом случае не изменяются в ходе выполнения транзакции и доступны другим транзакциям также, но только в режиме чтения;

- жесткое блокирование или монопольное (exclusive - X-блокировки) объект блокируется для выполнения операции записи, модификации или удаления. В этом случае выполняется монопольное блокирование объекта и объект остается недоступным другим транзакциям до момента завершения работы данной транзакции.

Применение различных типов блокировок приводит к тупиков. Тупиковая ситуация возникает тогда, когда две и более транзакции одновременно находятся в состоянии ожидания, причем для продолжения работы каждая из транзакций ожидает завершения работы другой транзакции.

Пример. Пусть транзакция 1 в момент времени t1 блокирует ресурс A, а транзакция 2 в момент времени t2 блокирует ресурс B (рис.10.3). В момент времени t3 транзакции 1 требуется ресурс B и она ожидает его освобождения транзакцией 2. В момент времени t4транзакции 2 нужен ресурс A и она ожидает его освобождения

Основой определения тупиковых ситуаций является построение графа ожидания транзакций. Алгоритм выхода из тупика предусматривает определение транзакции-жертвы. После выбора такой транзакции выполняется ее откат.

Для сериализации транзакций также применяется двухфазное блокирование, которое заключается в следующем:

- перед выполнением операций с любым объектом транзакция блокирует этот объект (накопление захватов);

- после снятия блокировки транзакция не должна накладывать никаких других блокировок (высвобождение захватов).

Многопользовательские СУБД

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

В технологии работы с БД выделяют функции:

транзакцией 1. Транзакция 1 ждет транзакцию 2, транзакция 2 ждет транзакцию 1.

- ввода и отображения данных (представление данных);

- прикладные функции, которые определяют основные алгоритмы решения прикладных задач (применение);

- обработки данных в приложениях;

- управление информационными ресурсами (СУБД).

Представление данных определяет то, что пользователь видит

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

Прикладные функции (бизнес-логика) определяют логику работы приложений приложений. Код применения пишется с использованием процедурных языков программирования.

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

Функции управления информационными ресурсами - это СУБД, которая обеспечивает хранение и управление БД.

В зависимости оттого, где расположены эти компоненты по отношению друг к другу различают монолитное исполнение (чаще всего для персональных БД), двух- и трехуровневое.

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

- модель файлового сервера;

- модель удаленного доступа к данным;

- модель сервера базы данных.

В модели файлового сервера (рис. 10.4) применение располагаются и выполняются на рабочих станциях. На файловом сервере хранятся только файлы БД (файлы данных, индексы и т.д.) и некоторые технологические файлы, которые необходимы для работы приложений и самой СУБД. Клиент обращается к СУБД на языке SQL, СУБД переводит запрос в последовательность файловых команд и передает файловому серверу. На каждую команду сервер передает блок данных. Обработка информации выполняется на рабочей станции с помощью СУБД. Системы этого класса стоят недорого, просты в установке и освоении. К недостаткам можно отнести следующее:

- на каждой рабочей станции находится копия СУБД;

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

- сложность распределенной обработки.

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

- запросы на языке SQL при интенсивной работе могут значительно загрузить сеть;

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

- сервер выполняет пассивную роль и поэтому функции управления информационными ресурсами должны выполняться клиентом.

Модель сервера базы данных (рис. 10.6) является дальнейшим развитием модели удаленного доступа. Эта модель расширена механизмами хранимых процедур и механизмами триггеров, которые создаются на расширении языка SQL.

Хранимые процедуры является средством программирования SQL-сервера и представляют собой подпрограммы, которые могут вызываться или приложениями пользователей, или триггерами. Триггеры представляют собой особый тип хранимой процедуры, которая самостоятельно реагирует на возникновение определенного события в БД. Триггер может активизироваться после операций сложения, модификации и удаления. Применение триггеров позволяет сделать сервер активным. Это означает, что сам сервер может быть инициатором обработки данных в БД.

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

Дальнейшим развитием модели сервера базы данных является трехуровневая архитектура (рис.10.7). Эта архитектура еще называется моделью с сервером приложений.

Сервер приложений - в трехзвенной архитектуре "клиент-сервер" компонент прикладной системы, который располагается между клиентом и сервером БД и реализует логику приложения.

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

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

Проектирование многопользовательских баз данных

Многопользовательская БД предполагает, что в определении требований к БД задействованы несколько пользователей. В зависимости от того, как учитываются требования пользователей, различают централизованный подход и интеграцию представлений пользователей. Централизованный подход предполагает, что требования к каждому представления пользователя объединяются в общий набор требований (рис. 10.8).

На этапе проектирования БД создается глобальная модель данных, которая соответствует общему представлению. Глобальная модель также проверяется, как и локальные модели. Корректность глобальной модели проверяется с помощью правил нормализации, что позволяет убедиться в структурной согласованности, логической целостности и минимальной убыточности принятой модели данных. Модель также проверяется с целью выявления возможностей выполнения транзакций, которые будут задаваться пользователями.

Интеграция представлений пользователей предусматривает, что требования к каждому представления пользователя применяются для создания отдельной модели данных, соответствует этому представлению пользователя. В дальнейшем, на этапе проектирования БД, модели данных, полученных объединяются в единую глобальную модель данных (рис. 10.9).

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

Проектирование распределенных баз данных

На рис. 10.10 показана архитектура распределенной СУБД.

Существуют такие схемы размещения данных в системе:

- централизованное;

- фрагментировано;

- с полной репликацией;

- с избирательной репликацией.

Централизованное размещение предполагает, что на одном из узлов создается и сохраняется единая БД. Доступ к этой БД имеют все пользователи сети.

фрагментированным размещения предполагает, что БД делится на непересекающихся фрагменты, каждый из которых размещается в одном из узлов системы.

Размещение с полной репликацией предусматривает, что полная копия БД размещается на каждом узле системы.

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

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

Обновление данных, что реплицируются, может выполняться синхронно и асинхронно. Синхронное обновление предполагает, что все копии реплицировать данных обновляются одновременно с обновлением исходной копии. Асинхронная репликация предусматривает

что обновление реплицировать данных выполняется с задержкой относительно обновления выходных данных.

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

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

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

- неперетиннисть - это значит, что один элемент не должен присутствовать в двух и более фрагментах.

Фрагментация может быть вертикальная (по атрибутам) и горизонтальная (по кортежах).

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

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

- распределенная система должна выглядеть с точки зрения пользователя, как обычная нераспределенная система;

- узлы в распределенной системе должны быть независимы или автономные;

- в системе не должно быть ни одного узла, без которого система не может функционировать;

- должно выполняться условие независимости от расположения и пользователь может получать доступ к БД с любого узла;

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

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

- поддержка обработки распределенных запросов;

- поддержка управления распределенными транзакциями;

- аппаратная, программная, мэрежна независимость, а также независимость от типа СУБД;

- обеспечение непрерывного функционирования.

Стандартные интерфейсы доступа к серверам баз данных

Для доступа к БД применяют такие интерфейсы:

- интерфейс прикладного программирования (API, Application Programming Interface);

- интерфейс уровня вызовов (SQL / CLI, SQL / Call Level Interface);

- открытый интерфейс для

Загрузка...

Страницы: 1 2