Трехуровневая архитектура базы данных. Базы данных

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

База данных Oracle

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

Физический уровень базы данных

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

Файлы базы данных

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

Файлы данных . В этих файлах хранятся собственно сами данные в виде таблиц, индексов, триггеров и прочих объектов. Файлы данных являются наиболее важными во всей базе данных. В стандартной базе должно присутствовать минимум два файла данных: для системных данных (табличное пространство SYSTEM) и для пользовательских данных (табличное пространство USER). В табличном пространстве SYSTEM хранятся пароли всех пользователей в зашифрованном виде.
Файлы журнала повторного выполнения (redo logs) . Файлы журнала повторного выполнения очень важны для базы данных Oracle. В них записываются все транзакции базы данных. Они используются только для восстановления данных в самой базе при сбое экземпляра. В журналах повторного выполнения можно обнаружить множество критичной информации, о существовании которой рядовой администратор мог и не задуматься, в том числе и пароли пользователей.
Управляющие файлы . В этих файлах определено местонахождение файлов данных и другая информация о состоянии базы данных. Управляющие файлы должны быть хорошо защищены. Наиболее важным является файл параметров инициализации экземпляра, потому что без него не удастся запустить экземпляр. Остальные файлы, такие как LISTENER.ORA, SQLNET.ORA, PROTOCOL.ORA, NAMES.ORA и пр., связаны с поддержкой сети и так же очень важны. В этих файлах можно обнаружить множество полезной информации для проникновения в СУБД.
Временные файлы . Временные файлы используются для хранения промежуточных результатов действий над большим объемом данных в случае, если в оперативной памяти для этого не хватает места. Во временных файлах можно обнаружить содержимое временных таблиц и построенных по ним индексов. Временные файлы могут оказаться полезными в процессе расследования инцидентов или при восстановлении важной информации, удаленной из базы данных.
Файлы паролей . Используются для аутентификации пользователей, выполняющих удаленное администрирование СУБД по сети. Более детально о них мы будем говорить позже.

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

Логический уровень базы данных

На логическом уровне находятся табличные пространства и схема БД, состоящая из таблиц, индексов, представлений, хранимых процедур и пр.

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

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

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

Три уровня архитектуры.

Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и внешний. В общих чертах они представляют собой следующее:

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

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

Концептуальный уровень-это «промежуточный» уровень между двумя первыми.

Внешний уровень (индивидуальные представления пользователей).Концептуальный уровень (обобщенное представление пользователей).

Внутренний уровень (представление в памяти).

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

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

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

У каждого пользователя есть свой язык общения .

Для прикладного программиста это либо один из распространенных языков программирования, такой как C, COBOL или PL/1, либо специальный язык рассматриваемой системы. Такие оригинальные языки называют (неформально!) языками четвертого поколения на том основании, что машинный код, язык ассемблера и такие языки, как COBOL, можно считать языками трех первых «поколений», а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

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

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

Язык обработки данных состоит из таких выполняемых операторов PL/1, которые передают информацию в и из БД; опять же, возможно, включая, новые специальные операторы.

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

Концептуальный уровень.

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

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

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

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

Теперь перейдем к более детальному исследованию трех уровней архитектуры.

Внутренний уровень.

Третьим уровнем архитектуры является внутренний уровень. Внутреннее представление - это представление нижнего уровня всей БД; оно состоит из многих экземпляров каждого типа внутренней записи. Термин «внутренняя запись» принадлежит терминологии ANSI/SPARC и означает конструкцию, называемую хранимой записью. Внутреннее представление так же, как внешнее и концептуальное, не связано с физическим уровнем, так как в нем не рассматриваются физические области устройства хранения, такие как цилиндры и дорожки. Другими словами, внутреннее представление предполагает бесконечное линейное адресное пространство; подробности того, как адресное пространство отображено на физическое устройство хранения, очень зависят от системы и умышленно не включены в общую архитектуру.

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

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

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

Локальная архитектура.

И программа, и база данных расположены на одном компьютере. В такой архитектуре работает большинство настольных приложений.

Файл - серверная архитектура.

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

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

Клиент - серверная архитектура.

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

Основной недостаток этой архитектуры не очень высокая надежность. Если сервер выходит из строй, вся работа останавливается.

Распределенная архитектура.

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

позволяют оптимизировать обработку запросов большого числа пользователей и равномерно распределить нагрузку между компьютерами в сети.

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

Интернет - архитектура.

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

Исследовательской группой ANSI-SPARC (ANSI - American National Standard Institute и SPARC - Standards Planning and Requirements Committee) были предложены три уровня абстракции для организации структуры базы данных. Это внешний , концептуальный и внутренний уровни описания данных.

