🗄️ SQL и базы данных · 20 вопросов · ~38 мин · ⏱ Таймер 38:00 · Средний ·

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

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

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 38 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

В системе доставки заказ имеет много изменений статуса. Что лучше хранить отдельно?

orders(id, current_status)
order_status_events(order_id, status, changed_at)

Один столбец status с последним значением и никакой истории Список статусов через запятую Таблицу order_status_events с заказом, статусом и временем Столбцы status1, status2, status3

Вопрос 2 из 20

Что является самостоятельной сущностью в библиотеке?

Правило оформления кнопки выдачи, одинаковое для всех экземпляров Подпись столбца автора Экземпляр книги, который имеет свой штрихкод и состояние Вычисленное число дней просрочки

Вопрос 3 из 20

Почему адрес доставки заказа часто стоит хранить как снимок, а не только ссылку на текущий адрес клиента?

orders(id, customer_id, delivery_address_snapshot)
customers(id, current_address_id)

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

Вопрос 4 из 20

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

products(id, images text) products(id, image1, image2, image3) product_images(id, product_id, url, position) images(product_name)

Вопрос 5 из 20

Нужно ли хранить age, если есть birth_date?

Возраст стоит хранить, чтобы все отчёты использовали одно значение до следующего ручного пересчёта Возраст нельзя вычислить, потому что числовые значения не связаны с датами Да, birth_date нельзя сравнивать Обычно нет: возраст меняется со временем и вычисляется на дату

Вопрос 6 из 20

Как моделировать товары и заказы при связи многие-ко-многим?

orders(product_id UNIQUE) order_items(order_id, product_id, qty, price_at_order) products(order_id) orders(product_ids text)

Вопрос 7 из 20

Где хранить роль участника в проекте?

В названии внешнего ключа В projects как список ролей В project_memberships рядом с project_id и user_id В users как единственную роль на все проекты

Вопрос 8 из 20

Какой ключ разумен для таблицы subscriptions(user_id, channel_id)?

PRIMARY KEY (channel_id) PRIMARY KEY (user_id, channel_id) PRIMARY KEY (user_id) PRIMARY KEY (created_at)

Вопрос 9 из 20

Почему список tag_ids в одном поле статьи слабее таблицы article_tags?

Массив идентификаторов даёт те же ограничения целостности, если на весь столбец поставить UNIQUE Нельзя надёжно поставить внешний ключ и уникальность на каждый элемент Теги не являются сущностями Массивы не хранят числа

Вопрос 10 из 20

Когда отдельная таблица связи нужна даже при предполагаемой связи один-к-одному?

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

Вопрос 11 из 20

Как выразить обязательного автора у каждой книги?

author_id bigint NOT NULL REFERENCES authors(id) author_id bigint UNIQUE author_id bigint NULL REFERENCES authors(id) CHECK (author_id=0)

Вопрос 12 из 20

Как выразить необязательный профиль один-к-одному с пользователем?

profiles(user_id REFERENCES users(id)) users(profile_ids text) profiles(user_id UNIQUE NOT NULL REFERENCES users(id)) profiles(user_id, profile_id без ограничений)

Вопрос 13 из 20

Что означает nullable manager_id в employees?

NULL в manager_id автоматически означает ссылку на сотрудника с id = 0 Каждый сотрудник обязан иметь двух руководителей, один из которых может быть NULL Связь с руководителем может отсутствовать, например у главы организации Самоссылочный manager_id нельзя объявить внешним ключом на employees

Вопрос 14 из 20

Как разрешить не более одного текущего основного адреса на пользователя, сохранив старые адреса?

CREATE UNIQUE INDEX ON addresses(user_id) WHERE is_primary AND valid_to IS NULL ALTER TABLE addresses ADD UNIQUE (user_id); ALTER TABLE addresses ADD UNIQUE (user_id, valid_to); ALTER TABLE addresses ADD CHECK (user_id > 0 AND is_primary);

Вопрос 15 из 20

В связи «страна — города» где находится внешний ключ?

В обоих местах обязательно cities.country_id countries.city_id Только в индексе

Вопрос 16 из 20

Как хранить цену товара, действующую в интервале?

product_prices(product_id, price, valid_from, valid_to) products(price1, price2, price3) products(price_history text) orders(current_price)

Вопрос 17 из 20

Какое правило нужно для интервалов цен одного товара?

Цена должна быть одинаковой во всех интервалах одного товара Пересечения допустимы, если valid_from двух интервалов различается Каждая строка должна иметь valid_to = valid_from, чтобы интервал был однозначным Два интервала действия не должны пересекаться, если в момент времени допустима одна цена

Вопрос 18 из 20

Почему order_items.price_at_order не обязательно дублирует текущую products.price ошибочно?

Текущая цена товара неизменяема, поэтому отдельный снимок в позиции заказа не нужен Любое повторение цены полезно, даже если оно не имеет отдельного исторического смысла Это исторический снимок фактической цены сделки, а не копия текущего справочника Внешний ключ product_id автоматически синхронизирует price_at_order с каталогом

Вопрос 19 из 20

Столбец qty уже объявлен NOT NULL. Какой CHECK запретит нулевое и отрицательное количество позиции?

FOREIGN KEY(qty) REFERENCES orders(id) CHECK (qty > 0) CHECK (qty <> NULL) UNIQUE(qty)

Вопрос 20 из 20

Почему бизнес-правило «в заказе должна быть хотя бы одна позиция» нельзя полностью выразить одним CHECK в orders?

Правило стало бы допустимым в CHECK, если orders.id был бы составным ключом CHECK видит позиции заказа, но не может посчитать их до завершения COMMIT Оно зависит от наличия строк в другой таблице и момента транзакции CHECK поддерживает boolean только для столбцов той же таблицы без NULL

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу