Вопрос или проблема
Я разрабатываю систему, которая регистрирует сделки с акциями для продукта. Некоторые типы продуктов требуют регистрации товаров по серийному номеру для отслеживания, некоторые типы продуктов не требуют серийного учёта.
При регистрации сделок с акциями я вижу возможность разработки в двух вариантах: 1) Регистрация по родителю, а затем связывание с дочерней таблицей для серийных номеров при необходимости, или 2) Регистрация самой мелкой сущности, либо родителя отдельно, либо комбинации родителя и серийного номера.
Ниже приведена картинка, поясняющая структуру. Я хотел бы знать, является ли один вариант нормализованным, а другой – нет, или оба варианта нормализованы, и это вопрос предпочтений, основанный на потребностях системы и пользователя.
Удалите концепцию “идентификатора серийной упаковки” и используйте идентификатор транзакции в качестве внешнего ключа:
create table transaction (
id int primary key,
product_id int not null references product,
quantity int not null
);
create table serial (
id int primary key,
transaction_id int not null references transaction,
quantity int not null
)
Обратите внимание, что лучшей практикой является простое именование первичного ключа как id для всех таблиц. Мы не добавляем префикс к другим столбцам с именем таблицы, например, transaction_quantity, и столбец id не должен быть исключением.
Ответ или решение
Вопрос о нормализации баз данных в контексте проектирования системы для учета товарных транзакций достаточно важен и требует детального рассмотрения различных подходов.
Нормализация баз данных
Нормализация данными является процессом упорядочивания таблиц и их отношений в базе данных для минимизации избыточности и предотвращения аномалий в обновлениях. Существует несколько нормальных форм (NF), и система считается нормализованной, если она соответствует этим формам.
Сравнение структур родитель-ребенок и плоской структуры
-
Структура с родителем и детьми (Parent-Child Structure)
В этой структуре у вас есть главная таблица, которая представляет родительские сущности (например, транзакции), и дочерняя таблица, которая содержит более детализированные данные (например, серийные номера). Это позволяет вам хранить общую информацию о транзакции в одной таблице и связывать с ней дополнительные данные только для тех товаров, которые требуют отслеживания по серийному номеру.
Преимущества:
- Возможность расширения: вы можете добавлять новые типы товаров с различными требованиями к отслеживанию без изменения основной структуры таблицы.
- Снижение избыточности данных, так как информация о серийном номере хранится только для соответствующих продуктов.
- Легче управлять данными и проводить их анализ.
Недостатки:
- Требует дополнительных запросов к базе данных для получения полной информации о транзакции, что может снизить производительность при больших объемах данных.
-
Плоская структура (Flat Structure)
В этом подходе каждое значение (например, каждая транзакция и каждый серийный номер) хранится в одной таблице, что может создавать избыточность. Это значит, что для каждого товара, даже если он не требует серийного номера, будет храниться соответствующая строка с пустым значением или дополнительным полем для серийного номера.
Преимущества:
- Более простая структура запросов, так как все данные располагаются в одной таблице.
- Возможность быстрого доступа ко всем данным, что может быть полезно в анализе.
Недостатки:
- Высокая степень избыточности данных, что затрудняет обновление и может вызвать несоответствия в данных.
- Лимитированная возможность хранения разнообразных типов информации, что затрудняет модернизацию системы.
Вывод
Обе структуры могут считаться нормализованными в зависимости от способа использования и требований системы. Структура с родительскими и дочерними таблицами более соответствует принципам нормализации, поскольку разделяет взаимосвязанные данные, минимизируя дублирование.
Плоская структура может быть уместной при специфических требованиях к производительности, но она более подвержена проблемам с избыточностью и может вызвать множество аномалий.
Таким образом, выбор между этими подходами в большей степени зависит от фактических требований системы, объема данных и частоты их обновления. Рекомендуется использовать структуру родитель-ребенок, когда разные уровни данных имеют различные требования, так как это обеспечит большую гибкость и лучшую управляемость данных в долгосрочной перспективе.