Comment exprimer cette contrainte dans un schéma de base de données?

Question

Je les dépendances fonctionnelles suivantes, qui sont en BCNF:

a,b -> c
a -> d
b -> d

Avec la contrainte supplémentaire, qui ne a et b doivent être combinés avec un c, où a et b ont des ds.

Exemple:

a | d   b | d   a | b | c
-----   -----   ---------
1 | 3   5 | 3   1 | 5 | 6
2 | 4           2 | 5 | 7

La première ligne a,b,c est autorisée (1->3, 5->3), mais la deuxième rangée est interdite, puisque (2->4, 5->3) 4 != 3.

Cette contrainte supplémentaire peut avoir deux effets sur mes données. Pour chaque a,b,c il y a deux façons redondantes de déterminer la d. Il peut y avoir des données qui porte atteinte à la contrainte. Comment mon schéma tenir compte de cette contrainte supplémentaire?

Answer 1

En un mot, créer un ASSERTION pour faire en sorte que, à aucun moment la règle métier peut être violé par exemple Standard complète syntaxe SQL-92:

CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 UNIQUE (a, b, c)
);

CREATE ASSERTION no_a_and_b_should_be_combined_with_a_c_where_a_and_b_have_different_ds
   CHECK (
          NOT EXISTS (
                      SELECT *
                        FROM T3
                       WHERE NOT EXISTS (
                                         SELECT T1.d
                                           FROM T1
                                          WHERE T1.a = T3.a 
                                         INTERSECT        
                                         SELECT T2.d
                                           FROM T2
                                          WHERE T3.b = T3.b 
                                        )
                     )
         );

Les mauvaises nouvelles est que pas commercial (ou autrement?) Supports produit SQL CREATE ASSERTION.

La plupart des produits SQL puissance industrielle prennent en charge les déclencheurs: on pourrait mettre en œuvre ci-dessus dans un déclencheur sur chaque table applicable . MS Access est le seul produit commercial que je connaisse qui prend en charge les sous-requêtes dans les contraintes de CHECK mais je ne considère pas que ce soit de force industrielle. Il existe d'autres solutions de contournement par exemple forçant les utilisateurs à des tables de mise à jour uniquement via des procédures stockées qui peuvent être affichées à ne jamais quitter la base de données dans un état illégal.

Answer 2

En un mot, introduire d dans la troisième table pour permettre les clés étrangères par exemple la vanille Transition syntaxe SQL-92:

CREATE TABLE T1
(
 a INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, d)
);

CREATE TABLE T2
(
 b INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (b, d)
);

CREATE TABLE T3
(
 a INTEGER NOT NULL,
 b INTEGER NOT NULL, 
 c INTEGER NOT NULL, 
 d INTEGER NOT NULL, 
 UNIQUE (a, b, c),
 FOREIGN KEY (a, d) REFERENCES T1 (a, d), 
 FOREIGN KEY (b, d) REFERENCES T2 (b, d)
);

Answer 3

« Alors est votre réponse « il est impossible »? »

Beaucoup de choses sont possibles. Dans votre cas, très particulier, il me semble que l'application de votre contrainte « supplémentaire » peut être obtenue en gardant la base de données unique table (4-colonne). Cela vous garantit que tout combiné a, b correspondra toujours au même d (car il ne peut jamais être un seul d). Le prix que vous payez est qu'il n'y a plus un « naturel » façon (c.-à-un qui est une conséquence immédiate de la structure très logique de la base de données elle-même) qui mettra en application vos a-> d et b-> d FDs « automatiquement » .

Il est un fait bien connu que le processus classique de normalisation-par décomposition, nécessite parfois que certains IFD soient réintégrés comme une contrainte de base de données, parce que dans la décomposées conception de la règle ne peut plus être déclaré comme FD. Votre cas particulier semble être un tel, vous avez le choix entre un design qui « automatiquement » Enforces a-> d et b-> d, mais où vous devez faire un effort supplémentaire pour appliquer votre contrainte supplémentaire, ou une conception « automatiquement » fait respecter votre contrainte supplémentaire, mais où vous devez faire un travail supplémentaire pour faire respecter [les contraintes correspondant à] votre a-> d et b-> d IFD.

Avoir toutes les contraintes que vous mentionnez simplement par la structure FORCÉES de base de données, est possible, dans votre cas particulier, en utilisant la solution de onedaywhen. Cependant, (a) qui est seulement une solution pour des cas particuliers comme votre exemple, (b) le prix que vous payez augmente la redondance, et donc une complexité supplémentaire à mettre à jour votre base de données (et certaines mises à jour peuvent être impossibles à réaliser !!!) et (c) il reste un fait que toutes les contraintes de base de données sont envisageables exprimable comme FD.

(Désolé pour l'affichage d'une deuxième réponse. Ma Stackoverflow connexion ne me permet pas de commenter ici.)