Развернутый сценарий занятия (Конспект)

Прямая речь преподавателя: «Здравствуйте, коллеги! Прошу занять свои рабочие места и включить компьютеры. Староста, подскажите, все ли присутствуют? Отлично.

Сегодня мы открываем ключевую практическую тему нашего курса: «Реляционная модель данных: таблицы и ограничения».
Большинство начинающих разработчиков уверены, что реляционная база данных — это просто набор табличек, похожих на файлы Excel. Это опаснейшее заблуждение! Если в Excel вы можете записать формулу в любую ячейку, вставить пустую строчку посреди списка или написать в графе «Возраст» слово «молодой», то в реляционной базе ядро СУБД жестко контролирует каждый байт по законам высшей математики.
Представьте складскую систему: если из-за ошибки в коде остаток товара на складе станет равен минус 15 штукам, а при удалении снятого с производства процессора из базы сотрутся все кассовые чеки за последние пять лет — предприятие понесет колоссальные убытки. Сегодня мы научимся проектировать реляционные таблицы так, чтобы сама база данных на уровне ядра физически отвергала любые некорректные действия.
Работаем по 4-балльной критериальной рубрике: 2 балла за проектирование схемы таблиц, 1 балл за ключи и правила ссылочной целостности, 1 балл за ограничения CHECK и самопроверку».

Прямая речь преподавателя: «Обратите внимание на экран — перед вами слайды презентации.

В 1970 году доктор Эдгар Франк Кодд, работая в корпорации IBM, совершил научную революцию. Он предложил реляционную модель, основанную на теории множеств и предикатной логике. Слово relation в переводе с английского означает «отношение». В математике отношением называется подмножество декартова произведения доменов. На прикладном уровне мы видим это отношение как двумерную таблицу.

Зафиксируем строгий терминологический мост:

• Отношение (Relation) — это таблица в SQL.
• Кортеж (Tuple) — это строка таблицы. Кортеж описывает конкретный единичный объект реального мира.
• Атрибут (Attribute) — это столбец или поле таблицы.
• Домен (Domain) — это множество всех допустимых значений атрибута. Например, домен «Количество товара» — это неотрицательные целые числа.

У каждого отношения есть две фундаментальные метрики:
Степень (арность) — это число атрибутов (столбцов). Если в таблице 4 столбца, отношение 4-арно. Эта характеристика постоянна при работе системы.
Кардинальность (мощность) — это число строк в таблице на данный момент времени. Это величина динамическая: добавили клиента — мощность выросла, удалили — уменьшилась.

Отношение обладает 4 фундаментальными свойствами:
1) Уникальность кортежей: в множестве не может быть двух одинаковых элементов. Каждая строка обязана быть уникальной, для чего служит Primary Key.
2) Отсутствие порядка строк: в реляционной теории нет понятия «первая строка». Порядок чтения с диска случаен. Если вам нужна сортировка, вы обязаны явно указать ORDER BY.
3) Отсутствие порядка столбцов: поля адресуются по именам, а не по порядковым номерам.
4) Атомарность значений (Первая нормальная форма — 1НФ): в каждой ячейке хранится строго одно скалярное неделимое значение. Никаких списков телефонов через запятую! Если у студента три телефона — создается отдельная связанная таблица.

Теперь перейдем к ограничениям целостности. В реляционной модели их три:
1. Целостность сущности (Entity Integrity): первичный ключ таблицы не может быть NULL и обязан быть строго уникальным.
2. Ссылочная целостность (Referential Integrity): внешний ключ (Foreign Key) дочерней таблицы обязан ссылаться на реально существующий первичный ключ родительской таблицы, либо быть NULL. Это исключает появление «висячих строк». В правилах ON DELETE мы используем:
• RESTRICT / NO ACTION — запретить удаление родителя, если есть дочерние строки;
• CASCADE — каскадно удалить всех потомков вместе с родителем;
• SET NULL — обнулить ссылку у потомков.
3. Семантическая / доменная целостность: правила предметной области, задаваемые через ограничение CHECK. Например: CHECK (quantity >= 0) или CHECK (score BETWEEN 0 AND 100).

Посмотрите на доску — вот классический скрипт связи таблицы "Товары" и таблицы "Складские_остатки" с ограничением CHECK и правилом RESTRICT. Есть ли вопросы по синтаксису и механике?».

Прямая речь преподавателя: «Перед тем как перейти к самостоятельному проектированию, взгляните на слайд 15. Это знаменитый мем xkcd №327 про маленького Бобби Таблицы — Роберта Дроп Тейбл Стьюдентс. Школа склеивала имя ученика строкой в запрос, и база данных стерла успеваемость за весь год! Это напоминание всем нам: строгая типизация и декларативные ограничения ядра СУБД спасают бизнес от катастроф.

