- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
мерческих SQL-серверов.
6.5.5. Архитектура «клиент-сервер» трехзвенная
Рассмотренная выше архитектура «клиент-сервер» является двухзвенной: первое звено – это клиентское приложение, второе звено – серверная СУБД и сама БД. Здесь вся бизнес-логика (деловая логика) сосредоточена в клиентских приложениях.
В трехзвенной архитектуре «клиент-сервер» вся бизнес-логика выделяется в отдельное звено, называемое сервером приложений, на котором располагается программное обеспечение делового анализа (бизнес-логика). При этом в клиентских приложениях остается лишь пользовательский интерфейс, реализуемый, например, с помощью Web-браузера. Такие клиентские приложения, реализующие лишь интерфейс пользователя, но не бизнес-логику, называются «тонким клиентом». Тонкий клиент инициирует по запросам пользователя обращение к программному обеспечению делового анализа, расположенному на сервере приложений. Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется язык SQL, так что по сети от сервера приложений к серверной СУБД передается лишь текст запроса. Серверная СУБД, инкапсулируя внутри себя все сведения о физической структуре БД, расположенной на сервере, инициирует обращения к данным, находящимся на сервере, и возвращает результат выполнения запроса на сервер приложений. Сервер приложений передает результат в клиентское приложение (пользователю). Клиентское приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнеслогики больше нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к клиентской аппаратуре.
6.5.6. Распределенные базы данных
Рассмотренные выше модели взаимодействия с БД предполагали, что база данных размещается на одном компьютере. Но развитие вычислительных компьютерных сетей обусловило новые возможности в организации и ведении баз данных, позволяющие, с одной стороны, каждому пользователю иметь на своем компьютере свои данные и работать с ними, и, с другой стороны, позволяющие работать всем пользователям со всей совокупностью данных как с единой централизованной базой данных. Соответствующая совокупность данных называется распределенной базой данных. Возможны и даже часто встречаются ситуации, когда фрагменты распределенной базы данных на различных компьютерах в сети пересекаются, дублируются.
Система управления распределенной базой данных – это программная система, обеспечивающая управление распределенной базой данных и позволяющая пользователю работать как с его локальными данными, так и со всей базой данных в целом. Система управления распределенной базой данных является распределенной системой. Каждый фрагмент базы данных работает под управлением отдельной СУБД, которая осуществляет доступ к данным этого фрагмента.
Пользователи взаимодействуют с распределенной базой данных через локальные и глобальные приложения. Локальные приложения дают пользователю возможность работать со своими локальными данными и не требуют доступа к другим фрагментам. Глобальные приложения дают пользователю возможность работать с другими фрагментами распределенной базы данных, расположенными на других компьютерах сети. Объединение данных организуется виртуально. Соответствующий подход, по сути, отражает организационную структуру предприятия, состоящего из отдельных подразделений. Причем, хотя каждое подразделение обрабатывает свой набор данных, существует необходимость доступа к этим данным, как к единому целому (в частности, для управления всем предприятием).
Основной принцип технологии распределенных баз данных заключается в том, что доступ к
распределенной базе данных выглядит для клиента точно так же, как и доступ к централизованной БД. Примером реализации такого принципа может служить Internet (данные вводятся и хранятся на разных компьютерах по всему миру, но любой пользователь может получить доступ к этим данным, не задумываясь о том, где они физически расположены).
Достоинством модели распределенной базы данных является приближение данных к месту их порождения. Недостатком модели является достаточно высокая сложность управления данными как единым целым.
6.5.7. Технология тиражирования данных
Альтернативой технологии распределенных баз данных является технология тиражирования данных, не требующая синхронной фиксации изменений. Действительно, далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах сети в любое время. Достаточно поддерживать идентичность данных лишь в определенные критичные моменты времени. Следовательно, можно накапливать изменения в данных в виде транзакций в одном узле сети и периодически фиксировать эти изменения в других узлах.
Функции тиражирования данных выполняет специальный модуль СУБД – сервер тиражирования данных, называемый репликатором. Его задача – поддержка идентичности данных в базах данных различных узлов сети.
Достоинством технологии тиражирования данных является увеличение производительности, так как данные всегда расположены там, где они обрабатываются. Недостаток – в возможности возникновения конфликтов данных из-за асинхронной фиксации изменений.
6.6. Фрактальные методы сжатия BLOB [11]
BLOB – это обобщенное название типов данных, предназначенных для хранения крупных двоичных объектов (Binary Large OBjects). Такими объектами могут быть графические изображения в различных форматах (скажем, .gif или .jpeg), фрагменты видеозаписей (например, в кодировке .mpeg), звук, сигналы радаров и т.д.
Работа с объектами BLOB в базах данных связана со многими технологическими проблемами. Объект BLOB должен сохраняться в виде последовательности блоков. В определенных ситуациях
объект BLOB должен считываться настолько быстро, что при размещении его на одном дисковом устройстве приемлемой скорости достичь не удается. Одним из решений такой проблемы является попеременное распределение соседних блоков объекта по нескольким дискам. В этом случае группа блоков может считываться одновременно, и скорость операции возрастает, грубо говоря, пропорционально количеству используемых дисковых устройств.
Естественное требование о том, что блок данных, запрошенный клиентом, должен возвращаться системой целиком, при возрастании размеров элементов данных подлежит радикальному пересмотру. Можно полагать, что система должна передавать единовременно и полностью только «небольшие» значения полей записей и позволять клиенту запрашивать отдельные блоки объекта BLOB, по одному в каждый момент времени и независимо от наличия оставшихся блоков. Например, если объект BLOB представляет двухчасовой кинофильм и клиент выдает запрос на его воспроизведение, система должна считывать и передавать клиенту последовательные блоки объекта с достаточной скоростью.
Во многих случаях важно, чтобы клиенту была предоставлена возможность считывания отдельных порций данных (скажем, титров кинофильма или финальной части аудиоклипа) независимо от порядка их расположения «внутри» объекта и без необходимости загрузки объекта целиком. Если система поддерживает подобные операции, ей, вероятно, требуются удобные структуры индексных