Информационное обеспечение систем управления

Обобщенная архитектура СУБД


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

Обобщенная структура связей программ и данных при использовании СУБД представлена на рис. 1.1 [5].

Рис. 1.1. Связь программ и данных при использовании СУБД

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

–       физическом размещении в памяти данных и их описаний;

–       механизмах поиска запрашиваемых данных;

–       проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

–       способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

–       поддержании баз данных в актуальном состоянии и множестве других функций СУБД [5, 8, 17].

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

–       сущности

интересующей предметной области;



–       атрибуты,

характеризующие неотъемлемые свойства каждой сущности;

–       связи,

ассоциирующие выделенные сущности.

С самых общих позиций, в архитектуре современных СУБД выделяют три уровня абстракции, т.е. три уровня описания элементов хранимых данных. Эти уровни составляют трехуровневую архитектуру, представленную на рис. 1.2, которая охватывает внешний, концептуальный и внутренний уровни [7].

Рис. 1.2. Трехуровневая архитектура ANSI/SPARC

Представленный подход к описанию данных предложен комитетом ANSI/SPARC (Комитет Планирования Стандартов и Норм Национального Института Стандартизации США) и имеет целью отделение пользовательского представления о базе данных от ее физической организации.
Такое отделение обеспечивает независимость хранимых данных и желательно по следующим причинам.

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

–       Пользователи не должны иметь дело с деталями физической организации данных, т.е. не должны зависеть от особенностей физического хранения данных.

–       Администратор базы данных (АБД) должен иметь возможность изменять структуру хранения данных в базе так, чтобы эти изменения оставались «прозрачными» для остальных пользователей.

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

Внешний уровень - представление базы данных с точки зрения конкретных пользователей.

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

Различные представления на внешнем уровне могут пересекаться, т.е. использовать общие описания абстракций предметной области.

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

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



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

–       сущности, их атрибуты и связи;

–       ограничения, накладываемые на данные;

–       семантическую информацию о данных;

–       информацию о мерах обеспечения безопасности.

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

На концептуальном уровне создается даталогическая модель

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

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

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

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

–       карта распределения дискового пространства для хранения данных и индексов;

–       описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);



–       сведения о размещении записей;

–       сведения о возможном сжатии данных и выбранных методах их шифрования.

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

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

Соответствующие трехуровневой архитектуре ANSI/ SPARC три уровня моделей данных для описания предметной области и реализации базы данных представлены на рис.1.3 [5].

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

Основные программные компоненты СУБД представлены на рис. 1.4 [7].



Рис. 1.3. Уровни моделей данных



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

–       Процессор запросов. Это основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкций для контроллера базы данных.

–       Контроллер базы данных. Этот компонент взаимодействует с запущенными пользователями прикладными программами и запросами. Контроллер базы данных принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса.


Затем контроллер базы данных вызывает контроллер файлов для выполнения поступившего запроса. Компоненты контроллера базы данных показаны на рис. 1.5 [7].

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

–       Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функции базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.

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

–       Контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.



Рис. 1.5. Компоненты контроллера БД

Ниже перечислены основные программные компоненты входящие в состав контроллера базы данных.

–       Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочии для выполнения затребованной операции.

–       Процессор команд. После проверки полномочии пользователя для выполнения затребованной операции управление передается процессору команд.

–       Средства контроля целостности. В случае операций, которые изменяют содержимое базы данных, средства контроля целостности выполняют проверку того, удовлетворяет ли затребованная операция всем установленным ограничениям поддержки целостности данных (например, требованиям, установленным для ключей).



–       Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса.

–       Контроллер транзакций. Этот модуль осуществляет требуемую обработку операций, поступающих в процессе выполнения транзакций.

–       Планировщик.

Этот модуль отвечает за бесконфликтное выполнение параллельных операций с базой данных. Он управляет относительным порядком выполнения операций, затребованных в отдельных транзакциях.

–       Контроллер восстановления. Этот модуль гарантирует восстановление базы данных до непротиворечивого состояния при возникновении сбоев. В частности, он отвечает за фиксацию и отмену результатов выполнения транзакций.

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

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


Содержание раздела