Преимущества протоколов удаленного вызова процедур

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

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

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

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

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

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

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

Функции администратора АБД:

1. анализ предметной области.

2. проектирование стр-ры БД.

3. задание ограничения целостности.

4. первоначальная загрузка и введение БД.

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

6. обеспеч восстановл БД.

7. Анализ обращ польз-лей к БД.

8. Анализ эффект функционир-я БнД.

9. Работа с пользователями.

10.Подготовка и поддержка сист программ ср-в, СУБД, ППП, ОС.

11. Организационно-методическая работа (созд методики проектир БнД, опред целей и направл развития системы, планирование этапов развития БнД, разработка и выпуск организационно-методических материалов)

Обеспечение защиты данных

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

Безопасность данных (обеспечение физической защиты)

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

Наиболее типичными сбоями являются следующие:

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

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

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

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

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

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

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

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

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

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

Резервное копирование может быть полным и инкрементным. Полная копия (level 0 backup) включает все блоки данных БД или табличной области. Инкрементная копия состоит только из тех блоков, которые изменились со времени последнего резервного копирования. Создание инкрементной копии происходит быстрее, чем полной, но возможно только после проведения полного резервного копирования.

Обычно технология проведения резервного копирования такова:

*раз в неделю (день, месяц) осуществляется полное копирование;

*раз в день (час, неделю) проводится обновление копии (инкрементное копирование).

Защита от несанкционированного доступа

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

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

*классификация данных в соответствии с их использованием;

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

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

*тестирование вновь создаваемых средств защиты данных;

*периодическое проведение проверок правильности работы системы защиты, исследование и предотвращение сбоев в её работе.

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

Парольная идентификация заключается в присвоении каждому пользователю двух параметров: имени (login) и пароля (password). При входе в систему она запрашивает у пользователя его имя, а для подтверждения того, что это имя ввел его владелец, система запрашивает пароль. Имя выдаётся пользователю при регистрации администратором, а пароль пользователь устанавливает сам.

При задании пароля желательно соблюдать следующие требования:

*длина пароля должна быть не менее 6-и символов;

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

*пароли должны часто меняться.

Для обеспечения выполнения этих требований обычно применяются специальные программы.

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

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

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

Дата добавления: 2015-05-09