Приведите пример спроектированной базы данных с денормализацией.

Да, я проектировал денормализованные схемы для витрин данных, чтобы ускорить выполнение аналитических запросов. Классический пример — таблица sales_denormalized в хранилище данных.

Пример схемы:

CREATE TABLE sales_denormalized (
    sale_id INT PRIMARY KEY,
    sale_date DATE,
    customer_id INT,
    customer_name VARCHAR(100),
    customer_city VARCHAR(50),
    product_id INT,
    product_name VARCHAR(100),
    product_category VARCHAR(50),
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    salesperson_id INT,
    salesperson_name VARCHAR(100),
    region VARCHAR(50)
);

Почему денормализация:

• Производительность: Отсутствие JOIN между таблицами sales, customers, products, employees ускоряет отчеты.
• Упрощение запросов: Аналитикам не нужно знать сложные связи.
• Сценарий использования: Эта таблица была создана как агрегированная витрина для ежедневных отчетов по продажам. Данные обновлялись один раз в сутки через ETL-процесс.

Компромисс: Денормализация увеличивает объем хранилища и требует строгого процесса обновления для поддержания консистентности данных.