Váš návrh se nijak „nezdá“, protože nedokážeme číst vaše myšlenky. Uvedli jste některé aspekty návrhu, ale ne obchodní „scénář“, který představuje/implementuje/popisuje, nebo jak to dělá.
SQL NULL, UNIQUE, PKs &FK jsou druhy omezení. Omezení je omezení toho, jaké databázové hodnoty se mohou objevit. SQL FK říká, že hodnoty podřádku pro seznam sloupců v tabulce se musí objevit jinde pro seznam sloupců, jehož sloupce tvoří sadu sloupců SQL UNIQUE NOT NULL (což je případ PK) v jejich tabulce. Pokud váš návrh podléhá omezení a není implikováno jinými vynucenými omezeními, vynucujte je. Jinak ne. Nejlépe deklarativně. Většina SQL DBMS vám umožňuje deklarovat pouze několik druhů levně vynutitelných omezení. Ostatní musí být vynuceny pomocí spouštěčů.
Omezení jsou důsledkem kritérií pro řádky jdoucí do vs. zůstávat mimo tabulky v dané situaci (tabulka predikáty , „co znamenají tabulky“) a jaké situace mohou a nemohou nastat podle vašich obchodních pravidel. Nevíme, co to je, pokud nám to neřeknete. Můžeme doufat, že uhodneme pomocí názvů vašich tabulek a sloupců, jakýchkoli dalších informací, které poskytnete, a zdravého rozumu.
Vy musíte nám to říct nám buď omezení, nebo predikáty a jaké situace mohou/nemohou nastat.
Zde vaše tabulky používají přímou tabulku plus nějaký návrh EAV k zaznamenání dat nějaké přímočaré tabulky, která nejsou explicitně ve vašem návrhu. Jako vždy můžete vyhněte se EAV pouhým použitím DDL, aby bylo schéma a omezení jednoduché tabulky aktuální, ale místo toho jste zvolili statické schéma, které vyžaduje složitější schéma, dotazy a omezení. Přímým vyjádřením omezení EAV je typicky to, že přímočará tabulka, kterou představují, má určitá omezení plus že t_criteria_x jsou pohledy na ni a/nebo že je to pohled na ně. Ale obvykle jediné dostupné deklarace SQL vám umožňují vyjádřit jejich fragmenty.
Hádám to, co zde zamýšlíte, zahrnuje to, že pro každou tabulku t_criteria_x se její hodnota PK musí objevit v t_criteria_director s hodnotou názvu_tabulky 't_criteria_x'. Jiný způsob, jak to vyjádřit, je, že pokud přidáte do t_criteria_x sloupec table_name s hodnotou 't_criteria_x', pak výsledek musí mít podřádky (id, table_name) jako podřádky t_criteria_director (id_kritéria, název_tabulky). Pokud také Podřádky t_criteria_director (id_kritéria, název_tabulky) jsou SQL UNIQUE NOT NULL, pak máme, že toto rozšířené t_criteria_x má složený SQL FK (id, název_tabulky) odkazující na t_director_director (id_kritéria, název_tabulky). Můžete to vyjádřit deklarativně tím, že skutečně rozšíříte t_criteria_x o takové (možná vypočítané/vygenerované/vypočítané) sloupce. Pravděpodobně však máte také další omezení, například v t_criteria_director nejsou žádné páry (constraint_id, table_name), na které by neodkazoval nějaký rozšířený t_constraint_x.
Volání sloupce název_tabulky ukazuje na implementaci orientované zkreslení z EAV, protože tento sloupec je diskriminátor/značka typu/varianty v ER smyslu, že typy entit reprezentovaných id v tabulkách t_criteria_x jsou "podtypy" typu entity reprezentované t_criteria_director. (Toto je také koncept/technika z datových struktur záznamu 3GL používaných pro dynamickou simulaci psaní.) Koneckonců, hodnota sloupce table_name nemusí být název tabulky, musí to být jen nějaká hodnota, která identifikuje podtyp entity, a takové entity se nemusí podílet pouze na vztahu/asociaci jedné tabulky. (Zkoumejte podtypování SQL/databáze/ER/polymorfismus/dědičnost a návrh protivzorových dvou/mnoho/více FK [sic] až dva/mnoho/vícenásobné tabulky.)
Musíte určit, co jsou predikáty tabulky a jaká jsou následně jejich omezení. Nejlépe určením toho, co je přímočará tabulka, kterou společně reprezentují, a jaký je její predikát a jaká databázová omezení jej používají. Pak se musíte rozhodnout, zda v poměru cena/přínos upravíte svůj návrh tak, aby omezení byla deklarativní a/nebo zda budete či nebudete vynucovat omezení prostřednictvím spouštěčů.