
- •Базы данных
- •Введение
- •Часть 1. Проектирование баз данных
- •1.1. Некоторые понятия и определения
- •1. 2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель данных
- •1.2.3. Реляционная модель данных Основные определения
- •Типы связей между отношениями
- •1.3. Классификация баз данных
- •1.4. Цели проектирования баз данных
- •1.5. Проектирование баз данных с использованием универсального отношения
- •1.5.1. Универсальное отношение
- •1.5.2. Проблемы, вызываемые использованием универсального отношения
- •Проблема вставки
- •Проблемы обновления
- •Проблемы удаления
- •1.5.3. Нормальная форма Бойса -Кодда
- •Функциональные зависимости
- •Возможный ключ и детерминант
- •Общий подход к декомпозиции
- •Анализ исходных аномалий
- •1.5.4. Возможные потери фз при декомпозиции
- •1.5.5. Избыточные функциональные зависимости
- •Приемы удаления избыточных фз
- •Минимальное покрытие
- •Модернизированный алгоритм проектирования бд
- •1.6. Метод er - проектирования
- •1.6.1. Сущности и связи
- •1.6.2. Степень связи
- •1.6.3. Переход от диаграмм er – типа к отношениям
- •Предварительные отношения для бинарных связей степени 1:1
- •Предварительные отношения для бинарных связей степени 1:n.
- •Предварительные отношения для бинарных связей степени n:m
- •1.6.4. Дополнительные конструкции, используемые в er - методе
- •Необходимость связей более высокого порядка
- •Предварительные отношения для трехсторонних связей
- •Использование ролей
- •1.6.5. Последовательность проектирования бд при использовании er- метода
- •1.6.6. Проверка отношений на завершающейся фазе проектирования
- •1.7. Другие нормальные формы
- •1.8. Контрольные вопросы
- •Часть 2. Специальные аспекты работы с базами данных
- •2.1. Защита данных в базе
- •2.2.1. Общие вопросы защиты данных
- •2.2.2. Реализация защиты данных в различных системах
- •Управление доступом в sql
- •Реализация системы защиты в ms sql Server
- •2.2. Обеспечение целостности данных
- •2.3. Организация параллельных процессов обработки данных
- •2.4. Восстановление бд
- •2.4.1. Уровни восстановления.
- •2.4.2. Восстановление и логический элемент работы
- •Требования к лэр
- •2.4.3. Промежуточное восстановление
- •2.4.4. Длительное восстановление
- •2.5. Математический аппарат, используемый при работе с реляционной базой данных
- •2.5.1. Теоретико-множественные операции реляционной алгебры
- •2.5.2. Специальные операции реляционной алгебры
- •2.6. Контрольные вопросы
- •Часть 3. Разработка приложений для работы с базами данных
- •3.1. Краткий обзор субд
- •3.2. Субд Access
- •3.2.1. Вводные замечания
- •3.2.2. Создание базы данных
- •3.2.3. Создание и работа с таблицами
- •3.2.4. Работа с запросами
- •3.2.5. Создание форм
- •3.2.6. Отчеты в Access
- •3.2.7. Макросы в Access
- •Преобразование макросов в программы на Visual Basic
- •3.2.8. Работа с внешними данными
- •3.3. Программирование в Access
- •3.3.1. Вводные замечания
- •3.3.2. Объявление переменных
- •3.3.3. Константы
- •3.3.4. Тип данных Variant
- •3.3.5. Пользовательские типы данных
- •3.3.5.Операторы, команды и выражения в vba
- •3.3.7. Процедуры vba
- •3.3.8. Управляющие структуры в vba
- •Работа с управляющими структурами
- •3.3.9. Объекты в Access
- •3.3.10. Классы в Access
- •3.3.11. Работа с ошибками в vba
- •3.4.Работа в ms sql –Server
- •3.4.1. Основные количественные показатели системы sql-сервер
- •3.4.2. Создание баз данных
- •3.4.3. Создание таблицы
- •3.4.4. Извлечение данных
- •3.4.5. Добавление данных
- •3.4.6. Изменение данных
- •3.4.7. Удаление данных
- •3.5. Контрольные вопросы
- •Цитированная литература
- •Оглавление
- •Часть 1. Проектирование баз данных 3
- •Часть 2. Специальные аспекты работы с базами данных 71
- •Часть 3. Разработка приложений для работы с базами данных 114
2.4. Восстановление бд
Возникновение сбоя в аппаратном или программном обеспечении может вызвать необходимость восстановления и быстрого возращения в состояние, по возможности близкое к тому, которое было перед возникновением сбоя. Причинами сбоев могут являться отключение питания, отказ аппаратуры, системно-программные ошибки, ошибки пользователей в управлении данными и т.д. К числу причин, вызывающих необходимость восстановления, можно отнести также и возникновение тупиковой ситуации.
2.4.1. Уровни восстановления.
Укрупнено можно выделить три уровня восстановления;
1. Оперативное восстановление. Характеризуется возможностью восстановления на уровне отдельного логического элемента работы при аномальном окончании управления данными (ошибка в программе, ошибка в аргументе и т.д.).
2. Промежуточное восстановление .Если возникают аномалии в системе (системно-программные ошибки, сбой аппаратного обеспечения не связанный с разрушением базы данных), то требуется восстановить состояние всех выполняемых логических элементов работы на момент возникновения сбоя.
3. Длительное восстановление. При разрушении базы данных в результате дефекта на диске осуществляют восстановление с помощью копии базы данных. Затем воспроизводят результаты выполненных с момента снятия копии логических элементов работы и возвращают систему в состояние на момент разрушения.
2.4.2. Восстановление и логический элемент работы
Непрерывное управление данными, при котором базу данных из одного целостного состояния переводят в другое целостное состояние, называют логическим элементом работы (ЛЭР). Логический элемент работы также называют транзакцией.
Рассмотрим операцию индексации размера оклада всем работникам. Перед началом данной операции размер оклада каждого работника соответствует ограничениям целостности. В ходе операции ЭВМ последовательно изменяет размер оклада, поэтому существует состояние, когда оклад будет повышен только части работников, а у других работников останется старое значение оклада. Такое состояние не является целостным. После завершения операции изменения размера оклада база данных возвращается в целостное с о с т о я н и е .
Прекращение выполнения логического элемента работы вследствие появления сбоя нарушает целостность БД. Однако даже если результаты такого выполнения логического элемента работы потеряны, то имеется возможность их воспроизведения на момент возникновения сбоя. Таким образом, понятие "логический элемент работы" играет важную роль при восстановлении.
Требования к лэр
1. Необходимо, чтобы логический элемент работы или выполнялся полностью, или совершенно не выполнялся.
2. Необходимо, чтобы ЛЭР допускал возможность возврата в первоначальное состояние.
3. Необходимо иметь возможность воспроизведения процесса выполнения ЛЭР.
При появлении сбоя осуществлять возврат удобнее не в начало логического элемента работы, a в некоторое промежуточное положение. Точку, куда происходит такой возврат, называют точкой фиксации (контрольной точкой). Пользователь может устанавливать в процессе выполнения ЛЭР произвольное количество контрольных точек.
Откат и раскрутка ЛЭР. Основным средством, используемым при восстановлении, является системный журнал, в котором регистрируются все изменения, осуществляемые в БД каждым ЛЭР. Возврат ЛЭР в начальное состояние состоит в аннулирование всех изменений, которые он осуществил в базе данных в процессе своего выполнения. Такую операцию называют откатом. Для воспроизведения результатов выполнения ЛЭР можно воспользоваться системным журналом и восстановить значения проведенных изменений в порядке их возникновения, либо повторно выполнить ЛЭР.
Воспроизведение результатов выполнения элемента с использованием системного журнала называют раскруткой. В любом случае эта операция является громоздкой. Однако такой способ можно использовать для устранения тупиковой ситуации, когда производится откат одного из логических элементов работы.
Для повышения эффективности выполнения отката ЛЭР записи системного журнала группируют по всем объектам, подлежащим изменению. По окончании ЛЭР копию можно отбросить.
На практике, оказывается, сложно фиксировать изменения всех объектов, подлежащих изменению. По мере выполнения операций в оперативной памяти создается копия рабочей области памяти. Поскольку единицу обмена (блок) называют также страницей, то этот метод называют двухстраничным или методом копирования страниц.
При двухстраничном способе нет необходимости фиксировать в журнале каждое изменение значений изменяемых объектов. Начальное значение изменяемого объекта можно зафиксировать в журнале только один раз -при первоначальном его изменении ЛЭР. Необходимость записи в журнал появляется также при прохождении точки фиксации.
Возможно, появление сбоя непосредственно перед операцией, связанной с отображением изменений в базе данных. Поэтому фактическое внесение изменений в БД откладывается до завершения ЛЭР. Информация о необходимых изменениях накапливается в специальном файле, который можно считать аналогом системного журнала.