Проектирование схемы и ограничения

В таблице заказов адрес клиента хранится в каждой строке заказа. Какое свойство нормализованной схемы нарушено, если адрес должен быть единственным для клиента?

Можно ли связать дочернюю сущность внешним ключом с обычным неуникальным столбцом родительской таблицы?

Разработчик добавил ограничение, требующее, чтобы скидка была неотрицательной. Почему строка с отсутствующей скидкой может пройти такую проверку?

Как обеспечить уникальность бизнес-идентификатора, если первичный ключ таблицы — искусственный?

В таблице связей пользователей с ролями внешние ключи настроены, но одна и та же пара может быть записана повторно. Какое ограничение предотвращает такую дубликацию?

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

Как внешний ключ должен вести себя при удалении родительской строки, если зависимые записи нельзя терять?

В системе переводов исходный счёт у операции может отсутствовать, но если он указан, должны быть заданы обе части его составного ключа. Что именно гарантирует MATCH FULL в этой схеме?

CREATE TABLE account (
    country_code CHAR(2) NOT NULL,
    account_no VARCHAR(20) NOT NULL,
    owner_name VARCHAR(100) NOT NULL,
    PRIMARY KEY (country_code, account_no)
);

CREATE TABLE transfer (
    transfer_id INTEGER PRIMARY KEY,
    src_country CHAR(2),
    src_account VARCHAR(20),
    FOREIGN KEY (src_country, src_account)
        REFERENCES account (country_code, account_no)
        MATCH FULL
);

При разбиении таблицы на две какие свойства нужно проверить, чтобы их обратное соединение не создавало ложных строк?

Объясните, как отложенная проверка внешнего ключа позволяет сохранить взаимозависимые записи в одной транзакции.

Представьте таблицу клиентов, где поле электронной почты допускает отсутствие значения и имеет ограничение уникальности. Почему несколько строк без электронной почты могут одновременно существовать, не нарушая это ограничение?

Разберите ошибку проектирования: правило «в отделе не может быть более одного руководителя» пытаются задать проверкой значения в строке. Почему такой подход не гарантирует правило на уровне таблицы?

В таблице заказов хранятся идентификатор заказа, идентификатор клиента и кредитный лимит клиента; кредитный лимит определяется клиентом, а не заказом. Какую зависимость следует устранить разбиением таблицы и к чему приводит её сохранение?

Представьте таблицу сотрудника, где каждая строка содержит одну комбинацию его навыка и сертификата, хотя эти два множества независимы. Какую нормализационную проблему создаёт такая модель?

Когда намеренная денормализация реляционной схемы оправдана?

Объясните механизм, при котором отношение проходит проверку третьей нормальной формы, но нарушает нормальную форму Бойса—Кодда.

У заказа естественный идентификатор может измениться после создания. Чем опасно использовать его как первичный ключ?

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

Разработчик меняет значение первичного ключа родительской строки. Как настроенное каскадное обновление внешнего ключа сохраняет ссылочную целостность дочерних строк?

Сервис бронирований должен запретить пересечение интервалов аренды одного помещения. Какое ограничение схемы выражает это правило надёжнее проверки в приложении?