我有各种类型的任务。每个任务类型都有一组给定的属性。创建任务并分配属性值。
为此的数据库设计是：
任务类型（pk_taskType，名称）
TaskTypeProperty（pk_taskTypeProperty，fk_taskType，名称）
任务（pk_task、fk_taskType、名称）
TaskProperty（pk_taskProperty、fk_task、fk_taskTypeProperty、值）
一切正常，但有可能给定一个任务，可以更改任务类型引用而不更改属性。这是无效的，但数据库仍然很高兴。
是否有更好的模式来表示这种情况并在数据库中强制执行？
示例数据：
如果任务表中的 fk_taskType 更改为 2，则数据库允许这样做，但我们知道与任务 T1 关联的属性不正确。
【问题讨论】：
标签： database-design foreign-keys
您根本不需要 TaskProperty 表。您有 TaskTypeProperty 表，其中包含每种任务类型的每个属性的条目。我想字段 pk_taskTypeProperty 和 fk_taskType 构成了该表的复合 PK（尽管我当然希望您不要真正将列命名为“FK_...”或“PK_...”）。
因此，在 Tasks 表中，应该有一个 TaskType 和 TaskProperty 字段，它们构成了 TaskTypeProperty 表的 FK。现在不可能有未在 TaskTypeProperty 表中正确定义的任务。
Tasks 表不需要有直接指向 TaskType 表的 FK。该引用链将通过 TaskTypeProperty FK 到达 TaskType 表。这是一个完美的设计。外键的目的是加强数据完整性，而不是从 UML 图复制一行继承。因此，请参考满足该要求的表。
【讨论】：
这应该没有问题，这个想法只是为了确保某种类型的任务只允许与该类型关联的属性。
| 任务类型TYPE_ID 存在。
任务类型由TYPE_ID标识。
| 属性 PROP_ID 存在。
属性由PROP_ID 标识。
| 任务类型 TYPE_ID 与属性 PROP_ID 相关联。
对于每个属性，一个任务类型可能与多个属性相关联 可能有多个任务类型与该属性相关联。
如果任务类型与属性相关联，则该任务类型必须存在。
如果任务类型与属性相关联，则该属性必须存在。
任务类型属性 {TYPE_ID, PROP_ID} PK {TYPE_ID，PROP_ID} FK1 {TYPE_ID} 参考任务类型 {TYPE_ID} FK2 {PROP_ID} REFERENCES 属性 {PROP_ID}
| 任务 TASK_ID 属于任务类型 TYPE_ID。
每个任务都属于一种任务类型；对于每个任务类型，可能会有更多 不止一项任务属于该任务类型。
如果任务属于任务类型，则该任务类型必须存在。
任务 {TASK_ID, TYPE_ID} PK {TASK_ID} AK {TASK_ID, TYPE_ID} -- 超级键，这里是多余的，但在 SQL 中是必需的 -- 被 FK 引用 FK1 {TYPE_ID} 参考任务类型 {TYPE_ID}
| 类型为 TYPE_ID 的任务 TASK_ID 具有属性 PROP_ID。
一个任务可能具有多个属性，对于每个属性，多个任务都可能具有该属性。
如果任务类型的任务具有属性，则该属性与该任务类型相关联。
如果任务具有与任务类型相关联的属性，则该任务属于该任务类型。
任务属性 {TASK_ID、PROP_ID、TYPE_ID} PK {TASK_ID，PROP_ID} FK1 {TASK_ID, TYPE_ID} 参考任务 {TASK_ID, TYPE_ID} FK2 {TYPE_ID, PROP_ID} REFERENCES TaskTypeProperty {TYPE_ID, PROP_ID}注意事项：
PK = 主键 AK = 备用键（唯一） FK = 外键【讨论】：