您的设计并没有“看起来”任何东西，因为我们无法读懂您的想法。您已经给出了设计的某些方面，但没有给出它所代表/实现/描述的业务“场景”或它是如何做到的。
SQL NULL、UNIQUE、PK 和 FK 是约束的种类。约束是对可以出现的数据库值的限制。 SQL FK 表示表中列列表的子行值必须出现在其他列列表的其他位置，该列列表的列在其表中形成 SQL UNIQUE NOT NULL 列集（PK 是一种情况）。如果您的设计受到约束并且其他强制约束没有暗示，请强制执行。否则不要。最好是声明式的。大多数 SQL DBMS 只允许您声明几种执行成本低廉的约束。其他必须通过触发器强制执行。
约束是在给定情况下（表谓词，“表的含义”）以及哪些情况可以&可以' t 根据您的业务规则出现。除非您告诉我们，否则我们不知道这些是什么。我们希望使用您的表名和列名、您提供的任何其他信息和常识来猜测。
您必须告诉我们约束或谓词以及哪些情况可以/不能出现。
这里你的表使用一个简单的表加上一些 EAV 设计来记录一些在你的设计中没有明确表示的简单表的数据。与往常一样，您可以通过仅使用 DDL 来保持简单表的架构和约束保持最新来避免 EAV，但是您选择了需要更复杂架构、查询和约束的静态架构。 EAV 约束的直接表达通常是它们表示的直接表具有某些约束，加上 t_criteria_x 是它的视图和/或它是它们的视图。但通常唯一可用的 SQL 声明只是让您表达其中的片段。
我猜您在此处的意图包括对于每个 t_criteria_x 表，其 PK 值必须出现在 t_criteria_director 中，表名值为“t_criteria_x”。另一种说法是，如果您向 t_criteria_x 添加了一个值为 't_criteria_x' 的 table_name 列，则结果必须有 (id, table_name) 子行显示为 t_criteria_director (criteria_id, table_name) 子行。如果 也 t_criteria_director (criteria_id, table_name) 子行是 SQL UNIQUE NOT NULL，那么我们认为扩充的 t_criteria_x 具有引用 t_criteria_director (criteria_id, table_name) 的复合 SQL FK (id, table_name)。您可以通过这样的（可能计算/生成/计算的）列实际增加 t_criteria_x 来以声明方式表达这一点。但是您可能还有其他约束，例如 t_criteria_director 中没有任何 (constraint_id, table_name) 对未被某些增强的 t_constraint_x 引用。
调用 table_name 列显示了 EAV 的面向实现的偏差，因为该列是 ER 意义上的类型/变体鉴别器/标记，即 t_criteria_x 中的 id 表示的实体类型表是由 t_criteria_director 表示的实体类型的“子类型”。 （这也是用于动态模拟打字的 3GL 记录数据结构的概念/技术。）毕竟 table_name 列值不必是表名，它只需是标识实体子类型的某个值，并且这样的实体不必只参与一个表的关系/关联。 （研究 SQL/数据库/ER 子类型/多态性/继承和设计反模式二/多/多 FK [原文如此] 到二/多/多表。）
您必须确定表谓词是什么以及它们的约束是什么。最好通过确定它们共同表示的简单表是什么、它的谓词是什么以及数据库约束正在使用它。然后，您必须决定是否要根据成本/收益来修改您的设计以使约束声明性和/或您是否将通过触发器强制执行约束。