Распределенные базы данных

Размещено на http://www.allbest.ru/

8. Распределенные базы данных

8.1 Предпосылки возникновения РБД

база данные фрагментация транзакция

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

РБД представляет собой базу данных, отдельные части которой размещены (возможно с дублированием) на нескольких ЭВМ сети. 60-е - 70-е - 80-е гг. - появление и развитие централизованных вычислительных систем. 80-90 - появились распределённые системы. Широко используемые ранее в 60-70-х годах иерархические и сетевые модели данных плохо приспособлены для организации РБД. Так как там требуется использование явных адресных указателей связей между данными и, кроме того - использование процедурного языка манипулирования данными (ЯМД), что ведёт к увеличению периодических сообщений по ЛВС. 80-90г. - используются реляционные базы данных, которые не требуют поддержки явных адресных указателей, наличие непроцедурного языка даёт возможность упростить формулировку сложных запросов. При проектировании РБД обязательно выполняется фрагментация данных - разбиение исходного объекта глобального типа на отдельные части и размещение их на разных ЭВМ. Для получения информации о размещении данных по сети вводится специальный словарь-справочник данных (ССД). Фрагментация может быть горизонтальной (a, b) или вертикальной (1,2 - 3,4.

Фрагментация данных

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

Эти требования означают, что пользователи не замечают распределенность данных, что при одновременной модификации одних и тех же данных разными пользователями сохраняется целостность данных. А также понимается независимость пользователей и ПП от типа ЛВС и применяемого сетевого программного обеспечения. Пользователь не должен замечать, что его запрос обрабатывается, возможно, на нескольких ЭВМ.

Существуют понятия системы распределенных баз данных (СРБД) и системы распределения обработки данных (СРОД). В СРБД базы данных распределены между несколькими (возможно, территориально разобщенными) ЭВМ. В СРОД возможен параллельный доступ нескольких пользователей к централизованной базе данных. Основной целью СРБД является обеспечение управляемого доступа и независимого обращения к данным, распределённым в сети ЭВМ. Под управляемым доступом понимается степень безопасности, необходимая для защиты данных от неавторизованного доступа. Независимость обращения или разделимость, позволяет пользователям получить доступ к данным через различные, подчас значительно удалённые вычислительные средства. Сеть ЭВМ представляет совокупность неоднородных вычислительных средств, связанных между собой высокоскоростными каналами связи.

Технологические проблемы в РБД делят на 2 категории: 1. проблемы проектирования; 2. проблемы реализации, затрагивающие функционирование распределённой системы.

Факторы, стимулирующие развитие распределённой обработки данных.

* Снижение стоимости процессора (мини ЭВМ);

* Повышение квалификации конечного пользователя;

* Неудовлетворённость пользователя работой централизованных групп;

* Творчество пользователей;

* Высокая стоимость телефонных каналов;

* Теледоступ к базам данных;

* Развитие сетевого программного обеспечения;

* Секретность. В распределённых системах легче обеспечить секретность, поскольку в них не складываются, «все яйца в одну корзину»;

* Перегрузка центральных процессоров.

8.2 Классификация систем по способам обработки данных

Данные могут храниться двумя способами - непосредственно в виде файлов или в базах данных. Файлы обычно создаются для работы с одной прикладной задачей или группой связанных задач. Представление программиста о файле практически соответствует физической структуре файла. Распределённые данные часто организуются в форме файлов, а не в форме баз данных. Данные могут храниться централизовано или децентрализовано, что диктуется существом самих хранимых данных. Например, если файл непрерывно обновляется, а территориально разобщённые пользователи должны получать всякий раз последнее состояние данных (как в файле резервирования авиабилетов), то естественно такой файл централизовать. Данные обычно централизуются и тогда, когда поиск производится во всей их совокупности. С другой стороны, если данные используются локально в точке их происхождения, они могут быть децентрализованными. При низкой скорости обновления или при автономном обновлении (off-line) допустимо хранение нескольких копий одних и тех же данных в разных местах.

Рассмотрим различные типы систем, различающихся по характеру распределения данных.

1. Системы с централизованными данными:

Рис.8.1. Системы с централизованными данными

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

2. Иерархические системы (рис.8.2)

Различают: иерархии - зависимые системы и иерархии - независимые системы

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

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

Рис.8.2. Иерархические системы

3. Расщепленные данные:

Рис.8.3. Системы с расщепленными данными

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

4. Разделенные данные:

Рис.8.4. Системы с разделенными данными

В системах с разделёнными данными (рис.8.4) объединённые в сеть подсистемы содержат разные данные и разные программы и, как правило, создаются разными группами разработчиков. Тем не менее, они обслуживают одну и ту же частную корпорацию или государственное учреждение. Компьютеры получают возможность запрашивать данные друг у друга.

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

5. Реплицированные (дублированные) данные:

Рис.8.5. Системы с дублированными данными

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

Достоинство: при дублировании очень высокая надежность.

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

6. Гетерогенные системы:

Рис.8.6. Гетерогенные системы

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

7. Комбинированные формы распределённых данных

Рис.8.7. Комбинированные системы

РОД ставит много новых проблем: Какие функции должны быть централизованы, а какие децентрализованы? Где должны храниться данные? Какая конфигурация больших машин, малых машин и интеллектуальных терминалов окажется наилучшей для обслуживания заказчика?

8.3 Однородные и неоднородные системы БД

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

Прозрачность может быть реализована двумя методами.

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

2. Использование единого для всей сети стандартного пользовательского интерфейса (единого протокола). В этом случае все пользователи используют общий интерфейс. Должна существовать единая схема сетевой БД. Каждому типу локальной СУБД должен соответствовать свой тип преобразования схемы. При этом используется лишь n типов преобразований. Недостаток - пользователь должен изучить новую систему - сетевую СУБД.

В настоящее время для взаимодействия с различными СУБД используются специальные средства:

1. ODBC (Open Date Base Connectivity) - разработка фирмы Microsoft.

2. BDE (Borland Database Engine) - фирма Borland.

3. CGI (Common Gateway Interface) - сценарий в рамках Интернета.

Дифференциальные файлы (ДФ)

ДФ в БД аналогичны списку опечаток в книге. Вместо того, чтобы печатать новое издание книги, всякий раз, когда требуется внести изменения в текст, составляется список исправлений с указанием страниц. При достаточно большом списке опечаток производится реорганизация, т.е. создаётся новая книга.

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

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

8.4 Стратегия размещения данных в РБД по узлам сети

Достоинства и недостатки.

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

1. Централизация (единственная копия базы данных, расположенная в одном узле).

Достоинства. Все операции под контролем центрального узла.

Недостатки. - Затраты на связь и временные задержки.

- Ограничения при параллельной обработке.

- Ограничения объема.

- Ограничения доступа к данным и надежности.

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

Достоинства. - Увеличение объема памяти.

- Снижение стоимости связи.

- Время отклика меньше по сравнению с централизованной БД.

- Выше доступность и надежность.

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

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

Достоинство. - Надежность, доступность и эффективность выборки.

- Простота восстановления.

Недостаток. - Большие затраты в объеме памяти.

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

4. Смешанная (несколько копий подмножеств БД, в каждом узле может содержаться произвольный фрагмент БД).

Достоинство. Гибкость. Например, архивные данные могут хранится в одном месте, а критические данные могут дублироваться для повышения надежности).

