
- •2 Субд первого поколения. Примеры.
- •2.1. Иерархические системы
- •2.1.1 Иерархические структуры данных
- •2.1.2 Манипулирование данными
- •2.1.3. Ограничения целостности
- •2.2. Сетевые системы
- •2.2.1. Сетевые структуры данных
- •2.2.2. Манипулирование данными
- •2.2.3. Ограничения целостности
- •3 Субд второго поколения. Примеры.
- •4.1. Базовые понятия реляционных баз данных
- •4.1.1. Тип данных
- •4.1.2. Домен
- •4.1.3. Схема отношения, схема базы данных
- •4.1.4. Кортеж, отношение
- •4.2. Фундаментальные свойства отношений
- •4.2.1. Отсутствие кортежей-дубликатов
- •4.2.2. Отсутствие упорядоченности кортежей
- •4.2.3. Отсутствие упорядоченности атрибутов
- •4.2.4. Атомарность значений атрибутов
- •4.3. Реляционная модель данных
- •4.3.1. Общая характеристика
- •4.3.2. Целостность сущности и ссылок
- •4 Субд третьего поколения. Примеры.
- •1 Введение
- •2 Принципы субд третьего поколения
- •3 Тринадцать предложений
- •3.1. Предложения, касающиеся управления объектами и правилами
- •3.2. Предложения, касающиеся увеличения функциональных возможностей субд
- •3.3. Предложения, следующие из необходимости открытости системы
- •4. Заключение
- •5 Структура субд. Структура субд линтер
- •Типовая организация современной субд
- •2.3. Пример: System r
5 Структура субд. Структура субд линтер
СУБД ЛИНТЕР - это комплекс задач, работающих под управлением операционной системы. Структура программного обеспечения СУБД ЛИНТЕР приведена на рис. 1.
Часть задач являются собственно системой управления базой данных, другие представляют собой утилиты и инструментальные средства для поддержки жизненного цикла базы данных (БД) (управление БД, архивирование и восстановление, тестирование и др.). Центральной частью системы являются средства ведения БД (обработки запросов).
Рис. 1– Структура программного обеспечения СУБД ЛИНТЕР
Компоненты СУБД ЛИНТЕР обращаются к БД через ядро системы (рис. 2) только с помощью внутреннего интерфейса (Call-интерфейса). В этом смысле вспомогательные компоненты системы ничем не отличаются от прикладных задач (приложений). Поэтому мы будем говорить только о пользовательских приложениях и их взаимодействии с системой.
Любое приложение, прежде чем обратиться с запросом к БД, должно открыть канал.
Канал СУБД ЛИНТЕР - это логическая линия обмена пользовательского приложения и ядра СУБД. Каждое приложение, пославшее запрос, принимает сообщения, адресованные именно ему. Кроме того, канал - это средство распараллеливания запросов.
Запросы, посланные по разным каналам, будут обрабатываться параллельно.
По одному каналу запросы могут обрабатываться только последовательно.
Архитектура связи с ядром такова, что разные задачи могут пользоваться только разными каналами. Алгоритмы Call-интерфейса открыты, их текст поставляется с дистрибутивом. Квалифицированный программист легко сможет разобраться в алгоритмах Call-интерфейса и изменить их, подстроив под специфические нужды (например, сделав интерфейс асинхронным).
Рис. 2 - Схема взаимодействия компонент с ядром СУБД ЛИНТЕР
Ядро СУБД ЛИНТЕР - это реентерабельная программа, осуществляющая диспетчеризацию и параллельную обработку запросов.
При получении запроса ядро производит анализ ресурсов. Если их достаточно, то запрос принимается на выполнение, в противном случае приложению посылается соответствующий код возврата, и приложение реагирует на него в соответствии с заложенным алгоритмом.
Среди запросов, принятых ядром, особую группу занимают так называемые служебные запросы.
Примеры таких запросов:
открыть/закрыть канал;
получить описание конкретной таблицы/столбца;
просмотреть внутренние очереди ядра СУБД ЛИНТЕР;
фиксировать/откатить (Commit/Rollback) изменения.
Эти служебные запросы имеют следующие особенности: их обработка непрерываема, они выполняется только модулями ядра СУБД ЛИНТЕР без участия других средств ведения БД. Таким образом, два служебных запроса, посланных по разным каналам, ядро будет выполнять последовательно, не прерываясь на обработку других запросов.
Служебные запросы не требуют ни трансляции, ни сортировки.
Запросы, отличные от служебных, обязательно проходят этап трансляции, т.к. они формулируются на языке высокого уровня и проходят через SQL-транслятор. Это могут быть запросы на манипулирование данными (найти, заменить, добавить, удалить) - DML-запросы (Data Manipulation Language), либо на описание данных - DDL-запросы (Data Definition Language).
В СУБД ЛИНТЕР имеется возможность получения и использования оттранслированных запросов. Если в приложении один и тот же запрос (серия похожих запросов) выполняется несколько раз, то имеет смысл один раз оттранслировать запрос, а потом пользоваться уже оттранслированным запросом.
Использование оттранслированного запроса более эффективно, т.к. он уже не проходит этап трансляции, привязки к реальным структурам БД, проверки на соответствие типов данных и т.п.
Если в самом общем виде описать прохождение запроса, то оно будет выглядеть так, как показано на рис. 3.
Рис. 3 - Схема обработки запроса
При этом:
служебный запрос обрабатывается только ядром, без привлечения этапов трансляции и сортировки ответов;
запрос, поданный в оттранслированной форме, не подключает к обработке SQL-транслятор;
SQL-запрос обрабатывается с прохождением этапа трансляции;
в двух последних случаях задача Sort подключается, только если поступил запрос, которому требуется сортировка (например, запросы, включающие предложения ORDER BY, GROUP BY, DISTINCT).