- •Глава 1. Базы данных и системы управления 9
- •Глава 2. Организация доступа к данным 45
- •Глава 3. Реляционная алгебра 60
- •Глава 4. Основы sql 67
- •Глава 5. Проектирование реляционных баз данных 89
- •Глава 6. Взаимодействие sql с приложениями 116
- •Глава 7. Некоторые проблемы администрирования баз данных 154
- •Базы данных и системы управления
- •Файловые системы
- •Концепция баз данных
- •Основные функции субд
- •Непосредственное управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация
- •Поддержка языков баз данных
- •Трехуровневая модель архитектуры систем баз данных
- •Модели данных
- •Характеристика связей
- •Компьютерно-ориентированные модели данных
- •Реляционный подход
- •Ключи и целостность реляционных данных
- •Моделирование концептуальной схемы базы данных
- •Организация доступа к данным
- •Страницы и файлы
- •Индексирование
- •Структуры типа б-дерева
- •Хеширование
- •Методы сжатия
- •Метод дифференциального сжатия
- •Иерархические методы сжатия
- •Кодирование по методу Хаффмена
- •Реляционная алгебра
- •Традиционные реляционные операции
- •Специальные реляционные операции
- •Дополнительные реляционные операции
- •Примеры использования реляционной алгебры для выражения словесных запросов в виде формул
- •Основы sql
- •Типы данных
- •Строковые типы данных
- •Битовые типы данных
- •Точные числовые типы данных
- •Вещественные числовые типы данных
- •Календарные типы данных
- •Значения null
- •Создание и обслуживание таблиц
- •Запрос на выборку
- •Статистические функции
- •Создание соединений
- •Вложенные запросы
- •Запрос на объединение
- •Запросы, выполняющие реляционные операции вычитания, пересечения и деления
- •Запросы на изменение
- •Перекрестные запросы
- •Проектирование реляционных баз данных
- •Нормализация отношений
- •Функциональные зависимости
- •Н ормальные формы, обоснованные функциональными зависимостями
- •Нормальная форма Бойса–Кодда
- •Нормальные формы, обоснованные более сложными зависимостями
- •Процедура нормализации и проектирования
- •Пример проектирования базы данных
- •Назначение и предметная область
- •Проектирование базы данных
- •Взаимодействие sql с приложениями
- •Встраивание sql-операторов в программный код
- •Тип курсора
- •Триггеры
- •Хранимые процедуры
- •Стандартные интерфейсы для доступа к данным
- •Информационное окружение веб-сервера
- •Стандарт odbc
- •Уровни соответствия
- •Уровень соответствия odbc
- •Задание имени источника данных odbc
- •Расширяемый язык разметки xml
- •Xml как язык разметки
- •Материализация хмl-документов с помощью xslt
- •Создание хмl-документов на основе информации из базы данных
- •Некоторые проблемы администрирования баз данных
- •Оптимизация запросов
- •Параллельная обработка данных
- •Потеря обновления
- •Зависимость от незафиксированных обновлений
- •Несогласованный анализ
- •Блокировки транзакций
- •Согласованность и уровень изоляции транзакций
- •Распределенные системы баз данных
- •Фрагментация
- •Репликация
- •Распространение обновлений
- •Управление каталогом
- •Распределенная обработка запросов
- •Типы распределенных систем баз данных
- •Нераспределенные мультибазовые субд
- •Клиент-серверные системы
- •Системы с общими ресурсами
- •Технические аспекты администрирования базы данных
- •Восстановление базы данных
- •Безопасность баз данных
- •Шифрование данных
- •Производительность баз данных
- •Администрирование данных
- •Литература
Управление каталогом
СУБД ведет словарь метаданных (каталог), в котором описываются все объекты данных, хранимые и обрабатываемые системой. В распределенной среде каждая локальная СУБД должна иметь средства доступа к элементам словаря метаданных, относящимся к объектам, хранимым в других локальных узлах. Таким образом, должен существовать некий глобальный каталог, в котором представлена сумма всех словарей метаданных системы. Существуют различные подходы к хранению каталога и управлению им.
Полностью распределенный подход. В этом случае каждый узел содержит информацию каталога, относящуюся к тем частям распределенной базы данных, которые локально хранятся в данном узле. Сложность при таком хранении заключается в том, что каждый раз, когда требуется получить доступ к нелокальным данным, узел должен исследовать каталоги всех других узлов, пока не будут найдены нужные данные. Это значительно снижает производительность при необходимости доступа к нелокальным данным.
Полностью реплицированный подход. В таком сценарии в каждом узле имеется полная копия каталога всей системы, что значительно ускоряет доступ к нелокальным данным. Однако каждый раз при создании или удалении в одном узле определенного объекта данных (отношения, атрибута и т.п.) обновление этого локального каталога должно распространяться на все каталоги системы.
Централизованный подход. В таком случае наряду с локальными словарями метаданных в одном из узлов существует каталог всех данных системы. Для доступа к нелокальным данным сначала проводится поиск в этом центральном узле. Все изменения, производимые в локальных словарях, должны вноситься и в центральный каталог. Данный подход является комбинацией первых двух и сочетает в себе их преимущества. Однако в нем нарушается принцип отсутствия зависимости от центрального узла. Если произойдет сбой машины, на которой ведется центральный каталог, то доступ к нелокальным данным станет невозможен.
Подход с использованием перманентных идентификаторов. Варианты этой схемы используются во многих системах, хотя детали ее реализации могут варьироваться. При создании в определенном узле объекта данных, объекту присваивается логический идентификатор, который экспортируется в словари метаданных всех других узлов. Этот логический идентификатор указывает узел, где был создан объект. Элемент каталога узла создания отслеживает, где в действительности хранится данный объект данных. Таким образом, если объект (например, отношение) перемещается из узла, где он был создан, в другой узел, элемент каталога в узле создания изменяется, чтобы указать новое местоположение объекта. Информация об объекте также заносится в словарь метаданных того узла, где он теперь хранится. Любой другой узел, которому нужен данный объект, будет сначала обращаться к элементу каталога в узле создания, а затем с помощью этой информации находить сам объект. Если объект вновь перемещается, он просто удаляется из словаря метаданных соответствующего узла, заносится в словарь данных нового узла, а элемент каталога в узле создания изменяется, чтобы отразить новое положение объекта. Если этот объект нужен другому узлу, доступ к нему по-прежнему можно осуществить с помощью обращения к двум каталогам: в узле создания и в том узле, где объект находится в настоящий момент. Недостаток подобной схемы заключается в том, что при сбое в узле создания объект обнаружить невозможно.