Главная » SQL, Базы данных » СИСТЕМА УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ

0

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

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

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

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

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

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

Конечно, описание предыдущего примера весьма упрощено; в частности, в данном случае предполагается, что весь процесс основан на интерпретации (т.е. анализ запроса,

проверка различных схем и другие процедуры осуществляются непосредственно во время

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

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

Рис. 2.4. Основные функции и компоненты типичной СУБД

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

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

■     Манипулирование данными

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

В целом, запросы ЯМД подразделяются на планируемые и непланируемые.

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

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

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

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

Запросы ЯМД, планируемые или непланируемые, должны быть обработаны таким компонентом, как оптимизатор, назначение которого состоит в поиске достаточно эффективного способа выполнения каждого из запросов7. Оптимизация подробно

7 Во всей данной книге термин "оптимизация" относится исключительно к оптимизации запросов ЯМД, если явно не указано иное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■     Обычно такие системы предоставляют недостаточную поддержку управления вос становлением данных и параллельным доступом к ним или же не предоставляют ее вовсе.

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

■     Вообще говоря, эти системы обеспечивают независимость от данных гораздо хуже по сравнению с СУБД.

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии