Din design "verkar" inte som något eftersom vi inte kan läsa dina tankar. Du har angett vissa aspekter av en design men inte affärsscenariot som den representerar/implementerar/beskriver eller hur den gör det.
SQL NULL, UNIQUE, PK och FK är olika typer av begränsningar. En begränsning är en begränsning för vilka databasvärden som kan visas. En SQL FK säger att underradsvärden för en kolumnlista i en tabell måste visas någon annanstans för en kolumnlista vars kolumner bildar en SQL UNIQUE NOT NULL kolumnuppsättning (vilket PK är ett fall av) i deras tabell. Om din design är föremål för en begränsning och den inte antyds av andra påtvingade begränsningar, genomdriv den. Annars gör det inte. Gärna deklarativt. De flesta SQL DBMS låter dig bara deklarera ett fåtal typer av begränsningar som är billiga att upprätthålla. Andra måste genomdrivas via utlösare.
Begränsningarna är en konsekvens av kriterierna för rader som går in i kontra att hålla sig utanför tabeller i en given situation (tabellen predikat , "vad tabellerna betyder") och vilka situationer som kan och inte kan uppstå enligt dina affärsregler. Vi vet inte vad det är om du inte berättar för oss. Vi kan hoppas att vi kan gissa med dina tabell- och kolumnnamn, all annan information du ger och sunt förnuft.
Du måste berätta för oss antingen begränsningarna eller predikaten &vilka situationer som kan/inte kan uppstå.
Här använder dina tabeller en enkel tabell plus lite EAV-design för att registrera data från en enkel tabell som inte är explicit i din design. Som alltid kunde du undvika EAV genom att bara använda DDL för att hålla den enkla tabellens schema och begränsningar uppdaterade, men istället har du valt ett statiskt schema som kräver mer komplext schema, frågor och begränsningar. Det enkla uttrycket för EAV-begränsningarna är vanligtvis att den enkla tabellen de representerar har vissa begränsningar plus att t_criteria_x är synpunkter på den och/eller att den är en syn på dem. Men vanligtvis låter de enda tillgängliga SQL-deklarationerna dig bara uttrycka fragment av det.
Jag gissar att det du avser här inkluderar att för varje t_criteria_x-tabell måste dess PK-värde visas i t_criteria_director med ett table_name-värde 't_criteria_x'. Ett annat sätt att uttrycka detta är att om du lagt till en kolumn tabellnamn med värdet 't_criteria_x' i t_criteria_x så måste resultatet ha (id, table_name) underrader som t_criteria_director (criteria_id, table_name) underrader. Om också t_criteria_director (criteria_id, table_name) underrader är SQL UNIQUE NOT NULL då har vi att den utökade t_criteria_x har en sammansatt SQL FK (id, table_name) som refererar till t_criteria_director (criteria_id, table_name). Du kan uttrycka detta deklarativt genom att faktiskt utöka t_criteria_x med en sådan (eventuellt beräknad/genererad/beräknad) kolumn. Men du har förmodligen också andra begränsningar, som att det inte finns några (constraint_id, table_name) par i t_criteria_director som inte refereras av någon utökad t_constraint_x.
Att anropa kolumnen table_name visar en implementeringsorienterad bias från EAV eftersom den kolumnen är en typ/variant diskriminator/tag i ER-bemärkelsen att de typer av entiteter som representeras av ID:en i t_criteria_x-tabellerna är "undertyper" av den typ av entitet som representeras av t_criteria_director. (Detta är också ett koncept/teknik från 3GL-postdatastrukturer som används för att dynamiskt simulera typning.) När allt kolumnvärdet tabellnamn behöver inte vara ett tabellnamn, det måste bara vara något värde som identifierar entitetsundertypen, och sådana enheter behöver inte bara delta i en tabells relation/association. (Forska SQL/databas/ER subtyping/polymorfism/arv och designantimönster två/många/flera FKs [sic] till två/många/flera tabeller.)
Du måste bestämma vad tabellpredikaten är och vad deras begränsningar är. Helst genom att bestämma vad den enkla tabellen de tillsammans representerar är och vad dess predikat är och vilka databasbegränsningar som använder den. Sedan måste du bestämma om du per kostnad/nytta ska modifiera din design för att göra begränsningar deklarativa och/eller om du ska eller inte ska genomdriva begränsningar via triggers.