ответствии с изменяющимися требованиями. Например, может возникнуть необходимость в периодической реорганизации хранимой базы данных с целью получения гарантий того, что производительность системы всегда будет поддерживаться на приемлемом уровне. Как уже упоминалось, любые изменения на уровне физического хранения данных (внутреннем уровне) должны сопровождаться соответствующими изменениями в определении его отображения на концептуальный уровень, что позволит сохранить концептуальную схему неизменной.

Конечно, перечисленное выше- отнюдь не исчерпывающий список обязанностей АБД, а лишь попытка высказать некоторые соображения об их существе и диапазоне.

2.8. Система управления базой данных

Система управления базой данных (СУБД) представляет собой программное обеспечение, которое управляет всем доступом к базе данных. Концептуально это происходит следующим образом (см. рис. 2.3).

1. Пользователь выдает запрос на доступ к данным, применяя определенный подъязык данных (обычно это язык SQL).

2. СУБД перехватывает этот запрос и анализирует его.

3. СУБД просматривает внешнюю схему (ее объектную версию) для этого пользователя, соответствующее отображение внешний-концептуальный , концептуальную схему, отображение концептуальный-внутренний и определение структуры хранения.

4. СУБД выполняет необходимые операции в хранимой базе данных.

В качестве примера рассмотрим, как осуществляется выборка экземпляра определенной внешней записи. В общем случае поля этой записи будут выбираться из нескольких экземпляров концептуальных записей, которые, в свою очередь, будут запрашивать поля из нескольких экземпляров хранимых записей. Концептуально СУБД сначала должна выбрать все требуемые экземпляры хранимых записей, затем построить требуемые экземпляры концептуальных записей и после этого сформировать экземпляр внешней записи. На каждом этапе могут потребоваться преобразования типов данных или другие преобразования.

Конечно, описание предыдущего примера весьма упрощено; в частности, в данном случае предполагается, что весь процесс является интерпретируемым (т.е. анализ запроса, проверка различных схем и другие процедуры осуществляются непосредственно во время выполнения). Однако интерпретация обычно характеризуется невысокой производительностью, поскольку на ее выполнение затрачивается много времени. На практике обычно существует возможность предварительно скомпилировать запрос на доступ к данным до начала его выполнения; в частности, в современных SQL-системах применяется именно такой подход (см. аннотации к [4.12] и [4.26] в главе 4).

Теперь рассмотрим функции СУБД немного подробнее. Они обязательно будут включать поддержку работы компонентов базы данных, показанных на рис. 2.4.

Определение данных

СУБД должна предоставлять средства определения данных (внешних схем, концептуальной схемы, внутренней схемы, а также всех необходимых отображений) в виде исходной формы и преобразования этих определений в соответствующую

объектную форму. Иначе говоря, СУБД должна включать в себя компоненты процессора ЯОД или компилятора ЯОД для каждого из поддерживаемых ею языков определения данных. СУБД должна также понимать синтаксис языка определения данных, например, в том смысле, что ей должно быть понятно, что внешние записи EMPLOYEE включают поле SALARY. Это понимание она должна использовать при анализе и выполнении запросов обработки данных (например, таких: Найти всех служащих с зарплатой, составляющей менее $50 ООО ).

Схемы и отображения на исходных языках

Планируемые запросы на языке манипулирования данными

pocbiN. /тГроизвольные запросы\ ювания) (на языке манипулирования) ..данными ,

СОткомпилированные запросы J

СИсходные и объектные схемы и отображения J

Оптимизатор

СОптимизированные запросы J

Менеджер времени выполнения

Метаданны

Реализация

ограничений

защиты и

поддержки

целостности

данных

за данныд

Данные

Метаданные (словарь данных)

Рис. 2.4. Основные функции и компоненты типичной СУБД Запросы на ЯМЛ разделяются на планируемые и непланируемые.

Обработка данных

СУБД должна уметь обрабатывать запросы пользователя на выборку, изменение или удаление данных, уже существующих в базе, или на добавление в нее новых данных. Другими словами, СУБД должна включать в себя компонент процессора ЯМЛ или компилятора ЯМЛ, обеспечивающего поддержку языка манипулирования данными.

а) Планируемый запрос - это запрос, необходимость выполнения которого была предусмотрена заранее. Администратор базы данных, возможно, должен будет построить физический проект базы данных таким образом, чтобы гарантировать достаточное быстродействие выполнения подобных запросов.

б) Непланируемый запрос - это, наоборот, некоторый произвольный запрос, необходимость выполнения которого не была предусмотрена заранее и возникла по какой-то особой причине. Физический проект базы данных может подходить, а может и не подходить для выполнения конкретного произвольного запроса.

Согласно терминологии, введенной в разделе 1.3, планируемые запросы более характерны для операционных приложений, а непланируемые- для приложений поддержки принятия рещений. Более того, планируемые запросы обычно выдаются из написанных заранее приложений, а непланируемые запросы по определению вводятся интерактивно, с помощью процессора языка запросов.

Замечание. В главе 1 уже отмечалось, что на самом деле процессор языка запросов - это встроенное интерактивное приложение, а не какая-то часть самой СУБД. Мы показали этот компонент на рис. 2.4 исключительно из соображений полноты общей картины.

Оптимизация и выполнение

Запросы ЯМД, планируемые или непланируемые, должны быть обработаны таким компонентом, как оптимизатор, назначение которого состоит в поиске достаточно эффективного способа выполнения каждого из запросов. Оптимизация подробно обсуждается в главе 17. Оптимизированные запросы затем выполняются под управлением менеджера времени выполнения (run-time manager).

Замечание. На практике менеджер времени выполнения, возможно, будет использовать что-то подобное менеджеру доступа к файлам для получения доступа к хранимым данным. Менеджеры файлов кратко обсуждаются в конце этого раздела.

Защита и сохранение целостности данных

СУБД должна контролировать пользовательские запросы и пресекать любые попытки нарущения ограничений защиты и сохранения целостности данных, определенные АБД (см. предыдущий раздел). Этот контроль может осуществляться во время компиляции, во время выполнения или на обоих этих этапах обработки запроса.

Восстановление данных и поддержка параллельности

СУБД или другой связанный с ней программный компонент, обычно называемый менеджером транзакций или диспетчером выполнения транзакций, должен обеспечивать необходимый контроль над восстановлением данных и управлением параллельностью обработки. Детали реализации этих функций системы выходят за рамки данной главы - подробное обсуждение указанных тем можно найти в части IV.