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

1. Проблема сопряжения человека и реляционной БД

Пользователь (Человек)

  • Мыслит визуальными образами, формами, карточками и документами.
  • Стремится к максимальной скорости и минимальным ограничениям при вводе.
  • Допускает опечатки, пропуски полей, ввод некорректных форматов.

Реляционная база данных (СУБД)

  • Математически строгая реляционная модель (таблицы, кортежи, домены).
  • Требует нормализации (1NF-3NF) для исключения избыточности.
  • Обеспечивает бескомпромиссную целостность (PK, FK, CHECK, NOT NULL).

Главная инженерная задача: Создать эргономичный графический интерфейс (UI), который берет на себя рутину форматирования и валидации, безопасно транслируя действия пользователя в атомарные изменения реляционной базы данных.

2. N-уровневая архитектура информационной системы

Прямой доступ пользовательского интерфейса к базе данных категорически запрещен в промышленных решениях.

Клиентская сторона (Frontend / UI)

  • Слой представления (View): Экранные формы, графические контролы, таблицы деталей.
  • Первичная валидация: Проверка обязательности полей и формата регулярных выражений для мгновенной обратной связи с пользователем.

Серверная сторона (Backend & DB)

  • Контроллеры и Сервисы: Обработка DTO, бизнес-логика, проверка прав, границы транзакций.
  • Слой доступа к данным (DAO / ORM): Генерация параметризованного SQL, маппинг объектов в строки таблиц.
  • СУБД: Декларативная целостность, индексы, ACID-транзакции.

3. Архитектурные паттерны: MVC, MVP, MVVM

MVC (Model-View-Controller)

Классическое разделение: View отображает интерфейс и ловит клики; Controller обрабатывает действия пользователя и обновляет Model; Model инкапсулирует бизнес-данные и уведомляет View об изменениях.

MVP (Model-View-Presenter)

View полностью пассивен и изолирован за интерфейсом. Presenter берет на себя всю координацию взаимодействия и синхронизацию с моделью.

MVVM (Model-View-ViewModel)

Стандарт современного веб- и настольного фронтенда. ViewModel хранит реактивное состояние формы, синхронизируясь через Data Binding.

4. Концепция Data Binding (Связывание данных)

Data Binding — программный механизм автоматической синхронизации свойств элементов графического интерфейса со структурами данных приложения.

Одностороннее связывание (One-Way)

  • Model → View: Значение из базы данных инициализирует форму просмотра/редактирования.
  • View → Model: При отправке формы снимок значений элементов пакуется в DTO-запрос.

Двустороннее связывание (Two-Way)

  • View ↔ ViewModel: Ввод символа в поле моментально меняет модель в памяти; программный расчет (например, скидки) тут же обновляет UI.
  • Избавляет разработчика от сотен строк рутинного DOM-кода.

Золотое правило архитектуры: UI связывается с DTO / ViewModel, а не с таблицами базы данных напрямую!

5. Текстовые поля и маски ввода (Masked Input)

Назначение в интерфейсе

  • Предотвращение ввода некорректных символов в реальном времени.
  • Автоматическое форматирование структурированных идентификаторов (телефон, СНИЛС, ИНН, автономера).
  • Устранение вариативности ввода одним и тем же оператором.

Маппинг на реляционную БД

  • Типы колонок: VARCHAR(n) или CHAR(n) фиксированной длины.
  • Ограничения СУБД: Предикаты CHECK (col ~ '^[0-9]+$').
  • Стратегия хранения: В базу сохраняется очищенная строка (raw value, без скобок и дефисов) для эффективного индексирования и поиска.
UI: +7 (922) 123-45-67 → DTO: "79221234567" → DB: client_phone VARCHAR(15)

6. Выпадающие списки (Combobox) для внешних ключей

Выпадающий список — основной элемент выбора связанных сущностей из справочников (связь «многие к одному»).

Разделение Display и Value

  • Display Member (Текст): Понятное человеку наименование (ФИО клиента, склад, марка авто).
  • Value Member (Значение): Суррогатный первичный ключ (client_id INT).
  • В реляционную таблицу дочерней сущности передается строго Value Member.

Масштабирование справочников

  • До 100 записей: Стандартный выпадающий список <select>.
  • Свыше 100 записей: Поле ввода с автодополнением (Autocomplete / Typeahead), запрашивающее данные с бэкенда через LIMIT 20 при вводе от 3 символов.

7. Переключатели (RadioGroup) и флажки (Checkbox)

Группа переключателей (RadioGroup)

  • Назначение: Взаимоисключающий выбор из 2–5 фиксированных альтернатив.
  • Примеры: Приоритет инцидента (Низкий, Средний, Высокий), тип плательщика.
  • Маппинг в БД: ENUM, VARCHAR(15) с предикатом CHECK (val IN (...)).
  • Преимущество: Все варианты видны сразу без раскрытия списка.

Флажок (Checkbox / Switch)

  • Назначение: Бинарный выбор (Да/Нет, 1/0).
  • Примеры: «Заказ оплачен», «Активен», «Согласие на обработку ПДн».
  • Маппинг в БД: BOOLEAN NOT NULL DEFAULT FALSE.
  • Особенность: Состояние checked конвертируется строго в TRUE или FALSE.

