Модуль 'Управление проектами'

Для начала сформулируем общие требования к базе данных в неформальной (содержательной) форме. Т.е. опишем базу данных с точки зрения пользователя. Ниже приведен список сущностей и их атрибутов.

Проекты:

• Код проекта - текстовая строка;

• Название - текстовая строка;

• Состояние (планируемый, текущий, завершенный);

• Описание проекта - текстовый комментарий к проекту;

• Плановая стоимость проекта (лимит финансовых затрат);

• Фактические затраты на проект;

• Плановый срок начала работ по проекту;

• Фактический срок начала работ по проекту;

• Плановый срок завершения работ по проекту;

• Фактический срок завершения работ по проекту;

• Этапы проекта;

• Список сотрудников, занятых в проекте (исполнители);

• Список материальных ресурсов, необходимых для реализации проекта.

Этапы проекта:

• Код этапа - текстовая строка;

• Название - текстовая строка;

• Состояние (планируемый, текущий, завершенный);

• Содержание этапа - текстовое описание этапа;

• Плановая стоимость этапа (лимит финансовых затрат);

• Фактические затраты на этап;

• Плановый срок начала работ по этапу;

• Фактический срок начала работ по этапу;

• Плановый срок завершения работ по этапу;

• Фактический срок завершения работ по этапу;

• Подэтапы этапа;

• Список исполнителей этапа;

• Список материальных ресурсов, необходимых для реализации этапа.

Исполнители:

• ФИО;

• Должность;

• Подразделение;

• Плановый объем работы в человекоднях.

• Фактически выполненный объем работы в человекоднях.

Материалы:

• Наименование;

• Запланированное количество;

• Фактически израсходованное количество;

• Единица измерения.

В соответствии с правилами нормализации:

• "Проект" и "Этап проекта" - "Список исполнителей этапа" выносится в отдельную таблицу, связь M:N. Каждый этап может иметь нескольких исполнителей. Каждый исполнитель может участвовать в реализации нескольких этапов. Поскольку все данные об исполнителе сводятся к одному полю NRec (см. ниже), а остальные поля (плановый и фактический объемы работ) уникальны для каждого этапа, связь сводится к виду 1:N. Т.е. каждый этап может иметь нескольких исполнителей. Данные об исполнителе (NRec) дублируются.

• "Проект" и "Этап проекта" - "Список материальных ресурсов, необходимых для реализации этапа" выносится в отдельную таблицу, связь M:N. При реализации этапа может потребоваться несколько наименований материальных ресурсов. И наоборот, каждый материальный ресурс может потребоваться при реализации разнличных этапов. Поскольку все данные о материале сводятся к одному полю NRec (см. ниже), а остальные поля (плановое и фактическое количество) уникальны для каждого этапа, связь сводится к виду 1:N. Т.е. каждый этап может иметь несколько материальных ресурсов. Данные об материале (NRec) дублируются.

При переходе от общих требований к описанию таблиц и полей необходимо учесть следующее:

• Данные об исполнителях поставляются модулем "Управление персоналом". Соответственно, ФИО, Должность и Подразделение заменяются ссылкой (NRec) на сведения об исполнителе.

• Данные о материальных ресурсах поставляются модулем "Управление снабжением". Соответственно, Наименование и Единица измерения заменяются ссылкой (NRec) на сведения о материальном ресурсе.

• Возможные значения атрибута "Состояние" сущностей "Проект" и "Этап проекта" фиксированы. Поэтому в таблице будет запоминаться односимвольный код состояния.

• Атрибуты "Список сотрудников, занятых в проекте (исполнители)" и "Список материальных ресурсов, необходимых для реализации проекта" получаются объединением соответствующих атрибутов по всем этапам данного проекта. Кроме того, обычно возникает необходимость запланировать работу или материал на проект в целом, не относя их на конкретный этап (накладные расходы). Поэтому будем считать, что указанные атрибуты сущностей "Проект" и "Этап проекта" содержат данные о сотрудниках и материалах относящихся непосредственно к этапу или проекту в целом. Полная потребность получается объединением соответствующих атрибутов по всему поддереву.

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

• Для разделения первичных и расчетных данных в таблицах "Список исполнителей" и "Список материальных ресурсов" необходимо ввести специальный признак. С практической точки зрения этот признак удобно разбить на 2 значения: "первичные данные" и "итого по этапу /проекту".

• Поскольку таблицы "Список исполнителей" и "Список материальных ресурсов" будет цепляться как к этапам, так и к проектам, целесообразно объединить таблицы "Проекты" и "Этапы проекта" в одну. Тем более, что по составу полей они практически совпадают. В этом случае уменьшается количество проверок и переключений при подцепке и при обработке таблиц. Таблица связана сама с собой по связи вида 1:N.

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

На последующих стадиях проектирования в результате анализа бизнес-объектов (см. "Объектный интерфейс ресурса проекта. ") было решено выделить таблицы "Список исполнителей" и "Список материальных ресурсов" в отдельный компонент "Ядро приложения" (см. "Компонент "Ядро приложения". ").

С учетом всего вышесказанного описание словаря БД "Управление проектами" принимает вид, приведенный в разделе "Таблицы модуля "Управление проектами". ".