Именно на основе архитектуры ANSI-SPARC базируется архитектура большинства современных СУБД.

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

Определение Концептуальный уровень _ это общее представление БД, описывающее все данные, которые хранятся в ней. Этот уровень содержит логическую структуру всей базы данных. Именно на этом уровне представлены следующие компоненты:

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

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

Определение Внутренний уровень - это физическое представление информации в компьютере. Этот уровень содержит описание структур данных и организации отдельных файлов для хранения данных на физических устройствах.

Определение Схемой базы данных называется ее описание. В соответствии с уровнями абстракции определяются и типы схем базы данных: совокупность внешних схем (соответствующих отдельным представлениям данных), концептуальная и внутренняя схемы. Именно концептуальная схема описывает все сущности, атрибуты и связи между ними. Наконец, внутренняя схема есть полное описание физической структуры данных.

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

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

Каждая система управления базой данных должна удовлетворять следующим требованиям:

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

В информационной системе с БД можно выделить несколько компонентов.

1. Пользователи - люди, которые используют информацию, находящуюся в БД. Принято выделять следующие группы пользователей: системные администраторы - отвечают за основные операции системы; администраторы базы данных - управляют работой СУБД и обеспечивают функционирование базы данных; проектировщики базы данных - разрабатывают структуру БД; системные аналитики - определяют основные функции системы базы данных и проектируют формы ввода данных, отчеты и процедуры, с помощью которых обеспечиваются доступ к данным и манипулирование ими (их добавление, изменение, удаление); программисты - создают программный код; непосредственные пользователи - используют прикладные программы для выполнения необходимых операций по автоматизации своей деятельности.
2. Приложения - программы пользователей, которым необходима информация из системы.
3. Система управления базой данных - ПО, управляющее доступом к данным и обеспечивающее указанные функциональные возможности ИС с БД.
4. Информация - обработанные данные (строки, хранящиеся в файлах).
5. Хост-система - компьютерная система, в которой хранятся файлы. Доступ к строкам данных осуществляется хост-системой. Роль СУБД состоит в том, чтобы генерировать запросы, позволяющие использовать функциональные возможности системы управления файлами хост- системы для обслуживания различных приложений. СУБД представляет собой дополнительный уровень ПО, надстроенный над программным обеспечением хост-системы.
6. Оборудование - все системные программные средства (универсальный компьютер, персональный компьютер, ноутбук, карманный компьютер).
7. Периферийные устройства - физические устройства, обеспечивающие ввод/вывод, а также электронные устройства для подключения дополнительных компьютеров и организации сети.

Графическая интерпретация ИС с БД в виде логической последовательности уровней представлена на рис. 3.1.

Рис. 3.1

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

Обычно современная СУБД содержит следующие компоненты:

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

Системы управления базой данных классифицируют по различным признакам, например: по модели данных - иерархические, сетевые, реляционные, объектно-ориентированные, объектно-реляционные; по способу размещения - локальные (все части локальной СУБД размещаются на одном компьютере), распределенные (части СУБД размещаются на двух и более компьютерах); по способу доступа к БД - файл-серверные, клиент-серверные, встраиваемые, - а также по другим признакам |9, 33].

Концептуальная, логическая и физическая модели предметной области. Предметная область представляет собой часть реального мира, которая исследуется или используется. Это может быть «Изготовление изделий на заказ», «Сбыт готовой продукции», «Оформление сотрудника на работу» и др. Из-за сложности предметной области охватить ее аспекты в одноуровневой модели не представляется возможным. Поэтому используются три уровня: концептуальный (понятийный), логический и физический.

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

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

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

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

В 1978 г. комитетом ANSI/SPARC (ANSI, American National Standard Institute - Национальный институт стандартизации США; SPARC,

Standard Planning and Requirements Committee - Комитет планирования стандартов и норм) официально зафиксировано различие между логическим и физическим представлением данных. В частности, была предложена обобщенная структура систем с базой данных. Эта структура получила название трехуровневой архитектуры, включающей внутренний, концептуальный и внешний уровни (рис. 3.2).

Рис. 3.2.

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

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

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

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

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

Под схемой данных (схемой базы данных) понимается общее описание базы данных. В соответствии с трехуровневой архитектурой различают и три типа схем базы данных:

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

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

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

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

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

Независимость бывает двух типов:

логическая - полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;
физическая - защищенность концептуальной схемы от изменений, которые вносятся во внутреннюю схему.

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

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

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

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

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

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

Обобщенная структура связей программ и данных при использовании СУБД показана на рисунке 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. Компоненты контроллера базы данных