8. Компоненты выбора даты (DatePicker)

Задачи элемента интерфейса

  • Физическое исключение ошибок ввода календарных дат (нет 30 февраля, 32 числа, 13 месяца).
  • Ограничение допустимого интервала (запрет выбора дат в прошлом или будущем через атрибуты min / max).
  • Удобный выбор диапазона дат (Date Range Picker).

Стандартизация и маппинг в БД

  • Тип в БД: DATE, TIMESTAMP, TIMESTAMPTZ.
  • Формат обмена (ISO 8601): Строго YYYY-MM-DD или YYYY-MM-DD"T"HH:mm:ss.
  • Предотвращение коллизий: Исключает ошибки различия локалей серверов (DD/MM/YYYY в РФ против MM/DD/YYYY в США).

9. Паттерн Master-Detail: сложные формы ввода

Используется для оформления документов, содержащих заголовок и табличную часть спецификации (отношение 1:M).

Шапка формы (Master)

Одиночные реквизиты документа: Номер, Дата оформления, Выбор контрагента (FK), Склад отгрузки (FK), Комментарий.

Табличная часть (Detail Grid)

Динамический список строк спецификации: Выбор товара (FK Combobox), Количество (Number Input), Цена, Скидка, Расчетная сумма строки. Кнопки добавления и удаления строк.

10. Транзакционная атомарность Master-Detail

Недопустимо сохранять строки спецификации отдельными несвязанными HTTP-запросами!

-- Серверный транзакционный блок сохранения заказа
BEGIN;

-- 1. Создание шапки заказа и получение сгенерированного ID
INSERT INTO orders (client_id, order_date, status)
VALUES (104, '2026-10-01', 'draft') RETURNING order_id;

-- 2. Вставка всех строк спецификации с привязкой к полученному order_id
INSERT INTO order_items (order_id, product_id, quantity, unit_price)
VALUES 
    (4812, 301, 5, 4500.00),
    (4812, 814, 2, 18200.00);

-- 3. Если хотя бы одна позиция вызвала ошибку (CHECK/FK) — откат ВСЕГО заказа!
COMMIT;

11. Двухуровневая валидация данных

Уровень 1. Клиентская валидация (UI/UX)

  • Где: В браузере (HTML5 required, JS-события blur, input).
  • Цель: Мгновенная обратная связь, комфорт пользователя, экономия сетевых запросов.
  • Статус: Не является гарантией безопасности (легко обходится через DevTools/Postman).

Уровень 2. Валидация ядра БД (Data Integrity)

  • Где: Внутри СУБД (PostgreSQL / MySQL).
  • Инструменты: PRIMARY KEY, FOREIGN KEY, NOT NULL, CHECK, UNIQUE, EXCLUDE.
  • Статус: Абсолютный рубеж защиты. Данные не могут быть повреждены ни при каких обстоятельствах.

12. Эргономика экранных форм (UX-инженерия)

Порядок навигации (Tab Order)

Клавиша Tab перемещает фокус логично: сверху вниз, слева направо. Оператор должен уметь заполнить и отправить форму без использования мыши.

Индикация обязательности (* NOT NULL)

Обязательные поля помечаются видимой звездочкой. Необязательные поля не должны блокировать отправку формы.

Защита от двойной отправки

Кнопка «Сохранить» блокируется (disabled) сразу после клика с показом спиннера, исключая дубликаты записей в БД.

Инлайн-подсветка ошибок

Текст ошибки выводится прямо под проблемным полем с четким объяснением, как исправить введенное значение.

13. Типовые архитектурные ошибки

1. Сохранение текста вместо ID внешнего ключа

Запись наименования категории или имени клиента прямо в дочернюю таблицу вместо FK ID разрушает нормализацию и ломает реляционные связи.

2. Прямой SQL-запрос из кнопки интерфейса (Direct SQL)

Внедрение SQL в клиентский код приводит к критическим SQL-инъекциям и невозможности разграничения прав доступа.

3. Отсутствие транзакции в Master-Detail

Построчное несогласованное сохранение порождает в базе данных «зависшие» пустые шапки документов без строк спецификации.

14. Архитектурная строгость: цена небрежности в ограничениях

Exploits of a Mom - Little Bobby Tables
Тематический интернет-мем: «Exploits of a Mom» (культовый комикс про «Little Bobby Tables», xkcd №327).
Автор: Randall Munroe. Первоисточник: xkcd.com/327. Лицензия: Creative Commons Attribution-NonCommercial 2.5 Generic (CC BY-NC 2.5).
Связь с темой занятия: Интерфейс ввода данных — это передовая линия безопасности и целостности всей информационной системы. Грамотный выбор компонентов ввода, клиентская фильтрация, изоляция слоев через параметризованные DTO/DAO и строгие ограничения целостности в реляционной СУБД гарантируют, что никакой вредоносный или некорректный пользовательский ввод никогда не разрушит корпоративную базу данных.
1 / 15