Лекция Трёхуровневая архитектура СУБД

« Назад

1. Архитектура базы данных. Физическая и логическая независимость

Терминология в СУБД, да и сами термины «база данных» и «банк данных» частично заимствованы из финансовой деятельности. Это заимствование — не случайно и объясняется тем, что работа с информацией и pa6oтa с денежными массами во многом схожи, поскольку и там и там отсутствует персонификация объекта обработки: две банкноты достоинством в сто рублей столь же неотличимы и взаимозаменяемы, как два одинаковых байта (естественно, за исключением серийных номеров).

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 2.1.

1978 год – появился стандарт, который принял коммитет ANSI/SPARC, который фиксирует разделение между логическим и физическим представлением данных. В часности, была предложена 3-х уровневая модель данных, т.е. обобщенная структура.

Рис. 1 - Трехуровневая модель системы управления базой данных, предложенная ANSI

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

2. Концептуальный уровень — центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

Обычно, сперва разрабатывают концептуальный уровень. Затем – как видит его пользователь. После этого уже внутренний.

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

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

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

Внешний уровень – определяет пользовательские представления данных.

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

Главное назначение трёхуровневой архитектуры – это обеспечение независимости от данных (внутеннего образа хранение от отображения). Независимость от данных бывает 2-х типов:

- логическая – это полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;

- физическая – это защищенность концептуальной схемы, от изменений, которые вносятся во внутреннюю схему.

2. Этапы жизненного цикла СУБД

Рис. 2 - Жизненный цикл баз данных

Последовательность задач, которые необходимо рассмотреть на первом этапе.

(План выполнения работ)

- Сформулировать перечень вопросов, которые будут решены при испльзовании новой ИС.

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

- Выбрать ИС, которая будет разрабатываться (обосновать с учетом предыдущих пунктов).

После этого уже можно выполнять этап проектирование.

1) Проектирование

2) Реализация

3) Тестирование

4) Эксплуатация

В часности, это –– водопадный подход.

Основные действия, выполняемые на каждом этапе жизненного цикла СУБД:

1) Планирование разработки БД. На этом этапе рассматривают самые эффективные методики.

2) Определение требований к системе. Диапазон действия БД, состав пользователей, области применения.

3) Сбор и анализ требований пользователей.

4) Проектирование БД. Проведение концептуального, логического и физического проектирование БД.

5) Реализация БД. Создание структуры данных, интерфейса пользователя и т.д., т.е. ПО.

6) Тестирование.

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

8) Эксплуатация и сопровождение. Для всех БД актуален. Администрирование. Доработка концептуальной схемы.

2.1. Жизненный цикл базы данных

ЖЦБД включает в себя следующие основные этапы:

- планирование разработки базы данных;

- определение требований к системе;

- сбор и анализ требований пользователей;

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

- разработка приложений (проектирование транзакций; проектирование пользовательского интерфейса);

- реализация;

- загрузка данных;

- тестирование;

- эксплуатация и сопровождение (а: анализ функционирования и поддержка исходного кода БД, б: адаптация, модернизация и поддержка переработанных вариантов).

Здесь представлен перечень основных этапов ЖЦБД. Естественно, что конкретное наполнение каждого этапа в значительной степени зависит от сложности разрабатваемого продукта.

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

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

2.2. Планирование разработки базы данных

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

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

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

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

Вторая часть – проверка операционной осуществимости — выяснение наличия экспертов и персонала, необходимых для работы БД.

Третья часть — проверка экономической целесообразности осуществления проекта. При исследовании этой проблемы весьма важно дать оценку ряду факторов, в том числе и таким:

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

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

- ожидаемая выгода от внедрения подлежащих созданию приложений;

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

- влияние системы управления БД на реализацию долговременных планов организации.

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

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

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

2.3. Определение требований к системе

На данном этапе необходимо определить диапазон действия приложения базы данных, состав его пользователей и области применения.

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

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

2.4. Сбор и анализ требований пользователей

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

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

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

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

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

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

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

2.5. Проектирование базы данных

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

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

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

- создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

- разработка предварительного варианта проекта, структура которого позволяет удовлетворить требования, предъявляемые к производительности системы.

В создании БД как модели ПрО (предметной области) выделяют:

- объектную (предметную) систему, представляющую фрагмент реального мира;

