Разработка и эксплуатация удаленных баз данных

Разработка и эксплуатация удаленных баз данных

План

1. Терминология УБД

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

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

4. Типы параллелизма

5. Модели транзакций Список литературы

1. Терминология УБД Пользователь БД — это программа или человек, обращающиеся к БД на языке манипулирования данными.

Запрос — это процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД.

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

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

Топология БД (структура РБД) — это схема распределения физических БД по сети. Локальная автономность означает принадлежность локальному владельцу информации локальной БД и связанных с ней определенных данных.

Удаленный запрос — это запрос, который выполняется с использованием модемной связи.

Возможность реализации удаленной транзакции — это обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.

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

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

Модель удаленного управления данными (модель файлового сервера). В этой модели BL и PL располагаются на клиенте. На сервере располагаются файлы с данными и доступ к ним. Функции управления информационными ресурсами в этой модели находятся на клиенте.

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

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

Модель удаленного доступа к данным. В модели удаленного доступа (RDA) база данных хранится на сервере. На нем же находится и ядро СУБД. На клиенте располагаются PL и BL приложения. Клиент обращается к серверу с запросами на языке SQL.

Достоинства: перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС. Процессор сервера целиком загружается операциями обработки данных, запросов и транзакций. Резко уменьшается загрузка сети, запросы на ввод-вывод и на SQL уменьшаются в объеме, т. е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу.

Унификация интерфейса клиент-сервер. Стандартным при обращении приложения клиента и сервера становится язык SQL.

Недостатки:

Запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть. На клиенте располагаются PL и BL, и если при повторении аналогичных функций в различных приложениях (других клиентов) их код должен быть повторен для каждого клиентского приложения, следовательно, дублирование кода приложения. Сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте => это усложняет клиентское приложение.

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

Модель активного сервера. Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server.

Основу данной модели составляет механизм хранимых процедур (как средства программирования SQL-сервера), механизм триггеров (как механизм отслеживания текущего состояния информационного хранилища) и механизм ограничений на пользовательские типы данных (который иногда называется механизмом поддержки доменной структуры).

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

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

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

Достоинства: Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях.

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

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

Клиент — обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы.

Серверы приложений — составляют новый, промежуточный уровень архитектуры.

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

удаленная файловый сервер триггер

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

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

Достоинства: Уменьшается нагрузка на ОС, возникающая при работе большого числа пользователей.

Многопотоковая односерверная архитектура. Недостатки: Т.к. сервер может выполняться только на одном процессоре, возникает ограничение на применение СУБД для мультипроцессорных платформ. Например, если компьютер имеет 4 процессора, то СУБД с одним сервером использует только один из них, не загружая оставшиеся 3. В некоторых системах эта проблема решается вводом промежуточного диспетчера — архитектура виртуального сервера.

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

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

4. Типы параллелизма Рассмотрим несколько путей распараллеливания запросов.

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

Достоинства: Сокращается время выполнения запроса.

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

Достоинства: Сокращается время выполнения запроса.

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

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

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

С точки зрения работника — это единая последовательность операций. Если она будет прервана, то БД потеряет свое целостное состояние.

Свойства транзакций. Способы их завершения

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

1. структура транзакции

2. параллельность внутри транзакции

3. продолжительность

4. Типы транзакций:

5. Плоские (классические)

6. Цепочечные.

7. Вложенные.

8. Плоские транзакции характеризуются 4 классическими свойствами:

9. атомарность;

10. согласованность;

11. изолированность;

Долговечность (прочность). Иногда данные транзакции называются ACID-транзакциями. ACID — Atomicity, Consistency, Isolation, Durability. Упомянутые выше свойства означают следующее:

Атомарность — выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

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

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

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

Варианты завершения транзакций:

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

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

Откат транзакции — это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции.

Каждый оператор в транзакции выполняет свою часть работы, но для успешного завершения всей работы в целом, требуется безусловное завершение всех их операторов. В стандарте ANSI/ISO SQL транзакция завершается одним из 4-х возможных путей:

Оператор COMMIT означает успешное завершение транзакции, его использование делает постоянными изменения, внесенные в БД в рамках текущей транзакции.

Оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в БД в рамках этой транзакции. Новая транзакция начинается непосредственно после использования ROLLBACK.

Успешное завершение программы, в которой была инициирована текущая транзакция, означает успешное завершение транзакции (как будто был использован оператор COMMIT). Ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

1. Карпова Т. С. Базы данных: Модели, разработка, реализация/ Т. С. Карпова СПб: Питер 2006 — 98с.

2. Фуфаев Э. В. Разработка и эксплуатация удаленных баз данных/ Э. В. Фуфаев, Д. Э. Фуфаев Изд.: Академия 2008 — 256с.

3. Кренке Д. Теория и практика построения баз данных: пер. с англ / Д. Кренке. — 9 — е изд. — СПб.: Питер, 2005. — 858 с.

4. Петров В. Н. Информационные системы/В.Н. Петров. — СПб.: Питер, 2002 — 123с

5. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А. Д. Хомоненко. — СПб.: КОРОНА 2000. — 416с.