Архитектура построения баз данных

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

Три уровня абстракции (концептуальный, внешний, физический) были предложены рабочей группой по БД КОДАСИЛ (СОDАSYL) в 1971 г. Они являются центральной идеей отчета по СУБД исследовательской группы Американского национального института стандартов АNSI/SРАRС, опубликованного в 1975 г., где называются соответственно (рис. 1.1):

концептуальный уровень с концептуальной схемой;

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

внутренний уровень с внутренней (физической) схемой.

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

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

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

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

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

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

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

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

Сформулируем основные свойства и назначение концептуальной схемы.

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

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

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

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

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

Пример 1.1. Рассмотрим концептуальную модель БД АВИАЛИНИИ, включающую три типа объектов: САМОЛЕТ, ПИЛОТ, РЕЙС и два типа связей: ОБСЛУЖИВАЕТ (САМОЛЕТ РЕЙС) и ВЫПОЛНЯЕТ (ПИЛОТ, РЕЙС) (рис. 1.2).

Объекты имеют следующие атрибуты.

САМОЛЕТ: СНОМ — номер самолета, СМОД — модель самолета, СМЕСТ— количество пассажирских мест, СПОРТ —аэропорт стоянки;

ПИЛОТ: ПНОМ — номер пилота, ПФАМ— фамилия пилота, ПАДР — адрес пилота, ПЗАР — зарплата пилота;

РЕЙС: РНОМ— номер рейса, РВ — место вылета, РП — место прибытия, РВРВ — время вылета, РВРП — время прибытия.

Множество связей подразделяется на следующие типы: N: 1 (функциональный), l:N (иерархический), М: N (смешанный); при этом 1: N и М: N — типы связей между объектами, а N: 1 — между атрибутами. Для модели БД АВИАЛИНИИ могут быть такие связи: СНОМ —-> (СМОД, СМЕСТ, СПОРТ); ПНОМ —-> (ПФАМ, ПАДР, ПЗАР);

N: 1

РНСНОМ

-----> (РВ, РП, РВРВ, РВРП).

N: 1

РНПНОМ

-----> (ПФАМ, ПАДР, ПЗАР)

N: 1

РНРНОМ

-----> (РВ, РП, РВРВ, РВРП)

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

N: 1

РНПНОМ

-----> РНОМ;

N: 1

РНПИЛОТ

----->РЕЙС;

N: 1

РНСНОМ

-----> РНОМ;

N: 1

РНСАМОЛЕТ

-----> РЕЙС;

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

РНПНОМ

-----> РНОМ;

1: N

РНПИЛОТ

----->РЕЙС;

1: N

РНСНОМ

-----> РНОМ;

РНСАМОЛЕТ

-----> РЕЙС;

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

M: N

РНСНОМ

-----> ПНОМ;

РНСАМОЛЕТ

М: N

-----> ПИЛОТ

Рис. 1.2. Представление отношений между объектами в концептуальной схеме

Внешний уровень. На подобном уровне БД описываются внешней моделью. Внешняя модель является частным представлением БД пользователя (группы пользователей). В связи с этим она включает классы объектов и связей, соответствующие группам пользователей. Так, в схеме БД АВИАЛИНИИ (см. рис. 1.2) можно выделить следующие внешние схемы: САМОЛЕТ, РЕЙС, ПИЛОТ, САМОЛЕТ-РЕЙС, ПИЛОТ-РЕИС, необходимые для различных приложений.

Внешняя модель БД описывается внешней схемой, включающей описания всех типов внешних (логических) записей. Например, для типа записи ПИЛОТ нужно описать поля ПНОМ, ПФАМ, ПАДР, ПЗАР и др. Кроме того, требуется определить отображение между внешней и соответствующей ей концептуальной схемой.

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

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

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

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

Хранение записей атрибутов может осуществляться различными способами:

1) с помощью фиксированного формата (значениям отводится фиксированный объем памяти, и они занимают определенное место в записи);

2) значения разделяются с помощью различных знаков;

3) каждому атрибуту соответствует идентифицирующий символ, и значения во внутренней записи появляются с этими символами.

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

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

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

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

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