Многоуровневая архитектура СУБД.

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

Рисунок - нормализованная схема предметной области. КМ - ЛМ - ФМ (в квадратах каждые), от ЛМ идут ВМ1, ..., ВМN.

От КМ идут КТ1, ..., KTN. От ФМ - БД. Всё в прямоугольниках, а БД - в овале xD.

КТ i — это концептуальные требования i-го пользователя и/или приложения, описывающие обычно неформально на естественном языке (ЕЯ) необходимые ему данные.

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

●имя

●состав атрибутов (реквизитов, характеристик, полей)

●связи с другими объектами с указанием тех задач и документов, где эти связи надо учитывать

Для этого от заказчика желательно получить дополнительно копии всех отчётных документов: как входных, так и выходных и промежуточных. Для каждого атрибута желательно указать домен допустимых значений, ограничение целостности (условие на эти значения), а также тип соответствия с другими атрибутами (1:1, 1:М, М:1, М:М).

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

Интеграция — это не просто объединение, а такое совместное взаимосвязанное описание данных, которое устраняет имеющиеся в разных КТi несоответствия и противоречия.

Чаще всего на практике одну и ту же характеристику либо называют по-разному, либо наоборот разные вещи называют одинаково. При объединении требований необходимо провести их анализ и хранить в концептуальной модели только такие атрибуты, которые являются атрибутами-основаниями, а все остальные сделать виртуальными.

Например, какое-то КТ требует, чтобы в БД хранили возраст. Очевидно, что нужно хранить дату рождения, а какой-то виртуальный атрибут будет показывать вычисленный возраст.

ЛМ (логическая модель) — это совместимый с конкретным типом СУБД вид концептуальной модели. Иными словами это концептуальная модель, записанная на языке описания данных конкретной СУБД.

ВМ — внешние модели (представления), соответствующие КТ требованиям, но записанные в нотации конкретной СУБД.

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

ФМ— физическая модель— описание данных на физическом уровне, то есть допустимые структуры хранения, методы доступа (последовательный, индексно-последовательный, прямой), способы индексации.

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

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

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

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

Физическая независимость данных означает, что изменение на физическом уровне (структуры хранения данных, методы доступа, способы индексации) не приводит ни к изменениям на логическом уровне, ни на внешнем.

Например, в FoxFox при переходе от DOS версий в шапку dbf файла добавилась ссылка на dbc , что не привело к необходимости внесения изменений в приложения.

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

Кроме того, сами разработчики СУБД при внесении изменений физической организации данных переписывают программный код в СУБД лишь на одном уровне (ЛМ – ФМ)

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