Su diseño no "parece" nada porque no podemos leer su mente. Ha proporcionado algunos aspectos de un diseño, pero no el "escenario" comercial que representa/implementa/describe o cómo lo hace.
SQL NULL, UNIQUE, PK y FK son tipos de restricciones. Una restricción es una limitación sobre los valores de la base de datos que pueden aparecer. Un SQL FK dice que los valores de subfila para una lista de columnas en una tabla deben aparecer en otro lugar para una lista de columnas cuyas columnas forman un conjunto de columnas SQL ÚNICO NO NULO (del cual PK es un caso) en su tabla. Si su diseño está sujeto a una restricción y no está implícito en otras restricciones impuestas, hágalo cumplir. De lo contrario, no lo hagas. Preferiblemente de forma declarativa. La mayoría de los DBMS de SQL solo le permiten declarar algunos tipos de restricciones de bajo costo. Otros deben aplicarse a través de activadores.
Las restricciones son una consecuencia de los criterios para que las filas entren y permanezcan fuera de las tablas en una situación dada (la tabla predica , "qué significan las tablas") y qué situaciones pueden y no pueden surgir de acuerdo con sus reglas comerciales. No sabemos cuáles son a menos que nos lo digas. Esperamos adivinar usando los nombres de sus tablas y columnas, cualquier otra información que proporcione y sentido común.
Tú tiene que decírnoslo a nosotros ya sea las restricciones o los predicados y qué situaciones pueden/no pueden surgir.
Aquí, sus tablas utilizan una tabla sencilla más un diseño EAV para registrar los datos de una tabla sencilla que no está explícitamente en su diseño. Como siempre, podrías evite EAV simplemente usando DDL para mantener actualizados el esquema y las restricciones de la tabla directa, pero en su lugar ha elegido un esquema estático que requiere un esquema, consultas y restricciones más complejos. La expresión directa de las restricciones de EAV es típicamente que la tabla directa que representan tiene ciertas restricciones más que t_criteria_x son vistas de ella y/o que es una vista de ellos. Pero, por lo general, las únicas declaraciones de SQL disponibles solo le permiten expresar fragmentos de eso.
Supongo que supongo que lo que pretende aquí incluye que para cada tabla t_criteria_x su valor PK debe aparecer en t_criteria_director con un valor de table_name 't_criteria_x'. Otra forma de expresar esto es que si agregó a t_criteria_x una columna table_name con el valor 't_criteria_x', entonces el resultado debe tener subfilas (id, table_name) como subfilas t_criteria_director (criteria_id, table_name). Si también Las subfilas t_criteria_director (criteria_id, table_name) son SQL ÚNICAS NO NULAS, entonces tenemos que ese t_criteria_x aumentado tiene un SQL FK compuesto (id, table_name) que hace referencia a t_criteria_director (criteria_id, table_name). Puede expresar esto de forma declarativa aumentando t_criteria_x con columnas de este tipo (posiblemente calculadas/generadas/calculadas). Pero probablemente también tenga otras restricciones, como que no hay pares (constraint_id, table_name) en t_criteria_director que no estén referenciados por alguna t_constraint_x aumentada.
Llamar a la columna table_name muestra un sesgo orientado a la implementación del EAV porque esa columna es un tipo/discriminador de variante/etiqueta en el sentido ER de que los tipos de entidades representadas por los id en las tablas t_criteria_x son "subtipos" del tipo de entidad representada por t_criteria_director. (Este también es un concepto/técnica de las estructuras de datos de registro 3GL utilizadas para simular dinámicamente la tipificación). Después de todo, el valor de la columna table_name no tiene que ser un nombre de tabla, solo tiene que ser algún valor que identifique el subtipo de entidad, y dichas entidades no tienen que participar únicamente en la relación/asociación de una tabla. (Investigue SQL/base de datos/subtipado ER/polimorfismo/herencia y el diseño antipatrón dos/muchos/múltiples FK [sic] a dos/muchos/múltiples tablas).
Debe determinar cuáles son los predicados de la tabla y cuáles son sus restricciones en consecuencia. Preferiblemente a través de la determinación de cuál es la tabla sencilla que representan colectivamente y cuál es su predicado y cuáles son las restricciones de la base de datos que la utilizan. Luego debe decidir si por costo/beneficio va a modificar su diseño para hacer que las restricciones sean declarativas y/o va a aplicar o no restricciones a través de disparadores.
