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

Если допустимость каждой тройки «поставщик — деталь — проект» полностью определяется тремя попарными связями, какую нормализационную проблему выявляет хранение троек в одной таблице?

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

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

CREATE TABLE app_user (
    user_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    username TEXT NOT NULL UNIQUE
);

INSERT INTO app_user (username) VALUES ('Alice');
INSERT INTO app_user (username) VALUES ('alice');

Как на уровне схемы гарантировать, что платёж связан ровно с одним типом документа: заказом или возвратом?

У связи «студент — курс» есть атрибут «дата зачисления». Где хранить его в нормализованной схеме?

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

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

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

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

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