Григорьев Ю.А., Ревунков Г.И. Банки данных - файл n1.doc

приобрести
Григорьев Ю.А., Ревунков Г.И. Банки данных
скачать (17866.6 kb.)
Доступные файлы (1):
n1.doc19450kb.28.01.2005 10:46скачать

n1.doc

1   ...   4   5   6   7   8   9   10   11   ...   62

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



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

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

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

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

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

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

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

ВМД  КМД  ВнМД  ФБД.
1   ...   4   5   6   7   8   9   10   11   ...   62


1.4. Архитектура банка данных
Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации