Ограничения уникальности в MS Access

Такие ограничения действительно могут быть реализованы в ACE/JET с использованием CHECK ограничений.

Человек, который сказал, что обычно использует триггеры для подобных вещей, не знает о разнице между ограничениями CHECK в ACE/Jet и SQL Server соответственно: в SQL Server они не могут включать подзапросы, то есть они не могут ссылаться на значения в других строки в той же таблице или в другие таблицы, тогда как в ACE/Jet это возможно.

В идеальном (но пока еще несуществующем) продукте SQL-92 описанная уникальность будет реализована с использованием ASSETION на уровне схемы. Поскольку ограничения CHECK находятся на уровне таблицы и проверяются только в том случае, если таблица, в которой они определены, имеет значение UPDATEd или INSERTed, вам потребуется установить соответствующие ограничения CHECK для всех ссылающихся таблиц (то же самое применимо к триггерам SQL Server). Вот краткий пример:

CREATE TABLE Parent 
(
   parent_ID INTEGER NOT NULL IDENTITY UNIQUE, 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Child1
(
   parent_ID INTEGER NOT NULL
      REFERENCES parent (parent_ID), 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Child2
(
   parent_ID INTEGER NOT NULL
      REFERENCES parent (parent_ID), 
   data_col INTEGER NOT NULL
)
;
ALTER TABLE Child1 ADD
   CONSTRAINT child1__no_dups_in_child2
   CHECK (NOT EXISTS (
                      SELECT * 
                        FROM Child1 AS C1
                             INNER JOIN Child2 AS C2
                                ON C1.parent_ID = C2.parent_ID
                     ))
;
ALTER TABLE Child2 ADD
   CONSTRAINT child2__no_dups_in_child1
   CHECK (NOT EXISTS (
                      SELECT * 
                        FROM Child1 AS C1
                             INNER JOIN Child2 AS C2
                                ON C1.parent_ID = C2.parent_ID
                     ))
;

Однако мне интересно, есть ли у вас подклассы (т.е. каждая сущность, представленная идентификатором, может быть типизирована), и в этом случае вы должны иметь возможность использовать ограничения FOREIGN KEYs и CHECK на уровне строки (или правила проверки, если вам удобнее использовать Интерфейс MS Access, чем SQL DLL, который требуется для CHECK ограничений). Логику будет проще реализовать, чем CHECK ограничения на уровне таблицы, просто следите за циклами в CASCADE ссылочных действиях. Вот еще один простой пример:

CREATE TABLE Parent 
(
   parent_ID INTEGER NOT NULL IDENTITY, 
   child_type VARCHAR(4) NOT NULL, 
   CONSTRAINT child_type__values 
      CHECK (child_type IN ('Boy', 'Girl')), 
   UNIQUE (child_type, parent_ID)
)
;
CREATE TABLE Girls
(
   parent_ID INTEGER NOT NULL, 
   child_type VARCHAR(4) DEFAULT 'girl' NOT NULL, 
   CONSTRAINT girl_child_type__must_be_girl
      CHECK (child_type = 'girl'),
   FOREIGN KEY (child_type, parent_ID)
      REFERENCES Parent (child_type, parent_ID), 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Boys
(
   parent_ID INTEGER NOT NULL, 
   child_type VARCHAR(4) DEFAULT 'boy' NOT NULL, 
   CONSTRAINT boy_child_type__must_be_boy
      CHECK (child_type = 'boy'),
   FOREIGN KEY (child_type, parent_ID)
      REFERENCES Parent (child_type, parent_ID), 
   data_col INTEGER NOT NULL
)
;

Движок Microsoft ACE/Jet не поддерживает триггеры, как вы обычно реализуете этот тип функциональности.

РЕДАКТИРОВАТЬ: Как указал @onedaywhen, JET 4.0 и выше поддерживает проверочные ограничения, но реализовать ограничение типа xor для двух столбцов непросто.

Если вы используете формы доступа, вы можете реализовать событие перед обновлением формы и проверить критерии ограничений.

Митч прав насчет того, что возможно в Access. Однако, если предположить, что у вас где-то есть BL, это приближается к тому, что является законным бизнес-правилом. Это то, что я, скорее всего, сделал бы.

Учитывая, что вы разрабатываете эту базу данных. Вы уверены, что структуры ваших таблиц соответствуют стандартным правилам нормализации.

Звучит необычно для строки в таблице A, чтобы иметь возможность ссылаться на две строки в таблице Measurements в зависимости от того, какое поле A.row вы просматриваете. У меня такое ощущение, что данные в таблице «Измерения» действительно нужно разделить на две или более таблиц.

Я сам настороженно отношусь к триггерам и ограничениям проверки, в основном потому, что я разрабатывал большинство своих приложений без них (Access/Jet и MySQL/MyISAM). Я согласен с BobClegg, что это похоже на ситуацию супертипа/подтипа. В этом случае вы должны использовать таблицу соединений с уникальным индексом внешнего ключа и столбцом, указывающим тип измерения. Уникальный индекс FK предотвратит добавление второго типа. Это также означало бы, что в вашей основной записи не будет пустых полей. Конечно, одно пустое числовое поле не является проблемой хранения, но два исключительных поля всегда кажутся мне ошибкой дизайна.