Методические указания для студентов специальности 2205, 0755 «Проектирование и технология эвс», «Комплексная информационная безопасность автоматизированных систем» (стр. 16 из 21)

Источниками отказов могут быть:

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

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

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

В стандарте ANSI/ISO SQL включены операторы фиксации транзакции и отката транзакции COMMIT, ROLLBACK.

COMMIT означает успешное завершение транзакции, все изменения принимаются.

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

Новая транзакция может начаться непосредственно после оператора ROLLBACK.

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

[оператор начала транзакции]

SQL оператор

[оператор конца транзакции]

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

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

Восстановление базы происходит в следующих случаях:

- Индивидуальный откат транзакций (применение ROLLBACK, аварийное завершение работы программы, взаимоблокировка, при параллельном выполнении транзакций).

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

- Поломка ВЗУ (жесткий сбой).

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

8 ТЕХНОЛОГИЯ КЛИЕНТ-СЕРВЕР

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

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

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

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

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

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

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

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

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

Преимущества архитектуры клиент - сервер:

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

2) снижается сетевой трафик за счет посылки сервером клиенту только тех данных, которые он запрашивал; например, если необходимо сделать из таблицы объемом 15 000 записей выборку, результатом которой будут всего 2 записи, сервер выполнит запрос и перешлет клиенту набор данных из 2 записей;

3) упрощается наращивание вычислительных мощностей в условиях развития программного обеспечения и возрастания объемов обрабатываемых данных: проще и чаще дешевле усилить мощности на сетевом сервере или полностью заменить сервер на более мощный, нежели наращивать мощности или полностью заменять 100-500 клиентских компьютеров;

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

5) сервер реализует управление транзакциями и предотвращает попытки одновременного изменения одних и тех же данных;

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

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

Рисунок 4 – Схема непосредственного клиент-серверного доступа

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