Вопросы для самоконтроля.
Расскажите о трехуровневой архитектуре ANSI/SPARC.
Какова цель введения трехуровневой архитектуры?
Каковы причины введения трехуровневой архитектуры?
Дайте определения основных уровней в трехуровневой архитектуре.
Какие виды независимости обеспечивает введение трехуровневой архитектуры? Расскажите об этих видах.
Почему современная модель трехуровневой архитектуры отличается от модели ANSI/SPARC?
Дайте определения инфологической, даталогической и физической моделей проектирования базы данных. Каким уровням проектирования соответствуют эти модели?
Какие базы данных являются фактографическими, а какие документальными?
Тема 6. Жизненный цикл баз данных.
БД является фундаментальным компонентом более широкого понятия - информационной системы (ИС). Следовательно, жизненный цикл приложений БД неразрывно связан с жизненным циклом ИС. Этапы жизненного цикла БД показаны на рис. 6.1.
рис. 6.1. Жизненный цикл БД.
Рассмотрим основные действия, выполняемые на каждом этапе жизненного цикла:
Планирование разработки БД. Этап разработки начинается с маркетинга, т.е. исследования рынка программного обеспечения, поиска аналогов, выяснения потребности в БД.
Планирование разработки БД состоит в определении трех основных компонентов:
требуемого объема работы;
необходимых ресурсов;
общей стоимости проекта.
Для поддержки планирования разработки БД может быть создана корпоративная модель данных, отображающая наиболее важные данные и связи между ними (т.е. сущности и связи предметной области), а также их отношение к различным функциональным сферам предметной области. Обычно корпоративная модель данных имеет вид ER-диаграммы.
Планирование разработки БД также должно включать разработку стандартов, которые определяют, как будет осуществляться сбор данных, каким будет их формат, какая потребуется документация, и как будет выполняться проектирование и реализация приложений.
Определение требований к системе. Определение диапазона действия и границ приложения БД, состав его пользователей и областей применения.
Сбор и анализ требований пользователей.
Необходимая для проектирования БД информация может быть собрана следующими способами:
посредством опроса отдельных пользователей предметной области;
с помощью наблюдений за деятельностью предметной области;
посредством изучения документов, которые используются для сбора или представления информации;
с помощью анкет, предназначенных для сбора информации у широкого круга пользователей;
за счет использования опыта проектирования других подобных систем.
Сбор и анализ требований является предварительным этапом концептуального проектирования БД, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых подробностей.
Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Эта цель достигается с помощью методов составления спецификаций требований, к числу которых относятся:
технология структурного анализа и проектирования (Structured Analysis and Design – SAD);
диаграммы потоков данных (Data Flow Diagrams – DFD);
графики «вход – процесс – выход» (Hierarchical Input Process Output – HIPO).
Проектирование БД. Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД.
Существует два основных подхода к проектированию систем БД: «нисходящий» и «восходящий». При восходящем подходе работа начинается с самого нижнего уровня – уровня определения атрибутов (т.е. свойств сущностей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними. Восходящий подход лучше всего подходит для проектирования простых БД с относительно небольшим количеством атрибутов. Однако использование этого подхода существенно усложняется при проектировании БД с большим количеством атрибутов, установить среди которых все существующие функциональные зависимости довольно затруднительно.
Более подходящей стратегией проектирования сложных БД является использование нисходящего подхода. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Нисходящий подход демонстрируется в концепции модели «сущность – связь». В этом случае работа начинается с идентификации сущностей и связей между ними, интересующих пользователей в наибольшей степени.
Выбор целевой СУБД (необязательно). На этом этапе выполняется выбор наиболее подходящей СУБД для приложения БД.
Разработка приложений. Определение пользовательского интерфейса и прикладных программ, которые используют и обрабатывают БД.
В жизненном цикле системы проектирование БД и приложений выполняется параллельно. В большинстве случаев проектирование приложений нельзя завершить до окончания проектирования БД. С другой стороны, БД предназначена для поддержки приложений, а потому между фазами проектирования БД и проектирования приложений для этой БД должен постоянно происходить обмен информацией.
На этом этапе следует также разработать соответствующий пользовательский интерфейс приложений БД. Этот интерфейс должен предоставлять необходимую пользователю информацию самым удобным для него образом. Пользовательские интерфейсы являются одним из важнейших компонентов системы.
Реализация. Реализация БД начинается с ее распространения для коммерческих и свободных продуктов или внедрения для собственных разработок и заказных программ. В обоих случаях различают БД, которые не требуют вмешательства специалиста для начала эксплуатации, и БД, нуждающиеся в начальной настройке. Внедрение БД обычно производится с участием разработчиков.
Конвертирование и загрузка данных. Перенос любых существующих данных в новую БД и модификация любых существующих приложений с целью организации совместной работы с новой БД (выполняется в том случае, если новая БД заменяет старую).
Тестирование. Приложение БД тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями.
Сбор статистических данных на стадии тестирования позволяет установить показатели надежности и качества созданного программного обеспечения.
Пользователи должны быть вовлечены в процесс тестирования. По завершении тестирования процесс создания прикладной системы считается законченным, и она может быть передана пользователям в промышленную эксплуатацию.
Эксплуатация и сопровождение. На этом этапе приложение БД считается полностью разработанным и реализованным. Впредь вся система будет находиться под постоянным наблюдением и соответствующим образом поддерживаться. В случае необходимости в функционирующее приложение могут вноситься изменения, отвечающие новым требованиям. Реализация этих изменений проводится посредством повторного выполнения некоторых из перечисленных выше этапов жизненного цикла.
Жизненный цикл БД заканчивается вместе с прекращением ее распространения и сопровождения. Обычно это происходит при моральном устаревании БД.
БД всегда сопровождается документацией, которая содержит следующую информацию:
характеристика БД (условия предоставления услуг, характер обработки информации, форма собственности, степень доступности, форма представления информации, тип используемой модели данных, характер организации хранения данных, а также предметная область, автор, версия и др.);
руководство программиста - описание способов настройки БД для решения конкретных задач (в некоторых случаях может отсутствовать);
руководство пользователя - описание интерфейса пользователя, возможностей БД и процесса ее установки, способов разрешения конфликтных ситуаций.
Обычно документация представляется в бумажной форме или в электронном виде на компакт-диске. Часть документации дублируется во встроенной в программу справочной системе.
Естественно, наиболее значительным фактором в жизненном цикле приложения, работающего с БД, является стадия проектирования. От того, насколько тщательно продумана структура БД, насколько четко определены связи между ее элементами, зависит производительность системы и ее информационная насыщенность, а значит - и время ее жизни.