Действие преподавателя: Приветствует учебную группу, сверяет присутствующих по журналу, проверяет запуск мультимедийного проектора и доступность веб-комплекта материалов. Выводит на экран вводную заставку.
Прямая речь преподавателя:
«Здравствуйте, коллеги! Садитесь. На прошлых занятиях мы детально изучили ядро реляционной базы данных — как нормализовать таблицы, как строить первичные и внешние ключи, как закладывать математически строгие декларативные ограничения через предикаты CHECK и интервальные исключения EXCLUDE.
Но представьте реальную ситуацию: мы с вами спроектировали идеальную реляционную базу данных для крупной оптовой компании. А затем отдали ее операторам, создав форму ввода, в которой каждое поле — это обычная свободная текстовая строка. Через месяц база оказалась заполнена мусором: один оператор написал клиента как "ООО Альфа", второй как "ОАО АЛЬФА", третий опечатался и написал "Алфа". В отчетах финансовый аналитик видит трех разных контрагентов, баланс не сходится, а при попытке сформировать акт сверки система выдает критическую ошибку.
Кто виноват в этом инциденте? Не оператор, а мы — инженеры, проектировавшие систему. Сегодня на занятии №23 мы разберем критически важную тему: "Организация интерфейса с пользователем: ввод". Мы научимся строить надежные экранные формы, жестко сопряженные с атрибутами базы данных, разберем многоуровневую архитектуру, паттерны MVC и Data Binding, и поймем, как графические компоненты защищают реляционное хранилище от аномалий ввода.»
Действие студентов: Слушают преподавателя, настраивают рабочие места, открывают тетради и браузеры, записывают тему занятия в конспекты.
Прямая речь преподавателя:
«Прежде чем мы перейдем к графическим формам, давайте вспомним фундамент реляционной модели. Вопрос к аудитории: что гарантирует нам ограничение FOREIGN KEY на уровне СУБД, и что произойдет, если мы попытаемся вставить в дочернюю таблицу ID, которого нет в родительском справочнике?»
Ответ студента:
«Внешний ключ гарантирует ссылочную целостность. Если мы попытаемся вставить ID, отсутствующий в родительской таблице, СУБД выбросит ошибку нарушения внешнего ключа (foreign_key_violation) и прервет транзакцию.»
Прямая речь преподавателя:
«Верно. А теперь представьте рядового оператора приемного отделения больницы или менеджера по продажам. Знает ли он наизусть числовые первичные ключи наших клиентов — например, что у ООО "СеверТранс" идентификатор client_id = 482? Разумеется, нет! Человек оперирует названиями и фамилиями. Следовательно, перед нами встает фундаментальная задача: как в интерфейсе пользователя показать удобное читаемое имя, а в базу данных передать строгий числовой внешний ключ? Давайте разберем архитектуру, которая решает эту проблему.»
Действие преподавателя: Включает слайд 2 и 3 интерактивной презентации prezentaciya.html, демонстрирует многоуровневую архитектуру приложения и изоляцию уровней.
Прямая речь преподавателя:
«Запомните главное инженерное табу: ни при каких условиях графический интерфейс пользователя не должен выполнять прямые SQL-запросы в базу данных! Если кнопка "Сохранить" в клиентском коде на JavaScript или C# напрямую выполняет SELECT или INSERT, это грубейший архитектурный провал. Вы открываете дыру для SQL-инъекций и раскрываете учетные данные СУБД прямо в памяти клиентской машины.
Промышленная система строится по многоуровневой (N-tier) архитектуре:
1. Уровень представления (View): Экранная форма, где оператор нажимает кнопки и вводит текст.
2. Уровень бизнес-логики (Controller / Backend Service): Серверная часть, куда форма отправляет компактный пакет данных — DTO (Data Transfer Object). Здесь проверяются права доступа и запускаются транзакции.
3. Слой доступа к данным (DAO / ORM Repository): Модуль, который принимает объекты и транслирует их в параметризованный SQL.
4. Реляционная СУБД: Обеспечивает ACID-гарантии, проверяет декларативные ограничения и записывает данные на диск.
Для связи элементов формы со структурами данных используется концепция Data Binding (привязка данных). Она избавляет разработчика от необходимости вручную вычитывать значения каждого инпута — изменения автоматически синхронизируются с объектом DTO.»
Действие преподавателя: Переключает презентацию на слайды 6–9, последовательно анализируя элементы управления формы ввода.
Прямая речь преподавателя:
«Теперь обратимся к сопряжению графических элементов с колонками таблиц. Каждый элемент интерфейса обязан строго соответствовать семантике атрибута базы данных:
• Текстовое поле с маской (Masked Input): Применяется для строго форматированных строковых атрибутов — телефонов, номеров автомобилей, СНИЛС, паспортов. Маска физически блокирует ввод недопустимых символов (например, букв в поле телефона). В базу данных мы отправляем так называемое raw-значение — очищенную строку из 11 цифр, где в СУБД на нее наложен предикат CHECK.
• Выпадающий список (Combobox / Select): Тот самый инструмент для внешних ключей. У каждого элемента списка есть два свойства: Display Member (то, что видит человек: "Иванов Иван Иванович") и Value Member (то, что уходит в INSERT: doctor_id = 15). Если в справочнике более 100 строк — обычный выпадающий список заменяется на Autocomplete с поиском по серверу.
• Группа переключателей (RadioGroup): Идеальна для атрибутов типа ENUM или коротких списков CHECK (status IN (...)), когда вариантов от 2 до 5 (например, приоритет: Низкий, Средний, Высокий). Пользователь видит все опции сразу.
• Флажок (Checkbox): Напрямую сопрягается с реляционным типом BOOLEAN. Состояние checked конвертируется в TRUE или FALSE.
• Компонент выбора даты (DatePicker): Исключает ввод некорректных календарных значений (31 февраля или 13 месяц) и передает данные строго в формате стандарта ISO 8601 (YYYY-MM-DD), защищая нас от путаницы региональных настроек сервера СУБД.»
Действие преподавателя: Открывает слайды 10–11, объясняя компоновку Master-Detail.
Прямая речь преподавателя:
«Особое внимание уделим паттерну Master-Detail (Шапка — Табличная часть). Почти все корпоративные документы устроены по этому принципу: заказ и позиции заказа, путевой лист и маршрутные точки, госпитализация и процедуры. В реляционной базе это отношение 1:M (один ко многим).
В интерфейсе шапка документа содержит одиночные атрибуты (клиент, дата, склад), а табличная часть — динамическую сетку строк. Главная инженерная ловушка: ни в коем случае нельзя сохранять строки спецификации отдельными одиночными запросами! Если при сохранении третьей строки пропадет связь, в базе останется "битый" заказ. Вся форма Master-Detail должна собираться на клиенте в один JSON-объект и фиксироваться на бэкенде в единой неделимой транзакции BEGIN ... COMMIT!»
Действие преподавателя: Проецирует на экран макет формы заказа в оптовой CRM и демонстрирует пошаговую трансляцию данных формы в транзакционный SQL.
Прямая речь преподавателя:
«Посмотрите на экран. Перед нами экранная форма оформления оптовой накладной. В шапке оператор выбирает контрагента "ООО СеверТранс" из Combobox. В скрытом значении лежит client_id = 104. В поле "Склад" выбран "Склад №1" (warehouse_id = 1). Дата выбрана через DatePicker: 2026-10-01.
В табличную часть оператор добавил две строки: 5 бухт витой пары и 2 коммутатора. Сумма пересчиталась автоматически на клиенте через Two-Way Data Binding: 57 775 рублей.
Оператор нажимает "Провести заказ". Кнопка моментально переходит в состояние disabled, чтобы оператор не нажал ее дважды. На сервер уходит DTO, и серверный контроллер выполняет блок:»
BEGIN;
-- Вставка шапки заказа
INSERT INTO orders (client_id, warehouse_id, order_date, total_amount, status)
VALUES (104, 1, '2026-10-01', 57775.00, 'confirmed')
RETURNING order_id;
-- Вставка строк спецификации
INSERT INTO order_items (order_id, product_id, quantity, unit_price)
VALUES
(4812, 301, 5, 4500.00),
(4812, 814, 2, 17637.50);
COMMIT;
Прямая речь преподавателя:
«Если склад заблокирован ограничением CHECK или товара нет на складе, СУБД прерывает транзакцию, а бэкенд возвращает ошибку, которую интерфейс аккуратно подсветит оператору красной плашкой без потери введенных данных.»
Действие преподавателя: Инструктирует обучающихся по открытию интерактивного рабочего листа zanyatie.html, распределяет группу по 4 вариантам кейсов, контролирует выполнение.
Прямая речь преподавателя:
«Коллеги, открываем на ваших ПК интерактивный рабочий лист zanyatie.html. Обязательно введите свои ФИО и группу в верхней части. Распределение по вариантам:
• Вариант 1: Форма регистрации заказа в оптовой CRM (Master-Detail, выбор клиента из Combobox);
• Вариант 2: Экранная форма оформления путевого листа АТП (автомобиль, водитель, DatePicker выезда/возврата, одометр);
• Вариант 3: Форма госпитализации пациента в стационар (персональные данные, выбор врача, справочник диагнозов МКБ-10 с Autocomplete);
• Вариант 4: Форма заявки в IT Service Desk (радиокнопки приоритета Low/Medium/High, категория, ограничение длины описания, файлы).
Ваша задача: составить эскиз формы, сформировать матрицу маппинга полей на атрибуты БД с указанием типов данных и правил валидации, и ответить на вопросы самопроверки. Данные сохраняются автоматически в браузере. Приступайте, я готов ответить на индивидуальные вопросы.»
Действие студентов: Переходят к выполнению заданий своего варианта в рабочем листе, проектируют интерфейсные формы, заполняют матрицы маппинга, формулируют правила клиентской и серверной валидации.
Действие преподавателя: Проводит экспресс-разбор решений, открывает слайд 15 с комиксом Bobby Tables, подводит образовательные итоги.
Прямая речь преподавателя:
«Время вышло. Давайте взглянем на слайд 15 нашей презентации. Перед вами легендарный мем про "Little Bobby Tables". Мама назвала сына именем, содержащим SQL-инъекцию, и при внесении данных школьная база данных была полностью стерта.
Этот комикс — наглядное предостережение каждому проектировщику интерфейсов. Интерфейс ввода — это первая линия обороны базы данных. Если вы правильно выбрали компоненты, привязали выпадающие списки к внешним ключам, замаскировали ввод и изолировали слои через DTO и параметризованные запросы, никакая ошибка оператора и никакая инъекция не смогут нарушить целостность хранилища.
Работы оцениваются по 4-балльной критериальной шкале: правильность компоновки формы — до 2 баллов, корректность маппинга на атрибуты БД — 1 балл, эргономика и самопроверка — 1 балл.
Нажмите кнопку "Печать / Сохранить в PDF" в рабочем листе для отправки отчета. Обратите внимание: файл domashnee_zadanie.html является резервным дистанционным заданием — выполняйте его только в случае пропуска пары по уважительной причине или по индивидуальному назначению. Всем спасибо за продуктивную работу! Урок окончен.»
Действие студентов: Задают финальные вопросы, сохраняют рабочий лист в PDF, приводят рабочие места в порядок.