МДК.11.01 - QUIZ. Задания для самопроверки

UNF

Представленная таблица находится в UNF, потому что у нас есть неатомарные значения в колонке items_bought, где несколько товаров записаны в одной ячейке.

2NF

Таблица находится как минимум в 1NF, так как данные атомарны. Но есть частичная зависимость: атрибут project_manager зависит только от project_id, а не от всего составного ключа (project_id + task_id).
Следовательно, таблица нарушает требования 3NF, но полностью соответствует условиям 2NF.

1NF

Представленная таблица находится в 1NF, так как все атрибуты содержат атомарные значения, и каждая запись уникальна.

BCNF

Представленные таблицы находятся в BCNF, потому что в таблице аренды составной ключ (car_id + rental_date) определяет все атрибуты, и нет транзитивных зависимостей. Две другие таблицы (клиентов и автомобилей) технически находятся в 3NF, так как в них все неключевые атрибуты зависят только от ключей. Однако, поскольку таблица аренды находится в BCNF, принято считать, что и вся база данных соответствует BCNF.

3NF

Представленные таблицы находятся в 3NF, потому что они удовлетворяют требованиям 2NF, и нет транзитивных зависимостей. Каждая таблица хранит только те данные, которые напрямую зависят от её первичного ключа. В таблице заказов все неключевые атрибуты зависят только от order_id, а в таблице клиентов — от customer_id.

DKNF

Таблица регистрации студентов на курсы находится в DKNF, потому что все ограничения основаны на ключах и доменах.

• Ограничение по ключам:
  • комбинация student_id и course_id уникальна для каждой записи.
• Доменные ограничения:
  • Для каждого студента есть ограничение по количеству курсов, которые он может выбрать selected_courses <= max_courses.
  • Для каждого курса установлено максимальное количество студентов max_students.

Здесь нет зависимостей, которые противоречат ограничениям доменов. Все зависимости, включая количество курсов и количество студентов, контролируются как ключами, так и доменными правилами, что соответствует доменно-ключевой нормальной форме DKNF. Другие таблицы (студентов и курсов) находятся в 3NF, но вся база считается соответствующей DKNF, потому что таблица регистрации удовлетворяет требованиям DKNF.

5NF

Таблица этапов производства находится в 5NF, потому что в ней есть трёхсторонняя зависимость: товар ↔ этап ↔ поставщик.

• У каждого товара несколько этапов.
• Каждый этап может выполняться разными поставщиками.
• У товара может быть несколько поставщиков.

Если разложить такие данные только на пары (товар-этап, этап-поставщик, товар-поставщик), то при соединении мы получим лишние комбинации, которых в реальности нет.

Поэтому мы должны хранить именно комбинацию product_id + stage_id + supplier_id — это и есть пример ситуации для 5NF.

Остальные таблицы (продукты, этапы, поставщики) находятся как минимум в 3NF. Но база данных в целом считается находящейся в 5NF, так как самая сложная таблица соответствует этой нормальной форме.

5NF — данные нельзя разделить на пары, нужно хранить именно тройки.

4NF

Таблица поставок находится в 4NF, потому что у товара есть две независимые многозначные зависимости:

• один товар может поставляться в несколько магазинов,
• один товар может иметь нескольких поставщиков.

Каждая строка — это комбинация трёх значений: product_id, store_id, supplier_id. Здесь нет сложной «трёхсторонней» зависимости, как в случае с производством.

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

Поэтому достаточно требований 4NF.

4NF — данные можно разделить на пары без потерь.

6NF

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

Добавлено доменное ограничение:

• для каждого сотрудника в конкретный период должно быть отработано минимум 30 и максимум 50 часов.
• зависимости управляются как ключами (employee_id, work_period), так и доменами (ограничения по количеству часов работы).

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

Эти данные не находятся даже в UNF.

Про такие данные обычно говорят что это т.н. «сырые данные» (RAW DATA), которые требуют предварительной обработки перед тем как с ними можно будет начать работать средствами какой-либо СУБД.

• У строк нет фиксированного набора атрибутов.
• Используются разные форматы (текст, JSON, смешанные записи).
• Несколько сущностей (клиент, товары, оплата) объединены в одной ячейке.
• Нельзя выделить корректный ключ.