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

 

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

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

· концептуальный,

· логический,

· физический.

Эта классификация предложена рабочей группой CODASYL в 1971 году и официально признана комитетом ANSI/SPARC в 1978 году.

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

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

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

Такие описания называют подсхемами (ПС) предметной области, из них компонуется полная концептуальная схема ПрО.

Логический и физический уровни являются внутренними.

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

ними в виде представления данных и отношений между ними в БД.

Сово­купность всех пользовательских представлений данных является логиче­ским уровнем описания БД. Этот уровень может поддерживаться машиной, но не всегда выделен явно, тогда получается двухуровневая архитектура БД.

Физический уровень указывает на физическое представление данных в машине – используемые дисководы, винчестеры, буферную

Рис. 1.2. Трёхуровневая архитектура БД память, физиче­ские адреса,

индексы, указатели и т.д. Этот уровень обеспечивается проекти­ровщиками физической БД, которые

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

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

Жизненный цикл БД

 

Главная составляющая в жизненном цикле БД. - это единство базы дан­ных и программ, необходимых для ее работы. Жизненный цикл содержит три основных этапа: анализ и проектирование БД, её реализацию и поддержку функционирующей БД.

Эти этапы включают в себя подэтапы:

1. Анализ и проектирование БД.

1.1.Формулирование задачи и анализ требований.

1.2.Концептуальное проектирование.

1.3.Проектирование реализации

2. Реализация БД.

2.1.Собственно реализация.

2.2.Физическое проектирование.

2.3.Тестирование.

3. Поддержка.

3.1.Анализ функционирования и поддержка исходного варианта БД.

3.2. Адаптация, модернизация и поддержка переработанных вариантов.

 

ЛЕКЦИЯ 4

ТЕМА: АНАЛИЗ И ПРОЕКТИРОВАНИЕ.

ПЛАН

1 Формулирование задачи и анализ требований

2 Инфологическое проектирование

3 Концептуальное проектирование

4. Моделирование локальной ПрО

5 Составные объекты

1 Формулирование задачи и анализ требований

 

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

Важной частью разработки стратегического плана является провер­ка осуществимости проекта и определение требований к нему.

Проверка осуществимости состоит из трёх частей:

1.Проверка технологической осуществимости состоит в выяснении вопроса, существует ли оборудование и программное обеспечение для реализации проекта, какие ресурсы имеются в наличии и что нужно (и можно ли) приобрести.

2. Проверка операционной осуществимости, т.е. наличия экспертов и персонала, необходимых для работы БДих квалификации и опыта, необходимость дополнительного обучения как пользователей, так и системного персонала. Администратор базы данных обычно выбирается и обучается из системного персонала.

3.Проверка экономической целесообразности реализации проекта, при которой даётся оценка следующим факторам:

• целесообразность совместного использования данных разными отделами организации-заказчика (пользователями);

• величина риска, связанного с реализацией системы базы данных;

• ожидаемая выгода от внедрения приложений БД;

• время окупаемости внедренной БД;

• влияние СУБДна реализацию долговременных планов организации-заказчика.

Явные издержки создания СУБДскладываются из за­трат на оборудование, программное обеспечения и про­граммирование.

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

Если результат проверки осуществимости проекта положителен, определяют требования к проекту.

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

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

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

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

Результаты работы на этом этапе должны решать четыре задачи:

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

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

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

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