Требуется ли первичный ключ в таблицах relvar 6NF отношения 5NF. Рассмотрим следующую схему:

-- The 5NF table
CREATE TABLE party_address(
    address_id int NOT NULL,
    party_id int NOT NULL,
    -- some other columns
    PRIMARY KEY (address_id, party_id)
);

CREATE TABLE party_address_is_billing(
    address_id int NOT NULL,
    party_id int NOT NULL,
    value boolean NOT NULL,
    transaction_time tstzrange NOT NULL DEFAULT tstzrange(CURRENT_TIMESTAMP, NULL, '[)'),
    EXCLUDE USING GIST (address_id WITH =, party_id WITH =, transaction_time WITH &&)
);

Требуется ли явное объявление PRIMARY KEY в таблице party_address_is_billing? Поскольку ограничение исключения задает уникальный идентификатор ((address_id, party_id, transaction_time)), явное указание PRIMARY KEY (address_id, party_id, transaction_time) кажется излишним. Это также создало бы дополнительный и ненужный индекс.

  • Каковы последствия отсутствия указания PRIMARY KEY в таблице?
0
Cochise Ruhulessin 18 Май 2013 в 15:23

1 ответ

Лучший ответ

Реляционная модель требует, чтобы каждое отношение имело хотя бы один ключ. Это не требует от вас использования определенных ключевых слов.

В вашей таблице 5NF, если вы объявите ключ как not null unique (address_id, party_id), вы вообще не измените лежащие в основе зависимости. И это то, о чем вы должны беспокоиться с реляционной точки зрения - этот альтернативный синтаксис не портит лежащие в основе зависимости. (Это означает, что реляционная модель не связана с «дополнительным и ненужным индексом» реализации.)

Итак, в "party_address_is_billing", если ограничение исключения ведет себя как ограничение ключа, я думаю, что с реляционной моделью все в порядке.

Каковы последствия отсутствия указания PRIMARY KEY в таблице?

  1. Если вы замените ограничение первичного ключа другим декларативным ограничением, поведение которого идентично, вы можете удивить программистов по обслуживанию. См. Статью Принцип наименьшего удивления.

  2. Вы также можете заставить программистов работать больше. Многие фреймворки требуют не только ограничения PRIMARY KEY, они также требуют, чтобы ограничение было суррогатным целым числом. (На самом деле это не проблема отношений.)

  3. Некоторые инструменты программной инженерии (CASE) могут подавиться ограничением исключения.

  4. Сообщение об ошибке, связанное с процессом, который нарушает ограничение исключения, может быть менее ясным, чем сообщение об ошибке о нарушении ограничения первичного ключа. (Это связано с цифрой "1" выше.)

Я не думаю, что это может иметь какие-либо последствия в отношении реляционной модели. (То есть до тех пор, пока вы заменяете ограничение первичного ключа декларативным ограничением, которое поведенчески идентично.)

2
Mike Sherrill 'Cat Recall' 18 Май 2013 в 19:29