2010-08-31 5 views
2

Картина делает больше справедливости, поэтому я начну с этого. Dependent RelationМодель базы данных Зависимые отношения

Так что в моей таблице Relation_Type у меня есть несколько разных типов (Owner, Reviewer, Approver и т. Д.).
В моей Relation_Status таблице у меня есть другой статус для некоторых типов:

Reviwer: (В ожидании обратной связи, полученные отзывы)
утверждающий: (В ожидании решения, Approved, Denied)

Моя проблема заключается в том, что я не знаю, как обеспечить соблюдение отношения, которое говорит , если тип отношения является обратной связью, ограничивает статус только статусом обратной связи '.
Прямо сейчас, как это моделируется, тип отношения обратной связи может иметь любой статус, который является логической несогласованностью. Кроме того, не все типы имеют статус.

Итак, какие-нибудь советы о том, как смоделировать это, чтобы он обеспечивал зависимость?

Спасибо, Рауль

ответ

0

Возможно, вам нужен сложный внешний ключ, который сочетает в себе Status_Id с Type_Id.

+0

Это сделало трюк. Мне пришлось добавить ограничение Unique в таблицу состояния со столбцами _id и type_id, чтобы я мог создать сложный внешний ключ. Причина, по которой я выбрал этот ответ, состоит в том, что остальные либо напрямую привязаны к статусу, либо имеют дополнительную таблицу с логическими группировками. Эти параметры не работают, потому что не все типы имеют статус. Thanks – HaxElit

1

Вы можете создать еще одну таблицу TypeStatus(ID, Type_Id, Status_Id). Он имел бы FK в таблице _Type и _Status, а таблица _Relation имела бы одну FK для этой новой таблицы, а не две FK для существующих таблиц. Я бы подумал, что вы также удалите столбец _Type_Id из таблицы _Status.

+0

В то время как новая таблица для хранения допустимых комбинаций типа и состояния была бы хорошей идеей, может быть, не такая хорошая идея заменить существующие два FK в таблице _Relation одним FK на новую таблицу - если существующая комбинация типа статуса перестает быть действительной, запись в новой таблице нужно будет удалить, но это оставит сиротские записи в таблице _Relation. –

+0

Я думаю, что это будет проблемой, есть ли у вас один FK или два ... в обоих случаях, если вы удалите действительную комбинацию статуса типа, могут быть записи в таблице _Relation, которые необходимо обновить или удалить соответствуют функциональному ограничению. – joelt

+0

Я думаю, что это решение работает только в том случае, если между типами и статусами существует взаимосвязь «многие-ко-многим». Хотя в вопросе явно не указано, диаграмма подразумевает, что между статусами и типами существует соотношение «один ко многим». Итак, если есть отношение «один ко многим», вам придется добавить дополнительные ограничения в это решение. Если отношения много-ко-многим, вы получаете мой голос за лучший ответ. Это правильное решение для отношений «многие-ко-многим». – bobs

0

Я бы удалил стол Project_Resource_Relation_Type_Id из таблицы Project_Resource_Relation. Это устраняет зависимость от Project_Resource_Relation к Project_Resource_Relation_Type.

Соотношение типа уже связано с Project_Resource_Relation таблицы через Project_Resource_Relation_Status таблицы. Таблица Project_Resource_Relation_Status уже обеспечивает взаимосвязь между типами и статусами.

+0

Это не работает, потому что не все типы имеют статус.Поэтому, если у меня нет статуса, я не могу вернуться к типу. – HaxElit

Смежные вопросы