В создании автоматизированной информационной системы, вклю-чающей базу данных, можно выделить три этапа:
- Предпроектная подготовка.
- Проектирование БД.
- Реализация (создание БД и ППО).
Проектирование начинается обычно с планирования, что позволяет:
- разбить задачу на небольшие, независимые, управляемые шаги;
- поставить краткосрочные и долговременные цели, которые служат для оценки фактических результатов проектирования и сравнения их с планом;
- определить временные зависимости между задачами, т.е. определить, какие задачи должны быть решены раньше других (составить сетевой план-график работ);
- выявить узкие места, т.е. ресурсы, от которых план зависит сильнее всего;
- спрогнозировать потребности в кадрах для проекта.
Работа по созданию БД начинается с подбора кадров. Требуется определить, какие специалисты необходимы для выполнения этой работы. В общем случае это должны быть следующие категории:
- Аналитики. Это специалисты исследуемой предметной области, которые в идеале должны быть знакомы с основами создания баз данных. В их задачу входит постановка задачи проектирования: анализ ПО, выявление бизнес-процессов и бизнес-правил, определение требований к БД.
- Пользователи. Наличие этой категории работников особенно важно тогда, когда проект БД создаётся в развитие существующей информационной системы, т.к. в этом случае есть определённый опыт работы (традиции, привычки и вместе с тем пожелания). Всё это желательно учитывать для того, чтобы обеспечить преемственность и не вызвать негативного отношения к системе, например, из-за непривычного интерфейса.
- Проектировщики. Это сотрудники, которые будут заниматься собственно разработкой проекта БД.
- Администраторы. В том случае, если система небольшая, администратор БД может быть один. Если же система большая и территориально распределенная, то помимо АБД потребуется ещё администратор системы, и, возможно, не один. АБД должен появиться не тогда, когда система уже спроектирована, а на этапе проектирования БД. Это необходимо хотя бы потому, что при проектировании для отладки и тестирования обязательно создаётся рабочий прототип БД, и желательно, чтобы за общее обеспечение функционирования этого прототипа отвечал отдельный специалист.
- Разработчики программного обеспечения. Любая БД требует помимо СУБД создания некоторого прикладного программного обеспечения (ППО). Если сложность этого ППО невелика, то обычно его созданием занимаются сами проектировщики. В противном случае, необходимо набрать программистов (или выделить из имеющихся), которые будут этим заниматься.
При определении потребности в кадрах может возникнуть ситуация, когда уже на этом этапе станет очевидна невозможность подбора нужного количества специалистов определённого профиля и квалификации. Тогда это может привести к пересмотру объёма задач, стоящих перед базой данных.
|
|
|
|
Общая схема жизненного цикла приложения баз данных приведена на рис. 8.1. Как видно из этого рисунка, проектирование носит итерационный характер. Например, если на каком-либо этапе выясняется, что ранее сформулированные требования или решения не могут быть реализованы, то разработчики должны вернуться на более ранний этап и внести соответствующие изменения. Эти изменения, естественно, могут потребовать корректировки ранее выполненных этапов.
Перечислим более подробно задачи, решение которых должно предшествовать созданию проекта БД.
- Предварительный анализ ПО.
Включает в себя сбор документов, характеризующих ПО, укрупнённое описание ПО (не детализированное) и общую постановку задачи.
В процессе анализа и проектирования желательно ранжировать плани-руемые функции системы по степени важности. Один из возможных вариантов классификации – MoSCoW-анализ (терминология Клегга и Баркера, [8]):
Must have – необходимые функции;
Should have – желательные функции;
Could have – возможные функции;
Won't have – отсутствующие функции
Необходимые функции обеспечивают возможности, которые являются критическими для успешной работы системы. Реализация желательных и возможных функций системы ограничена временными и/или финансовыми рамками. Отсутствующие функции – это те функции, которые реально существуют, но не будут реализованы в этом проекте по различным причинам.
Примечание: если применяются средства автоматизации проектирования (CASE-средства), то задачу последовательного внесения изменений берёт на себя это CASE-средство.
- Рассмотрение и принятие результатов анализа.
Эта задача обычно решается итеративно во взаимодействии проектировщиков и заказчиков (или аналитиков). На этом этапе очень важно определить, что проектировщики правильно понимают описание предметной области и задачи, поставленные перед ними аналитиками. Для этого обычно проводятся совместные семинары, на которых проверяется адекватность модели и предметной области.
Рис. 8.1. Жизненный цикл приложения баз данных
- Определение критических факторов успеха.
В данном случае под термином критические факторы подразумеваются как "жизненно важные для приёмки и успешной реализации проекта", так и "критические с точки зрения функционирования системы". Очевидно, что если не учесть хотя бы один из таких факторов, то существование и успешное функционирование проекта будет поставлено под вопрос.
- Оценка системных ограничений.
В качестве часто встречающихся ограничений можно отметить следующие:
- финансовые
- временные
- технические (например, выбор определённой аппаратуры);
- программные (например, выбор определённого программного обеспечения);
- Определение целевой архитектуры.
Под целевой архитектурой в данном случае понимается архитектура с точки зрения СУБД (однозадачная или многозадачная, архитектура клиент-сервер, параллельный сервер). Выбор архитектуры повлияет в дальнейшем на перечень требуемых аппаратных и программных средств.
- Определение требований к производительности.
Необходимо примерно оценить количество транзакций в единицу времени и объём обрабатываемых этими транзакциями данных. Требования к производительности зависят от режима, в котором будет функционировать система:
a. Интерактивный режим. Для этого режима устанавливается время, в течение которого пользователь должен получить ответ на свой запрос. Обычно время реакции системы не должно превышать нескольких секунд.
|
|
- Пакетный режим. Здесь требования к производительности обычно не такие жёсткие, как для интерактивного режима, и выражаются в минутах или часах, требующихся на получение конечного результата вычислений.
- Режим реального времени. Этот режим является самым сложно реализуемым. В настоящее время (2009 г.) существует только одна СУБД, которая в полной мере отвечает требованиям режима реального времени: СУБД ЛИНТЕР – единственная СУБД отечественного производства (компания РЕЛЭКС, г. Воронеж).
- Согласование стандартов проектирования, в частности:
- правил именования объектов;
- стандарта проектной документации;
- правил введения общих типов и т.п.
- Выбор программных средств для проектирования и реализации системы (имеется в виду вспомогательные средства типа CASE и др.).
Собственно процесс проектирования БД включает в себя следующие основные этапы:
- Информационно-логическое (инфологическое) проектирование
- Определение требований к операционной обстановке, в которой будет функционировать информационная система.
- Выбор СУБД и других инструментальных программных средств
- Логическое проектирование БД. (Иногда этот этап называется даталогическим проектированием).
- Физическое проектирование БД.
Эти этапы подробно рассмотрены в следующем разделе.
После того, как проект базы данных создан, наступает этап реализации проекта. Он разбивается на следующие шаги:
- Создание прототипа БД и его отладка. Отладка подразумевает проверку правильности функционирования процедурных объектов БД (триггеры, процедуры, функции). Прототип позволяет определить жизнеспособность проекта БД и выявить его недостатки, что может потребовать внесения изменений в проект. Прототип также нужен как база для разработчиков приложений. Для этого БД наполняется реальными или тестовыми данными.
- Разработка и отладка приложений. Выполняется разработчиками про-граммного обеспечения на основе функциональных требований, которые были выявлены на этапах I.2, I.3, и спецификации БД (схемы БД).
- Конвертирование и загрузка данных в БД. Этот этап выполняется в том случае, если данные в БД загружаются из ранее существовавшей системы.
- Тестирование работы базы данных и АИС в целом. Различают такие виды тестов, как:
- автономные – тесты отдельных модулей;
- тесты связей – тесты между модулями;
- регрессивные – тесты на проверку уже автономные – тесты отдельных модулей;
- протестированных модулей в связи с подключением новых модулей (функций), которые могут нарушить работу ранее созданных модулей;
- нагрузочные – тесты на проверку времени реакции системы в рабочем режиме или определение производительности системы;
- системные – тесты на проверку функционирования системы в целом;
- приёмо-сдаточные – тесты, которые проводятся при сдаче системы (АИС) в эксплуатацию.
На этапе III.4 обычно выполняются нагрузочные, системные и приёмо-сдаточные тесты.
|
|
- Эксплуатация и сопровождение созданной АИС. Здесь можно выделить ряд задач:
- В процессе эксплуатации АИС может возникнуть необходимость внесе-ния изменений в систему. Это может быть вызвано изменениями пред-метной области, появлением новых задач или выявлением существенных недостатков в АИС. Нельзя забывать о том, что все вносимые изменения должны быть документированы.
- Необходимо выполнять резервное копирование данных, чтобы предот-вратить их потерю в случае серьёзного сбоя или ошибки пользователя.
- Сопровождение АИС обычно включает периодические проверки выполнения системных ограничений (на объём данных и время реакции системы). В результате этих проверок удаляются устаревшие данные (если не предусмотрено автоматическое архивирование данных). Улучшение показателей производительности системы может быть достигнуто за счёт настройки СУБД, которая выполняется администратором базы данных.
Теперь перейдём к более подробному обсуждению этапов проектирования БД.