Моделирование таблицы — это проектирование структуры табличных данных так, чтобы они корректно хранились, легко обновлялись и удобно использовались в запросах/отчётах. Под “способами” обычно имеют в виду подходы (концептуальный, логический, физический), а также конкретные техники (нормализация, денормализация, звезда/снежинка, EAV и т.п.). Ниже — основные способы и когда их применяют.

1) Концептуальное моделирование (ER-модель)

Цель: описать предметную область “как есть” без привязки к конкретной СУБД.

Как выглядит:

• Сущности (например, Клиент, Заказ, Товар)

• Атрибуты (у Клиента: имя, телефон)

• Связи (Клиент делает Заказ; Заказ содержит Товары)

• Кардинальности (1:1, 1:N, N:M)

Плюсы:

• Понятно бизнесу и аналитикам

• Помогает выявить сущности и правила до деталей реализации

Когда подходит:

• На старте проектирования

• Когда нужно согласовать смысл данных и связи

2) Логическое моделирование (реляционная схема)

Цель: перевести концептуальную модель в структуру таблиц, ключей и ограничений.

Основные действия:

• Выделение таблиц из сущностей

• Выбор первичных ключей (PK)

• Разбиение связей:

  • 1:N — внешний ключ (FK) на стороне “многие”

  • N:M — таблица-связка (junction table) с двумя FK

• Определение типов данных (логически: строка/число/дата), уникальностей, обязательности (NOT NULL)

Плюсы:

• Формализует структуру, готовит к нормализации

• Независимо от конкретных индексов/движка хранения

Когда подходит:

• При проектировании БД под транзакционные системы, CRM/ERP и т.д.

3) Физическое моделирование (под конкретную СУБД)

Цель: сделать схему “исполняемой” и оптимизированной под нагрузку.

Что добавляется:

• Точные типы данных СУБД (VARCHAR(n), NUMERIC(p,s), TIMESTAMP)

• Индексы (B-tree, hash, GIN/GiST и т.п. — зависит от СУБД)

• Партиционирование, кластеризация

• Настройки хранения, колляции, сжатие

• Ограничения и триггеры с учётом производительности

Плюсы:

• Реальная производительность и масштабируемость

• Учитывает особенности движка и запросов

Когда подходит:

• Когда известны объёмы, паттерны запросов, требования по скорости

Техники моделирования таблиц (практические способы)

4) Нормализация (3НФ/BCNF и далее)

Цель: минимизировать дублирование и аномалии обновления.

Суть:

• 1НФ: атомарные значения (без списков в одной ячейке)

• 2НФ: нет частичной зависимости от составного ключа

• 3НФ: нет транзитивных зависимостей (атрибут не зависит от неключевого атрибута)

Плюсы:

• Меньше дубликатов

• Обновления/удаления безопаснее

• Данные “чище”

Минусы:

• Больше таблиц и JOIN-ов

• Иногда сложнее отчёты

Когда подходит:

• OLTP-системы (много вставок/обновлений)

• Данные часто меняются и важна целостность

5) Денормализация

Цель: ускорить чтение и упростить запросы за счёт контролируемого дублирования.

Примеры:

• Хранить вычисляемые поля (итоговая сумма заказа)

• Дублировать справочные названия рядом с фактами (название категории)

• Материализованные представления

Плюсы:

• Быстрее отчёты и витрины

• Меньше JOIN-ов

Минусы:

• Риск рассинхронизации

• Сложнее поддержка (нужны триггеры/процедуры/ETL)

Когда подходит:

• BI/аналитика, отчётность

• Очень частые чтения и редкие обновления

• Кэш-таблицы, витрины

6) Размерное моделирование (Star Schema / Snowflake)

Часто используется в хранилищах данных.

6.1 “Звезда” (Star Schema)

• Факт: таблица событий/измерений (продажи, клики) с числовыми показателями

• Измерения: справочники (товар, магазин, дата), обычно денормализованы

Плюсы:

• Простые и быстрые запросы

• Удобно для BI-инструментов

Минусы:

• Дублирование в измерениях

6.2 “Снежинка” (Snowflake)

