Базы данных

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

Содержание

1. Введение в дисциплину

2. Клиенты и серверы локальных сетей

3. Модель "клиент-сервер"

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

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

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

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

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

9. Журнал транзакций.

10. Структура журнала.

11. Многопользовательская работа с БД в СУБД MS Access

12. Существующие в Access типы прав доступа

13. Манипуляции с файлами рабочих групп

14. Шифрование БД

15. Репликация баз данных

локальный сеть сервер запрос транзакция

Тема 1. Введение в дисциплину

Архитектура "клиент-сервер"

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

Открытые системы

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

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

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

Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось придти к соглашению об основных стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным (а в большинстве случаев и системным) программистам. Как кажется, несмотря на появление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в ближайшие годы.

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

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

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

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

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

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

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

Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось придти к соглашению об основных стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным (а в большинстве случаев и системным) программистам. Как кажется, несмотря на появление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в ближайшие годы.

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

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

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

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

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

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

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

Режимы работы с базой данных.

Тема 2. Клиенты и серверы локальных сетей

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

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

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

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

Примерами сервером могут служить:

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

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

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

файловый сервер, поддерживающий общее хранилище файлов для всех рабочих станций;

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

Сервер локальной сети предоставляет ресурсы (услуги) рабочим станциям и/или другим серверам.

Принято называть клиентом локальной сети, запрашивающий услуги у некоторого сервера и сервером - компонент локальной сети, оказывающий услуги некоторым клиентам.

Системная архитектура "клиент-сервер"

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

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

Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

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

Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду

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

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

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

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

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

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

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

Тема 3. Модель "клиент-сервер"

Модель "клиент-сервер" связана с принципом открытых систем. Термин "клиент-сервер" исходно применялся в архитектуре ПО, которое ориентировало распределение процесса выполнения по принципу взаимодействия 2-х программ, процессов, один из которых в этой модели назывался клиентом, а другой - сервером. При этом предполагалось, что один серверный процесс может обслуживать множество клиентских процессов.

Ранее приложение (пользовательская программа) не разделялось на части, а выполнялось монолитным блоком, но при рациональном использовании ресурсов сети данный принцип не актуален. Теперь все ПК в сети обладают собственными ресурсами и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы. Основной принцип технологии "клиент-сервер" в БД заключается в разделении функций стандартного интерактивного приложения на 5 групп:

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

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

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

Функции управления информационными ресурсами (DML);

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

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

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

Основные задачи PL:

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

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

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

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

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

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

Процессор управления данными (Data Base Manager System Processing) - это собственно СУБД, которая обеспечивает управление и хранение данных. В идеале СУБД должна быть скрыта от BL-приложения. Однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.

Тема 4. Двухуровневые модели

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

Модель файл-сервера.

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

Достоинства:

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

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

Алгоритм выполнения запроса клиента.

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

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

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

Достоинства:

перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС.

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

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

унификация интерфейса клиент-сервер.

стандартным при обращении приложения клиента и сервера становится язык SQL.

Недостатки:

запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть.

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

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

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

Для того, чтобы избавиться от недостатков модели удаленного доступа должны быть соблюдены следующие условия:

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

БД должна отображать некоторые правила ПО, законы ПО.

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

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

Одной из важных проблем СУБД является контроль типов данных через язык описания данных (ЯОД).

Модель активного сервера.

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

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

Трафик обмена информацией между клиентом и сервером резко уменьшается.

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

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

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

Достоинства:

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

Недостатки:

Очень большая загрузка сервера.

Функции сервера:

Осуществляет мониторинг событий, связанных с описанными триггерами;

Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;

Обеспечивает исполнение внутренней программы каждого триггера;

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

Запускает хранимые процедуры из триггеров;

Возвращает требуемые данные клиенту;

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

Для разгрузки сервера была предложена 3-уровневая модель сервера:

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

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

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

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

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

Достоинства:

Обладает большей гибкостью, чем двухуровневая модель.

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

Серверы баз данных

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

Взаимодействие серверных и клиентских процессов в модели 1:1.

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

Такая архитектура получила название многопотоковой односерверной.

Достоинства:

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

Многопотоковая односерверная архитектура.

Недостатки:

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

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

Архитектура виртуального сервера.

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

Недостатки:

невозможно направить запрос от конкретного клиента к конкретному серверу.

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

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

Многопотоковая мультисерверная архитектура.

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

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

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

Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.

Достоинства:

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

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

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

Достоинства:

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

Гибридный параллелизм.

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

Выполнение запроса при вертикальном параллелизме.



Выполнение запроса при гибридном параллелизме.

Тема 7. Модели транзакций

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

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

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

ввод нового заказа со всеми реквизитами заказчика;

изменения состояния для всех выбранных комплектующих на складе на "занято" с привязкой к определенному заказу;

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

включение нового заказа в производство.

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

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

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

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

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

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

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

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

Цепочечные.

