Seu design não "parece" nada porque não podemos ler sua mente. Você forneceu alguns aspectos de um projeto, mas não o "cenário" de negócios que ele representa/implementa/descreve ou como o faz.
SQL NULL, UNIQUE, PKs e FKs são tipos de restrições. Uma restrição é uma limitação sobre quais valores de banco de dados podem aparecer. Um SQL FK diz que os valores de sub-linha para uma lista de colunas em uma tabela devem aparecer em outro lugar para uma lista de colunas cujas colunas formam um conjunto de colunas SQL UNIQUE NOT NULL (do qual PK é um caso) em sua tabela. Se seu design estiver sujeito a uma restrição e não estiver implícito em outras restrições impostas, aplique-o. Caso contrário, não. De preferência declarativamente. A maioria dos SGBDs SQL só permite que você declare alguns tipos de restrições de baixo custo. Outros devem ser aplicados por meio de gatilhos.
As restrições são uma consequência dos critérios para as linhas entrarem versus ficarem fora das tabelas em uma determinada situação (a tabela predicados , "o que as tabelas significam") e quais situações podem e não podem surgir de acordo com suas regras de negócios. Nós não sabemos o que são, a menos que você nos diga. Podemos esperar adivinhar usando seus nomes de tabela e coluna, qualquer outra informação que você der e bom senso.
Você tem que nos dizer nós as restrições ou os predicados e quais situações podem/não podem surgir.
Aqui suas tabelas estão usando uma tabela simples mais algum projeto EAV para registrar os dados de alguma tabela direta não explicitamente em seu projeto. Como sempre, você poderia evite EAV usando apenas DDL para manter o esquema e as restrições da tabela simples atualizados, mas, em vez disso, você escolheu um esquema estático que requer esquema, consultas e restrições mais complexos. A expressão direta das restrições EAV é tipicamente que a tabela direta que eles representam tem certas restrições mais que os t_criteria_x são visualizações dela e/ou que é uma visualização delas. Mas normalmente as únicas declarações SQL disponíveis apenas permitem que você expresse fragmentos disso.
Eu acho que o que você pretende aqui inclui que para cada tabela t_criteria_x seu valor PK deve aparecer em t_criteria_director com um valor table_name 't_criteria_x'. Outra maneira de colocar isso é que, se você adicionou a t_criteria_x uma coluna table_name com o valor 't_criteria_x', o resultado deve ter sublinhas (id, table_name) aparecendo como t_criteria_director (criteria_id, table_name). Se também t_criteria_director (criteria_id, table_name) são SQL UNIQUE NOT NULL, então temos que t_criteria_x aumentado tem um FK SQL composto (id, table_name) referenciando t_criteria_director (criteria_id, table_name). Você pode expressar isso declarativamente aumentando t_criteria_x por tais colunas (possivelmente computadas/geradas/calculadas). Mas você provavelmente também tem outras restrições, como não existem pares (constraint_id, table_name) em t_criteria_director que não são referenciados por algum t_constraint_x aumentado.
Chamar a coluna table_name mostra um viés orientado à implementação do EAV porque essa coluna é um tipo/variante discriminador/tag no sentido de ER que os tipos de entidades representadas pelos ids nas tabelas t_criteria_x são "subtipos" do tipo de entidade representada por t_criteria_director. (Este também é um conceito/técnica das estruturas de dados de registro 3GL usadas para simular dinamicamente a digitação.) Afinal, o valor da coluna table_name não precisa ser um nome de tabela, apenas precisa ser algum valor que identifique o subtipo da entidade e essas entidades não precisam participar apenas do relacionamento/associação de uma tabela. (Pesquise SQL/banco de dados/subtipagem/polimorfismo/herança de ER e o anti-padrão de design dois/muitos/múltiplos FKs [sic] para duas/muitos/múltiplas tabelas.)
Você tem que determinar quais são os predicados da tabela e quais são suas restrições consequentemente. De preferência, determinando qual é a tabela direta que eles representam coletivamente e qual é seu predicado e quais são as restrições do banco de dados que o estão usando. Então você deve decidir se por custo/benefício você vai modificar seu design para tornar as restrições declarativas e/ou você vai ou não impor restrições por meio de gatilhos.
