Добрый вечер!

Мне нужно создать базу данных для программы управления проектом.
Project - общее описание всех проектов,
Tasks - описание иерархической последовательности выполнения псевдо задач (групп задач) проекта,
ProjectTasks - разделение каждой псевдо задачи на модели, происходит фиксация плановых сроков и стоимости, а так же фактических сроков и стоимости,
ProjectProcedure - задания входящие в модели псевдо задач, эти задачи выпорлняются исполнителями, происходит их планирование,
PlannedProjectTasks, PlannedProjectProcedure - история планирования псевдо задач и задая соответственно.

Вопросы:
Правильно я поступая, делая в каждой таблице один уникальный индефикатор, т.е. у меня получается так, что чтобы узнать название проекта по задаче нужно будет последовательно осуществить поиск по таблицам (ProjectProcedure -> ProjectTasks->Tasks)?
не делаю многосоставной ключ из-за того что тогда не получится связать ProjectTasks с PlannedProjectTasks и ProjectProcedure с PlannedProjectProcedure, или может быть лучше отказаться этого ограничения целостности и сделать везде многосоставной ключ?

Заранее спасибо!

С уважением,
Kosteles

База данных будет большой, где-то по 500 записей в таб. Tasks, по 1500 в таб.ProjectTasks, по 6000 в ProjectProcedure В ГОД. Вот из-за этого и сомнения о правильности такой схемы данных...

Работа будет в основном с таблицами Project, Tasks, ProjectTasks и ProjectProcedure... Эти таблицы будут использоваться для контроля текущего состояния, будет постоянные обновления в клименте данных....

Пользоваться обратным ходом по иерархие придется где-то в 5 раз меньше. Для сбора статистики, анализ проенктов...

С уважением,
From Kosteles

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

Вроде так нормально дублировать, или лучше текущие искать в таблицах истоии?

С уважением,
Kosteles

Bely
По теории - это не правильно, но часто так делается для практики.
Интересно, а как по теории подобную иерархию отображают?
и в чем будет проигрышь по теории? по скорости?

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

С уважением,
Kosteles

а может быть будет лучше, если я объеденю похожие таблицы;
можно объединить:
1) PlannedProjectProcedure и PlannedProjectTasks
2) ProjectProcedure и ProjectTasks

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

С уважением,
Kosteles

Переделал схему данных. Хотелось бы узнать мнение на счет новой схемы. Стоит ли так делать? Какой вариант будет граммотней?

Я вынес общие параметры в 2 таблицы: RealParams (реальные параметры сроков, стоимости), PlannedParams (плановые параметры стоимости, сроков). PlannedParams хранит все варианты плановых параметров во время выполнения проекта. Необходимо учитывать, что в плановые папраметры так же входят назначения исполнителей, может быть на одно задание несколько исполнителей. Назначения исполнителей находятся в таблице Appointments. Назначения принадлежат к конкретной версии плановых параметров. В id_project_task(procedure) может находиться id как из таблицы ProjectTask так и из таблицы ProjectProcedure. По иерархии ProjectTasks включает ProjectProcedure, т.е. для каждой задачи есть набор процедур, плановые параметры должны быть для обоих, но назначения (таб. Appointments) и один столбец id_iteration(количество повторных подходов из-за ошибок по по работе) только для процедур.

Заранее Спасибо,
Kostya

Ошибся немного, поправил схему. id_project_task(procedure), id_planned_task(procedure) не совсем подходит для связи, т.к. id_project_task и id_project_procedure могут содержать одинаковые значения. Добавил id_real_param и id_planned_param в таб. ProjectTasks и ProjectProcedure и PlannedParams. С помощью этих параметров связал таблицы с RealParams и PlannedParams.
Ещё убрал параметр id_planned_param_ver, т.к. он может повторяться и по нему нельза связать PlannedParams с Appointments. Связь сделал по id_project_planned.

На всякий случай связи моих таб.:
ProjectTasks и RealParams связь по id_real_param
ProjectProcedure и RealParams связь по id_real_param
ProjectTasks и PlannedParams связь по id_planned_param
ProjectProcedure и PlannedParams связь по id_planned_param
PlannedParams и Appointments связь по id_project_planned

Смущает немного полученные связи: 1. между ProjectTasks и RealParams многие к одному. получилось, что в RealParams уник.
2. между ProjectTasks и PlannedParams один к многим. может тут должна быть связь многие к многим, т.к. ни там ни там не ключ...

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

Новая схема во вложение.