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

Поскольку обеспечение независимости данных от программ – важнейшая функция базы данных, остановимся на ней немного подробнее. Для решения проблемы обеспечения независимости данных в 1975 году Национальный институт стандартизации США (ANSI) начал работал над стандартом архитектуры баз данных. Стандартом эта работа так и не стала, но заложила основы построения архитектуры баз данных и до сих пор пользуется известностью как «Трехуровневая архитектура ANSI / SPARC».

Основной идеей было выделение трех уровней – внутреннего, концептуального и внешнего. На каждом уровне используется свое представление данных, которое не зависит от представления данных на других уровнях. Схема трехуровневой модели показана на рис ….

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

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

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

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

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

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

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

Наконец, прикладные приложения также должны преодолевать несовпадения типов данных, имеющихся в языках программирования, и типов данных БД. В разных языках и средах разработки эта проблема решается по-разному. В каких-то случаях есть возможность встраивать инструкции на языке, поддерживаемом СУБД (чаще всего это SQL) непосредственно в программный код. Но в большинстве случаев в состав библиотек, сопровождающих язык программирования, входят библиотеки, обеспечивающие работу с базами данных. Если говорить о платформе Windows, то на сегодня наиболее широко применяемыми являются библиотеки ADO (и их аналоги) и ADO.Net. Кроме того, в последних версиях Visual Studio.Net появились и возможности для создания запросов непосредственно в программном коде (технология LINQ), и организации доступа к данным в полностью объектно-ориентированном ключе (Entity Framework). Мы будет рассматривать эти вопросы во второй части конспекта.