К чему может привести нарушение нормализации БД

# К чему может привести нарушение нормализации БД

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

Нарушение нормализации баз данных приводит к аномалиям данных (вставки, обновления, удаления), избыточности, снижению производительности и усложнению обслуживания. Это создаёт угрозу целостности данных и увеличивает затраты разработки.

Основные проблемы

1. Аномалия вставки (Insertion Anomaly)

Невозможно вставить данные без дополнительной информации.

// Плохо: Таблица преподавателей, курсов и расписания вместе
CREATE TABLE TeacherCourse {
    teacherId INT,
    courseName VARCHAR(100),
    schedule VARCHAR(50),
    salary DECIMAL
};

// Нельзя добавить нового преподавателя без курса!
INSERT INTO TeacherCourse (teacherId, courseName, schedule, salary) 
VALUES (1, NULL, NULL, 50000);  // Ошибка!

Решение (нормализация):

CREATE TABLE Teachers {
    teacherId INT PRIMARY KEY,
    name VARCHAR(100),
    salary DECIMAL
};

CREATE TABLE Courses {
    courseId INT PRIMARY KEY,
    courseName VARCHAR(100),
    schedule VARCHAR(50)
};

CREATE TABLE TeacherCourses {
    teacherId INT FOREIGN KEY,
    courseId INT FOREIGN KEY
};

// Теперь можно просто добавить преподавателя
INSERT INTO Teachers (teacherId, name, salary) 
VALUES (1, 'John', 50000);

2. Аномалия обновления (Update Anomaly)

Нужно обновлять одни и те же данные в нескольких местах - ведёт к несогласованности.

// Ненормализованная таблица
CREATE TABLE StudentCourse {
    studentId INT,
    courseId INT,
    courseName VARCHAR(100),      // Дублируется!
    instructor VARCHAR(100),      // Дублируется!
    credits INT                    // Дублируется!
};

// 100 студентов на курсе "Java Advanced"
// Если название курса изменилось, нужно обновить 100 записей!
UPDATE StudentCourse 
SET courseName = 'Java Advanced 2025' 
WHERE courseId = 5;

// Если забыли обновить даже одну запись - данные несогласованны

Вероятные ошибки:

• Обновили названия в 99 записях, одну забыли
• При конкурентном доступе возникают race conditions
• Усложняется отладка, нарушается логическая целостность

3. Аномалия удаления (Deletion Anomaly)

Удаление одних данных влечёт случайное удаление других.

// Ненормализованная таблица
CREATE TABLE EmployeeProject {
    employeeId INT,
    name VARCHAR(100),
    department VARCHAR(50),
    projectId INT,
    projectName VARCHAR(100),
    budget DECIMAL
};

// Удаляем последнего сотрудника проекта
DELETE FROM EmployeeProject 
WHERE employeeId = 10;

// Упс! Потеряли информацию о проекте: projectId, projectName, budget!
// Если это был единственный сотрудник этого проекта

Правильный подход:

CREATE TABLE Employees {
    employeeId INT PRIMARY KEY,
    name VARCHAR(100),
    department VARCHAR(50)
};

CREATE TABLE Projects {
    projectId INT PRIMARY KEY,
    projectName VARCHAR(100),
    budget DECIMAL
};

CREATE TABLE EmployeeProjects {
    employeeId INT FOREIGN KEY REFERENCES Employees(employeeId),
    projectId INT FOREIGN KEY REFERENCES Projects(projectId)
};

// Теперь можно удалить сотрудника без потери информации о проекте
DELETE FROM Employees WHERE employeeId = 10;
// Проект остаётся нетронутым в таблице Projects

Денормализация: Избыточность и противоречия

// Денормализированная таблица заказов
CREATE TABLE Orders {
    orderId INT,
    customerId INT,
    customerName VARCHAR(100),    // Дублируется из таблицы Customers
    customerEmail VARCHAR(100),   // Дублируется из таблицы Customers
    productId INT,
    productName VARCHAR(100),     // Дублируется из таблицы Products
    productPrice DECIMAL,         // Дублируется из таблицы Products
    quantity INT,
    totalAmount DECIMAL           // Рассчитано из productPrice * quantity
};

// Проблемы:
// 1. Если email клиента изменился, нужно обновить все его заказы
// 2. Если цена товара изменилась, какие заказы обновлять? Старые?
// 3. Занимает в 3 раза больше места на диске
// 4. Сложнее синхронизировать данные между таблицами