Вложенные.

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

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

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

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

долговечность (прочность).

Иногда данные транзакции называются ACID-транзакциями.

ACID - Atomicity, Consistency, Isolation, Durability.

Упомянутые выше свойства означают следующее:

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

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

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

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

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

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

Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в БД, которые были сделаны в процессе выполнения транзакций.

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

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

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

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

В стандарте ANSI/ISO SQL транзакция завершается одним из 4-х возможных путей:

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

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

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

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

Тема 9. Журнал транзакций

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

Общие принципы восстановления:

Результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД.

Результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии БД.

Это означает, что восстанавливается последнее по времени согласованное состояние БД.

Ситуации, при которых требуется производить восстановление состояния БД:

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

оператор ROLLBACK;

аварийное завершение программы;

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

восстановление после внезапной потери содержимого ОП (мягкий сбой). Случаи:

при аварийном выключении электропитания;

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

восстановление после поломки основного внешнего носителя БД (жесткий сбой).

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

Возможны два основных варианта ведения журнальной информации:

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

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

Достоинства:

Позволяет выполнять индивидуальные откаты транзакций.

Недостатки:

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

Тема 10. Структура журнала

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

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

Имеются два альтернативных варианта журнала транзакций:

Протокол с отложенными обновлениями.

Протокол с немедленными обновлениями.

Ведение журнала по принципу отложенных изменений предполагает следующий механизм выполнения транзакций:

Когда транзакция (T1) начинается, в протокол заносится запись 1 <T1.Begin.Transaction>.

На протяжении выполнения транзакции в протоколе для каждой изменяемой записи заносится новое значение: 2 <T1, TD_RECORD, атрибут, новое значение,…>, где ID_RECORD - уникальный номер записи.

Если все действия, из которых состоит транзакция T1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится: 3 <T1.COMMIT>.

После того как транзакция фиксирована, записи протокола, относящиеся к T1, используются для внесения соответствующих изменений в БД.

Если происходит сбой, то СУБД просматривает протокол и выясняет какие транзакции необходимо переделать. Транзакцию T1 необходимо переделать, если протокол содержит обе записи (1, 3). БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется системная процедура REDO(), которая заменяет все значения элементов данных на новые, просматривая протокол.

Если в протоколе не содержится команда фиксации транзакции COMMIT, то никаких действий проводить не требуется, а транзакция запускается заново.

Журнал транзакций:

Существует альтернативный механизм с немедленным выполнением предусмотренных изменений сразу в БД, а в протокол заносятся не только новые, но все и все старые значения изменяемых атрибутов. Строка в журнале транзакций выглядит так: <T1, TD_RECORD, атрибут новое значение старое значение …>. Если транзакция успешно завершена, то все изменения уже внесены в БД, а при откате транзакции выполняется системная процедура UNDO(), которая возвращает все старые значения в отмененной транзакции.

Для восстановления при сбое используется следующий механизм:

Если транзакция содержит команду начала транзакции, но не содержит команды фиксации (COMMIT), то выполняется последовательность действий, как при откате транзакции (т.е. восстанавливаются старые значения).

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

Изменения заносятся как в журнал транзакций, так и в БД не сразу, а сначала буферируются.

Тема 11. Многопользовательская работа с БД в СУБД MS Access

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

Использовать защиту на уровне пользователя можно на отдельном компьютере и при коллективной работе - в составе локальной сети.

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

Для организации защиты на уровне пользователя в системе Access создаются рабочие группы (РГ). Каждая РГ определяет единую технологию работы совокупности пользователей. Информация о каждой рабочей группе хранится в соответствующем файле РГ (system.mdw), который автоматически создается при установке системы. Информация о размещении этого файла хранится в системном реестре. Для управления РГ в Access 2002 имеется программа "Администратор рабочих групп" (АРГ), запустить которую можно из подменю Сервис->Защита.

Кроме сведений о системе защиты на уровне пользователя в файле РГ хранятся параметры системы Access:

параметры отображения информации системой Access (строки состояния, окна запуска, панели инструментов, скрытых и системных объектов).

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

Файл РГ описывает группы пользователей и отдельных пользователей, входящих в эту РГ. Он содержит учетные записи групп пользователей и отдельных пользователей. По каждой учетной записи система Access хранит права доступа к объектам БД.

По умолчанию, в каждую рабочую группу входит 2 группы пользователей:

администраторы (имя группы Admins)

обычные пользователи (имя группы Users)

Причем в группу Admins первоначально включен один администратор под именем Admin. При создании групп указывается имя (идентификатор) группы и код, представляющий собой последовательность от 4 до 20 символов. При регистрации (создании) пользователей в системе защиты им присваивается имя, код и необязательный пароль. Каждому из пользователей, независимо от принадлежности к группе, можно присвоить пароль.

Этот пароль, в отличие от пароля БД, называется паролем учетной записи и хранится в учетной записи в файле РГ.

