Обобщенная архитектура СУБД
Основной интерес применения СУБД заключается в том, чтобы предложить пользователю (или прикладным процессам) абстрактное представление данных, скрыв особенности хранения и управления ими.
СУБД должна представлять доступ к данным посредством прикладных процессов любым пользователям, в том числе не имеющим представления:— о физическом размещении в памяти данных и их описаний;
— о механизме поиска запрашиваемых данных;
— о проблемах, возникающих при одновременном запросе одних и тех же данных большим числом пользователей (прикладных программ);
— о способах защиты данных от некорректных обновлений и (или) несанкционированного доступа;
— о поддержании базы данных в актуальном состоянии.
Обобщенная структура связей программ и данных при использовании СУБД показана на рисунке 6.6.
При выполнении основных из этих функций СУБД должна использовать различные описания данных, в которых должны быть учтены:
— сущности интересующей предметно области;
— атрибуты, характеризующие неотъемлемые свойства каждой сущности;
— связи, ассоциирующие выделенные сущности.
Рис. 6.6. Обобщенная структура связей программ и данных в СУБД
Подход к архитектуре и описанию данных предложен комитетом ANSISPARC (Комитет планирования Стандартов и норм
национального института стандартизации США) и имеет целью отделение пользовательского представления о БД от ее физической организации. В соответствии с этим предложением архитектура СУБД должна быть трехуровневой и должна содержать внешний, концептуальный и внутренний уровни (рис. 6.7).
Рис. 6.7. Трехуровневая архитектура ANSI-SPARC
Такое отделение по уровням обеспечивает независимость хранимых данных, что необходимо по следующим причинам:
1.
Каждый пользователь должен иметь возможность обращаться к данным, используя свое представление о них, изменять свое представление о данных без влияния на представление других пользователей.2. Пользователи не должны иметь дело с деталями физической организации данных, т.е. не должны зависеть от особенностей физического хранения данных.
3. Администратор базы данных должен иметь возможность изменять структуру хранения данных так, чтобы эти изменения оставались прозрачными для остальных пользователей.
4. Структура БД не должна зависеть от физических аспектов хранения, например, при переключении на новое внешнее устройство памяти.
Внешний уровень — это представление БД с точки зрения конкретных пользователей. Указанный уровень может включать несколько различных представлений БД со стороны различных групп пользователей. При этом каждый пользователь имеет дело с представлением предметной области, выраженным в наиболее понятной и удобной для него форме. Такое представление содержит только те сущности, атрибуты и связи, которые интересны ему при решении профессиональных задач. Различные представления на внешнем уровне могут пересекаться, т.е. использовать общие описания абстракций предметной области. На внешнем уровне создается инфологическая модель БД, полностью независимая от платформы (вычислительной системы, на которой будет использоваться).
Инфологическая модель является человеко-ориентированной: средой ее хранения может быть память человека, а не ЭВМ. Ин- фологическая модель не изменяется до тех пор, пока какие-то изменения в реальном мире не потребуют изменения некоторых определений, чтобы эта модель продолжала отражать предметную область.
Концептуальный уровень — обобщающее представление БД, описывающее то, какие данные хранятся в БД, а также связи, существующие между ними. Концептуальный уровень является промежуточным в трехуровневой архитектуре. Содержит логическую структуру всей базы данных. Фактически это полное представление требований к данным со стороны организации, которая не зависит от соображений относительно способов их хранения.
На концептуальном уровне необходимо выделить:1) сущности, их атрибуты и связи;
2) ограничения, накладываемые на данные;
3) семантическую информацию о данных;
4) информацию о мерах обеспечения безопасности.
Концептуальный уровень поддерживает каждое внешнее представление. Поэтому на этом уровне содержатся любые доступные пользователю данные, за исключением сведений о методах хранения этих данных. На концептуальном уровне создается даталогическая модель.
Даталогическая модель представляет собой описание инфо- логической модели на языке определения данных конкретной СУБД. Эта модель является компьютерно-ориентированной (зависит от применяемой на компьютере СУБД и операционной системы).
Внутренний уровень — физическое представление БД, описывающее методы ее хранения в вычислительной системе. Данный уровень описывает физическую реализацию БД и предназначен для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. Содержит описание структур данных и отдельных файлов, используемых для хранения на запоминающих устройствах.
На внутреннем уровне осуществляется взаимодействие СУБД с методами доступа операционной системы с целью эффективного размещения данных на носителях, создания индексов и т.д. На этом уровне используются:
— карта распределения дискового пространства для хранения данных и индексов;
— описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);
— сведения о размещении записей;
— сведения о возможности сжатия данных и выбранных методов шифрования.
Реализация перечисленной информации производится на физическом уровне вычислительной системы, который контролируется операционной системой. В настоящее время функции СУБД и операционной системы строго не разграничиваются. Имеются СУБД, использующие все методы доступа, предусмотренные в данной операционной системе, в других используются только некоторые из методов либо реализована своя файловая система.
На внутреннем уровне создается физическая модель.
Физическая модель дает возможность СУБД представлять программам и пользователям доступ к хранимым данным по именам, не заботясь об их физическом расположении. Является компьютерно-ориентированной (зависит от СУБД и операционной системы). По этой модели СУБД отыскивает данные на внешних запоминающих устройствах.
В соответствии с предложениями ANSI-SPARC можно представить соответствующую трехуровневую модель данных (рис. 6.8):
Рис. 6.8. Уровни моделей данных
СУБД строится по модульному принципу, т.к. это достаточно сложный программный продукт. Состав и взаимосвязь модулей реальных СУБД сильно различаются, однако можно выделить ряд обобщенных компонентов (рис. 6.9):
Рис. 6.9. Основные компоненты СУБД
Рассмотрим основные компоненты СУБД.
Процессор запросов — основной компонент СУБД, преобразующий запросы в последовательность низкоуровневых инструкций для контроллера БД.
Контроллер базы данных взаимодействует с запущенными пользовательскими программами и запросами. Контроллер БД принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Контроллер БД вызывает контроллер файлов для выполнения поступившего запроса.
Контроллер файлов манипулирует предназначенными для хранения данных файлами и отвечает за распределение доступного дискового пространства. Он создает и поддерживает список структур и индексов, определенных во внутренней схеме. (Контроллер файлов не управляет физическим вводом — это функция операционной системы).
Препроцессор языка DML преобразует внедренные в прикладные программы DML операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.
Язык манипулирования данными (Data Manipulation Language — DML) — совокупность языковых средств организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД.Компилятор языка DDL преобразует DDL команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация — в заголовках файлов с данными. Язык определения данных (Data Definition Language — DDL) — формальный закон, используемый в некоторой модели данных для определения структуры данных.
Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.
Контроллер базы данных, как и другие компоненты СУБД, содержит большое количество программных единиц. Например, в контроллер базы данных входят следующие программные компоненты (рис. 6.10):
1. Контроль прав доступа (пользователь имеет или не имеет права на затребованную операцию).
2. Процессор команд (для выполнения запроса управление передается процессору команд).
3. Средства контроля целостности (при выполнении операций, связанных с изменением содержимого базы данных, проверяется целостность ключей).
4. Оптимизатор запросов определяет наилучшую стратегию выполнения запроса.
5. Контроллер транзакций осуществляет требуемую обработку операций, поступающих в процессе выполнения транзакций.
6. Планировщик отвечает за бесконфликтное выполнение параллельных с базой данных операций.
7. Контроллер восстановления обеспечивает восстановление данных до непротиворечивого состояния после сбоя.
8. Контроллер буферов отвечает за перенос данных между ОЗУ и внешними носителями.
Рис. 6.10. Компоненты контроллера базы данных
6.5.