Краткий ответ

Такая модель нарушает четвёртую нормальную форму (4НФ) из-за независимых многозначных зависимостей: сотрудник может иметь множество навыков и независимо множество сертификатов. Если хранить их в одной таблице, появляется искусственное декартово произведение значений, поэтому независимые факты следует разделить на отдельные отношения.

Исторический контекст

Первые нормальные формы устраняли повторяющиеся группы и зависимости неключевых атрибутов от части или всего ключа. Однако даже таблица в 3НФ или НФ Бойса—Кодда может дублировать данные, если для одной сущности существуют несколько независимых многозначных фактов.

4НФ была введена для более точного описания такой ситуации. Её цель — не допустить, чтобы независимые множества значений хранились как комбинации в одном отношении и тем самым порождали избыточность.

Постановка проблемы

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

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

Подробное решение

Проблема выражается многозначными зависимостями: сотрудник определяет множество навыков и отдельно множество сертификатов, но навык не определяет сертификат. Если детерминант такой зависимости не является сверхключом, отношение не соответствует 4НФ.

Обычно таблицу разделяют на две связи «сотрудник—навык» и «сотрудник—сертификат»:

CREATE TABLE employee_skill (
    employee_id INTEGER,
    skill_id INTEGER,
    PRIMARY KEY (employee_id, skill_id)
);

CREATE TABLE employee_certificate (
    employee_id INTEGER,
    certificate_id INTEGER,
    PRIMARY KEY (employee_id, certificate_id)
);

Каждый факт хранится один раз, а составные первичные ключи запрещают повторение одной связи. Внешние ключи на employee_id, skill_id и certificate_id дополнительно обеспечивают ссылочную целостность; в реальной схеме их следует добавить к соответствующим таблицам-справочникам.

Разделение корректно, если множества действительно независимы и исходное отношение можно восстановить соединением без потери фактов. Если же сертификат подтверждает конкретный навык или связь между навыком и сертификатом имеет собственный смысл, разбиение на две таблицы будет неверным: нужна отдельная таблица такой связи.

Ситуация из практики

В HR-системе в одной таблице хранили сотрудника, навык и сертификат. При добавлении навыка число строк быстро росло как произведение количества навыков и сертификатов, а импорт данных регулярно создавал дубли.

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

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

Что кандидаты часто упускают

Вопрос: Достаточно ли наличия двух атрибутов, зависящих от одного сотрудника, чтобы утверждать нарушение 4НФ?

Ответ: Нет. Нарушение возникает не из-за самого количества атрибутов, а из-за их независимых многозначных зависимостей. Если сертификат всегда связан с конкретным навыком, это не два независимых множества; их следует хранить как одну связь, возможно с дополнительными атрибутами.
Вопрос: Почему декомпозиция на две таблицы не должна автоматически считаться правильной?

Ответ: Она корректна только при сохранении смысла исходных данных. Если исходная строка описывала допустимую пару «навык—сертификат», независимое хранение уничтожит это ограничение и при соединении создаст недопустимые комбинации. Нужно проверить семантику зависимости, потерю информации и возможность восстановить исходные факты без ложных строк.
Вопрос: Всегда ли нарушение 4НФ требует физического разбиения таблицы?

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