DB 建模：这种不可识别的关系是否保持可识别性？

Question

我有一些表，我使用 MySQL Workbench 创建了role_has_action 表。
创建的字段为：(role_id,action_id,action_controller_id):
（为简洁起见，我将action_controller_id 重命名为controller_id）：

我知道这是role_has_action 和action 表之间的识别关系。 action 表本身和控制器表有一个复合键。因此，role_has_action 表现在有一个三重复合主键来维护可识别的关系。

然而，我声称，如果 role_has_action 仅具有 (role_id,action_id) 字段，那么在实践中将保留可识别性，尽管可能不是严格的理论意义上的。我这么说是因为控制器是独一无二的；动作对于控制者来说是唯一的；而role_has_action 可以通过使用action.id 列将role 表中的角色唯一地绑定到一个动作，因此controller_id 键在role_has_action 表中是多余的。

我错过了什么吗？删除该列 (controller_id) 会使 MySQL Workbench 将此关系标记为不可识别，所以我有点担心。我可以举一个反例说明这如何变成不可识别的关系，或者我可以在实践中删除该列并且不太担心失去可识别性吗？

Answer 1

正式地说，在识别关系中，子实体的主键必须包括其父实体的主键。 MySQLWorkbench 似乎遵循这个严格的定义。

由于action 被定义为与controller 具有识别关系（可以说是正确的），因此严格的规则要求controller_id 是action 主键的一部分，并级联到@987654326 @

但假设 action.id 是唯一的，那么此列实际上就变得多余了。

但是，action.id 的唯一性正式不是必需的（事实上，这是一个surrogate key，它的存在是可选的）。您可以很好地删除此列并让(name, conroller_id) 成为主键。在这种情况下，role_has_action.controller_id 将实际上再次被要求。

Answer 2

严格来说，从role_has_action 中删除controller_id 确实会引起关系完整性问题，因为唯一定义action 的方法是同时使用id 和controller_id 字段。通过将controller_id 包含在action 的主键中，您实际上是在说“同一操作可以用于多个控制器”。因此，了解您正在谈论的操作/控制器的唯一方法是查看这两个 ID；否则它是模棱两可的。如果这在“现实生活中”不是真的，那么您可能需要重新考虑您的关系模型。

如果action 表中的每条记录都保证具有唯一的id 值，那么解决此问题的“快速而肮脏”的方法是从其主键中删除controller_id（但保留它作为controller 表的外键）。这将允许您从role_has_action 表的主键中删除controller_id，因为您现在可以通过action_id 唯一地标识操作。我对这种方法的担忧是action 表变得有点难以理解：表结构意味着每个操作都是唯一的，尽管仅凭借（可能是人为生成的）id 列，这意味着为了保证表中数据的业务功能一致和正确，必须进行一些数据库外部的逻辑，这只会继续打开后续的蠕虫。

您可以尝试将您的关系模型调整为如下所示：

• role 表：所有可用角色的定义（主键：role_id）
• action 表：所有可用操作的定义（主键：action_id）
• controller表：所有可用控制器的定义（主键：controller_id）
• role_has_action：属于每个角色的操作列表（主键：role_id, action_id，带有role 和action 表的外键）
• controller_has_action：属于每个控制器的操作列表（键：controller_id, action_id，带有controller 和action 表的外键）

您需要在此模型中添加一个表，但所有可能的角色、操作和控制器都是唯一定义的，并且它们之间的关系是明确和清晰的。