Измерения нормализованы на подизмерения.

Плюсы:

• Меньше дублирования

• Чётче структура справочников

Минусы:

• Больше JOIN-ов

Когда подходит:

• OLAP/аналитика, отчёты по агрегатам

• Большие объёмы исторических фактов

7) Таблицы-справочники и кодирование (Lookup / Reference modeling)

Цель: вынести повторяющиеся значения и обеспечить единые правила.

Как делается:

• Отдельная таблица статусов, типов, категорий

• В основной таблице хранится FK на справочник

Плюсы:

• Единообразие значений

• Легче менять наименования без массовых обновлений

Минусы:

• JOIN для получения “человеческого” названия

Когда подходит:

• Статусы, типы, классификаторы, роли

8) Моделирование иерархий (деревья)

Если в таблице есть структуры “родитель–потомок” (категории, оргструктура).

Способы:

1. Adjacency List (parent_id)

• Просто, но запросы на “всю ветку” могут быть тяжёлыми

2. Materialized Path (путь строкой/массивом)

• Быстро искать поддерево по префиксу, но сложнее обновлять перемещения

3. Nested Sets (lft/rgt)

• Быстро читать поддерево, но сложно вставлять/перестраивать

4. Closure Table (таблица всех пар предок–потомок)

• Очень гибко для запросов, дороже по объёму и поддержке

Когда подходит:

• Каталоги, меню, оргструктуры, комментарии

9) Моделирование “время-история” (Temporal / SCD)

Если важно хранить изменения во времени.

Подходы:

• Valid from / valid to (периоды действия)

• Версионирование строк (каждое изменение — новая запись)

• В хранилищах: SCD Type 1/2/3 (особенно тип 2 с историей)

Плюсы:

• Можно восстановить состояние на дату

• Удобно для аудита

Минусы:

• Усложнение запросов (нужно учитывать период)

Когда подходит:

• Цены, тарифы, реквизиты, статусы, договоры

10) EAV (Entity–Attribute–Value) / “Гибкие атрибуты”

Используют, когда набор атрибутов сильно разный и постоянно меняется (например, характеристики товаров).

Структура:

• Entity (объект)

• Attribute (название характеристики)

• Value (значение)

Плюсы:

• Очень гибко добавлять новые атрибуты без ALTER TABLE

• Подходит для “разреженных” данных

Минусы:

• Сложные запросы, хуже индексация, тяжелее контроль типов

• Сложнее обеспечивать целостность и ограничения

Когда подходит:

• Конфигураторы, метаданные, “кастомные поля” пользователей

• Но часто лучше рассмотреть JSON/документные поля или отдельные таблицы по группам атрибутов

11) JSON/Document-поля внутри реляционной таблицы

Компромисс между строгой схемой и гибкостью.

Идея:

• Основные поля строго типизированы

• Дополнительные/редкие атрибуты — в JSON

Плюсы:

• Быстро добавить новые атрибуты

• Удобно хранить “разные” данные

Минусы:

• Контроль целостности сложнее

• Индексация и запросы зависят от возможностей СУБД

Когда подходит:

• “Допполя”, интеграционные payload’ы, редкие атрибуты

12) Широкие таблицы vs узкие таблицы (wide vs narrow)

Это скорее стиль проектирования под аналитику/производительность.

• Широкая таблица: много колонок, меньше JOIN-ов
  Хорошо для витрин и отчётов, хуже для частых изменений схемы.

• Узкая таблица: меньше колонок, больше связанных сущностей
  Хорошо для поддержки и целостности, иногда медленнее для сложных отчётов.

Как выбрать способ на практике

• Если система транзакционная и важна целостность → нормализованная модель (3НФ) + аккуратные индексы.

• Если основная нагрузка — отчёты и аналитика → звезда/снежинка, витрины, частичная денормализация.

• Если атрибуты непредсказуемы и часто меняются → JSON или EAV (с осторожностью), либо отдельные таблицы по группам.

• Если много иерархий/категорий → выбрать подход к деревьям (parent_id, closure table и т.д.) по типу запросов.

• Если критична история изменений → temporal/SCD-модели.