- •Учебное пособие для подготовки к экзамену по дисциплине «базы данных»
- •1. Этапы развития баз данных. Принципы их работы.
- •Базы данных. Предпосылки возникновения баз данных.
- •Основная терминология.
- •2. Архитектура баз данных. Процесс прохождения пользовательского запроса.
- •Процесс прохождения пользовательского запроса
- •3. Пользователи баз данных.
- •Администраторы данных и администраторы баз данных
- •Разработчики баз данных.
- •Пользователи
- •4. Модели данных. Классификация.
- •Объектные модели данных
- •Модели данных на основе записей
- •Физические модели данных
- •Концептуальное моделирование
- •5. Этапы разработки информационной структуры базы данных
- •6. Реляционная модель данных. Основные понятия и определения.
- •Альтернативная терминология
- •Свойства отношений
- •Виды отношений
- •Основные виды связей
- •7. Первичные и внешние ключи. Непротиворечивость и целостность данных
- •Средства поддержки целостности данных (см. Dcl sql и т.Т.)
- •Реляционная алгебра
- •Выборка (или ограничение)
- •Проекция
- •Декартово произведение
- •Объединение
- •Разность
- •Операция соединения
- •Пересечение
- •Деление
- •Принципы нормализации. Описание предметной области. Нормальные формы.
- •Модель «Сущность-связь». Er - модель. Типы связей: «один к одному», «многие к одному», «один ко многим», «многие ко многим»
- •Язык sql, его достоинства. Классификация операторов sql
- •Успех sql принесли следующие его достоинства:
- •Классификация операторов sql
- •Типы данных sql. Оператор выбора select
- •Скалярные операторы
- •Оператор выбора select. Формирование запросов из базы данных
- •Примеры запросов
- •Агрегатные функции, вложенные запросы в операторе выбора.
- •Операторы манипулирования данными
- •Команда insert
- •Values ('Иванов и.И.', 546237);
- •Insert into t1 (fio, pasport) values ('Иванов и.И.', 546237);
- •Insert into t1 (fio) values ('Петров п.П.');
- •Команда update
- •Команда delete
- •Работа с триггерами
- •Модели "Клиент-сервер" в технологии баз данных
- •Работа технологии "клиент-сервер"
- •Модели транзакций. Свойства. Способы завершения Поддержка транзакций
- •Улучшенные модели транзакций
- •Модель вложенных транзакций
- •Эмуляция механизма вложенных транзакций с помощью точек сохранения
- •Хроники
- •Модель многоуровневых транзакций
- •Динамическая реструктуризация
- •Модели рабочих потоков
- •Журнал транзакций. Восстановление после сбоев. Назначение атрибутов пользователей
- •Контроль сеансов доступа к данным
- •Уровни защиты бд
- •Виды привилегий
- •Привилегии доступа к объектам
- •Методы восстановления
- •Метод восстановления с использованием отложенного обновления
- •Метод восстановления с использованием немедленного обновления
- •Защита информации в базах данных
- •Контрмеры – компьютерные средства контроля
- •Архитектура субд. Перспективы развития баз данных и субд
- •Традиционная двухуровневая архитектура "клиент-сервер"
- •Трехуровневая архитектура
- •Субд для хранилища данных
- •Требования к субд для хранилища данных
- •Высокая производительность загрузки данных
- •Возможность обработки данных во время загрузки
- •Наличие средств управления качеством данных
- •Высокая производительность запросов
- •Широкая масштабируемость по размеру
- •Масштабируемость по количеству пользователей
- •Возможность организации сети хранилищ данных
- •Наличие средств администрирования хранилища
- •Поддержка многомерного интегрированного анализа
- •Расширенный набор функциональных средств запросов
- •Параллельные субд
- •Интерактивная аналитическая обработка данных (olap)
- •Литература, рекомендуемая при самоподготовке
Метод восстановления с использованием немедленного обновления
При использовании этого протокола все изменения вносятся в базу данных сразу же после их выполнения в транзакции, не дожидаясь ее завершения. Помимо необходимости повторного прогона изменений, выполненных транзакциями, закончившимися до появления сбоя, в данном случае может потребоваться выполнить откат изменений, внесенных транзакциями, которые не были завершены к этому моменту. При применении данного метода файл журнала используется с целью восстановления следующим образом.
При запуске транзакции в журнал помещается запись Начало транзакции.
При выполнении любой операции записи помещаемая в файл журнала строка содержит все указанные выше данные.
Как только упомянутая выше запись будет помещена в файл журнала, все выполненные обновления вносятся в буфера базы данных.
В собственно файлы базы данных изменения будут внесены при очередной разгрузке буферов базы данных во вторичную память.
Когда транзакция завершает свое выполнение, в файл журнала заносится запись Транзакция завершена.
Очень важно, чтобы в файл журнала все записи (или хотя бы определенная их часть) помещались до внесения соответствующих изменений в базу данных. Это требование известно как протокол предварительной записи журнала. Если изменения вначале будут внесены в базу данных и сбой в системе возникнет до помещения информации об этом в файл журнала, то менеджер восстановления не будет иметь возможности отменить (или повторить) данную операцию. При использовании протокола предварительной записи журнала менеджер восстановления всегда сможет безопасно предположить, что если для определенной транзакции в файле журнала отсутствует запись Транзакция завершена, значит, эта транзакция была активна в момент возникновения отказа и, следовательно, должна быть отменена.
Если выполнение транзакции было прекращено, то для отмены выполненных ею изменений может быть использован файл журнала, так как в нем сохранены сведения об исходных значениях всех измененных элементов данных. Поскольку транзакция может выполнить несколько изменений одного и того же элемента, отмена обновлений выполняется в обратном порядке. Независимо от того, были ли результаты выполнения транзакции внесены в саму базу данных, наличие в записях журнала исходных значений полей гарантирует, что база данных будет приведена в состояние, отвечающее началу отмененной транзакции.
На случай отказа системы процедурой восстановления предусмотрено использование файла журнала для повторного прогона или отката транзакций. Для любой транзакции Т, для которой в файле журнала присутствуют записи Начало транзакции и Транзакция завершена, следует выполнить ее повторный прогон, используя для внесения в базу данных значения после изменения всех обновленных полей - как было описано выше. Отметим, что если новые значения уже были реально внесены в файлы базы данных, повторная их перезапись, хотя и будет излишней, тем не менее не окажет на базу данных никакого отрицательного влияния. Те же изменения, которые еще не достигли базы данных к моменту отказа, будут в нее внесены в процессе восстановления. Для любой транзакции S, для которой в файле журнала присутствует запись Начало транзакции, но нет записи Транзакция завершена, необходимо выполнить откат внесенных ею изменений. На этот раз из записей файла журнала извлекается информация о значении измененных полей до их изменения, что позволяет привести базу данных в состояние, которое она имела до начала данной транзакции. Операции отмены выполняются в порядке, обратном порядку их записи в файл журнала.