Главная страница

Физическая организация данных


Скачать 487.44 Kb.
НазваниеФизическая организация данных
Дата23.02.2018
Размер487.44 Kb.
Формат файлаdocx
Имя файлаdb.docx
ТипДокументы
#37060
страница7 из 16
1   2   3   4   5   6   7   8   9   10   ...   16

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

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

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

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

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

    После выполнения этих этапов восстановления БД находится в согласованном состоянии и с ней можно работать.

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

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

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

    • назначение отдельным группам пользователей прав доступа (привилегий) к отдельным группам данных в соответствии с правилами ПО;

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. GRANT - предоставление одной или нескольких привилегий пользователю (или группе пользователей):

    GRANT { <список привилегий> | ALL PRIVILEGES } ON <имя объекта> TO {<список пользователей> | PUBLIC} [WITH GRANT OPTION];

    где <список привилегий> - набор прав, которые необходимо предоставить, или ALL PRIVILEGES - все права на данный объект; <имя объекта> - имя объекта БД, к которому предоставляется доступ; <список пользователей> - перечень пользователей (или ролей, см. дальше), которым будут предоставлены указанные права; PUBLIC - предопределённый пользователь, привилегии которого доступны всем пользователям БД. WITH GRANT OPTION - ключевые слова, дающие возможность пользова-телям из списка пользователей предоставлять назначенные права другим пользователям (т.е. передавать эти права).

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


    Таблица 6.1. Использование объектных привилегий

    Привилегия

    Операции

    Таблицы

    Представления

    Процедурные

    объекты

    ALTER

    изменение

    определения объекта

    +

    +

    +

    DELETE

    удаление данных

    +

    +




    EXECUTE

    выполнение объекта







    +

    INSERT

    добавление данных

    +

    +




    SELECT

    чтение данных

    +

    +




    UPDATE

    изменение данных

    +

    +










    Примечание: процедурные объекты - это хранимые процедуры и функции.

    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;

    "Плох тот план, который не допускает изменений".

    Публиус Сирус, древнеримский мыслитель

    1. ОПТИМИЗАЦИЯ РЕЛЯЦИОННЫХ ЗАПРОСОВ

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

      1. Этапы оптимизации запросов в реляционных СУБД

    Язык 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 (Зарплата). Если по этим полям есть индексы, то способы выполнения этого запроса могут быть такими:

    1. Найти по индексу INDEX(depNo) записи, удовлетворяющие первому условию, и проверить для найденных записей второе условие.

    2. Найти по индексу INDEX(born) записи, удовлетворяющие второму условию, и проверить для найденных записей первое условие.

    3. Последовательно считать все записи таблицы Emp и проверить для каждой записи оба условия.
    1   2   3   4   5   6   7   8   9   10   ...   16


  • написать администратору сайта