- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
Операция сечения формирует подмножество гиперкуба, в котором значение одного или более измерений фиксировано, например, (Население, Доход) = function(2000, Область, Возраст).
Операция вращения изменяет порядок представления измерений для удобства восприятия. Обычно применяется к двумерным сечениям, например, (Население, Доход) = function(2000, Область, Возраст ! 2000, Возраст, Область).
Для выполнения операций свертки и детализации должна существовать иерархия значений измерения, то есть подчиненность одних значений другим. Например, год состоит из кварталов, кварталы из месяцев и т.д. При выполнении операции свертки одно из значений измерения заменяется значением более высокого уровня иерархии (например, вместо месяца год). Операция детализации
– это операция, обратная свертке. Она обеспечивает переход от обобщенных к детализированным данным.
Примерами систем, поддерживающих многомерные модели данных, являются Oracle Express Service и Microsoft Analysis Services (OLAP-сервер фирмы Microsoft, входящий в комплект поставки Microsoft SQL Server 2000 Enterprise Edition).
Достоинством многомерной модели данных является более быстрый поиск и чтение данных, и отсутствие необходимости множественного соединения таблиц.
Недостаток многомерной модели заключается в потребности в большом объеме памяти для хранения данных и сложность модификации структуры данных. Например, добавление еще одного измерения приводит к необходимости полной перестройки гиперкуба.
6.3. Основные функции СУБД
Кчислу функций СУБД принято относить следующие:
1)управление данными во внешней памяти,
2)управление буферами оперативной памяти,
3)управление транзакциями,
4)журнализация и восстановление БД после сбоев,
5)поддержка языков баз данных.
6.3.1. Управление данными во внешней памяти
Непосредственное управление данными во внешней памяти означает поддержку со стороны СУБД необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для ускорения доступа к данным. Реализации СУБД могут активно использовать возможности существующих файловых систем, либо брать на себя эту работу вплоть до уровня устройств внешней памяти. Но важно, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему вообще, и если использует, то как. В частности, СУБД поддерживают собственную систему именования объектов базы данных.
6.3.2. Управление буферами оперативной памяти
Управление буферами оперативной памяти необходимо в связи с тем, что СУБД обычно работают с БД значительного размера, существенно превышающего размер доступной оперативной памяти. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
6.3.3. Управление транзакциями
Управление транзакциями позволяет СУБД поддерживать логическую целостность базы данных, то есть непротиворечивость данных, хранимых в БД. Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и тогда СУБД фиксирует изменения данных во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.
6.3.4. Журнализация и восстановление БД после сбоев
Журнализация позволяет обеспечить одно из основных требований к СУБД – надежность хранения данных во внешней памяти. Под надежностью хранения понимается возможность восстановления последнего согласованного состояния БД после любого аппаратного или программного сбоя.
Типичные виды аппаратных сбоев:
1)так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера, например, из-за аварийного отключения питания;
2)жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть
аварийное завершение работы СУБД по причине ошибки в программе или в результате некоторого аппаратного сбоя,
аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной.
Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя. При возникновении последней требуется ликвидировать последствия только одной транзакции.
Ясно, что для восстановления БД нужно располагать некоторой избыточной информацией. Наиболее распространенным методом поддержания такой избыточности является ведение журнала изменений БД.
Журнал – это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках). В журнал поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализируются на разных уровнях:
1)иногда запись в журнале соответствует некоторой логической операции изменения БД, например, операции удаления строки из таблицы реляционной БД,
2)иногда – минимальной внутренней операции модификации страницы внешней памяти;
3)в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log – WAL). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не
поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу. Для этого все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (содержимое которых, по причине использования буферов оперативной памяти, при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия – это полная копия БД к моменту начала заполнения журнала. Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Поэтому к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.