Предлагаемая нормализованная схема (ключи и связи кратко):
- Customers (PK: CustomerID) — Email, Name, Phone, DefaultAddressID (FK -> Addresses)
- Addresses (PK: AddressID) — CustomerID (FK), Line1, Line2, City, Region, PostalCode, Country
- Products (PK: ProductID) — SKU, Name, Description, Price, CurrentSupplierID (FK -> Suppliers)
- Categories (PK: CategoryID) — Name, ParentCategoryID (FK -> Categories)
- ProductCategories (PK: ProductID, CategoryID) — связь многие‑ко‑многим
- Suppliers (PK: SupplierID) — Name, ContactInfo
- Inventory (PK: ProductID, WarehouseID) — QuantityOnHand, ReorderLevel
- Orders (PK: OrderID) — CustomerID (FK), OrderDate, Status, ShippingAddressID (FK -> Addresses), BillingAddressID (FK -> Addresses), TotalAmount
- OrderItems (PK: OrderID, ProductID) — Quantity, UnitPriceAtPurchase, Discount
- Payments (PK: PaymentID) — OrderID (FK), Amount, PaymentDate, PaymentMethod, Status
- Reviews (PK: ReviewID) — ProductID (FK), CustomerID (FK), Rating, Text, CreatedAt
- CartItems (PK: CustomerID, ProductID) — Quantity, AddedAt
Обозначения: все PK — суррогатные либо естественные уникальные ключи; FK — внешние ключи, поддерживающие целостность.
Нормальные формы — объяснение до $\text{3NF}$:
- $\text{1NF}$ — все атрибуты атомарны, нет повторяющихся групп. Пример: в таблице Orders не храним список товаров в одном поле; вместо этого — отдельная таблица OrderItems.
- $\text{2NF}$ — таблицы с составным ключом не содержат частичных зависимостей от части ключа. Пример: в OrderItems ключ $(OrderID,ProductID)$; поля Quantity и UnitPriceAtPurchase зависят от всей пары, а не только от ProductID. Если бы мы хранить ProductName в OrderItems, это была бы частичная/избыточная зависимость (демонстрирует нарушение $\text{2NF}$).
- $\text{3NF}$ — нет транзитивных зависимостей; каждый неключевой атрибут зависит только от ключа. Пример: в Customers не храним CityName и RegionName в одном поле, если есть отдельная таблица Regions; если Customer -> Address -> City, то Orders хранит ссылку на Address, а не город (удаляем транзитивную зависимость OrderID -> AddressID -> City).
Формально: пример функциональной зависимости в OrderItems:
$OrderItem(OrderID,ProductID)\to Quantity,UnitPriceAtPurchase$.
Аргументы за и против денормализации (производительность vs согласованность):
Плюсы денормализации:
- Быстрее чтение сложных запросов (меньше JOIN’ов), полезно для отчетов и страниц товара с большим количеством агрегированных данных.
- Уменьшение задержки в OLTP/OLAP-сценариях — предвычисленные поля (например, кэшированная общая оценка товара, агрегаты продаж).
- Упрощение некоторых запросов и уменьшение нагрузки на БД при высоких пиковых чтениях.
Минусы денормализации:
- Усложнение логики записи: необходимость поддерживать согласованность вручную (триггеры, транзакции, фоновые задачи).
- Риск рассинхронизации данных (stale data) и усложненные сценарии восстановления/миграции.
- Дополнительное хранилище и возможные аномалии при параллельных обновлениях.
Рекомендации по практическому применению:
- Нормализовать до $\text{3NF}$ для основной OLTP-модели (заказы, инвентарь, клиенты) — обеспечивает согласованность и простые транзакции.
- Денормализовать выборочно для ускорения чтения: кэшировать агрегаты (например, рейтинг товара, total_sales) или хранить часто читаемые срезы в отдельных таблицах/материализованных представлениях. Обновление таких полей — через атомарные операции/транзакции или через надежные фоновые задачи с идемпотентностью.
- Использовать индексы, read replicas и кеш (Redis) прежде чем масштабировать за счёт денормализации; для аналитики — ETL в хранилище данных.
- Всегда описывать договоры согласованности (актуальность кэша, допустимая задержка обновления) и тестировать сценарии рассинхронизации.
Коротко: нормализованная модель до $\text{3NF}$ даёт корректность и простоту транзакций; денормализация оправдана ради производительности чтения, но требует дополнительных механизмов для поддержания согласованности.