Каждой из групп присваиваются определенные права на объекты базы данных. Члены группы Admins имеют максимальные права.

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

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

При создании рабочих групп и регистрации пользователей действуют следующие ограничения:

Группы Admins и Users удалить невозможно;

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

Все регистрируемые пользователи автоматически становятся членами группы Users. Удалить их из этой группы нельзя.

Уудалить пользователя Admin из РГ нельзя (из группы Admins его можно удалить, а из группы Users - нет).

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

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

Структура рабочей группы.

Основное назначение системы защиты на уровне пользователя состоит в контроле прав доступа к объектам БД. Для этого нужно установить защиту БД с помощью мастера защиты.

Тема 12. Существующие в Access типы прав доступа

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

Явные права имеются в случае, если они определены для учетной записи пользователя.

Неявные права - это права той группы, в которую входит пользователь.

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

Типы прав доступа:

Права доступа	Разрешенные действия	Объекты
Открытие/запуск	Открытие БД, формы или отчета, запуск макроса	БД, формы, отчеты, макросы
Монопольный доступ	Открытие БД для монопольного доступа	БД
Чтение макета	Просмотр объектов в режиме конструктора	Таблицы, запросы, формы, отчеты, макросы, модули
Изменение макета	Просмотр и изменение макета объектов или удаление объектов	Таблицы, запросы, формы, отчеты, макросы, модули
Администратора	Для баз данных: установка пароля, репликация и изменение параметров запуска. Для объектов БД: полные права на объекты и данные, в том числе предоставление прав доступа	БД, таблицы, запросы, формы, отчеты, макросы, модули
Чтение данных	Просмотр данных	Таблицы, запросы
Обновление данных	Просмотр и изменение данных без их вставки и удаления	Таблицы, запросы
Вставка данных	Просмотр и вставка данных без их изменения	Таблицы, запросы
Удаление данных	Просмотр и удаление данных без их изменения и вставки	Таблицы, запросы

Изменить права других пользователей на объекты некоторой БД могут следующие пользователи:

Члены группы Admins;

Владелец объекта;

Пользователь, получивший на объект права администратора.

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

Владелец объекта - это пользователь, создавший объект.

Владельца объекта можно изменить путем передачи права владельца другому пользователю. Правами изменения владельца обладают пользователи, имеющие право изменить права доступа к объекту или создать объект (Сервис->Защита->Разрешения).

Создать объект в новой БД, можно с помощью операции импорта/экспорта или копирования его в БД. Для создания и защиты на уровне пользователя копии всей БД можно воспользоваться мастером защиты (Сервис->Защита->Мастер). Владельцем защищенной БД может стать другой пользователь => здесь происходит изменение владельца БД, но у исходной БД остается свой владелец.

Установка защиты на уровне пользоваеля - это процесс, сложнее парольной защиты. Она состоит из следующих операций:

Создание файлов РГ;

Создание учетных записей пользователей и групп;

Включение пользователей в группы;

Активизация процедуры подключения к Access;

Защита каждой из БД с помощью "мастера защиты".

Тема 13.

Выполняются с помощью программы "Администратор рабочих групп" (АРГ).

Назначение - привязка Access к нужному файлу РГ. (Сервис->Защита).

Функции АРГ:

создание файла РГ;

связь с произвольным файлом РГ;

выход из программы.

Система защиты на уровне пользователя действует в двух основных режимах:

С требованием подключения пользователя к системе;

Без требования подключения пользователя к системе;

Для активизации окна входа в систему необходимо:

Запустить Access;

Сервис->Защита->Пользователи и группы. Откроется окно "Пользователи и группы".

На вкладке "Пользователи" проверить, что в поле имя выбрана учетная запись Admin.

На вкладке изменение пароля оставить пустым поле "текущий пароль", а в поле "новый пароль" ввести его (от 1 до 14 символов, без пробелов).

Подтверждение пароля.

С помощью кнопки отчет о защите можно получить отчет различной степени детальности:

о пользователях и группах;

о пользователях;

о группах.

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

Определение прав пользователей и групп.

Вызов окна управления правами доступа: Сервис->Защита->Разрешение.

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

Для выбора нескольких объектов в области "имя объекта" используется клавиша Ctrl.

Для смены владельца некоторого объекта БД - вкладка "Смена владельца".

Тема 14. Шифрование БД

Средства шифрования в Access позволяют копировать файл БД таким образом, что он становится недоступным для чтения из других программ, в которых известен формат БД Access. Шифровать не защищенную паролем БД смысла нет, т.е. шифрация в Access применяется, чтобы изменить до неузнаваемости стандартный формат файла БД (Запустить Access->Сервис->Защита->Шифровать/дешифровать->указать имя БД, которую требуется зашифровать->указать имя, диск и папку для целевой БД->ОК).

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

Вывод: при шифровании необходимо дать другое имя БД, проверить ее, а исходную удалить.