Рабочий лист: Реляционная модель данных: таблицы и ограничения

Индивидуальный практический лист студента СИЭУиП (ОП.08 Основы проектирования баз данных, занятие 07)

ФИО студента:

Учебная группа:

Выберите вариант практического задания:

Вариант 1: Складской комплекс

Предметная область: Складской распределительный центр ведет учет номенклатуры и фактического наличия товаров по ячейкам склада. Требуется спроектировать схему из двух таблиц: Товары (Products) и Складские_остатки (Inventory) с гарантией целостности сущности, внешним ключом на артикул товара и ограничением CHECK на неотрицательное количество.

Часть 1. Спецификация отношений и атрибутов (2 балла)

Заполните спецификацию полей родительской таблицы «Товары» и дочерней таблицы «Складские_остатки»:

Родительская таблица: Товары (Products)

Имя атрибута	Тип данных / Домен	Ключ (PK/None)	Ограничения (NOT NULL, CHECK...)

Дочерняя таблица: Складские_остатки (Inventory)

Имя атрибута	Тип данных / Домен	Ключ (PK/FK/None)	Ограничения (NOT NULL, CHECK...)

Часть 2. Первичные и внешние ключи (1 балл)

2.1. Какое правило поведения ссылочной целостности (ON DELETE RESTRICT или ON DELETE CASCADE) следует применить при удалении записи товара из таблицы Products? Обоснуйте выбор с точки зрения материальной ответственности и учета:

Часть 3. Ограничения целостности и самопроверка (1 балл)

3.1. Запишите точный синтаксис ограничения CHECK для атрибута quantity, гарантирующего отсутствие отрицательного складского остатка. Что вернет СУБД при попытке списания товара в минус?

3.2. Какое свойство истинного отношения нарушится, если для одного товара (sku) в одной и той же ячейке склада (warehouse_zone) разрешить создать две разные записи? Какое ограничение устраняет этот риск?

Вариант 2: Медицинская клиника

Предметная область: Медицинская информационная система регистрирует пациентов и выписанные им медикаментозные назначения. Требуется спроектировать связанные таблицы: Пациенты (Patients) и Назначения (Prescriptions). Внешний ключ на ID пациента, жесткий запрет NULL и предикат CHECK на терапевтический диапазон разовой дозировки лекарств.

Часть 1. Спецификация отношений и атрибутов (2 балла)

Родительская таблица: Пациенты (Patients)

Имя атрибута	Тип данных / Домен	Ключ (PK/None)	Ограничения (NOT NULL, CHECK...)

Дочерняя таблица: Назначения (Prescriptions)

Имя атрибута	Тип данных / Домен	Ключ (PK/FK/None)	Ограничения (NOT NULL, CHECK...)

Часть 2. Первичные и внешние ключи (1 балл)

2.1. Почему внешний ключ patient_id в таблице «Назначения» обязан иметь ограничение NOT NULL? К каким опасным клиническим последствиям приведет разрешение NULL в поле patient_id?

Часть 3. Ограничения целостности и самопроверка (1 балл)

3.1. Сформулируйте условие CHECK для атрибута dosage_mg с ограничением разовой дозы строго от 0.1 мг до 500.0 мг. Почему контроль дозировок должен выполняться именно на уровне СУБД, а не только в коде приложения медсестры?

3.2. Какое действие (RESTRICT или CASCADE) следует применить при удалении записи пациента, если в базе хранятся выписанные ему сильнодействующие препараты? Обоснуйте с позиции законодательства о хранении медицинских карт.

Вариант 3: Автосервис

Предметная область: Станция технического обслуживания ведет прием автомобилей и оформление актов дефектовки. Требуется спроектировать таблицы: Автомобили (Vehicles) и Акты_дефектовки (Inspection_Reports). Анализ естественного ключа VIN против суррогатного id_авто, обеспечение ссылочной целостности и ограничение уникальности.

Часть 1. Спецификация отношений и атрибутов (2 балла)

Родительская таблица: Автомобили (Vehicles)

Имя атрибута	Тип данных / Домен	Ключ (PK/None)	Ограничения (NOT NULL, CHECK...)

Дочерняя таблица: Акты_дефектовки (Inspection_Reports)

Имя атрибута	Тип данных / Домен	Ключ (PK/FK/None)	Ограничения (NOT NULL, CHECK...)

Часть 2. Первичные и внешние ключи (1 балл)

2.1. Сравните два варианта первичного ключа для автомобилей: естественный ключ VIN (строка CHAR(17)) против суррогатного vehicle_id (целое число INT). В чем преимущества суррогатного ключа при выполнении JOIN и при исправлении ошибок ввода оператором?

Часть 3. Ограничения целостности и самопроверка (1 балл)

3.1. Как ограничение UNIQUE для столбца vin защищает базу от дублирования карточек одного и того же автомобиля? Какое исключение выдаст ядро СУБД при попытке повторного ввода того же VIN?

3.2. Если клиент продал автомобиль, допустимо ли удалить запись из таблицы Vehicles? Какую опцию ON DELETE следует назначить для внешнего ключа в таблице Inspection_Reports?

Вариант 4: Онлайн-курсы

Предметная область: Образовательная онлайн-платформа фиксирует сдачу практических заданий студентами. Требуется спроектировать таблицы: Студенты (Students) и Сдача_заданий (Submissions). Внешний ключ на студента, составной альтернативный ключ (student_id + task_id) и ограничение CHECK на балл от 0 до 100.

Часть 1. Спецификация отношений и атрибутов (2 балла)

Родительская таблица: Студенты (Students)

Имя атрибута	Тип данных / Домен	Ключ (PK/None)	Ограничения (NOT NULL, CHECK...)

Дочерняя таблица: Сдача_заданий (Submissions)

Имя атрибута	Тип данных / Домен	Ключ (PK/FK/None)	Ограничения (NOT NULL, CHECK...)

Часть 2. Первичные и внешние ключи (1 балл)

2.1. Если студент повторно сдает то же самое задание, как ограничение UNIQUE (student_id, task_id) предотвратит появление дубликатов оценок? Как это связано с 1-м свойством истинных отношений?

Часть 3. Ограничения целостности и самопроверка (1 балл)

3.1. Сформулируйте точный предикат CHECK для проверки балла студента (score от 0 до 100 включительно). Почему проверка балла на фронтенде недостаточна?

3.2. Если студент отчисляется с платформы, какую политику ON DELETE логично применить к его сданным работам: CASCADE (полное удаление истории сдачи) или RESTRICT (запрет удаления профиля при наличии оценок в ведомости)? Обоснуйте выбор.

Данные успешно сохранены в браузере!