Как выразить это ограничение в схеме базы данных?

Question

У меня есть следующие функциональные зависимости, которые находятся в BCNF:

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

С дополнительным ограничением, что нет a а также b следует сочетать с c, куда a а также b иметь разные dс

Пример:

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

Первый ряд в a,b,c позволено (1->3,5->3), но второй ряд запрещен, так как (2->4,5->3) 4 != 3.

Это дополнительное ограничение может иметь два эффекта на мои данные. Для каждого a,b,c Есть два избыточных способа определения d. Анкет Могут быть данные, которые нарушают ограничение. Как моя схема может отразить это дополнительное ограничение?

Answer 1

В двух словах, создайте ASSERTION Чтобы гарантировать, что ни разу не может быть нарушено деловое правило, например, полный стандартный синтаксис 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 
                                        )
                     )
         );

Плохая новость в том, что не коммерческая (или иначе?) SQL Product Supports CREATE ASSERTION.

Большинство промышленных промышленных продуктов SQL Triggers: можно реализовать вышеизложенное в триггере в каждой применимой таблице. Анкет MS Access - единственный коммерческий продукт, который я знаю, который поддерживает подразделы в CHECK Ограничения, но я не считаю, что это промышленной силой. Существуют дальнейшие обходные пути, например, заставляя пользователей обновлять таблицы только с помощью хранимых процедур, которые можно показать, чтобы никогда не покидать базу данных в незаконном состоянии.

Answer 2

В двух словах d в третью таблицу, чтобы включить ванильные ограничения иностранного ключа, например, переходной синтаксис 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

«Так твой ответ" это невозможно "?"

Многое возможно. В вашем конкретном случае это похоже на то, что для обеспечения соблюдения вашего «дополнительного» ограничения может быть достигнуто, сохранив базу данных одним столом (4-колонна). Это гарантирует вам, что любой комбинированный A, B всегда будет соответствовать одному и тому же D (потому что когда -либо может быть только один D). Цена, которую вы платите, заключается в том, что больше нет «естественного» способа (т.е. тот, который является непосредственным следствием самой логической структуры самой базы данных), которая автоматически обеспечит ваш A-> D и B-> D FDS «автоматически» Анкет

Это хорошо известный факт, что классический процесс нормализации-проведенной декорации иногда требует, чтобы определенные FD были восстановлены в качестве ограничения в базе данных, потому что в разложенном дизайне правило больше не может быть заявлено в качестве FD. Ваш конкретный случай, кажется, является одним из таких, где у вас есть выбор между дизайном, который «автоматически» обеспечивает соблюдение A-> d и b-> d, но где вам нужно сделать дополнительные усилия для обеспечения соблюдения дополнительных ограничений или дизайна, который «Автоматически» обеспечивает соблюдение вашего дополнительного ограничения, но где вам нужно выполнять дополнительную работу, чтобы обеспечить соблюдение [ограничений, соответствующих] вашим A-> D и B-> D FDS.

Наличие всех ограничений, которые вы упоминаете, применяемые просто структурой базы данных, возможно, в вашем конкретном случае с использованием решения OneDaywhen. Однако (а) это только решение для конкретных случаев, таких как ваш пример, (б) цена, которую вы платите, является повышенной избыточностью, и, следовательно, дополнительная сложность в обновлении вашей базы данных (и некоторые обновления могут быть невозможно достичь !!!) и (c) все еще остается фактом, что не все возможные ограничения базы данных выражаются как FD.

(Извините за то, что опубликовал второй ответ. Мой логин Stackoverflow не позволяет мне комментировать здесь.)