Физическая организация данных
 Скачать 487.44 Kb.
|
|
Блоки, содержащие подтверждённые модификации, не были записаны в файлы данных, так что эти изменения отражены лишь в журнале тран закций. Следовательно, журнал транзакций содержит подтверждённые данные, которые должны быть переписаны в файлы данных. Журнал транзакций и блоки данных содержат изменения, которые не были подтверждены. Изменения, внесенные неподтверждёнными транзакциями, во время восстановления БД должны быть удалены из файлов данных. Для того чтобы разрешить эти ситуации, СУБД автоматически выполняет два этапа при восстановлении после сбоев: прокрутку вперед и прокрутку назад.
После выполнения этих этапов восстановления БД находится в согласованном состоянии и с ней можно работать.
Под функцией секретности данных понимается защита данных от пред намеренного искажения и/или доступа пользователей или посторонних лиц. Для этого вся информация делится на общедоступные данные и конфиденци альные, доступ к которым разрешен только для отдельных групп лиц. Решение этого вопроса относится к компетенции юридических органов или администрации предприятия, для которого создаётся БД, и является внешней функцией по отношению к БД. Рассмотрим техническую сторону обеспечения защиты данных в БД от несанкционированного доступа. Общий принцип управления доступом к базе данных такой: СУБД не должна разрешать пользователю выполнение какой- либо операции над данными, если он не получил на это права. Санкционирование доступа к данным осуществляется администратором БД. В обязанности администратора БД входит:
Примечание: администратор БД обычно назначает права доступа в соответствии с проектом БД, который должен включать перечень групп пользователей и их привилегии. Для каждого пользователя система поддерживает паспорт пользователя, содержащий его идентификатор, имя процедуры подтверждения подлинности и перечень разрешённых операций. Подтверждение подлинности заключается в доказательстве того, что пользователь является именно тем человеком, за которого себя выдаёт. Чаще всего подтверждение подлинности выполняется путём парольной идентификации. Перечень операций обычно определяется той группой, к которой принадлежит пользователь. В реальных системах иногда преду-сматривается возможность очень ограниченного доступа к данным постороннего человека, не требующая идентификации (доступ типа "гость"). Парольная идентификация заключается в присвоении каждому пользователю двух параметров: имени (login) и пароля (password). При входе в систему она запрашивает у пользователя его имя, а для подтвер-ждения того, что это имя ввёл его владелец, система запрашивает пароль. Имя выдаётся пользователю при регистрации администратором, пароль пользователь устанавливает сам. При задании пароля желательно соблюдать следующие требования:
Для контроля выполнения этих требований обычно применяются специаль-ные программы. Управление доступом к данным осуществляется через СУБД, которая и обеспечивает защиту данных. Но такие данные вне СУБД становятся общедоступны. Если известен формат БД, можно осуществить к ней доступ с помощью другой программы (СУБД), и никакие ограничения при этом не помешают. Для таких случаев предусмотрено кодирование данных. Используются различные методы кодирования: перекомпоновка символов в кортеже, замена одних символов (групп символов) другими символами (группами символов) и т.д. Кодирование может быть применено не ко всему кортежу, а только к ключевым полям. Декодирование производится непосредственно в процессе обработки, что, естественно, увеличивает время доступа к данным. Поэтому к кодированию прибегают только в случае высоких требований к конфиденциальности данных. Предоставление прав доступа (привилегий) в системах, поддерживающих язык SQL, осуществляется с помощью двух команд: 1. GRANT - предоставление одной или нескольких привилегий пользова телю (или группе пользователей): GRANT { <список привилегий> | ALL PRIVILEGES } ON <имя объекта> TO {<список пользователей> | PUBLIC} [WITH GRANT OPTION]; где <список привилегий> - набор прав, которые необходимо предоста вить, или ALL PRIVILEGES - все права на данный объект; <имя объекта> - имя объекта БД, к которому предоставляется доступ; <список пользователей> - перечень пользователей (или ролей, см. дальше), которым будут предоставлены указанные права; PUBLIC - предопределённый пользователь, привилегии которого доступны всем пользователям БД. WITH GRANT OPTION - ключевые слова, дающие возможность пользова-телям из списка пользователей предоставлять назначенные права другим пользователям (т.е. передавать эти права). Права, подразумеваемые под словами ALL PRIVILEGES, зависят от типа объекта. Примерный перечень прав в зависимости от типа объекта БД приведён в табл. 6.1. Таблица 6.1. Использование объектных привилегий
Примечание: процедурные объекты - это хранимые процедуры и функции. 2. REVOKE - отмена привилегий: REVOKE [GRANT OPTION FOR] { <список привилегий> | ALL PRIVILEGES } ON <имя объекта> FROM {<список пользователей> | PUBLIC} { RESTRICT | CASCADE }; где [GRANT OPTION FOR] - отмена права передачи привилегий; CASCADE - при отмене привилегий у пользователя отменяются все приви-легии, которые он передавал другим пользователям; RESTRICT - если при отмене привилегий у пользователя необходимо отменить переданные другим пользователям привилегии, то операция завершается с ошибкой. Другие ключевые слова имеют то же значение, что и в команде GRANT. Для того чтобы упростить процесс управления доступом, многие СУБД предоставляют возможность объединять пользователей в группы или определять роли. Роль - это совокупность привилегий, предоставляемых пользователю и/или другим ролям. Такой подход позволяет предоставить конкретному пользователю определённую роль или отнести его к определённой группе пользователей, обладающей набором прав в соответствии с задачами, которые на неё возложены. Кроме привилегий на доступ к объектам СУБД ещё может поддерживать так называемыесистемныге привилегии: это права пользователя на создание/изменение/удаление (create/alter/drop) объектов различных типов. В некоторых системах такими привилегиями обладают только пользователи, включённые в группу АБД. Другие СУБД предоставляют возможность назначения дифференцированных системных привилегий любому пользователю в случае такой необходимости. Например, в СУБД Oracle права на создание таблиц и представлений пользователю manager можно предоставить с помощью той же команды GRANT, только без указания объекта: GRANT create table, create view TO manager; "Плох тот план, который не допускает изменений". Публиус Сирус, древнеримский мыслитель
В оптимизацию реляционных запросов входят два различных аспекта. Во- первых, это внутренняя задача СУБД, которая заключается в опре-делении наиболее оптимального (эффективного) способа выполнения реляционных запросов. Во-вторых, это задача программиста (или квалифицированного пользователя): она заключается в написании таких реляционных запросов, для которых СУБД могла бы использовать более эффективные способы нахождения данных. Сначала рассмотрим первый аспект.
Язык SQL является декларативным языком. В его командах отсутствует информация о том, как выполнить запрос, какие методы доступа к данным использовать. А почти каждая команда SQL из подмножества языка манипулирования данными (DML) может быть выполнена разными способами. Рассмотрим следующий запрос: Пример 7.1. Список сотрудников 4-го отдела не старше 25 лет с «чистой» зар платой не менее 30000 рублей" («чистой» называется зарплата после уплаты подоходного налога, в настоящее время - 13%). SELECT * FROM Emp WHERE depNo=4 AND born>'1985/01/01' AND salary*0.87>=30000; В этом запросе к таблице Emp (Сотрудники) указаны условия на поля depNo (Номер отдела), bom (Дата рождения) и salary (Зарплата). Если по этим полям есть индексы, то способы выполнения этого запроса могут быть такими:
|