Архитектура баз данных

Построению систем, основанных на использовании СУБД, предшествовали интенсивные научные исследования, направленные на решение проблемы устройства самой СУБД. Наиболее фундаментальным результатом этих исследований стало определение трех уровней абстракции, т. е. трех различных уровней описания элементов данных, зафиксированных в модели ANSI-SPARC [13]. Эти уровни формируют трехуровневую архитектуру базы данных, которая охватывает внешний, концептуальный и внутренний уровни (рис. 1.2). Уровень, на котором данные воспринимаются пользователями, называется внешним уровнем (external level), тогда как СУБД и операционная система воспринимают данные на внутреннем уровне (internal level). Именно на внутреннем уровне данные реально сохраняются с использованием структур данных и файловой организации. Концептуальный уровень (conceptual level) представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.

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

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

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

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

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

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

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

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

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

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

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

• — распределение дискового пространства для хранения данных и индексов;
• — описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);
• — сведения о размещении записей;
• — сведения о сжатии данных и выбранных методах их шифрования.

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

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

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

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

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

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

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

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

Если СУБД поддерживает уровень подсхем, то перед проектировщиком встает задача определения подсхем. Э го также можно рассматривать как этап проектирования БД.

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

Рис. 1.3. Модели и описания структуры БД, поддерживаемые

СУБД

Взаимосвязь этапов проектирования базы данных показана на рис. 1.4.

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

Рис. 1.4. Взаимосвязь этапов проектирования

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