Недостаток. - Необходимо хранить информацию о том, где находятся данные в сети.

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

Функции СУРБД

1. Автоматическое определение ЭВМ, на которой хранятся требуемые в запросе данные;

2. Декомпозиция общего запроса на частные подзапросы к БД;

3. Планирование обработки запросов;

4. Передача частных подзапросов и их исполнение на удалённых ЭВМ;

5. Поддержание копий дублированных данных;

6. Управление параллельным доступом к РБД многих пользователей;

7. Обеспечение целостности РБД.

Вопросы

1. Назовите основные этапы развития баз данных.

2. Каковы отличительные черты настольных СУБД в эпоху персональных компьютеров.

3. Укажите отличительные особенности технологии распределенных баз данных.

4. В чем состоит удобство применения интранет - технологии.

5. Назовите имена полнофункциональных СУБД и серверов.

6. Какие существуют средства разработки программ для работы с БД.

7. С какой целью проводится фрагментация данных?

8. Назовите факторы, стимулирующие развитие распределенной обработки данных.

9. Дайте классификацию систем по способам обработки данных.

10. Укажите достоинства и недостатки централизованных систем.

11. Каковы преимущества расчлененных баз данных?

12. Укажите отличительные черты однородных и неоднородных БД.

13. С какой целью используются дифференциальные файлы.

