Архитектура БД

Методы и средства проектирования БД

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

— каждый пользователь должен иметь право обращаться к общим данным, используя своё представление о них;

— взаимодействие пользователя с БД не должно зависеть от особенностей её физической организации;

— администратор базы данных (АБД) должен иметь возможность изменять структуру и формат данных, не оказывая влияния на пользовательские представления;

— внутренняя структура БД не должна зависеть от переключения на новое устройство хранения;

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

Для удовлетворения этих потребностей архитектура большинства современных коммерческих СУБД, существующих на рынке программного обеспечения, в той или иной мере, строится на базе так называемой архитектуры ANSI—SPARC. Название произошло по названию комитета планирования стандартов и норм (Standards Planning and Requirements Committee, SPARC) национального института стандартизации (American National Standard Institute, ANSI) США. Комитет признал необходимость использования трехуровневого подхода к организации БД, отделяющего пользовательские представления базы данных от её физического представления посредством создания независимого уровня.

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

ПП₁ – представление 1—го пользователя, ПП_к – представление к—того пользователя

Рисунок 1 — Трехуровневая архитектура БД

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

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

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

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

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

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

Внешний уровень представляется внешней схемой, содержащей несколько подсхем, отображающих внешние представления различных пользователей БД. Во—первых, это представление сотрудника фирмы, выполняющего обязанности кадрового учета. Его функциями являются учет личных данных сотрудников, сведений о приеме их на работу, всех перемещений и увольнений. Сотрудник—кадровик представляет данные в таком виде: каждому сотруднику присваивается табельный номер, это 5—значное целое число. Личные данные сотрудника вводятся в базу данных из следующих документов: паспорта, диплома об образовании, договора о найме на работу. Сотрудник—кадровик создает личную карточку сотрудника, в которую, кроме личных данных, вводит сведения о том в какое подразделение и на какую должность принимается сотрудник. Эти данные он берет из приказов о приемах, переводах, увольнениях и отпусках. Сотрудник—кадровик также периодически формирует различные отчеты по качественному составу персонала для руководителя фирмы: список сотрудников, достигших пенсионного возраста на заданную дату, список сотрудников, имеющих более 2—х несовершеннолетних детей, список сотрудников, не имеющих высшего образования и тому подобное. Второе внешнее представление – это представление сотрудника, выполняющего функции начисления заработной платы. Он ведет учет количества отработанных дней каждого сотрудника, сведения о полагающихся сотруднику надбавках, ежемесячно осуществляет расчет заработной платы, формирует ряд отчетов, как для руководителей фирмы, так и для внешних организаций – налоговой инспекции, пенсионного фонда. Третий пользователь базы данных это руководитель фирмы, который может просматривать личные данные сотрудников, сведения о выплатах по зарплате. Четвертый внешний пользователь — это пользователь сети Интернет, который на сайте фирмы может получить следующие сведения о сотрудниках фирмы – фотографии, фамилии, имена и отчества, названия подразделений, должности, ученые звания, степени и другую общедоступную информацию. Таким образом, можно представить, что каждый пользователь видит «свой» фрагмент данных, при этом данные могут иметь разное представление по длине, по виду отображения. Описание всех представлений пользователей дает общее описание внешнего уровня БД. Оно обычно представляется в виде технической документации (технического задания), описаний входных и выходных документов, в виде схем, рисунков, словесного описания.

Концептуальный уровень базы данных рассматриваемого примера может быть отображен в виде 2—х схем, получаемых последовательно. Первая схема — концептуальная информационно—логическая модель предметной области (ИЛМ), представляющая классы объектов (сущности) предметной области и связи между ними. Вторая схема — концептуальная даталогическая модель базы данных (ДЛМ), отображающая описание предметной области в виде логической структуры данных в терминах выбранной модели данных. Каждая из этих схем обобщает представление всех пользователей базы данных и описывает все данные, которые должны храниться в БД, какие связи между ними существуют. Схемы могут быть отображены на бумаге, либо в электронном формате и являются проектной документацией. Формируют концептуальный уровень проектировщики базы данных, администратор данных и администратор базы данных. Это особая категория пользователей базы данных — её разработчики. Представление концептуального уровня БД в виде ИЛМ и ДЛМ, либо только в виде ДЛМ, зависит от выбранного метода проектирования БД.

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

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

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

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