Votre design ne "semble" rien car nous ne pouvons pas lire dans vos pensées. Vous avez donné certains aspects d'une conception, mais pas le « scénario » d'entreprise qu'elle représente/implémente/décrit ou comment elle le fait.
SQL NULL, UNIQUE, PKs &FKs sont des types de contraintes. Une contrainte est une limitation sur les valeurs de base de données qui peuvent apparaître. Un FK SQL indique que les valeurs de sous-lignes pour une liste de colonnes dans une table doivent apparaître ailleurs pour une liste de colonnes dont les colonnes forment un ensemble de colonnes SQL UNIQUE NOT NULL (dont PK est un cas) dans leur table. Si votre conception est soumise à une contrainte et qu'elle n'est pas impliquée par d'autres contraintes appliquées, appliquez-la. Sinon ne le faites pas. De préférence de manière déclarative. La plupart des SGBD SQL ne vous permettent de déclarer que quelques types de contraintes peu coûteuses à appliquer. D'autres doivent être appliqués via des déclencheurs.
Les contraintes sont une conséquence des critères pour que les lignes entrent dans ou restent hors des tables dans une situation donnée (la table prédicats , "ce que signifient les tableaux") et quelles situations peuvent et ne peuvent pas se produire selon vos règles métier. Nous ne savons pas ce que c'est à moins que vous nous le disiez. Nous pouvons espérer deviner en utilisant vos noms de table et de colonne, toute autre information que vous donnez et votre bon sens.
Vous je dois nous le dire soit les contraintes, soit les prédicats et quelles situations peuvent/ne peuvent pas survenir.
Ici, vos tables utilisent une table simple plus une conception EAV pour enregistrer les données d'une table simple non explicitement dans votre conception. Comme toujours, vous pourriez évitez EAV en utilisant simplement DDL pour maintenir à jour le schéma et les contraintes de la table simple, mais vous avez plutôt choisi un schéma statique qui nécessite un schéma, des requêtes et des contraintes plus complexes. L'expression simple des contraintes EAV est généralement que la table simple qu'elles représentent a certaines contraintes et que les t_criteria_x en sont des vues et/ou qu'il s'agit d'une vue d'elles. Mais généralement, les seules déclarations SQL disponibles vous permettent simplement d'en exprimer des fragments.
Je suppose que ce que vous avez l'intention ici inclut que pour chaque table t_criteria_x, sa valeur PK doit apparaître dans t_criteria_director avec une valeur table_name 't_criteria_x'. Une autre façon de le dire est que si vous avez ajouté à t_criteria_x une colonne table_name avec la valeur 't_criteria_x', le résultat doit avoir des sous-lignes (id, table_name) apparaissant comme des sous-lignes t_criteria_director (criteria_id, table_name). Si aussi Les sous-lignes t_criteria_director (criteria_id, table_name) sont SQL UNIQUE NOT NULL alors nous avons que t_criteria_x augmenté a un SQL FK composite (id, table_name) référençant t_criteria_director (criteria_id, table_name). Vous pouvez exprimer cela de manière déclarative en augmentant réellement t_criteria_x par de telles colonnes (éventuellement calculées/générées/calculées). Mais vous avez probablement aussi d'autres contraintes, comme il n'y a pas de paires (constraint_id, table_name) dans t_criteria_director qui ne soient pas référencées par un t_constraint_x augmenté.
L'appel de la colonne table_name montre un biais orienté implémentation de l'EAV car cette colonne est un type/variant discriminator/tag dans le sens ER que les types d'entités représentés par les identifiants dans les tables t_criteria_x sont des "sous-types" du type d'entité représenté par t_criteria_director. (Il s'agit également d'un concept/technique des structures de données d'enregistrement 3GL utilisées pour simuler dynamiquement le typage.) Après tout, la valeur de la colonne table_name n'a pas besoin d'être un nom de table, il doit juste s'agir d'une valeur qui identifie le sous-type d'entité, et ces entités ne doivent pas seulement participer à la relation/association d'une table. (Recherche SQL/base de données/sous-typage ER/polymorphisme/héritage et l'anti-modèle de conception deux/plusieurs/multiples FK [sic] vers deux/plusieurs/multiples tables.)
Vous devez déterminer ce que sont les prédicats de table et quelles sont leurs contraintes par conséquent. De préférence en déterminant quelle est la table simple qu'ils représentent collectivement et quel est son prédicat et quelles sont les contraintes de base de données qui l'utilisent. Ensuite, vous devez décider si par coût/bénéfice vous allez modifier votre conception pour rendre les contraintes déclaratives et/ou vous allez ou non appliquer des contraintes via des déclencheurs.
