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

1. Поминутный тайминг учебного занятия (80 и 60 минут)

Занятие структурировано по комбинированной дидактической модели с упором на сквозной инженерный разбор архитектуры взаимодействия экранных форм ввода с реляционной СУБД. Ниже представлены два нормативных тайминга: основной (80 минут) и сокращенный (60 минут при выпадающих парах / расписании по сокращенному звонку).

2. Архитектурные принципы сопряжения UI и реляционной базы данных

2.1. Многоуровневая (n-уровневая) архитектура и изоляция слоев

Фундаментальный принцип современной программной инженерии при работе с базами данных — строгое разделение ответственности (Separation of Concerns, SoC). Прямой доступ интерфейса пользователя к базе данных категорически запрещен в промышленных информационных системах, так как создает критические уязвимости безопасности (SQL Injection, перехват учетных данных БД), исключает масштабирование и делает систему неподдерживаемой.

+-----------------------------------------------------------------------+
|  УРОВЕНЬ ПРЕДСТАВЛЕНИЯ (Presentation Layer / View)                   |
|  Элементы управления: Input, Select, DatePicker, Таблицы Detail      |
+-----------------------------------+-----------------------------------+
                                    | (События UI: Submit, Change, Input)
                                    v
+-----------------------------------------------------------------------+
|  УРОВЕНЬ БИЗНЕС-ЛОГИКИ И КООРДИНАЦИИ (Controller / Service / Backend) |
|  - Парсинг DTO, валидация бизнес-правил, аутентификация пользователя |
|  - Управление транзакциями (Transaction Boundary: BEGIN / COMMIT)     |
+-----------------------------------+-----------------------------------+
                                    | (Вызов методов репозитория / DAO)
                                    v
+-----------------------------------------------------------------------+
|  УРОВЕНЬ ДОСТУПА К ДАННЫМ (Data Access Layer / DAO / ORM Repository)  |
|  - Формирование параметризованных запросов INSERT / UPDATE / SELECT   |
|  - Преобразование объектов (Object-Relational Mapping / Data Mapper)   |
+-----------------------------------+-----------------------------------+
                                    | (SQL через драйвер БД: JDBC, Npgsql, asyncpg)
                                    v
+-----------------------------------------------------------------------+
|  СЛОЙ ХРАНЕНИЯ ДАННЫХ (Database Engine / PostgreSQL, MySQL, Oracle)   |
|  - Первичные (PK) и внешние (FK) ключи, CHECK, UNIQUE, NOT NULL       |
|  - Индексы, триггеры целостности, ACID-гарантии хранения              |
+-----------------------------------------------------------------------+

2.2. Паттерны организации пользовательского интерфейса (MVC, MVP, MVVM)

• MVC (Model-View-Controller): Классический паттерн. View отображает форму ввода и генерирует события. Controller перехватывает ввод, формирует команды обновления Model (доменных сущностей и репозиториев) и определяет следующее отображение. В веб-приложениях MVC часто реализуется через серверные шаблонизаторы или связку SPA-клиента и REST-контроллера на бэкенде.
• MVP (Model-View-Presenter): Presenter полностью берет на себя логику координации, извлекая значения из пассивного View через интерфейс и передавая их в модель. Широко применяется в настольных толстых клиентах (WinForms, WPF).
• MVVM (Model-View-ViewModel): Стандарт современных клиентских фреймворков (Vue, Angular, React с хуками, WPF). ViewModel хранит реактивное состояние формы, а механизм декларативного Data Binding автоматически синхронизирует состояние контролов и свойств модели.

2.3. Механизм связывания данных (Data Binding)

Data Binding (привязка данных) — программный мост между графическими элементами пользовательского интерфейса (UI Controls) и атрибутами программных моделей / реляционных таблиц. Различают два основных типа связывания:

• Одностороннее связывание (One-Way Binding, View ← Model или Model ← View): Данные передаются только в одном направлении. Например, при открытии формы редактирования атрибуты строки таблицы инициализируют поля UI; либо при клике кнопки «Сохранить» снимок полей формы переносится в объект запроса (DTO).
• Двустороннее связывание (Two-Way Binding, View ↔ ViewModel): Любое изменение пользователем текста в <input> немедленно модифицирует свойство в оперативной памяти, а программное изменение модели мгновенно перерисовывает контрол интерфейса.

3. Инженерная типология элементов ввода и правила их маппинга на атрибуты БД

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

4. Компоновка форм ввода и правила эргономики UI (UX-инженерия)

Качество проектного решения оценивается не только правильностью типов данных, но и эргономикой формы (сокращение числа ошибок оператора, снижение утомляемости, скорость ввода):

5. Типовые ошибки студентов и методы их педагогического устранения

6. Рекомендации по оцениванию и закрытая критериальная шкала

Оценивание результатов работы студентов на уроке производится по 4-балльной шкале, зафиксированной в критериальной рубрике .rubrika.md:

• Критерий 1 (2 балла): Схема экранной формы ввода, корректный выбор UI-компонентов и компоновка (1 балл за неполный состав элементов или нарушение порядка ввода, 0 баллов за отсутствие схемы или бессистемный набор полей).
• Критерий 2 (1 балл): Маппинг элементов управления формы на атрибуты реляционной БД (корректность разделения Value/Text для FK, соответствие типов данных, индикация NOT NULL).
• Критерий 3 (1 балл): Эргономика пользовательского интерфейса, валидация и ответы на контрольные вопросы самопроверки.

Итоговая отметка выставляется по шкале СИЭУиП: 4 балла — «отлично» (5), 3 балла — «хорошо» (4), 2 балла — «удовлетворительно» (3), 0–1 балл — «неудовлетворительно» (2).