14. Укажите достоинства и недостатки различных стратегий размещения данных.

9. Удаленный доступ взаимодействия с базой данных

9.1 Режим работы с БД при удаленном доступе

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

Рис.9.1 Режимы работы с БД

Если же БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен параллельный доступ нескольких пользователей, то мы имеем дело с параллельным доступом к распределённой БД. Подобные системы называются системами распределения баз данных. В 90-х годах наметили переход от отдельных mainframe - систем к открытым распределённым системам. На первых порах при использовании модели «клиент-сервер» пользовательская программа не разделялась на части, она выполнялась некоторым монопольным блоком. Но при монопольном исполнении используются ресурсы только одного компьютера, а остальные компьютеры в сети рассматриваются как терминалы. Но теперь в отличие от эпохи майнфреймов при распределённой обработке используется архитектура «клиент-сервер».

Рис.9.2. Архитектура “клиент - сервер”

Сервер - это собственно СУБД. Он поддерживает все основные функции СУБД: определение данных, обработку данных, защиту и целостность данных.

Клиент - это различные приложения, которые выполняются под СУБД. Приложения - это программы, написанные на языках программирования С, Pascal и т.д. Клиент и сервер запускаются на разных машинах.

Существуют 2 способа:

1. Клиент может получать доступ к любому количеству серверов, но лишь к одному в одно и то же время. При этом пользователь должен знать, на какой именно машине, какая часть данных содержится (рис. 9.3а).

2. Клиент может получать доступ к любому количеству серверов одновременно. В этом случае серверы рассматриваются клиентом как один (с логической точки зрения), и пользователь может не знать, на какой именно машине какая часть данных содержится (рис.9.3б).

а) б)

Рис.9.3. Модели взаимодействия “клиента” и “сервера”

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

Основной принцип технологии «клиент-сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп:

1. Функции ввода и отображения данных (Presentation Logic);

2. Функции решения задач приложения (Business Logic);

3. Функции обработки данных внутри приложения (Database Logic);

4. Функции управления информационными ресурсами (Database Manager System); (СУБД) (DBMS)

5. Служебные функции (для связывания первых 4-х групп).

Структура типового приложения, работающего с БД представлена на рис.9.4.

Рис.9.4. Структура типового приложения “клиента”

Функции 1-й группы Presentation Logic:

* формирование экранных изображений;

* чтение и запись в экранные формы информации;

* управление экраном;

* обработка движений мыши и нажатия клавиш клавиатуры.

Бизнес-логика определяет алгоритм решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как C, C++, Cobol, Visual-Basic.

Логика обработки данных - связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используется язык запросов и средства манипулирования данными стандартного языка SQL. Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения.

9.2 Архитектура моделей удалённого доступа

9.2.1 Двухуровневые модели

Модель файлового сервера (File Server, FS)

В этой модели презентационная логика и бизнес-логика располагаются на клиенте. На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами находятся на клиенте.

Рис.9.5. Модель файлового сервера

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

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

Недостатки:

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

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

* отсутствие адекватных средств безопасности доступа к данным.

9.2.2 Модели удалённого доступа к данным (Remote Data Access, RDA) в архитектуре «клиент-сервер»

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

Рис.9.6. Модель “клиент-сервер”

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

Резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод/вывод файлов, а запросы SQL, а их объём существенно ниже. В ответ на запросы клиент получает только данные, релевантные запросу, а не блоки файлов, как в FS-модели.

