Файл: Конспект лекций по учебной дисциплине по дисциплине мдк. 02. 02. Технология разработки и защиты баз данных.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 26.04.2024

Просмотров: 202

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Содержание

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

ТЕМАТИЧЕСКИЙ ПЛАН

ПОЯСНЕНИЯ К НАПИСАНИЮ КОНСПЕКТА

Раздел 1 Основы теории баз данных.

Тема: Понятие базы данных, системы управления баз данных.

Тема: Классификация баз данных. Архитектура баз данных.

Тема: Администратор базы данных и его функции. Пользователи баз данных.

Раздел 2 Модели данных.

Тема: Понятие о моделировании данных

Тема: Иерархическая модель данных. Сетевая модель данных.

Раздел 3 Реляционная модель данных.

Тема: Основные понятия реляционной модели данных.

Тема: Инфологическая модель данных.

Проектирование инфологической модели данных

Тема: ER моделирование базы данных.

Раздел 4. Основы реляционной алгебры.

Тема: Реляционная алгебра. Операции: объединение, пересечение, разность, декартово произведение

Тема: Выборка, проекция, соединение, деление

Тема: Применение реляционной алгебры.

Раздел 5. Этапы проектирования базы данных.

Тема: Этапы проектирования базы данных.

Тема: Концептуальное моделирование предметной области.

Тема: Метод нормальных форм

Тема: Нормальные формы

Тема: ER моделирование предметной области.

Тема: Методы создания основных объектов

Тема: Создание таблиц в СУБД Access

Тема: Разработка схемы базы данных

Тема: Создание однотабличных запросов в СУБД Access.

Тема: Создание многотабличных запросов в СУБД Access.

Раздел 6. Язык запросов SQL.

Тема: Основные понятия и компоненты языка SQL.

Тема: Выражения, условия и операторы языка SQL.

Тема: Средства управления таблицами.

Тема: Средства управления данными.

Раздел 7. Оформление и работа с базой данных.

Тема: Типы и виды форм. Методы и средства создания.

Тема: Создание отчётов. Создание печатных форм отчётов

Тема: Макросы. Основные макрокоманды

1 Определение макроса

1 Определение макроса

Раздел 8. Распределенные, параллельные базы данных.

Тема: Основные условия и требования к распределённой обработке данных

1 Терминология распределенных баз данных

3 Принципы функционирования распределенной БД

1 Терминология распределенных баз данных

3 Принципы функционирования распределенной БД

Тема: Базовые архитектуры распределенных баз данных

Тема: Архитектура сервера баз данных

ПЛАН

2 Архитектура «активный сервер баз данных»

3. Архитектура сервера приложений

2 Архитектура «активный сервер баз данных»

3. Архитектура сервера приложений

Тема: Доступ к базам данных в архитектуре «клиент-сервер»

Тема: Вычисление распределенных запросов.

Тема: Транзакции и целостность базы данных.

Тема: Триггеры и хранимые процедуры.

Раздел 9. Защита базы данных.

Тема: Безопасность данных. Управление правами доступа.

Тема: Обязательные методы защиты базы данных.

3 Поддержка мер обеспечения безопасности в языке SQL

3 Поддержка мер обеспечения безопасности в языке SQL

Директивы GRANT и REVOKE

Раздел 10. Базы данных в Интернете.

Тема: Основы XML.

1 Определение XML

1 Определение XML

Тема: Доступ к данным с помощью ADO.NET.

функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.
Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.

5 Межоперабельность

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

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

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

Контрольные вопросы для

  1. Опишите и сопоставьте стили архитектуры клиент/серверных вычислений.

  2. Сопоставьте клиент/серверную обработку данных и традиционную схему.

  3. Какова цель функций оптимизации запроса?

  4. С каким прозрачным свойством связана оптимизация запроса?

  5. Перечислите типы алгоритмов оптимизации запроса.

  6. Опишите три стратегии фрагментации данных. Приведите примеры.

  7. Что такое репликация данных, и каковы три стратегии репликации?

  8. Какие факторы влияют на реализацию технологии «клиент-сервер»?

  9. Какой спектр операций манипулирования данными используется в модели файлового сервера?

  10. Что означает пассивная роль сервера БД в модели доступа к удаленным данным?

  11. Какие ограничения языка SQL можно отнести к недостаткам модели сервера приложений?

  12. Как распределены роли клиента и сервера в модели сервера приложений?

  13. Какие технологии используются при построении систем распределенных обработки данных?

  14. Свойства идеальных распределенных систем

  15. Поддержка целостности в распределенных системах

  16. Как обрабатываются распределенные запросы

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


ЛЕКЦИЯ 35

Тема: Транзакции и целостность базы данных.


ПЛАН

1 Определение и свойства транзакций

2 SQL-выражения для управления транзакциями

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

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

5 Транзакции в Microsoft .NET
ЛИТЕРАТУРА: [1], стр. 264 – 278


1 Определение и свойства транзакций

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

Свойства транзакций

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

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

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

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

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

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

    2. Цепочечные

    3. Вложенные

Для поддержания целостности используемых ресурсов транзакция должна обладать свойствами ACID (ACID - Atomicity, Consistency, Isolation, Durability.)
Плоские транзакции характеризуются 4 классическими свойствами:

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

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

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

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

2 SQL-выражения для управления транзакциями

Для управления транзакциями имеется три выражения:

SET TRANSACTION - Начинает транзакцию и определяет ее поведение.

COMMIT - Сохраняет изменения, внесенные транзакцией, в базе данных и завершает транзакцию.

ROLLBACK - Отменяет изменения, внесенные транзакцией, и завершает транзакцию.
Синтаксис команды SQL для запуска транзакции:

SET TRANSACTION [Access mode] [Lock Resolution]
[Isolation Level] [Table Reservation]

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

В отличие от файлов данных, журналы транзакций не организованы в страницы по 8 КВ

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

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

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

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

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

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

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


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

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

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

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

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

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

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

5 Транзакции в Microsoft .NET

Вызов хранимой процедуры (stored procedure), которая заключает необходимые операции в операторы BEGIN TRANSACTION и COMMIT/ROLLBACK TRANSACTION, дает наилучшую производительность, позволяя выполнить транзакцию с разовым обменом данными с сервером (single round-trip). Кроме того, транзакции баз данных могут быть вложенными, т. е. внутри активной транзакции можно начать выполнение новой транзакции.

Контрольные вопросы

    1. Сформулируйте понятие транзакции.

    2. Опишите типы транзакций.

    3. Какие SQL-выражения для управления транзакциями вам известны?

    4. Каков назначение журнала транзакций?

    5. Какими свойствами должна обладать транзакция?

    6. Перечислите основные проблемы модифицирующих транзакций

    7. Что такое устойчивое состояние базы данных и как его можно достичь?

    8. Перечислите и поясните четыре основных свойства транзакций.

    9. Какие уровни резервного копирования используются в управлении восста-новлением БД? Кратко опишите предназначение каждого из этих уровней.

    10. С помощью какого оператора оповещается СУБД об окончании транзакции?

    11. Что такое откат транзакции?

ЛЕКЦИЯ 36

Тема: Триггеры и хранимые процедуры.


ПЛАН

1 Триггеры

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

3 Генераторы

ЛИТЕРАТУРА: [1], стр. 288 – 290
1 Триггеры

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

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

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

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

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

- при отказе (отмене) транзакций отменяются также все изменения, внесенные в БД с помощью триггеров.

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