В современных системах БД выделяют 3 уровня представления данных: внешний, концептуальный и внутренний (рис. 1.3). Внешний уровень отражает представление пользователей на БД. Внутренний уровень отражает представление, на котором СУБД и ОС воспринимают данные. Концептуальный (логический) уровень – связан с обобщенным представлением всех пользователей БД ( это взгляд администратора БД).
Этот подход является общепризнанным и существует уже более 30 лет. Первые предложения по многоуровневой архитектуре были выдвинуты рабочей группой CODACYL в 1971 г. В 1975 г. Комитет планирования стандартов и норм SPARC (Standarts Planning and Requirements Committee) Американского национального института стандартов FNSI (American National Stsndsrt Institute) предложил обобщенную 3-х уровневую структуру СУБД, которая была официально признана в 1978 г и получила название ANSI SPARC.
Первая попытка создания стандартной терминологии и общей архитектуры СУБД была предпринята в 1971 году группой DBTG, признавшей необходимость использования двухуровневого подхода, построенного на основе использования системного представления, т.е. схемы, и пользовательских представлений, т.е. подсхем . Сходные терминология и архитектура были предложены в 1975 году Комитетом планирования стандартов и норм SPARC. Комитет ANSI/SPARC признал необходимость использования трехуровневого подхода. Хотя модель ANSI/SPARC не стала стандартом, тем не менее она все еще представляет собой основу для понимания некоторых функциональных особенностей СУБД.
В данном случае наиболее важным моментом в этих и последующих разработках является идентификация трех уровней абстракции, т.е. трех различных уровней описания элементов данных. Эти уровни формируют трехуровневую архитектуру, которая охватывает внешний, концептуальный и внутренний уровни. Цель трехуровневой архитектуры заключается в отделении пользовательского представления базы данных от ее физического представления. Ниже перечислено несколько причин, по которым желательно выполнять такое разделение.
· Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них. Каждый пользователь должен иметь возможность изменять свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей.
· Пользователи не должны непосредственно иметь дело с подробностями физического хранения данных в базе
· Администратор базы данных должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательские представления.
· Внутренняя структура базы данных не должна зависеть от таких изменений физических аспектов хранения информации, как переход на новое устройство хранения.
· АБД должен иметь возможность изменять концептуальную или глобальную структуру базы данных без какого-либо влияния на всех пользователей.
Уровень, на котором воспринимают данные пользователи, называется внешним уровнем (external level), тогда как СУБД и операционная система воспринимают данные на внутреннем уровне (internal level). Именно на внутреннем уровне данные реально сохраняются с использованием всех тех структур и файловой организации. Концептуальный уровень (conceptual level) представления данных предназначен для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга.
Основным назначением такой архитектуры является обеспечение независимости данных, суть которого заключается в том, что изменения на нижних уровнях архитектуры не влияют на верхние уровни.
Внешний уровень – это пользовательский уровень. Пользователем может быть программист, конечный пользователь или администратор БД. Представление с точки зрения пользователя называется внешним представлением. Оно отражает представление пользователя о данных в БД в удобной для него форме (например, для бухгалтерии - это данные о студентах, которым начисляется стипендия, при этом не важно, какие у них оценки. Для деканата данные о тех же студентах будут содержать сведения об их оценках в сессию и т.п.) . Эти частичные представления пользователей о БД называют подсхемой БД. При этом каждый пользователь может использовать свои языковые и программные средства для работы с БД.
Концептуальный уровень является промежуточным уровнем и обеспечивает представление всей БД в абстрактной форме. Описание БД на этом уровне называют концептуальной схемой , которая является результатом концептуального проектирования. Концептуальная схема отражает интересы всех пользователей и представляет собой единое логическое описание всех элементов данных и отношений между ними, образуя логическую структуру всей БД.
Концептуальная схема должна содержать:
· объекты и атрибуты предметной области;
· связи между объектами;
· ограничения, накладываемые на данные;
· семантическую информацию о данных;
· обеспечение безопасности данных;
· поддержку целостности данных.
Концептуальный уровень поддерживает каждое внешнее представление, в том смысле, что любые доступные пользователю данные должны содержаться (или могут быть вычислены) на этом уровне. Однако на этом уровне не содержаться сведения о методах хранения данных.
Внутренний уровень характеризует внутреннее представление. Оно не связано с физическим уровнем, т.к. физический уровень хранения информации обладает существенной индивидуальностью для каждой системы. На внутреннем уровне все эти особенности не учитываются, а вся область хранения представляется как бесконечное линейное адресное пространство. На нижнем уровне находится внутренняя схема, которая является полным описанием внутренней модели данных. Для каждой БД она только одна. Внутренняя схема описывает физическую реализацию и предназначена для достижения оптимальной производительности и обеспечения экономного использования дискового пространства. На внутреннем уровне хранится следующая информация:
· распределение дискового пространства для хранения данных и индексов;
· описание подробностей сохранения записей (типы, размеры элементов данных и др.);
· сведение о размещении записей;
· сведения о сжатии записей и выбранных методах шифрования.
СУБД отвечает за установление соответствия между всеми тремя уровнями и поддержку их непротиворечивости.
СУБД является сложным программным продуктом и должна обеспечивать выполнение всех определенных ранее функций. Следует отметить, что некоторые функции могут выполняться ОС. Поэтому при проектировании СУБД следует учитывать особенности интерфейса СУБД с ОС.
В структуре СУБД выделяют ядро СУБД (рис. 1.4), которое включает транслятор с языка БД (ЯОД И ЯМД), подсистему поддержки времени выполнения (управление данными во внешней памяти, управление собственными буферами оперативной памяти, управление журнализацией), подсистему управления транзакциями. Кроме того в состав СУБД входит набор утилит, который существенно зависит от выбранной СУБД. В некоторых СУБД эти части явно не выделены, но логически присутствуют всегда.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами ОП, управление транзакциями и ведение журналов. Каждая функция реализуется в виде соответствующего менеджера (менеджер транзакций, менеджер буферов и т.д.). Эти функции взаимосвязаны и должны работать под управлением четко проверенных протоколов. Ядро СУБД обладает собственным интерфейсом, недоступным пользователю напрямую и является резидентной частью СУБД. При использовании архитектуры «клиент-сервер» оно является основной составляющей серверной части. Поэтому программа, обеспечивающая выполнение функций СУБД называется машина БД.
В структуре программного комплекса СУБД можно выделить:
Процессор запросов – преобразует запросы в последовательность низкоуровневых инструкций для контроллера БД.
Транслятор с ЯОД – преобразует его команды в набор таблиц, содержащих метаданные. Эта информация хранится в системном каталоге, а управляющая информация – в заголовке файлов.
Транслятор с ЯМД – преобразует внедренные в прикладные программы операторы в вызовы стандартных функций базового языка. Взаимодействует с процессором запросов.