Недостатки:

* SQL - запросы при интенсивной работе клиентских приложений могут существенно загрузить сеть;

* Дублирование кода приложения при одинаковых запросах для каждого клиентского приложения;

* Сервер в этой модели играет пассивную роль.

Данная модель и предыдущие модели называются моделями с «толстым клиентом».

9.2.3 Модель «сервера БД»

Данную модель поддерживает большинство современных СУБД: Informix, Ingres, SyBase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур (ХП) как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных.

Рис.9.7. Модель “сервера БД”

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

Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определённого события в БД. При возникновении соответствующего события, сервер запускает соответствующий триггер. Триггеры могут вызывать ХП.

Для написания ХП и триггеров используется расширение стандартного языка SQL, так называемый, встроенный SQL. Недостаток - большая загрузка сервера. Данную модель называют с «тонким клиентом» в отличие от предыдущих моделей.

9.2.4 Хранимые процедуры (ХП) и триггеры

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

ХП могут быть написаны на собственных ЯП СУБД. Так в СУБД Oracle для этого используется язык PL/SQL, а в MS SQL Server используется язык Transact SQL. Пример.

Create proc pr1 As Select *

From stud

Where spec=”2201”

ХП вызывается оператором EXEC <имя проц.><значение входного параметра><имя переменной для выходного параметра>

EXEC pr1

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

Create trigger <имя триггера>

On <имя таблицы> For {[insert][update][.delete]} - [with encripting] AS

SQL - операторы (тело триггера)

9.3 Многоуровневые модели

9.3.1 Модель сервера приложений

Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений (рис.9.8).

Рис.9.8. Модель сервера приложений

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

9.3.2 Модель серверов баз данных

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

Появление сервера для управления данными. Архитектура «один к одному». Один сервер обслуживает одного клиента. Выделение сервера в отдельную программу - революционный шаг, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем - на другую, осуществляя взаимодействие между ними по сети. Для обслуживания многих клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов.

Рис.9.9. Модель серверов баз данных

Проблемы, возникающие в модели «один к одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запуск от имени клиентов. Логически каждый клиент связан с сервером отдельной нитью (thread), или потоком, по которому передаются запросы. Такая архитектура получила название многопотоковой односерверной (multi-thread). Они позволяют значительно уменьшить нагрузку на ОС.



Рис.9.10. Модель с выделенным сервером

Возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты, что значительно уменьшает потребности в памяти и общее число процессов ОС. Например, системой с архитектурой «один к одному» будет создано 100 копий процессов СУБД для 100 пользователей, а здесь понадобится только один единый процесс.

Недостаток:

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

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («Virtual Server»).

Рис.9.11. Модель с архитектурой виртуального сервера

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

Недостатки:

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

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

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

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

Например. Имеется последовательность операций.

1. R5=R1[A,C]

2. R6=R2[A,B,D]

3. R7=R5[A>128]

4. R8=R5[A] R6

Здесь 1 и 3 операции можно объединить и выполнить параллельно с операцией 2, а затем выполнить над результатом последнюю четвёртую операцию. В моделях «клиент-сервер» большая часть бизнес-логики клиентского приложения выполняется именно на сервере, а не на клиенте. Для этого используются специальные объекты - хранимые процедуры, и хранятся в БД как таблицы. Курсоры делятся на курсоры сервера и курсоры клиента. Курсоры сервера создаются и выполняются на сервере, данные, связанные с ним, не пересылаются на компьютер клиента. Курсоры сервера определяются обычно в хранимых процедурах или триггерах.

9.4 Архитектура распределённых СУБД

Архитектура распределённых СУБД имеет многоуровневую архитектуру (5 уровней).( См.рис.9.12.)

1 часть. Верхние 4 уровня: процессоры - пользовательский, глобальный логический, фрагментный и распределённый. Они входят в сетевую СУБД.

2 часть. Нижний уровень - процессор узлового уровня. Относят к локальной СУБД.

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

