- •Серия «Учебники и учебные пособия»
- •Э.П. Голенищев
- •И.В. Клименко
- •Рецензент
- •Предисловие
- •Введение
- •Глава 1. ИФОРМАЦИОННЫЕ СИСТЕМЫ НА БАЗАХ ДАННЫХ
- •1.1. Понятие информационной системы, информационное обеспечение
- •1.2. Понятие базы данных
- •1.3. Понятие системы управления базами данных
- •1.3.1. Обобщенная архитектура СУБД
- •1.3.2. Достоинства и недостатки СУБД
- •1.3.3. Архитектура многопользовательских СУБД
- •Технология «клиент/сервер»
- •Таблица 1.1
- •1.4. Понятие независимости данных
- •1.5. Категории пользователей базой данных
- •1.5.1. Общая классификация пользователей БД
- •1.5.2. Администратор базы данных
- •1.5.3. Разделение функций администрирования
- •Таблица 1.2
- •1.6. Средства администрирования баз данных
- •Таблица 1.3
- •Глава 2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
- •2.1. Жизненный цикл информационной системы
- •2.1. Подходы и этапы проектирования баз данных
- •2.2.1. Цели и подходы к проектированию баз данных
- •2.2.2. Этапы проектирования баз данных
- •2.3. Инфологическое проектирование базы данных
- •Таблица 2.1
- •Пояснение
- •2.3.1. Модель «сущность-связь»
- •2.3.2. Классификация сущностей, расширение ER-модели
- •Рис. 2.15. Пример ловушки разрыва
- •2.4. Логическое проектирование
- •2.4.1. Выбор СУБД
- •2.4.1.1. Метод ранжировки
- •Таблица 2.2
- •Таблица 2.3
- •2.4.1.2. Метод непосредственных оценок
- •2.4.1.3. Метод последовательных предпочтений
- •Таблица 2.4
- •Таблица 2.5
- •2.4.1.4. Оценка результатов экспертного анализа
- •Таблица 2.6
- •Наименование параметра
- •2.4.2. Даталогические модели данных
- •2.4.2.1. Иерархическая модель
- •2.4.2.2. Сетевая модель
- •2.4.2.3. Реляционная модель
- •2.4.2.4. Достоинства и недостатки даталогических моделей
- •2.4.3. Нормализация
- •2.4.3.1. Понятие функциональной зависимости
- •Таблица 2.7
- •2.4.3.2. Аксиомы вывода функциональных зависимостей
- •2.4.3.3. Первая нормальная форма
- •НОМЕР
- •2.4.3.4. Вторая нормальная форма
- •2.4.3.5. Третья нормальная форма
- •2.4.3.6. Нормализация через декомпозицию
- •2.4.3.7. Недостатки нормализации посредством декомпозиции
- •2.4.3.8. Нормальная форма Бойса–Кодда (НФБК)
- •2.4.3.9. Многозначные зависимости
- •Таблица 2.8
- •Таблица 2.9
- •Таблица 2.10
- •2.4.3.10. Аксиомы вывода многозначных зависимостей
- •2.4.3.11. Четвертая нормальная форма
- •2.4.3.12. Зависимости соединения
- •2.4.3.13. Пятая нормальная форма
- •2.4.3.14. Обобщение этапов нормализации
- •Глава 3. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ДАННЫХ В СУБД
- •3.1. Списковые структуры
- •3.1.1. Последовательное распределение памяти
- •3.1.2. Связанное распределение памяти
- •Рис. 3.4. Пример двунаправленного линейного списка
- •3.2. Модель внешней памяти
- •3.3. Методы поиска и индексирования данных
- •3.3.1. Последовательный поиск
- •Рис. 3.7. Пример организации файла при начальной загрузке
- •3.3.2. Бинарный поиск
- •3.3.3. Индекс - «бинарное дерево»
- •3.3.4. Неплотный индекс
- •3.3.5. Плотный индекс
- •3.3.6. Инвертированный файл
- •Глава 4. МАТЕМАТИЧЕСКИЕ ОСНОВЫ МАНИПУЛИРОВАНИЯ РЕЛЯЦИОННЫМИ ДАННЫМИ
- •4.1. Теоретические языки запросов
- •4.1.1. Реляционная алгебра
- •4.1.2. Реляционное исчисление кортежей
- •4.1.3. Реляционное исчисление доменов
- •4.1.4. Сравнение теоретических языков
- •4.2. Определение реляционной полноты
- •Глава 5. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ И СУБД
- •5.1. Основные определения, классификация распределенных систем
- •5.2. Преимущества и недостатки распределенных СУБД
- •Таблица 5.1
- •5.3. Функции распределенных СУБД
- •5.4. Архитектура распределенных СУБД
- •5.5. Разработка распределенных реляционных баз данных
- •5.5.1. Распределение данных
- •Таблица 5.2
- •5.5.2. Фрагментация
- •5.5.3. Репликация
- •5.5.3.1. Виды репликации
- •5.5.3.2. Функции службы репликации
- •5.5.3.3. Схемы владения данными
- •5.5.3.4. Сохранение целостности транзакций
- •5.5.3.5. Моментальные снимки таблиц
- •5.5.3.6. Триггеры базы данных
- •5.5.3.7. Выявление и разрешение конфликтов
- •5.6. Обеспечение прозрачности
- •5.6.1. Прозрачность распределенности
- •5.6.2. Прозрачность транзакций
- •5.6.3. Прозрачность выполнения
- •5.6.4. Прозрачность использования
- •ЗАКЛЮЧЕНИЕ
- •ПРИЛОЖЕНИЯ
- •Приложение 1. Недостатки файловых систем
- •Приложение 2. Краткая история развития субд
- •Приложение 3. Сравнительная характеристика даталогических моделей
- •Сводная характеристика систем баз данных
- •Приложение 4. Пример мифологического проекта базы данных
- •Приложение 5. Обобщенная методика проектирования реляционных баз данных
- •Приложение 6. Принципы организации компьютерных сетей
- •Отличие ЛВС от систем на основе мини-ЭВМ
- •Таблица П.6.1
- •Приложение 7. Правила распределенных СУБД
- •Независимость от операционной системы
- •Приложение 8. Краткий толковый словарь
- •Содержание
назначения еще не получили широкого распространения. Соответственно, еще не накоплен необходимый опыт промышленной эксплуатации распределенных систем, сравнимый с опытом эксплуатации централизованных систем. Такое положение дел является серьезным сдерживающим фактором для многих потенциальных сторонников данной технологии.
Усложнение процедуры разработки базы данных
Разработка распределенных баз данных, помимо обычных трудностей, связанных с процессом проектирования централизованных баз данных, требует принятия решения о фрагментации данных, распределении фрагментов по отдельным сайтам и организации процедур репликации данных.
5.3. Функции распределенных СУБД
Очевидно, что типичная СУРБД должна обеспечивать, по крайней мере, тот же набор функциональных возможностей, который был определен для централизованных СУБД в главе 1.
Кроме того, СУРБД должна предоставлять следующий набор функциональных возможностей [7].
Расширенные службы установки соединений должны обеспечивать доступ к удаленным сайтам и позволять передавать запросы и данные между сайтами, входящими в сеть.
Расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети.
Средства обработки распределенных запросов, включая механизмы оптимизации запросов и организации удаленного доступа.
Расширенные функции управления параллельностью, позволяющие поддерживать целостность реплицируемых данных.
Расширенные функции восстановления, учитывающие возможность отказов в работе отдельных сайтов и отказов линий связи.
5.4. Архитектура распределенных СУБД
Трехуровневая архитектура ANSI-SPARC для СУБД, обсуждавшаяся в разделе 1.3, представляет собой типовое решение для централизованных СУБД. Однако распределенные СУБД имеют множество отличий, которые сложно отразить в некотором эквивалентном архитектурном решении, приемлемом для большинства случаев.
Один из примеров рекомендуемой архитектуры СУРБД представлен на рис. 5.3. Он включает следующие элементы [7]:
набор глобальных внешних схем;
глобальную концептуальную схему;
схему фрагментации и схему распределения;
набор схем для каждой локальной СУБД, отвечающих требованиям трехуровневой архитектуры ANSI-SPARC.
102
Рис. 5.3. Рекомендуемая архитектура СУРБД
Соединительные линии на схеме представляют преобразования, выполняемые при переходе между схемами различных типов. В зависимости от поддерживаемого уровня прозрачности некоторые из уровней рекомендуемой архитектуры могут быть опущены.
Глобальная концептуальная схема
Глобальная концептуальная схема представляет собой логическое описание всей базы данных, представляющее ее так, как будто она не является распределенной. Этот уровень СУРБД соответствует концептуальному уровню архитектуры ANSI-SPARC и содержит определения сущностей, связей, требований защиты и ограничений поддержки целостности информации. Он обеспечивает физическую независимость данных от распределенной среды. Логическую независимость данных обеспечивают глобальные внешние схемы.
Схемы фрагментации и распределения
Схема фрагментации содержит описание того, как данные должны логически распределяться по разделам. Схема распределения является описанием того, где расположены имеющиеся данные. Схема распределения учитывает все организованные в системе процессы репликации.
Локальные схемы
Каждая локальная СУБД имеет свой собственный набор схем. Локальная концептуальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSISPARC. Локальная схема отображения используется для отображения фрагментов в схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются зависимыми от типа используемой СУБД и служат основой для построения гетерогенных СУРБД.
Независимо от рекомендованной общей архитектуры СУРБД компонентная архитектура СУРБД должна включать четыре следующих важнейших компонента (рис. 5.4) [7]:
1)локальную СУБД;
2)компонент передачи данных;
3)глобальный системный каталог;
103
4) распределенную СУБД (СУРБД).
Рис. 5.4. Компонентная архитектура распределенной СУБД
Локальная СУБД
Компонент локальной СУБД представляет собой стандартную СУБД, предназначенную для управления локальными данными на каждом из сайтов, входящих в состав распределенной базы данных. Локальная СУБД имеет свой собственный системный каталог, в котором содержится информация о данных, сохраняемых на этом сайте. В гомогенных системах на каждом из сайтов в качестве локальной СУБД используется один и тот же программный продукт. В гетерогенных системах существуют, по крайней мере, два сайта, использующих различные типы СУБД и/или различные типы вычислительных платформ.
Компонент передачи данных
Компонент передачи данных представляет собой программное обеспечение, позволяющее всем сайтам взаимодействовать между собой. Он содержит сведения о существующих сайтах и линиях связи между ними.
Глобальный системный каталог
Глобальный системный каталог имеет то же самое функциональное назначение, что и системный каталог в централизованных базах данных. Глобальный каталог содержит информацию, специфическую для распределенной природы системы, например схемы фрагментации и распределения. Этот каталог сам по себе может являться распределенной базой данных и поэтому подвергаться фрагментации и распределению, быть полностью реплицируемым или централизованным, как и любое другое отношение.
Что касается отношений, созданных на некотором сайте (сайте создания), то ответственность за фиксацию описания каждого его фрагмента, каждой реплики, каждого фрагмента, а также хранение сведений о расположении этих фрагментов, возлагается на локальный каталог данного сайта. В случае если фрагмент или реплика перемещается в другое место, сведения в локальном каталоге сайта создания соответствующего отношения необходимым образом обновляются. Следовательно, для определения расположения фрагмента или реплики отношения необходимо получить доступ к каталогу его сайта создания. Сведения о сайте создания каждого глобального отношения должны фиксироваться в каждом локальном экземпляре глобального системного каталога.
Распределенная СУБД
104