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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.9. Система управления передачей данных

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

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

2.10. Архитектура клиент/сервер

в предыдущих разделах этой главы подробно обсуждалась так называемая архитектура ANSI/SPARC для систем баз данных. Ее упрощенная схема приведена на рис. 2.3. В настоящем разделе мы посмотрим на базу данных с несколько иной точки зрения. Общее назначение систем баз данных- это, конечно, поддержка разработки и выполнения приложений баз данных. Поэтому на высоком уровне систему баз данных можно рас-

сматривать как систему с очень простой структурой, состоящей из двух частей - сервера {внутреннего компонента или машины базы данных) и набора клиентов {внешнего компонента или внешнего интерфейса), как показано на рис. 2.5.

Конечные пользователи

Клиенты

Сервер

База данных

Рис. 2.5. Архитектура клиент/сервер

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

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

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

Приложения, в свою очередь, делятся на несколько четко определенных категорий.

Приложения, написанные пользователями. В основном, это обычные прикладные программы, чаще всего написанные либо на популярном языке программирования, подобном С или COBOL, либо на специализированных языках четвертого поколения, хотя в обоих случаях эти языки должны как-то связываться с соответствующим подъязыком данных (см. раздел 2.3).

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