Тема 4. Проектирование структур баз данных — Организация интерфейса с пользователем: ввод

1. Введение: интерфейс пользователя как точка входа данных в БД

Реляционная база данных — это строгое математическое ядро информационной системы, оперирующее нормализованными таблицами, первичными и внешними ключами, ограничениями доменов и декларативными предикатами (CHECK, UNIQUE, EXCLUDE). Однако подавляющее большинство данных генерируется людьми — операторами, клиентами, менеджерами, врачами, диспетчерами.

Человек не мыслит в категориях SQL-команд INSERT INTO orders (id, client_id, ...) VALUES (...). Для человека естественной средой взаимодействия является графический пользовательский интерфейс (GUI / UI), представленный экранными формами, диалоговыми окнами, текстовыми полями, переключателями и табличными сетками.

2. Архитектура сопряжения слоев приложения: от клика до диска

В современной промышленной разработке прямое взаимодействие интерфейса (View) с сервером базы данных категорически исключено. Применяется многоуровневая (N-tier) архитектура, обеспечивающая изоляцию ответственности, безопасность учетных данных СУБД и независимое масштабирование.

2.1. Паттерны архитектуры UI: MVC, MVP, MVVM

• MVC (Model-View-Controller): Model представляет бизнес-данные и правила их изменения; View отображает пользовательский интерфейс; Controller перехватывает пользовательские действия (клик по кнопке «Оформить заказ»), преобразует входные параметры, обновляет Model и запрашивает обновление View.
• MVP (Model-View-Presenter): Разновидность для классических настольных систем. Presenter полностью управляет представлением, манипулируя интерфейсом IView.
• MVVM (Model-View-ViewModel): Ключевой паттерн современного фронтенда. ViewModel — это абстракция View, хранящая состояние полей формы. Благодаря Data Binding изменение значения в поле ввода автоматически изменяет свойство во ViewModel без ручного написания кода чтения DOM-дерева.

2.2. Механизм Data Binding (привязка данных)

Data Binding связывает визуальное свойство контрола (например, input.value или select.selectedValue) со свойством структуры данных. В контексте баз данных выделяют:

• One-Way Binding (Однонаправленная привязка): Данные текут либо от источника к контролу (отображение строки БД в форме просмотра), либо от контрола к объекту (сборка DTO перед отправкой на сервер).
• Two-Way Binding (Двунаправленная привязка): Изменение текста в поле ввода оператором немедленно обновляет свойство DTO в памяти, а если фоновый процесс меняет значение DTO (например, рассчитывает сумму со скидкой), интерфейс мгновенно перерисовывает расчетное значение.

3. Типы элементов управления формы ввода и их реляционный маппинг

Каждому атрибуту реляционной таблицы соответствует определенный тип данных и семантическое назначение. Графический интерфейс должен предоставлять элемент ввода, физически препятствующий вводу невалидных данных еще до отправки в СУБД.

4. Компоновка сложных форм ввода: паттерн Master-Detail

Большинство корпоративных учетных документов (заказы, счета-фактуры, путевые листы, истории болезней) представляют собой иерархическую структуру «Один-ко-Многим» (1:M). Для их ввода используется паттерн Master-Detail (Шапка — Табличная часть).

Транзакционная механика сохранения Master-Detail в СУБД

При сохранении формы на бэкенд передается единый JSON-объект. Бэкенд выполняет атомарную транзакцию:

-- Серверная транзакция сохранения документа Master-Detail
BEGIN;

-- 1. Вставка родительской записи (Master) с получением сгенерированного ID
INSERT INTO orders (client_id, warehouse_id, order_date, total_amount, status)
VALUES (104, 1, '2026-10-01', 64435.00, 'draft')
RETURNING order_id INTO :new_order_id;

-- 2. Вставка строк спецификации (Detail) с привязкой к новому order_id
INSERT INTO order_items (order_id, item_id, quantity, unit_price, discount_percent)
VALUES 
    (:new_order_id, 301, 5, 4500.00, 5.00),
    (:new_order_id, 814, 2, 18200.00, 0.00),
    (:new_order_id, 922, 4, 1850.00, 10.00);

-- 3. Фиксация транзакции: данные записаны либо полностью, либо ни одна строчка
COMMIT;

5. Правила эргономики UI и UX-инженерия экранных форм

Эргономика интерфейса ввода напрямую влияет на достоверность информации в базе данных. Чем сложнее и неудобнее интерфейс, тем выше вероятность ошибки оператора при рутинном вводе:

• Логическая группировка: Поля разделяются на карточки по смыслу (Идентификация → Реквизиты → Параметры заказа → Служебные отметки).
• Порядок обхода фокуса (Tab Order): Нажатие клавиши Tab должно последовательно перемещать фокус по полям сверху вниз, слева направо. Разрыв последовательности табуляции приводит к пропуску полей.
• Визуальные индикаторы: Поля со свойством NOT NULL обязательно маркируются красной звездочкой (*). Недоступные для редактирования поля (вычисляемая сумма) делаются readonly с серой подложкой.
• Двухуровневая валидация:
  1. Клиентская валидация (Instant UX Feedback): Проверяется при потере фокуса (blur) или вводе символа (input). Подсвечивает границу поля красным цветом и выводит текст подсказки. Экономит время пользователя и сетевой трафик.
  2. Серверная валидация и ограничения СУБД: Единственный гарантированный рубеж защиты целостности данных. Выполняет проверку ограничений CHECK, FOREIGN KEY, UNIQUE.
• Защита от двойного клика (Double Submit): При нажатии кнопки отправки кнопка немедленно переводится в состояние disabled с индикацией вращающегося спиннера до получения ответа от сервера, предотвращая создание записей-дубликатов.

6. Вопросы для самопроверки студентов