Откройте в браузерах файл zanyatie.html. Введите вашу фамилию, имя и номер группы.
Каждый выбирает свой вариант:
• Вариант 1 (Складской комплекс): проектируем таблицы Товары и Складские_остатки. Внешний ключ на артикул товара, обязательный CHECK на неотрицательный остаток, запрет удаления товара при наличии остатков (RESTRICT).
• Вариант 2 (Медицинская клиника): таблицы Пациенты и Назначения. Внешний ключ на ID пациента, жесткий запрет NULL, предикат CHECK на терапевтический диапазон дозировки (от 0 до 500 мг).
• Вариант 3 (Автосервис): таблицы Автомобили и Акты_дефектовки. Сравниваем естественный ключ VIN и суррогатный id_авто, обеспечиваем уникальность и ссылочную целостность.
• Вариант 4 (Онлайн-курсы): таблицы Студенты и Сдача_заданий. Внешний ключ, ограничение CHECK на балльно-рейтинговую оценку строго от 0 до 100 баллов.

Ваши ответы автоматически сохраняются в браузере через LocalStorage. Приступайте к выполнению, я подхожу для индивидуальных консультаций».

Прямая речь преподавателя: «Время выполнения практической части подошло к концу. Давайте разберем характерные ошибки, которые встретились в работах.

Первая типовая ошибка: в третьем варианте некоторые попытались сделать внешний ключ на номер государственного регистрационного знака или модель авто, забыв, что модель не уникальна, а госномер может меняться при перевесе. Внешний ключ обязан ссылаться строго на первичный или уникальный ключ!
Вторая ошибка: использование ON DELETE CASCADE для складских остатков. Если менеджер случайно удалит позицию товара, база молча сотрет историю движения на складе! Запомните: для финансовых и товарных систем стандартом является ON DELETE RESTRICT.

Сверьте ваши результаты с 4-балльной рубрикой. Сохраните заполненный рабочий лист (кнопка "Сохранить") либо экспортируйте его в PDF через печать.

Инструктаж по домашнему заданию: файл domashnee_zadanie.html является резервным дистанционным заданием. Его выполняют только те обучающиеся, которые пропустили сегодняшнее занятие по уважительной причине либо получили персональное указание на доработку. Срок сдачи — до начала следующей пары.
Всем спасибо за продуктивную инженерную работу, занятие окончено!».

Прямая речь преподавателя: «Здравствуйте! Сегодня работаем в интенсивном 60-минутном регламенте. Тема занятия: «Реляционная модель данных: таблицы и ограничения».
Наша главная цель — освоить математические правила связи таблиц и научиться накладывать ограничения целостности (PRIMARY KEY, FOREIGN KEY, CHECK), защищающие базу от порчи данных при программных сбоях. Оценивание — 4 балла по критериальной рубрике».

Прямая речь преподавателя: «Внимание на экран. Реляционная модель Эдгара Кодда заменяет физические указатели табличными отношениями.
Запоминаем термины: таблица — это отношение, строка — это кортеж, столбец — атрибут, допустимые значения — домен.
Степень (арность) — число столбцов. Мощность (кардинальность) — число строк.
Главные правила:
1. Строки уникальны (обязателен Primary Key).
2. Значения атомарны (1-я нормальная форма — никаких списков через запятую в ячейке).
3. Ссылочная целостность: Foreign Key в дочерней таблице строго указывает на существующий Primary Key в родительской. Опция ON DELETE RESTRICT запрещает удаление родителя, если есть связанные строки. Опция ON DELETE CASCADE удаляет дочерние записи вслед за родителем.
4. Ограничение CHECK — предикат бизнес-правила (например, quantity >= 0). Ядро СУБД отвергнет транзакцию, если предикат ложен.
Посмотрите на DDL-код связи "Товары — Остатки". Все предельно логично и математически выверено».

Прямая речь преподавателя: «Открываем интерактивный рабочий лист zanyatie.html, вводим ФИО и группу, выбираем один из 4 вариантов:
• Вариант 1: Склад (Товары и Остатки, CHECK остатка ≥ 0).
• Вариант 2: Клиника (Пациенты и Назначения, CHECK дозировки ≤ 500 мг).
• Вариант 3: Автосервис (Автомобили и Дефектовка, естественный VIN vs ID).
• Вариант 4: Онлайн-курсы (Студенты и Сдача заданий, CHECK балла 0..100).
Ваша задача — спроектировать спецификацию полей, задать первичные и внешние ключи, прописать предикаты CHECK и обосновать правило ON DELETE. Работа сохраняется автоматически».

Прямая речь преподавателя: «Подводим итоги. Проверяем ключевые узлы: у всех ли внешний ключ ссылается на Primary Key? Нет ли висячих связей? Заданы ли проверки CHECK на неотрицательность?
Выставляем баллы по 4-балльной шкале рубрики. Напоминаю: файл domashnee_zadanie.html — это резервное задание строго для пропустивших очную пару. Сохраняйте свои работы в браузере. Спасибо за работу, до встречи!».