Uw ontwerp "lijkt" niets omdat we uw gedachten niet kunnen lezen. Je hebt een aantal aspecten van een ontwerp gegeven, maar niet het zakelijke "scenario" dat het vertegenwoordigt/implementeert/beschrijft of hoe het dat doet.
SQL NULL, UNIQUE, PK's en FK's zijn soorten beperkingen. Een beperking is een beperking van welke databasewaarden kunnen worden weergegeven. Een SQL FK zegt dat subrijwaarden voor een kolomlijst in een tabel ergens anders moeten verschijnen voor een kolomlijst waarvan de kolommen een SQL UNIQUE NOT NULL-kolomset vormen (waar PK een geval van is) in hun tabel. Als uw ontwerp onderhevig is aan een beperking en dit niet wordt geïmpliceerd door andere opgelegde beperkingen, moet u dit afdwingen. Anders niet. Bij voorkeur declaratief. Met de meeste SQL DBMS'en kunt u slechts een paar soorten goedkope-te-afdwingen-beperkingen declareren. Andere moeten worden afgedwongen via triggers.
De beperkingen zijn een gevolg van de criteria voor rijen die in een bepaalde situatie in of uit tabellen gaan (de tabel predikaten , "wat de tabellen betekenen") en welke situaties wel en niet kunnen ontstaan volgens uw bedrijfsregels. We weten niet wat dat zijn, tenzij je het ons vertelt. We kunnen hopen te raden met behulp van uw tabel- en kolomnamen, andere informatie die u geeft en gezond verstand.
Jij moet het ons vertellen ofwel de beperkingen of de predikaten en welke situaties wel/niet kunnen voorkomen.
Hier gebruiken uw tabellen een eenvoudige tabel plus een EAV-ontwerp om de gegevens van een eenvoudige tabel vast te leggen die niet expliciet in uw ontwerp staan. Zoals altijd kon je vermijd EAV door alleen DDL te gebruiken om het schema en de beperkingen van de eenvoudige tabel up-to-date te houden, maar in plaats daarvan hebt u een statisch schema gekozen dat complexere schema's, vragen en beperkingen vereist. De directe uitdrukking van de EAV-beperkingen is meestal dat de eenvoudige tabel die ze vertegenwoordigen bepaalde beperkingen heeft plus dat de t_criteria_x weergaven ervan zijn en/of dat het een weergave ervan is. Maar meestal laten de enige beschikbare SQL-declaraties je slechts fragmenten daarvan uitdrukken.
Ik denk dat wat je hier van plan bent, inhoudt dat voor elke t_criteria_x-tabel de PK-waarde ervan moet verschijnen in t_criteria_director met een tabelnaamwaarde 't_criteria_x'. Een andere manier om dit te zeggen is dat als je aan t_criteria_x een tabelnaamkolom met waarde 't_criteria_x' hebt toegevoegd, het resultaat (id, tabelnaam) subrijen moet hebben die verschijnen als t_criteria_director (criteria_id, tabelnaam) subrijen. Als ook t_criteria_director (criteria_id, table_name) subrijen zijn SQL UNIEK NIET NULL dan hebben we dat augmented t_criteria_x een samengestelde SQL FK (id, table_name) heeft die verwijst naar t_criteria_director (criteria_id, table_name). Je kunt dit declaratief uitdrukken door t_criteria_x daadwerkelijk te vergroten met zulke (mogelijk berekende/gegenereerde/berekende) kolommen. Maar je hebt waarschijnlijk ook andere beperkingen, zoals dat er geen (constraint_id, table_name) paren in t_criteria_director zijn waarnaar niet wordt verwezen door een augmented t_constraint_x.
Het aanroepen van de kolom table_name toont een implementatiegerichte bias van de EAV omdat die kolom een type/variant-discriminator/tag is in de ER-zin dat de typen entiteiten die worden vertegenwoordigd door de id's in de t_criteria_x-tabellen "subtypes" zijn van het type entiteit dat wordt vertegenwoordigd door t_criteria_director. (Dit is ook een concept/techniek uit 3GL-recordgegevensstructuren die worden gebruikt voor het dynamisch simuleren van typen.) De kolomwaarde table_name hoeft immers geen tabelnaam te zijn, het moet gewoon een waarde zijn die het subtype van de entiteit identificeert, en dergelijke entiteiten hoeven niet alleen deel te nemen aan de relatie/associatie van één tabel. (Onderzoek SQL/database/ER-subtypering/polymorfisme/overerving en het ontwerp-antipatroon twee/veel/meerdere FK's [sic] naar twee/veel/meerdere tabellen.)
Je moet bepalen wat de tabelpredikaten zijn en wat hun beperkingen zijn. Bij voorkeur door te bepalen wat de eenvoudige tabel is die ze samen vertegenwoordigen en wat het predikaat is en wat de databasebeperkingen ervan gebruiken. Vervolgens moet u beslissen of u per kosten/baten uw ontwerp gaat aanpassen om beperkingen declaratief te maken en/of u wel of niet beperkingen oplegt via triggers.