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

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

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

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

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

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

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

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

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

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

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

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

Планируемые запросы на языке манипулирования данными роизвольные запросы на языке манипулированияу данными ( Откомпилированные ^ запросы J Оптимизатор				■
Процессор языка манипулирования данными			Процессор языка запросов
	t			1

Реализация

ограничений

защиты и

поддержки

целостности

данных

аза данных

Данные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ Словарь данных

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

Замечание. Здесь мы коснулись области, в которой может возникнуть путаница из-за используемой терминологии. То, что мы называем словарем, иногда называют ди- ректорией или каталогом, потому что директории и каталоги в некотором смысле хуже настоящего словаря, а термин "словарь" зарезервирован для специального (важного) вида инструментов разработки приложений. Также встречаются и другие термины — репозиторий данных (глава 13) и энциклопедия данных.

■ Производительность

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

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

В заключение вкратце сопоставим описанную здесь типовую СУБД с системой управ- ления файлами (также для краткости — с менеджером файлов или файловым сервером). В своей основе система управления файлами является компонентом базовой операционной системы, предназначенной для управления хранимыми файлами. Проще говоря, она распо- ложена "ближе к диску", чем СУБД. (В действительности СУБД обычно строится на базе некоторого варианта файлового сервера.) Таким образом, пользователь системы управле- ния файлами может создавать и уничтожать хранимые файлы, а также выполнять простые операции выборки и обновления хранимых записей в созданных им файлах. Однако в срав- нении с СУБД системе управления файлами свойственны следующие недостатки.

• Система управления файлами ничего не знает о внутренней структуре хранимых записей и, следовательно, не способна обрабатывать запросы, предполагающие знание этой структуры.

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

• Как правило, эти системы предоставляют недостаточную поддержку управления восстановлением данных и параллельным доступом к ним или же не предостав- ляют ее вовсе.

• На уровне менеджера файлов не существует концепции настоящего словаря данных.

• Как правило, эти системы обеспечивают независимость данных гораздо хуже, чем СУБД.

• Как правило, отдельные файлы не "интегрированы" или не "разделяемы" в том смысле, который вкладывается в эти понятия применительно к базам данных. (Обычно они являются собственными файлами пользователя или приложения.)