(База данных) Могут ли две слабые сущности образовать ассоциативную сущность?

В настоящее время у меня есть ситуация, когда 2 слабых объекта образуют ассоциативный объект (из-за отношения «многие ко многим»).

Сильная сущность «проекта» состоит из

projectID (PK), projectName, projectStartDate, projectEndDate

Слабая сущность «Задачи» состоит из

composite primary key projectID (FK,PK) and taskID (PK), taskName,etc

"Ресурсное" слабое звено состоит из

composite primary key projectID (FK,PK) and resourceID (PK), resourceName, maxUnits, standardRate, costPerUse, etc

(Ресурсная сущность похожа на рабочую силу / оборудование / механизмы. Однако каждый ресурс для каждого проекта различается, поэтому я считаю, что это не может быть автономная сущность, но она должна быть слабой сущностью, связанной с сущностью «Проект».)

Однако у 1 ресурса может быть много задач в проекте, а у 1 задачи может быть много ресурсов. Таким образом, образовались отношения «многие ко многим». (между слабыми объектами Resource и Task)

Следовательно, у него есть ассоциативная сущность, называемая сущностью «Назначение».

Если бы я составил карту таблицы «Назначение», у нее были бы следующие атрибуты:

projectID, taskID, resourceID, workCompleted, work, units

После чего я сбит с толку, когда я создаю структуру SQL для таблицы «Назначение», могу ли я ссылаться на projectID из Слабая сущность задачи или из Слабая сущность ресурса?

Или я все неправильно отображаю?


entities associative weak
person DoubleClickOnThis    schedule 09.01.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Что ж - на самом деле будет сложно ответить полностью, потому что многое зависит от ваших реальных данных, модели данных и т. Д.

Из того, что вы упомянули, я бы подумал, что вам нужна таблица ресурсов, которая не связана с проектом, потому что, если это персонал / рабочая сила - один сотрудник должен быть связан с несколькими проектами (я бы подумал), что делает его многим для -многие ассоциации между «Персоналом» и «Проектом».

Итак, во-первых - я думаю, вам понадобится такая структура таблицы:

Staff/Resource --> ResourceOnProject     <-- Project
Id (PK)        --> ProjectID, ResourceId <-- Id (PK)

вместо существующей таблицы ресурсов.

Если это возможно, я думаю, это должно вам помочь. В зависимости от информации в задачах, вы можете сделать то же самое для этого.

Но теперь у вас должна быть возможность изменить свое назначение, чтобы просто удерживать ResourceId из Staff / Resource без необходимости «двойной» проблемы ProjectId, с которой вы столкнулись в вашей текущей настройке.

Итак, в основном:

Staff/Resource (Id PK)
Project (Id PK)
ResourceOnProject (ProjectId FK, ResourceId FK)
Task (Id PK, ProjectId FK) 
Assignment (TaskId FK, ProjectId FK, ResourceId FK)
person Allan S. Hansen    schedule 09.01.2015
comment
Привет, спасибо за ответ. Обычно в таблице ресурсов есть такие атрибуты, как maxUnits, standardRate, costPerUse. (Ресурсы также могут включать оборудование, а не только рабочую силу). Однако, например, у Джека есть другие обязательства по отношению к другим проектам, поэтому его maxUnits (например, уровень обязательств) для этого конкретного проекта составляет 50% вместо 100%. Это причина, по которой мне нужно было связать ресурс с проектом, потому что уровень обязательств каждого ресурса для каждого проекта различается. - person DoubleClickOnThis; 09.01.2015
comment
Эту информацию все еще можно поместить в таблицу ассоциаций (ResourcesOnProject). Основываясь на вашей информации здесь, вам понадобится базовая таблица персонала / ресурсов, потому что у Джека есть другие обязательства. Это означает, что ваша таблица назначений не относится к связи между персоналом и проектом, а только к персоналу, и, таким образом, она устраняет ваши проблемы с двойным ProjectId для назначения. - person Allan S. Hansen; 09.01.2015
comment
Значит ли это, что таблица ресурсов не должна быть слабым звеном для Project, а должна быть сильной сама по себе? - person DoubleClickOnThis; 09.01.2015
comment
Вам нужна базовая таблица, содержащая Джека и других ваших сотрудников / ресурсов. Тот, который я назвал в своем ответе «Персонал / Ресурс». Затем вы можете связать эту таблицу со своим проектом, содержащим информацию, необходимую для этой связи. Это тот, который вы назвали Resource, а я - ResourceOnProject. Тогда ваша таблица назначения будет ссылаться на персонал / ресурс вместо ResourceOnProject, а также на вашу задачу, и у вас больше не будет проблемы с двойной ссылкой ProjectID в назначении. - person Allan S. Hansen; 09.01.2015