При каком условии таблица будет в нормальной форме Бойса-Кодда

Нормальная форма Бойца-Кодда (BCNF)

Нормальная форма Бойца-Кодда (Boyce-Codd Normal Form, BCNF) — это самая строгая форма нормализации в реляционных БД. Таблица находится в BCNF, если она удовлетворяет одному условию.

Главное условие BCNF

Для каждой функциональной зависимости A → B, A должен быть суперключом (candidate key).

Другими словами:

• Любой атрибут должен зависеть ТОЛЬКО от первичного ключа
• Не может быть зависимостей между неключевыми атрибутами
• Каждый атрибут однозначно определяется только ключом

Формальное определение

Таблица находится в BCNF если:

Для каждой функциональной зависимости X → Y:

1. X это суперключ (содержит первичный ключ), ИЛИ
2. Y это часть ключа X

Таблица в BCNF = 3NF + дополнительные ограничения на ключи

Пример: Таблица НЕ в BCNF

CREATE TABLE professor_courses (
    professor_id INT,
    course_id INT,
    department_id INT,
    PRIMARY KEY (professor_id, course_id)
);

Проблема: Функциональная зависимость department_id → professor_id

Профессор назначен в определённый departament, поэтому:

• Если профессор professor_id = 1
• То department_id = 10 (одно значение)

НО department_id это НЕ суперключ! Это нарушает BCNF.

Пример: Таблица В BCNF

До нормализации (нарушение BCNF):

CREATE TABLE professor_schedule (
    professor_id INT,
    course_id INT,
    time_slot VARCHAR(50),
    room_id INT,
    PRIMARY KEY (professor_id, course_id)
);

Функциональные зависимости:

• (professor_id, course_id) → (time_slot, room_id) ✓ ключ
• (professor_id, time_slot) → room_id ✓ ключ

После нормализации (BCNF):

-- Таблица 1: Назначения курсов
CREATE TABLE professor_courses (
    professor_id INT,
    course_id INT,
    PRIMARY KEY (professor_id, course_id)
);

-- Таблица 2: Расписание
CREATE TABLE course_schedule (
    course_id INT,
    time_slot VARCHAR(50),
    room_id INT,
    PRIMARY KEY (course_id, time_slot)
);

Теперь каждая таблица в BCNF:

• professor_courses: первичный ключ (professor_id, course_id)
• course_schedule: первичный ключ (course_id, time_slot)

Сравнение NF: 1NF → 2NF → 3NF → BCNF

1NF (Первая нормальная форма)
↓ Удалить частичные зависимости
2NF (Вторая нормальная форма)
↓ Удалить транзитивные зависимости  
3NF (Третья нормальная форма)
↓ Сделать все ключи суперключами
BCNF (Бойца-Кодда)

Пример разницы между 3NF и BCNF

Эта таблица находится в 3NF, но НЕ в BCNF:

CREATE TABLE student_advisor (
    student_id INT PRIMARY KEY,
    major_id INT,
    advisor_id INT
);

Функциональные зависимости:

• student_id → major_id
• student_id → advisor_id
• major_id → advisor_id (один консультант на major)

Проблема: Функциональная зависимость major_id → advisor_id

major_id это НЕ суперключ, но он определяет advisor_id. Это нарушает BCNF!

Исправление (BCNF):

-- Таблица 1: Студент и специальность
CREATE TABLE student_major (
    student_id INT PRIMARY KEY,
    major_id INT
);

-- Таблица 2: Специальность и консультант
CREATE TABLE major_advisor (
    major_id INT PRIMARY KEY,
    advisor_id INT
);

Теперь:

• student_major: major_id → advisor_id исчезла из этой таблицы
• major_advisor: major_id это суперключ
• Обе таблицы в BCNF ✓

Как проверить, в BCNF ли таблица

Алгоритм:

1. Идентифицируй все функциональные зависимости
2. Для каждой зависимости A → B проверь:
   • A является ли суперключом? → BCNF ✓
   • A является ли ключом (candidate key)? → BCNF ✓
   • B является ли частью A? → BCNF ✓
   • Иначе → НЕ BCNF ✗

Пример проверки:

Таблица: employees (id, name, department_id, department_name)

Функциональные зависимости:
1. id → name: id это PRIMARY KEY → BCNF ✓
2. id → department_id: id это PRIMARY KEY → BCNF ✓
3. department_id → department_name: 
   department_id это НЕ суперключ → BCNF ✗

Ошибка! Таблица НЕ в BCNF.

Практический пример из real world

Таблица запись к врачу (НЕ в BCNF):

CREATE TABLE doctor_appointment (
    appointment_id INT PRIMARY KEY,
    doctor_id INT,
    patient_id INT,
    clinic_id INT,
    clinic_name VARCHAR(100),
    time DATETIME
);

Проблема: clinic_id → clinic_name

clinic_id определяет clinic_name, но clinic_id не суперключ. Это нарушение BCNF.

Исправление:

-- Таблица 1: Клиники
CREATE TABLE clinic (
    clinic_id INT PRIMARY KEY,
    clinic_name VARCHAR(100)
);

-- Таблица 2: Запись к врачу
CREATE TABLE doctor_appointment (
    appointment_id INT PRIMARY KEY,
    doctor_id INT,
    patient_id INT,
    clinic_id INT FOREIGN KEY REFERENCES clinic(clinic_id),
    time DATETIME
);

Теперь обе таблицы в BCNF.

BCNF в реальных приложениях

Преимущества BCNF:

• Исключает аномалии обновления
• Исключает избыточность данных
• Гарантирует консистентность

Недостатки BCNF:

• Требует больше таблиц
• Требует больше JOIN-ов при запросах
• Может снизить производительность

В практике часто останавливаются на 3NF, потому что BCNF может привести к чрезмерной нормализации.

Вывод

Таблица в BCNF когда для каждой функциональной зависимости A → B, левая часть A является суперключом.

Это означает:

• Нет нефункциональных зависимостей
• Все атрибуты зависят ТОЛЬКО от ключа
• Максимальная нормализация

BCNF это идеал, но требует баланса между нормализацией и производительностью.