- информационную систему, описывающую некоторую объектную систему;

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

Оптимальная модель данных должна удовлетворять таким критериям, как: структурная достоверность, простота, выразительность, отсутствие избыточности, расширяемость, целостность, способность к совместному использованию.

2.6. Концептуальное проектирование базы данных

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

Существует два основных подхода к проектированию систем баз данных: "нисходящий" и "восходящий".

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

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

Нисходящий подход демонстрируется в концепции модели "сущность-связь" (Entity - Relationship model – ER-модель) - cамой популярной технологии высокоуровнего моделирования данных, предложенной Ченом.

Модель «сущность-связь» относится к семантическим моделям. Семантическое моделирование данных, связанное со смысловым содержанием данных, независимо от их представления в ЭВМ, изначально возникло с целью повышения эффективности и точности проектирования баз данных Методы семантического моделирования оказались применимы ко многим пользовательским проблемам и легко преобразуемы в сетевые, иерархические иреляционные модели.

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

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

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

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

- Выделение ключевых атрибутов.

- Спецификация связей между объектами. Удаление избыточных связей.

- Анализ и добавление не ключевых атрибутов.

- Объединение локальных представлений.

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

2.7. Логическое проектирование базы данных

Цель второй фазы проектирования базы данных состоит в создании логической модели данных.

3. Особенности проектирования СУБД и модели данных

При разработке БД необходимо решить вопрос размещения информации по отношениям. Информацию надо размещать таким образом, что бы были выполнены такие цели:

1) Обеспечение быстрого доступа к данным. Обычно этот вопрос решают окончательно уже ближе к концу, на этапе проектирования и тестирования.

2) Исключение ненужного повторения данных, которое может явится причиной ошибок при вводе.

3) Обеспечение целостности данных таким образом, что бы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ним объектом.

Можно выделить 2 подхода к проектированию реляционной БД (основаны на нисходящем и восходящем подходах).

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

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

4. Избыточность данных в БД

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

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

Пример:

Номер зачетной книжки	Фамилия	Код группы	ФИО старосты	Куратор
201	Иванов	Т-11	Рябов	Доц. Фок
215	Петров	Т-12	Сизов	Доц. Дюкин
217	Рябов	Т-11	Рябов	Доц. Фок
211	Сенова	Т-11	Рябов	Доц. Фок

Первичный ключ – «Номер зачетной книжки»

При использовании универсального отношения возникают две проблемы:

- избыточность данных;

- потенциальная противоречивость (аномалии).

Повторяются в кортежах сведения о коде группы, ФИО старосты и Кураторе. На практике это означает, что данное отношение надо разбить (декомпозировать) на 2 отношения. При вводе информации можно сделать ошибку, например, при вводе ФИО старосты.

5. Аномалии обновления в БД

Различают 3 вида аномалий в БД:

1) Аномальные включения;

2) Аномальные удаления;

3) Аномальные модификации.

5.1. Аномальное включение

Пример:

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

1. Добавлено нового студента, для этого нужно повторить «ФИО старосты» и «Куратора», которые уже присутствуют в отношении.

2. Необходимо добавить новую группу, в которую студенты ещё не приняты. Тогда первичный ключ кортежа – «Номер зачетной книжки» = NULL.

В обоих случаях целесообразно провески декомпозицию отношения «Студент». Тогда получим:

«Студент2»

Номер зачетной книжки	Фамилия	Код группы
201	Иванов	Т-11
215	Петров	Т-12
217	Рябов	Т-11
211	Сенова	Т-11
…	…	…
220	Ушаков	NULL

«Группы»

Код группы	ФИО старосты	Куратор
Т-11	Рябов	Доц. Фок
Т-12	Сизов	Доц. Дюкин
…	…	…
Т-13	NULL	NULL

5.2. Аномалии удаления

Примером аномалии удаления может быть случай, когда из отношения «Студент» необходимо удалить 2-й кортеж:

215

Петров

Т-12

Сизов

Доц. Дюкин

Вместе с этим удалятся все сведения о группе. Решением этой проблеммы будет опять-таки декомпозиция.

5.3. Аномалии модификации

Это замена одних данных кортежа другими.

Пример: если заменить старосту гр.Т-11 Рябова на Семову, то придётся менять данный в 3-х кортежах о старостах.