Существование 3 и 4-го уровней представления объясняется распределённой природой базы данных и решением использовать управляемую избыточность. Третий уровень представления - фрагментное представление. Используя это представление, АБД определяет несвязанное подмножество базы данных, называемые логическими фрагментами, каждый из которых является подмножеством строк в таблице.

Рис.9.12. Архитектура распределенной СУБД

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

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

Ниже приведён пример «Вузовская БД», иллюстрирующий задачи уровней представления данных. В этом примере БД представлена в виде нескольких таблиц, с помощью которых задаются указанные выше уровни представления 1-й уровень, называемый глобальным логическим уровнем представления, соответствует логической структуре всей сетевой базы данных, как она представляется с точки зрения администратора БД. Этот уровень подобен концептуальному уровню представления. Пользовательский уровень описывает часть базы данных, доступную конкретному пользователю для использования. Эта часть является подмножеством глобального логического представления и подобна внешнему представлению.

Имеются три отношения: Студенты, Факультеты, Дисциплины.

Студенты (N, ФИО, Факультет, Стипендия)

Факультеты (Nф, Наим)

Дисциплины (Nд, Наим_Д, Кол_час)

Глобальный уровень:

Рис.9.13. Глобальный уровень представления

Ф₁,Ф₂,Ф₃ - фрагменты табл.Студенты, Ф_а-фрагмент табл.Факультеты,

Ф_А,Ф_В,Ф_С - фрагменты табл.Дисциплины

Распределенный уровень:

Рис.9.14. Распределенный уровень

Рис. 9.14 иллюстрирует распределение и дублирование хранимых фрагментов в трёхузловой системе в соответствии с факультетами 1,2,3.

Хранимые фрагменты являются физической реализацией логических фрагментов. Размещение фрагментов представлено в таблице (рис.9.15.)

Рис.9.15. Таблица размещения фрагментов базы данных.

Уровень узлового представления:

Рис.9.16. Узловое представление базы данных.

Конечное, или локальное, представление есть представление части базы данных, существующей в конкретном узле (отсюда «локальные»). Безусловно, база данных, расположенная в узле может рассматриваться как с точки зрения логической, так и физической структуры. Локальное представление является логической структурой, а физическая структура при этом является скрытой.

Вопросы

1. Основные режимы работы с БД.

2. Сервер БД - это?

3. В чем отличие систем распределенной обработки данных (РОД) от распределенных баз данных (РБД)?

4. Назовите основные функции стандартного интерактивного приложения?

5. Каковы основные функции Presentation Logic?

6. Какая функция определяет алгоритм решения задач приложения?

7. Стандартный язык запросов?

8. Назовите основные модели удаленного доступа.

9. Каковы недостатки модели файлового сервера?

10. В чем отличие модели файлового сервера (FS) от модели удаленного доступа (RDA).

11. Недостатки модели удаленного доступа (RDA).

12. Какие модели называются моделями с «толстым клиентом» и почему?

13. Какие модели можно отнести к моделям с “толстым клиентом” и к моделям с “тонким клиентом”.

14. Какие объекты составляют основу модели «сервера БД»?

15. Преимущества модели “сервера БД”.

16. С какой целью используются хранимые процедуры (ХП) и триггеры?

17. Что такое сервер приложений?

18. Какова эволюция развития архитектуры «клиент-сервер»?

19. Что такое многопотоковый сервер?

20. Архитектура распределенной СУБД имеет уровни представления:?

10 Параллельные процессы (или процесс транзакций)

10.1 Транзакции

Транзакцией называется последовательность операций, произведённых над БД и переводящих БД из одного непротиворечивого (согласованного) состояния в другое непротиворечивое (согласованное) состояние.

Транзакция - это логическая единица работы. Транзакция - это разовый прогон программы. Транзакция - это единица взаимодействия с базой данных. Логическая единица работы - не просто одиночная операция системы, а скорее согласование нескольких таких операций (например, добавление + изменение какого-либо кортежа). В общем, это преобразование одного согласованного состояния базы данных в другое, причём в промежуточных точках база данных находится в несогласованном состоянии.

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

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