Потеря целостности данных

// Ненормализованная таблица преподавателей-курсов
CREATE TABLE TeacherCourseData {
    teacherId INT,
    department VARCHAR(50),       // Одно значение на преподавателя
    courseId INT,
    courseName VARCHAR(100)       // Повторяется для каждого курса преподавателя
};

// Данные:
// teacherId=1, department='CS', courseId=101, courseName='Java'
// teacherId=1, department='CS', courseId=102, courseName='Python'
// teacherId=1, department='SE', courseId=103, courseName='C++'  <- ПРОТИВОРЕЧИЕ!

// Какой department у преподавателя 1? CS или SE?

Влияние на производительность

// Плохо: денормализованная таблица с дублями
CREATE TABLE UserActivityDenormalized {
    userId INT,
    userName VARCHAR(100),          // 100 байт, повторяется в каждой строке!
    userEmail VARCHAR(100),         // 100 байт, повторяется!
    activityType VARCHAR(50),
    timestamp DATETIME,
    description VARCHAR(500)
};

// На 1 млн записей активности: 200 МБ потраченной памяти только на дубли!
// INDEX на userId медленнее работает, т.к. больше данных
// Запросы с JOIN выполняют лишнюю фильтрацию

// Хорошо: нормализованная структура
CREATE TABLE Users {
    userId INT PRIMARY KEY,
    userName VARCHAR(100),
    userEmail VARCHAR(100)
};

CREATE TABLE UserActivity {
    activityId INT PRIMARY KEY,
    userId INT FOREIGN KEY,
    activityType VARCHAR(50),
    timestamp DATETIME,
    description VARCHAR(500)
};

// Таблица Activity в 3-4 раза меньше
// Индексы работают быстрее
// JOIN с Users выполняется эффективнее

Практический пример из Java приложения

// ❌ Плохо: DAO работает с денормализованными данными
public class OrderDAO {
    public List<OrderDTO> getOrders() {
        // Тяжелый запрос, т.к. данные дублируются
        String sql = "SELECT o.id, o.customerId, c.name, c.email, " +
                     "p.productId, p.name, p.price, o.quantity " +
                     "FROM orders o, customers c, products p";
        // Приходится работать с 8+ полями, много памяти на дубли
    }
}

// ✅ Хорошо: нормализованная структура
@Entity
@Table(name = "orders")
public class Order {
    @Id
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;  // Ссылка, не дубль данных
    
    @ManyToOne
    @JoinColumn(name = "product_id")
    private Product product;    // Ссылка, не дубль данных
    
    private Integer quantity;
}

// Преимущества:
// 1. ORM правильно работает с связями
// 2. Нет дублирования данных в памяти
// 3. Легче обновлять customer или product - изменения сразу везде
// 4. Меньше памяти, лучше кэширование

Аномалии в Java приложении

@Entity
public class Department {
    @Id
    private Long id;
    private String name;
    private String manager;      // Дублируется для каждого сотрудника!
    private String location;     // Дублируется!
    
    @OneToMany
    private List<Employee> employees;
}

// Проблема в коде:
public void updateDepartmentManager(Long deptId, String newManager) {
    Department dept = repository.findById(deptId);
    
    // Нужно обновить только одно место!
    dept.setManager(newManager);
    
    // Но данные дублируются в базе у каждого сотрудника
    // Если одного забыли обновить - несогласованность!
}

// Правильный подход:
@Entity
public class Department {
    @Id
    private Long id;
    private String name;
    private String manager;
    private String location;
}

@Entity
public class Employee {
    @Id
    private Long id;
    private String name;
    
    @ManyToOne
    @JoinColumn(name = "department_id")
    private Department department;  // Ссылка, не копия
}

// Теперь обновление менеджера - одна операция в БД

Итоговые последствия нарушения нормализации

Вывод для интервью

"Нарушение нормализации приводит к аномалиям: нельзя вставить/обновить/удалить данные без побочных эффектов. Возникает дублирование, что занимает память, замедляет запросы и усложняет синхронизацию. В Java приложении это создаёт проблемы в ORM, требует ручной синхронизации данных и ведёт к багам на production.

Нормализация разбивает данные на отдельные таблицы со связями, что обеспечивает целостность, снижает избыточность и делает приложение надёжнее и масштабируемее."