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

Инициализация передачи

данных и их редактирование

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

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

Словарь данных – это специальная система в банке данных, которая предназначена для хранения единообразной централизованной информации обо всех ресурсах конкретного банка данных.

В словаре содержатся следующие сведения:

- об объектах, их свойствах и отношениях для конкретной предметной области;

- о данных, хранимых в базе: наименование, структура этих данных;

- коды защиты данных;

- источники информации и т.д.

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

Администратор базы данных – это лицо или группа лиц, которые реализуют управление базой данных. Если рассматривать банк данных как систему управления, то в качестве объекта управления выступает база данных, а в качестве управляющего органа – группа специалистов. Поэтому банк данных рассматривают как автоматизированную систему.

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

Современные банки данных имеют 3-х уровневую архитектуру. Покажем ее на рисунке.

пользователь

П1

П2

Пn

Комплекс системных программ

ПП1

ПП2

ППn

РО

РО

РО

Внешний уровень

ВМД1

ВМД2

ВМДn

Концептуальный уровень

КМД

Внутренний уровень

ВнМД

ПП₁…, ПП₂ - прикладная программа

РО – рабочая область

ВМД- внешняя модель данных

КМД – концептуальная модель данных

ВнМД – внутренняя модель данных

ФБД – физическая база данных

Рассмотрим модели данных.

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

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

КМД – это уровень глобального логического представления информационного содержания базы данных. КМД имеет свою схему.

Таким образом, в 3-х уровневой архитектуре банка данных СУБД реализует следующее отображение:

ВМД→КМД→ВнМД→ФБД

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

Выводы:

1) 3-х уровневый подход к построению банков данных, включающий внешний, концептуальный и внутренний уровни, получил наибольшее распространение.

2) При таком подходе на внешнем уровне поддерживается модель предметной области для всех приложений. При этом форма соблюдается удобная для каждого пользователя. На концептуальной уровне поддерживается модель предметной области общая для всех приложений. На внутреннем уровне хранятся данные модели предметной области для всех приложений.

3) При такой архитектуре банк данных обладает высокой способностью адаптации к возможным изменениям не только в приложениях, но и в самих данных. Это обеспечивается изолированностью внешних и внутренних моделей данных. В основе такой изолированности лежит КМД. Схема КМД стабильна и поэтому может обеспечить долговременную работу всей системы.

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

Рассмотрим этапы проектирования баз данных.

Процесс проектирования баз данных представляет собой сложный процесс проектирования отображения:

Описание предметной области

Схема ВнМД

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

1) Описание предметной области будущей базы данных.

а) Получение и анализ концептуальных требований пользователей.

б) Формализация и стандартизация этих требований.

в) Построение инфологической модели.

2) Выбор СУБД.

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

б) Выбор конкретных СУБД (СУБД претендентов), окончательный выбор СУБД.

3) Логический этап проектирования.

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

б) Разработка концептуальной схемы внешних моделей данных с учетом выбираемой СУБД.

4) Проектирование физической модели.

Производится выбор рациональной структуры хранения данных и методы доступа к этим данным.

Дата добавления: 2014-01-20