Оператор COMMIT TRANSACTION сигнализирует об успешном окончании транзакции. Оператор ROLLBACK TRANSACTION сигнализирует о неудачном окончании транзакции. Все обновления должны быть аннулированы.

Для этого используется файл регистрации (журнал), где записываются детали всех операций обновления. Оператор COMMIT и ROLLBACK завершают транзакцию, а не программу. Программа может выполнять несколько транзакций. Сама программа завершается оператором RETURN.

10.2 Модели транзакций

В стандарте ANSI/ISO SQL определена модель транзакций. Стандарт определяет, что транзакция начинается с первого SQL-оператора. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается оператором COMMIT (успешное завершение) или ROLLBACK (прерывает транзакцию) (рис.10.1).

a) b)

Рис.10.1. Выполнение транзакций

а) успешное выполнение, в)аварийное завершение

В некоторых СУБД (например SYBASE) транзакции начинаются явно оператором BEGIN TRANSACTION.

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



Рис.10.2. Выполнение программы Р; Т₁ Т₂ Т₃ - транзакции

Транзакция - это не только логическая единица работы, но также единица восстановления.

10.3 Свойства транзакций

Транзакция обладает 4 свойствами: атомарность, согласованность, изоляция и долговечность (АСИД)

Атомарность означает, что выполняется всё или ничего.

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

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

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

10.4 Восстановление системы

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

· отказ системы (например, сбои в питании). Их называют аварийным отказом программного обеспечения.

· отказы носителей (например, поломка готовок дискового накопителя). аварийный отказ аппаратуры.

В 1-м случае для восстановления системы вводятся контрольные точки, которые фиксируются в журнале.

Рис.10.3. Этапы выполнения транзакций.

Транзакция Т₁ - полностью сохраняется; Т₂, Т₄ - перезапускаются;

Т₃ и Т₅ - отменяются.

10.5 Параллельные операции над БД

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

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

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

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

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

10.6 Проблемы параллелизма

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

1 - проблема потери результатов обновления,

2 - проблема незафиксированной зависимости,

3 - чтение «грязных» данных,

4 - проблема несовместимого анализа.

1). Проблема потери результатов обновления

Рис.3.4. Потеря результатов обновления.

А - элемент БД; Т1, Т2 - транзакции; t-время

Транзакция Т1 извлекает кортеж А в t1; Транзакция Т2 извлекает кортеж А в t2;

Транзакция Т1 обновляет кортеж А (на основе значений, полученных в момент времени t1) в t3; Транзакция Т2 обновляет тот же кортеж А (на основе значений, полученных в момент t2, которые имеют те же значения, что и в t1) в момент t4. Однако результат операции обновления, выполняемой транзакцией Т1 будет утерян, поскольку в момент времени t4 она не будет учтена и потому будет «отменена» операцией обновления, выполненной транзакции Т2.

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

P: А =5; READ A; A=A+1; WRITE A;

Рис.10.5. Выполнение программы Р.

Легко заметить (см.рис.10.5.), что хотя каждая транзакция добавляла к А единицу, его значение возросло лишь на 1. Это представляет серьёзную проблему, если, например А - число мест, проданных на определённый авиарейс.

2). Незафиксированная зависимость.

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

Рис.10.6. Незафиксированная зависимость

Транзакция Т1 выполняется на основе фальшивого предположения, что кортеж А имеет некоторое значение в момент времени t2, тогда как на самом деле он имеет некоторое значение, существовавшее ещё в момент времени t1. В итоге после выполнения Т1 будет получен неверный результат. Надо иметь ввиду, что отмена выполнения Т2 может произойти не по вине Т2, а, например, в результате краха системы.

3). Чтение «грязных» данных (фиктивные элементы - фантомы):

Рис.10.7. Чтение «грязных» данных

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

Транзакция Т1 дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция Т2, которая добавляет строку, удовлетворяющую условию отбора б. Т1 ничего не знает о существовании Т2, и так как сама она ничего не меняет в базе данных, то ожидает, что после повторного отбора будут отобраны те же самые строки. Результат: Транзакция Т1 в двух одинаковых выборках строк получит разные результаты.

4). Проблема несовместимого анализа

Транзакция Т1 выполняет анализ по всей таблице, например, подсчитывает общую сумму денег на счетах клиентов банка для главного бухгалтера. Пусть на всех счетах находятся одинаковые суммы, например, по 1000$. Пусть имеются три счёта S1, S2, S3 и везде по 1000$. Транзакция Т2 в этот момент выполняет перевод $500 c счёта S3 на S1. Общая сумма по всем счетам не меняется.

Рис.10.8. Несовместимый анализ

Т1 - подводит баланс. Т2 - переводит суммы с одного счета на другой.

Результат: Sum=2500, а должно быть Sum=3000. Это произошло из-за параллельной работы.

10.7 Конфликт транзакций

Анализ проблемы параллелизма показывает, что если не предпринимать специальных мер, то при совместной работе нарушается свойство (И) транзакций - изолированность. Транзакции реально мешают друг другу получать правильные результаты, если они пересекаются и обращаются к одним и тем же данным. В результате конкуренции за данными возникают конфликты доступа к данным.

Различают конфликты:

· W-W (Запись-Запись). Первая транзакция изменила объект и не закончилась. Вторая пытается изменить этот объект. Результат - потеря обновления.

· R-W (Чтение-Запись) Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат - несовместный анализ.

· W-R (Запись-Чтение). 1-я транзакция изменила объект и не закончилась. 2-я пытается прочитать этот объект. Результат - чтение двух «грязных» файлов.

Конфликты типа R-R (Чтение-чтение) отсутствуют, т.к. данные при чтении не изменяются.

График запуска транзакций могут быть:

1. Последовательные - если транзакции выполняются строго по очереди.

2. Чередующиеся - если график содержит чередующиеся элементарные операции транзакций.

В первом случае процесс замедляется, но зато выполняется правило.

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

Замечание:

При выполнении двух различных последовательных (а, следовательно, верных) графиков, содержащих один и тот же набор транзакций, могут быть получены различные результаты. Пусть Т1 выполняет действие «сложить X с 1», а транзакция Т2 - «Удвоить X». Тогда последовательный график {Т1,Т2} даст результат 2(Х+1), а последовательный график {Т2,Т1} даст результат 2Х+1. Таким образом, может существовать несколько верных графиков запуска транзакций, приводящих к разным результатам при одном и том же начальном состоянии базы данных. Существуют два способа разрешить конкуренции между транзакциями.

1. «Притормаживать» некоторые транзакции (таким образом обеспечить, чтобы конкурирующие транзакции выполнялись в разное время).

2. Предоставить конкурирующим транзакциям «разные» экземпляры данных

1-ый реализуется путём использования блокировок

2-ой реализуется путём использования данных из журнала транзакций.

10.8 Элементы блокировки

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

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

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

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

Пример 2. Программу Р из примера 1. можно было бы записать с блокировками следующим образом:

P: LOCK A; READ A; A:=A+1; WRITE A; UNLOCK A;

Пусть Т1 и Т2 - две исполнимых программы Р. При выполнении Т1 произойдёт блокировка. Если Т2 начинается до завершения Т1, то система заставит её ждать A:=A+1

Т1 |----------------------|

Т2 - - - - - - - - |--------------------|

Совместным результатом окажется увеличение А на 2.

10.8.1 Бесконечное ожидание и тупики

Пусть существует механизм блокировки. В примере 2 блокировка предоставляется Т2 после снятия её транзакцией Т1. Рассмотрим теперь иную ситуацию. Пусть во время пребывания Т2 в состоянии ожидания транзакция Т3 только запрашивает блокировку А, и этот запрос выполняется раньше, чем запрос Т2. Далее, в то время, когда блокировку установила транзакция Т3, её запрашивает Т4, чьё требование удовлетворяется после разблокирования А транзакцией Т3 и т.д. Очевидно, при этом не исключена возможность того, что Т2 будет бесконечно находиться в состоянии ожидания.

...