Когда мы говорим об анализе базы данных на соответствие нормальным формам, мы имеем в виду изучение структуры таблиц, их взаимосвязей и зависимостей между атрибутами. Основная цель анализа — найти нарушения нормализации и оценить их влияние на производительность, целостность и удобство работы с данными.
Проще говоря, это как аудит бухгалтерии: вы проверяете, чтобы деньги не лежали как попало, а были строго распределены по нужным статьям расходов.
Практический подход к анализу базы данных
В любой базе данных мы начинаем с того, что задаем три принципиальных вопроса, соответствующих трем нормальным формам.
Предположим, у нас есть база данных склада с таблицей следующей структуры:
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Гвозди | СтройКомплект | +12301112233 | 150 |
| 2 | Шурупы | КрепёжПро | +12306667788 | 200 |
| 3 | Гайки | СтройКомплект | +12301112233 | 100 |
Как проверить эту таблицу на соответствие нормальным формам?
Напомню, таблица в 1NF, если:
- Каждая ячейка содержит одно значение.
- В таблице нет повторяющихся столбцов для одного и того же типа данных.
В нашем примере нарушения 1NF нет: каждая ячейка содержит атомарное значение. Это означает, что таблица приведена к 1NF. Ура! Можно двигаться дальше.
Таблица в 2NF, если:
- Она находится в 1NF.
- Все неключевые атрибуты зависят только от всего первичного ключа (а не от его части).
В данной таблице мы видим, что supplier_name и supplier_phone зависят только от product_id — первичного ключа. Однако здесь есть дублирование данных: для одного и того же поставщика мы храним его имя и телефон в нескольких строках.
Чтобы привести таблицу к 2NF, можем разделить её на две таблицы:
Таблица Products:
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Гвозди | 1 | 150 |
| 2 | Шурупы | 2 | 200 |
| 3 | Гайки | 1 | 100 |
Таблица Suppliers:
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | СтройКомплект | +78901112233 |
| 2 | КрепёжПро | +78906667788 |
Теперь каждый поставщик представлен один раз, и связь между таблицами реализована через внешний ключ supplier_id.
Таблица в 3NF, если:
- Она находится в 2NF.
- Все неключевые атрибуты зависят только от первичного ключа, а не от других неключевых атрибутов.
В случае нормализованных таблиц Products и Suppliers мы не видим никаких транзитивных зависимостей. Это означает, что таблицы приведены к 3NF.
Практическое задание
Допустим, у нас есть исходная таблица "Университет"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Математика | Peter Pen | pen@university.com |
| 102 | Anna Song | Физика | Alex Sid | sid@university.com |
| 103 | Otto Lin | Физика | Alex Sid | sid@university.com |
- Проверьте таблицу на соответствие нормальным формам.
- Приведите её к 1NF, 2NF и 3NF, если это необходимо.
Решение
ШАГ 1: Проверка на 1NF
Таблица уже в 1NF: каждая ячейка содержит одно значение.
ШАГ 2: Проверка на 2NF
Таблица нарушает 2NF: информация о преподавателях (имя и email) повторяется. Мы можем вынести её в отдельную таблицу:
Таблица Students:
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Таблица Courses:
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Математика | 1 |
| 2 | Физика | 2 |
Таблица Professors:
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Таблица Enrollments:
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
ШАГ 3: Проверка на 3NF
В новой структуре отсутствуют транзитивные зависимости. Таблицы соответствуют 3NF.
Практические рекомендации
- Не стремитесь к идеалу без необходимости. Иногда избыточная нормализация усложняет запросы.
- Подходите к анализу как детектив. Ищите дубли, лишние зависимости и другие "аномалии".
- Не забывайте о производительности. Нормализация — это баланс между чистотой данных и быстротой их обработки.
Теперь, когда вы умеете находить проблемы в базе данных и решать их, вы смогли бы честно провести "ревизию" базы любого размера. Помните: хорошая база данных — это не только функциональный, но и красивый (или нормализованный) проект.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