Введение в системы БД (542480), страница 18
Текст из файла (страница 18)
Физический проект базы данных может подходить, а может и не подходить для выполнения конкретного произвольною запроса. Согласно терминологии, введенной в разделе 1.3, планируемые запросы более характерны для операционных приложений, а непланируемые — для приложений поддержки принятия решений. Более того, планируемые запросы обычно выдаются из написанных заранее приложений, а непланируемые запросы по определению вводятся интерактивно, с помощью процессора языка запросов. Замечание. В главе 1 уже отмечалось, что на самом деле процессор языка запросов — это встроенное интерактивное приложение, а не какая-то часть самой СУБД.
Мы показали этот компонент на рис. 2А исключительно из соображений полноты общей картины. ° Оптичизанил и выполнение Запросы ЯМД, планируемые или непланнруемые, должны быть обработаны таким компонентом, как оптимизатор, назначение которого состоит в поиске достаточно эффективного способа выполнения каждого из запросов. Оптимизация подробно обсуждается в главе !7. Оптимизированные запросы затем выполняются под управлением менеджера времени выполнения (гоп-Йпе шапаяег).
Зачечание. На практике менеджер времени выполнения, возможно, будет использовать что-то подобное менеджеру доступа к файлам для получения доступа к хранимым данным. Менеджеры файлов кратко обсуждаются в конце этого раздела. ° Защита и сохранение целостности данных СУБД должна контролировать пользовательские запросы и пресекать любые попытки нарушения ограничений зашиты и сохранения целостности данных, определенные АБД (см. предыдущий раздел). Этот контроль может осуществляться во время компиляции, во время выполнения или на обоих этих этапах обработки запроса.
° Восстановление данных и поддержка параллельности СУБД или другой связанный с ней программный компонент, обычно называемый менеджером транзакций нли диспетчером выполнения транзакций, должен обеспечивать необходимый контроль над восстановлением данных и управлением параллельностью обработки. Детали реализации этих функций системы выходят за рамки данной главы — подробное обсуждение указанных тем можно найти в части 1Ч. Глава 2.
Архитектура системы баз данных 79 Замечание. Менеджер транзакций не показан на рис. 2.4, поскольку обычно он не является частью самой СУБД. ° Словарь данных СУБД должна поддерживать функцию ведения словари данных. Сам словарь данных вполне можно считать самостоятельной базой данных (но не пользовательской, а системной). Словарь содержит "данные о данных" (иногда называемые метаданными или дескрипторами), т.е. определения других объектов системы, а не просто обычные данные. В частности, в словаре данных будут сохранены исходные и объектные формы всех существующих схем (внешних, концептуальной и т.д.) и отображений, а также установленные ограничения зашиты и сохранения целостности данных.
Расширенный словарь может также включать большой объем дополнительной информации, например, показывающей, какие из программ используют ту нли иную часть базы данных, какие отчеты требуются каждому из пользователей и т.д. Словарь может быть (а фактически просто должен быть) интегрирован в определяемую им базу данных, а значит, должен содержать описание самого себя. Конечно, должна существовать возможность обращения к словарю с запросами, как к любой другой базе данных, например, для того, чтобы узнать, какие программы гнили пользователи будут затронуты при предполагаемом внесении изменения в систему. Дальнейшее обсуждение этого вопроса приводится в главе 3. Замечание. Здесь мы коснулись области, в которой может возникнуть путаница из-за используемой терминологии. То, что мы называем словарем, иногда называют дирвктарием или каталогом, потому что директории и каталоги в некотором смысле хуже настоящего словаря, а термин "словарь" зарезервирован для специального (важного) вида инструментов разработки приложений.
Также встречаются и другие термины — репозитарий данных (глава 13) и энциклопедия данных. ° Производительность Очевидно, что СУБД должна выполнять все указанные функции с максимально возможной эффективностью. Подводя итог сказанному, можно сделать вывод, что, в целом, назначением СУБД является предоставление пользовательского интерфейса с системой баз данных. Пользовательский интерфейс может быть определен как существующий в системе ограничительный уровень, ниже которого для пользователя все остается невидимым. Следовательно, по определению пользовательский интерфейс находится на внешнем уровне.
Тем не менее в главе 8 мы увидим, что иногда внешнее представление едва ли значительно отличается от соответствующей ему части основного концептуального представления (по крайней мере, в современных коммерческих ЯЯ:продуктах). В заключение вкратце сопоставим описанную здесь типовую СУБД с системой управления файлами (также для краткости — с менеджером файлов или файловым сервером). В своей основе система управления файлами является компонентом базовой операционной системы, предназначенной для управления хранимыми файлами. Проще говоря, она расположена "ближе к диску", чем СУБД. (В действительности СУБД обычно строится на базе некоторого варианта файлового сервера.) Таким образом, пользователь системы управления файлами может создавать и уничтожать хранимые файлы, а также выполнять простые операции выборки и обновления хранимых записей в созданных им файлах.
Однако в сравнении с СУБД системе управления файлами свойственны следующие недостатки. Часть 1 Основные понятия ° Система управления файлами ничего не знает о внутренней структуре хранимых записей и, следовательно, не способна обрабатывать запросы, предполагающие знание этой структуры. ° Как правило, эти системы предоставляют слабую поддержку ограничений защиты и поддержки целостности данных или же не предоставляют ее вовсе. ° Как правило, эти системы предоставляют недостаточную поддержку управления восстановлением данных и параллельным доступом к ним или же не предоставляют ее вовсе.
° На уровне менеджера файлов не существует концепции настоящего словаря данных. ° Как правило, эти системы обеспечивают независимость данных гораздо хуже, чем СУБД. ° Как правило, отдельные файлы не "интегрированы" или не "разделяемы" в том смысле, который вкладывается в эти понятия применительно к базам данных. (Обычно они являются собственными файлами пользователя или приложения.) 2.9.
Система управления передачей данных В этом разделе вкратце рассматривается передача данных. Запросы к базе данных от конечных пользователей в действительности передаются от рабочей станции пользователя (которая может быть физически удалена от самой системы баз данных) к некоторому интерактивному приложению (встроенному или нет), а от него — к СУБД в форме каммуникачиоккых сообщений.
Более того, ответы пользователю (от СУБД и оперативного приложения к станции пользователя) также передаются в форме подобных сообщений. Передача таких сообщений происходит под управлением другого программного компонента — менеджера передачи данныж Менеджер передачи данных не является частью СУБД; он представляет собой автономную систему со своими правами. Однако, поскольку очевидно, что от менеджера передачи данных и СУБД требуется согласованная совместная работа, они иногда рассматриваются как равноправные партнеры в компоненте более высокого уровня, называемого системой базы данных и передачи данных.
В этой системе СУБД отвечает за работу с базой данных, а менеджер передачи данных обрабатывает все сообщения, поступающие в СУБД и из нее, а точнее говоря, в то приложение, которое использует СУБД, и из него. Однако в этой книге об обработке сообщений нам осталось сказать относительно немного (поскольку такая обширная тема вполне заслуживает самостоятельного обсуждения). В разделе 2.12 кратко рассматриваются вопросы передачи данных между отдельными системачи (т.е.
между отдельными машинами в сети передачи данных, подобной 1п1егпег), но это уже совсем другая тема. 2.10. Архитектура "клиент/сервер" В предыдуших разделах этой главы подробно обсуждалась так называемая архитектура АХЯ1!БРАКС для систем баз данных.
Ее упрощенная схема приведена на рис. 2.3. В настоящем разделе мы посмотрим на базу данных с несколько иной точки зрения. Общее назначение систем баз данных — это, конечно, поддержка разработки и выполнения приложений баз данных. Поэтому на высоком уровне систему баз данных можно рас- Глава 2. Архитектура системы баэ данных сматривать как систему с очень простой структурой„состоящей из двух частей — серве- ра (виутреэтиего компонента нли машины базы данных) и набора клиентов (внешнега компонента или внешнего интерфейса), как показано на рнс. 2.5.
° Сервер — это сама СУБД. Он поддерживает все основные функции СУБД, которые обсуждались в пользователи разделе 2.8, а именно: определение данных, обработку данных, защиту данных, поддержание целостности данных и т.д. В частности, он предоставляет полную поддержку внешнего, концептуального и внутреннего уровней, обсуждавшихся в разделах 2.3 — 2.6.
Поэтому "сервер" в этом контексте— это просто другое название для СУБД. ° Клиенты — это различные приложения, которые выСервер полняются поверх СУБД: как приложения, написанные пользователями, так и встроенные приложения, предоставляемые поставщиками СУБД или некоторыми сторонними поставщиками программного обеспечения. Конечно, с точки зрения сервера разни- Б цы между встроенными приложениями и приложениями, написанными пользователем, нет: все они используют один и тот же интерфейс сервера, а имен- Рис. 2.5. Архитектура но — интерфейс внешнего уровня, который уже рас- "клиеипьсервер" сматривался в разделе 2.3. Замечание.
Некоторые специальные "служебные" приложения могут оказаться исключениями. Как упоминалось выше, они иногда работают непосредственно на внутреннем уровне системы (см. раздел 2.5). Подобные утилиты правильнее относить к встроенным компонентам СУБД, а не к приложениям в обычном смысле. В следующем разделе утилиты обсуждаются более подробно. Клиенты аэа данных Приложения, в свою очередь, делятся на несколько четко определенных категорий. ° Приложения, написанные пользователями. В основном, это обычные прикладные программы, чаше всего написанные либо на популярном языке программирования, подобном С или СОВОЬ, либо на специализированных языках четвертого поколения, хотя в обоих случаях эти языки должны как-то связываться с соответствующим подъязыком данных (см.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
