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

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

1. Предпроектная подготовка.
2. Проектирование БД.
3. Реализация (создание БД и ППО).

Проектирование начинается обычно с планирования, что позволяет:

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

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

• Аналитики. Это специалисты исследуемой предметной области, которые в идеале должны быть знакомы с основами создания баз данных. В их задачу входит постановка задачи проектирования: анализ ПО, выявление бизнес-процессов и бизнес-правил, определение требований к БД.
• Пользователи. Наличие этой категории работников особенно важно тогда, когда проект БД создаётся в развитие существующей информационной системы, т.к. в этом случае есть определённый опыт работы (традиции, привычки и вместе с тем пожелания). Всё это желательно учитывать для того, чтобы обеспечить преемственность и не вызвать негативного отношения к системе, например, из-за непривычного интерфейса.
• Проектировщики. Это сотрудники, которые будут заниматься собственно разработкой проекта БД.
• Администраторы. В том случае, если система небольшая, администратор БД может быть один. Если же система большая и территориально распределенная, то помимо АБД потребуется ещё администратор системы, и, возможно, не один. АБД должен появиться не тогда, когда система уже спроектирована, а на этапе проектирования БД. Это необходимо хотя бы потому, что при проектировании для отладки и тестирования обязательно создаётся рабочий прототип БД, и желательно, чтобы за общее обеспечение функционирования этого прототипа отвечал отдельный специалист.
• Разработчики программного обеспечения. Любая БД требует помимо СУБД создания некоторого прикладного программного обеспечения (ППО). Если сложность этого ППО невелика, то обычно его созданием занимаются сами проектировщики. В противном случае, необходимо набрать программистов (или выделить из имеющихся), которые будут этим заниматься.

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

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

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

1. Предварительный анализ ПО.

Включает в себя сбор документов, характеризующих ПО, укрупнённое описание ПО (не детализированное) и общую постановку задачи.

В процессе анализа и проектирования желательно ранжировать плани-руемые функции системы по степени важности. Один из возможных вариантов классификации – MoSCoW-анализ (терминология Клегга и Баркера, [8]):

Must have – необходимые функции;

Should have – желательные функции;

Could have – возможные функции;

Won't have – отсутствующие функции

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

Примечание: если применяются средства автоматизации проектирования (CASE-средства), то задачу последовательного внесения изменений берёт на себя это CASE-средство.

1. Рассмотрение и принятие результатов анализа.

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

Рис. 8.1. Жизненный цикл приложения баз данных

1. Определение критических факторов успеха.

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

1. Оценка системных ограничений.

В качестве часто встречающихся ограничений можно отметить следующие:

• финансовые
• временные
• технические (например, выбор определённой аппаратуры);
• программные (например, выбор определённого программного обеспечения);
1. Определение целевой архитектуры.

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

1. Определение требований к производительности.

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

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

1. Пакетный режим. Здесь требования к производительности обычно не такие жёсткие, как для интерактивного режима, и выражаются в минутах или часах, требующихся на получение конечного результата вычислений.
2. Режим реального времени. Этот режим является самым сложно реализуемым. В настоящее время (2009 г.) существует только одна СУБД, которая в полной мере отвечает требованиям режима реального времени: СУБД ЛИНТЕР – единственная СУБД отечественного производства (компания РЕЛЭКС, г. Воронеж).
1. Согласование стандартов проектирования, в частности:

• правил именования объектов;
• стандарта проектной документации;
• правил введения общих типов и т.п.
1. Выбор программных средств для проектирования и реализации системы (имеется в виду вспомогательные средства типа CASE и др.).

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

1. Информационно-логическое (инфологическое) проектирование
2. Определение требований к операционной обстановке, в которой будет функционировать информационная система.
3. Выбор СУБД и других инструментальных программных средств
4. Логическое проектирование БД. (Иногда этот этап называется даталогическим проектированием).
5. Физическое проектирование БД.

Эти этапы подробно рассмотрены в следующем разделе.

После того, как проект базы данных создан, наступает этап реализации проекта. Он разбивается на следующие шаги:

1. Создание прототипа БД и его отладка. Отладка подразумевает проверку правильности функционирования процедурных объектов БД (триггеры, процедуры, функции). Прототип позволяет определить жизнеспособность проекта БД и выявить его недостатки, что может потребовать внесения изменений в проект. Прототип также нужен как база для разработчиков приложений. Для этого БД наполняется реальными или тестовыми данными.
2. Разработка и отладка приложений. Выполняется разработчиками про-граммного обеспечения на основе функциональных требований, которые были выявлены на этапах I.2, I.3, и спецификации БД (схемы БД).
3. Конвертирование и загрузка данных в БД. Этот этап выполняется в том случае, если данные в БД загружаются из ранее существовавшей системы.
4. Тестирование работы базы данных и АИС в целом. Различают такие виды тестов, как:
• автономные – тесты отдельных модулей;
• тесты связей – тесты между модулями;
• регрессивные – тесты на проверку уже автономные – тесты отдельных модулей;
• протестированных модулей в связи с подключением новых модулей (функций), которые могут нарушить работу ранее созданных модулей;
• нагрузочные – тесты на проверку времени реакции системы в рабочем режиме или определение производительности системы;
• системные – тесты на проверку функционирования системы в целом;
• приёмо-сдаточные – тесты, которые проводятся при сдаче системы (АИС) в эксплуатацию.

На этапе III.4 обычно выполняются нагрузочные, системные и приёмо-сдаточные тесты.

1. Эксплуатация и сопровождение созданной АИС. Здесь можно выделить ряд задач:
• В процессе эксплуатации АИС может возникнуть необходимость внесе-ния изменений в систему. Это может быть вызвано изменениями пред-метной области, появлением новых задач или выявлением существенных недостатков в АИС. Нельзя забывать о том, что все вносимые изменения должны быть документированы.
• Необходимо выполнять резервное копирование данных, чтобы предот-вратить их потерю в случае серьёзного сбоя или ошибки пользователя.
• Сопровождение АИС обычно включает периодические проверки выполнения системных ограничений (на объём данных и время реакции системы). В результате этих проверок удаляются устаревшие данные (если не предусмотрено автоматическое архивирование данных). Улучшение показателей производительности системы может быть достигнуто за счёт настройки СУБД, которая выполняется администратором базы данных.

Теперь перейдём к более подробному обсуждению этапов проектирования БД.