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

Нормализация базы данных

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

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

⏱ --:--

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

Вопрос 1 из 20

Какое правило выражает зависимость order_id → order_date?

Зависимость означает, что order_id и order_date должны иметь одинаковый тип данных У каждого заказа одна определённая дата Дата определяет клиента У каждой даты только один заказ

Вопрос 2 из 20

Можно ли доказать зависимость city → postal_code только потому, что в текущих десяти строках города не повторились?

SELECT city, postal_code FROM addresses;

Да, любой текущий набор доказывает правило Нет, потому что строки нельзя сравнивать Да, если есть ORDER BY Нет, правило должно следовать из предметной области

Вопрос 3 из 20

В таблице order_items ключ (order_id, product_id). От чего зависит qty?

CREATE TABLE order_items (
 order_id bigint,
 product_id bigint,
 qty integer,
 PRIMARY KEY (order_id, product_id)
);

Только от order_id От названия товара От всей пары order_id и product_id Только от product_id

Вопрос 4 из 20

Какая зависимость показывает лишнее хранение customer_name в orders, если customer_id определяет имя клиента?

customer_name определяет customer_id, потому что имя показано рядом с идентификатором order_id определяет customer_name напрямую и не зависит от customer_id customer_id и customer_name независимы, если у orders есть первичный ключ order_id → customer_id и customer_id → customer_name

Вопрос 5 из 20

Какое изменение выявляет аномалию обновления?

orders(order_id, customer_id, customer_name, order_date)

Вставка нового заказа для уже известного клиента без изменения его имени Сортировка отчёта по имени клиента после соединения с таблицей заказов Добавление индекса по customer_id для ускорения поиска заказов Смена имени клиента требует исправить множество заказов

Вопрос 6 из 20

Что проблемно в phones = '555-1,555-2'?

CREATE TABLE customers (
 id bigint PRIMARY KEY,
 phones text
);

Телефонный номер обязательно должен иметь числовой тип, поэтому text нарушает первую нормальную форму Несколько телефонов смешаны в одном значении Запятая является недопустимым символом для значения реляционного столбца Проблема только в длине строки; при text[] поиск и ограничения останутся теми же

Вопрос 7 из 20

Какая схема лучше хранит несколько телефонов клиента?

customer_phones(customer_id, phone, type) customers(id, phones text) customers(id, phone_count) customers(id, phone1, phone2, phone3)

Вопрос 8 из 20

Почему phone1, phone2, phone3 — повторяющаяся группа?

Один тип факта размножен по заранее ограниченным колонкам Отсутствие отдельного PRIMARY KEY не позволяет хранить телефонные номера Одинаковый тип трёх столбцов делает их функционально зависимыми друг от друга Цифры в названиях столбцов нарушают синтаксис первой нормальной формы

Вопрос 9 из 20

Всегда ли JSON-массив нарушает разумный дизайн?

CREATE TABLE documents (
  id bigint PRIMARY KEY,
  payload jsonb NOT NULL
);

Нет: любой JSON-массив автоматически раскладывается СУБД на связанные строки Да: массив нарушает дизайн уже при наличии второго элемента, независимо от операций Нет, решение зависит от операций над элементами Да: реляционная база не допускает хранение документов и массивов как единого значения

Вопрос 10 из 20

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

UNIQUE (type) UNIQUE (customer_id, phone) CHECK (phone <> phone) PRIMARY KEY (customer_id)

Вопрос 11 из 20

Какое поле нарушает вторую нормальную форму в таблице с ключом (order_id, product_id)?

order_items(order_id, product_id, product_name, qty)

line_total, если вычисляется из qty и price product_name, если зависит только от product_id qty, если зависит от всей пары discount, если определяется парой

Вопрос 12 из 20

В order_items с ключом (order_id, product_id) поле product_name зависит только от product_id. Какая декомпозиция устраняет эту частичную зависимость?

order_items(order_id, product_id, product_name, qty)

order_items(order_id, product_id, qty) и products(product_id, product_name) orders(order_id, product_name) и order_items(product_id, qty)orders(order_id, product_name) products(order_id, qty) и order_items(product_id, product_name)products(order_id, qty) order_items(order_id, product_name, qty) и products(product_id)order_items(order_id, product_name, qty)

Вопрос 13 из 20

В employees(department_id, department_name) имя отдела зависит от department_id. Какой риск повторения?

Переименование отдела может оставить разные department_name в строках сотрудников Сортировка сотрудников по department_name станет синтаксически невозможной department_id может стать NULL при переименовании отдела JOIN между сотрудниками и отделами перестанет использовать индекс

Вопрос 14 из 20

Какая схема ближе к третьей нормальной форме?

employees(id, department_name1, department_name2) employees(id, department_id) и departments(id, name) employees(id, department_id, department_name) departments(employee_id, employee_name)

Вопрос 15 из 20

Почему декомпозиция должна быть соединением без потерь?

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

Вопрос 16 из 20

Когда хранение order_total рядом с позициями может быть оправдано?

orders(id, stored_total)
order_items(order_id, qty, price)

Когда итог никто не читает и его значение не участвует ни в одном запросе Хранимый итог предпочтительнее вычисления SUM, если таблица позиций содержит больше одной строки Только в системе без транзакций, где рассогласование не может быть замечено После измерений и при надёжном обновлении итога

Вопрос 17 из 20

Почему копирование customer_name в orders ради одного отчёта опасно?

Копия имени создаёт каскадное удаление клиента при удалении заказа Повтор текста опасен только тем, что строки таблицы становятся физически короче Имя может измениться, и нужно решить, хранится исторический снимок или актуальная копия Текстовое имя нельзя соединять через JOIN, поэтому его приходится копировать в заказ

Вопрос 18 из 20

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

Удалить ограничения Измерить реальный узкий запрос и его план Добавить копии всех столбцов Заменить ключи строками

Вопрос 19 из 20

Как поддержать materialized customer_order_total без тихого рассогласования?

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

Вопрос 20 из 20

Что означает осознанная денормализация?

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

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

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

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

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