Проектирование реляционных баз данных: аномалии, функциональные зависимости и нормализация (1NF, 2NF, 3NF)

При проектировании баз данных наивный подход часто приводит к созданию одной огромной 'универсальной' таблицы, куда складываются все атрибуты сущностей (например, студент, его группа, куратор, номер кабинета куратора и название сданного экзамена). Такой подход порождает избыточность данных (дублирование) и три критические аномалии модификации:

1. Аномалия вставки (Insertion Anomaly): невозможно добавить куратора или курс в систему до тех пор, пока на него не записан хотя бы один студент (первичный ключ студента не может быть NULL).

2. Аномалия удаления (Deletion Anomaly): если единственный студент группы отчисляется и его запись удаляется, безвозвратно теряются данные о самой группе, кураторе и кабинете.

3. Аномалия обновления (Update Anomaly): если куратор меняет номер кабинета, необходимо обновить сотни строк для каждого студента его группы. Если хотя бы одна строка будет пропущена, база данных придет в состояние логической несогласованности.

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

Таблица находится в Первой нормальной форме (1NF), если:

1. В каждом поле каждого кортежа (строки) содержится ровно одно атомарное (неделимое) значение.

2. В таблице отсутствуют повторяющиеся группы или массивы в рамках одной строки (например, поле 'Телефоны' не должно содержать строку '8701111; 8702222').

3. У таблицы определен первичный ключ (простой или составной), однозначно идентифицирующий каждую строку.

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

Таблица находится во Второй нормальной форме (2NF), если:

1. Она уже находится в Первой нормальной форме (1NF).

2. Каждый неключевой атрибут функционально полно зависит от всего первичного ключа в целом, а не от его части.

Требование 2NF актуально для таблиц с составным первичным ключом (ключом, состоящим из двух и более колонок). Если первичный ключ состоит из (Student_ID, Course_ID), а поле Course_Title зависит исключительно от Course_ID, то это частичная функциональная зависимость.

Для приведения к 2NF атрибуты, зависящие от части ключа, выносятся в отдельную таблицу (в данном примере — справочник Courses со своим ключом Course_ID).

Таблица находится в Третьей нормальной форме (3NF), если:

1. Она находится во Второй нормальной форме (2NF).

2. Ни один неключевой атрибут не зависит транзитивно от первичного ключа.

Транзитивная зависимость возникает, когда первичный ключ X определяет неключевой атрибут Y, а атрибут Y, в свою очередь, определяет другой неключевой атрибут Z (X -> Y и Y -> Z, следовательно, X -> Z).

Классический пример: в таблице Студентов с первичным ключом Student_ID хранятся поля Group_ID и Group_Specialty. Первичный ключ определяет группу, а группа определяет специальность. Специальность зависит от Student_ID транзитивно через Group_ID. Приведение к 3NF требует выноса Group_ID и Group_Specialty в отдельную таблицу Groups.